[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[WalterB]

@kcs123: I had no idea there were problems with CKAN. I will remove FAR and MFI and reinstall both manually.

@ferram4: Yes, I did leave out two pieces of information in my first post: The craft file contains parts from RT and PF and I did not fly it manually.

I set up the RT Flight Computer to point the rocket straight up (P:90, H:90, R:0), pressed the space bar to stage then immediately clicked the Custom button in the Flight Computer to lock in my settings. At some point I may have reduced throttle slightly to improve stability but I do not know at exactly what altitude or my velocity at that point. I staged after flame out, nothing unusual or different there. Once in space, I used the flight computer to point surface retrograde just prior to reentry.

I will create a clean install of KSP with only FAR and MFI along with RT and PF and will try again. I figure if I try to fly manually that will be much more difficult to reproduce.

Thanks

[ferram4]

No. I don't want any other mods involved for the basic test. I don't care how difficult it is to fly your rocket without them, for bug reporting, every single extra mod you add is an additional confounder. Unless the mod interaction is the actual source of the bug (which I seriously doubt) adding in more mods just makes things harder for me to deal with. Hence the request for "just FAR."

[kcs123]

OK, I have removed even GCMonitor and TemperatureGauge killer. Only FAR, module manager and ModularFlightIntegrator left.

Pictures are exactly same as shown here.

It is pointless to upload craft file, recreating one is simple and could be reproduced by looking at picture.

From nose to tail, place MK2 cockpit, MK2 Liquid fuel and MK2 bicoupler on tail.

Voxelization is still asymetic on MK2 bicoupler. Don't know if I can help with anything else.

[WalterB]

Ok, I started with a fresh install of KSP 1.0.2 and added in FAR (including MFI) and also RT and PF. Everything worked ok: the vehicle broke the sound barrier, reached space and reentered normally so looks like interaction with another mod might be the problem. I did not see your latest message until afterwards but RT and PF do not seem to be causing the problem. I will try with FAR only and if that works I will start adding in mods one at a time until something breaks then I will test with only that one mod plus FAR.

[allenby]

I'm getting voxel updates when I wouldn't expect them, namely when craft are in space or on airless bodies. Normally the bit of lag isn't an issue (i.e. when deploying antennas), but it does chug noticeably when doing EVA flights across moons (updates would happen every couple seconds or so). I don't know if voxel updates in space are a bug or maybe due to some kind of coding constraint, but if it's feasible to restrict them to when there's an atmosphere, it might cut down on some unnecessary lag.

Edited May 22, 2015 by allenby

[WalterB]

I launched a manned capsule in a clean install with only FAR, MFI and MM. I launched it straight up and let it fall straight back down. FAR continued to work after reentry and the capsule slowed down as expected. I copied the craft file to my main installation of KSP that has all the mods and I got the same results there too, no problems with FAR. It could be something about that first rocket I was testing with so I will go back to that one and see what happens. Need to stop for the day however so I will pick it up again sometime over the weekend.

[Volt]

Transient faults are always good fun. My suggestion as an engineer rather than a coder, in the case that you can't reproduce, would be to continue playing until you experience the bug again. As soon as you get the bug again, grab the output_log.txt from that session. That's more useful than repeated 'no luck' reports, even if it still has lots of confounders.

[Tarheel1999]

Transient faults are always good fun. My suggestion as an engineer rather than a coder, in the case that you can't reproduce, would be to continue playing until you experience the bug again. As soon as you get the bug again, grab the output_log.txt from that session. That's more useful than repeated 'no luck' reports, even if it still has lots of confounders.

Or better yet, when it happens pay careful attention to what was happening and try and reproduce it. In the moment, you have a much better chance of identifying what the problem is. Also a log is rarely a good substitute for specific steps on how to reproduce a bug.

[Volt]

True. It might be better to read the log yourself and try and work out what triggered it, maybe a single part or something you did.

[RyanRising]

Okay, fine, I switched to 32bit. The game crashes every half hour, but at least the atmosphere makes sense.

*grumble*. There IS no official 64-bit build, I wouldn't worry too much about the false bug reports. And I think that anybody who installs the 64-bit hack would know enough not to report the bug without reproducing it in 32-bit. Besides, the 64-bit hack is more stable than the official 64-bit version ever was. By now, it just seems like the compatibility checker is leftover code that isn't needed anymore. As it is, we're stuck with either a game that looks nice OR a game that plays nice. I feel like we should be able to have both if we really want to.

Edited May 23, 2015 by RyanRising
[COLOR="#F6F6F6"]This stuff[/COLOR]

[jrandom]

Looks like the helicopter blade from KAX isn't being voxelized properly. Or the creator of KAX hasn't correctly specified the collision mesh? I dunno. Anyhow, if there's no easy fix for this then I wouldn't worry about it, as I'm just playing with goofy ideas at the moment and don't normally use helicopter engines.

Javascript is disabled. View full album

[ferram4]

On the voxelization errors on certain parts: They're all the same issue, I just need to re-implement the fix from before I ported to 1.0. Already fixed in the dev build, everything should be fine.

@Everyone talking good bug report steps: The very best reproduction steps is a video recording (with annotations, hopefully, to make jumping around easier) of everything that led up to the bug. Because then, you don't need to figure out what the steps are, and we don't have to sit here screaming because you left out something I don't do / I do something you never do. Easy.

@RyanRising: All it takes is recompiling with all the lines that check Win64 in CompatibilityChecker removed. It's not difficult. Also, given that when win64 builds of KSP started they were unofficial hacks, with the same exact messy nightmare of bug reports and false information (seriously, the original "Win64 Hack Mod Compatibility Thread" said that a lot of mods were incompatible even though people were able to run them fine, sans crashing because win64), I see no reason to open myself up to more hell. Look at the bug reports now. Why would I put my workload more at the mercy of someone else's ability to figure out what's going on? Especially since all it takes is one modder to create a utility to make the hack for you, reduce it to "push button receive win64," and we're back to the same irritating mess. No thanks.

@jrandom: Collision mesh looks fine for the blades. I may need to look into adding an override to make sure those meshes aren't voxelized like I do for propellers on Firespitter stuff.

[sidfu]

ferram4

I was trying out the combat contract pack and found that when the mission spawns its vessels(only tested the one that spawns right at KSC). Far will tart throwin errors as it trys to figure out its aerodynamics. here u can see the error http://forum.kerbalspaceprogram.com/threads/116245-1-x-5dim-Military-Contract-Pack-v0-4-2015-05-3?p=1961165#post1961165

I have already did some trouble shooting on it. I rebuilt the ship and resaved it then added it back to mod didnt fix the error. Its easy to reproduce. Just accept the very first combat contrat. Before u even leave the contract building FAR will start throwing errors on the plane. Once u take control of the plane the errors stop, but in the 15-30sec to go from contract building to the plane will generate around 8k error messages.

Just seems like FAR dont like spawned in vechiles? Havent heard from 5dm about it yet he might move them farther from ksc to see if it will stop far from throwing errors.

[Wurst]

Hello, another new player here, first of all I would like to thank you for your hard work as the mod is amazing.

But I am also here to report a bug many others are experiencing, I have been trying all day to find the cause, installing and reinstalling, removing all mods other than FAR and starting many frustrating campaign games.

The bug doesn't seem to trigger until you leave the atmosphere (70.000m), as I am still pretty bad at the game I can't get a stable orbit, so many times sending stuff past 70,000 to have it reenter the atmosphere at a very shallow angle will cause atmospheric drag to disappear, leaving my command pod with a single parachute crashing into the ground at 1000-2000m/s speeds, or even getting a stable orbit as low as 30,000m above the ground.

After the bug occurs once, FAR seems to stop working correctly, there will be no atmosphere in any following launch, drag, Cl, Cd, terminal velocity and pretty much everything other than pressure and angles will be at N/A or 0.

The only fix is to restart the game and continue where you were before the bug occurred, but this is impossible in career hard mode.

None of my rockets are over 30 parts, I always detach something in the atmosphere and then again in orbit.

I hope any of this can help you solve the bug.

On another note, what happened to the parts suffering drag glowing red FAR had before?

[ferram4]

The entire log, not a single snippet. I have no idea if that's the initial cause or something else.

Also, for anyone interested, I threw what I know about the 0-drag issue on github. So if you're interested in progress or you can help, it would be appreciated.

[Bit Fiddler]

So what am I looking at exactly?

The text tells me small smooth curves are best but what is it I am seeing here...

There are some black horizontal lines, are these marking some critical point? or just an arbitrary scale? and how small and smooth do I need to be etc.

If all this is spelled out somewhere feel free to point me in the direction, as I would also like to know what all the other numbers and data this mod reports means as well. I guess just a basic delving into aerodynamic theory will answer most of those questions other than the specifics about this graph.

And on a side note; I was just reading some of the latest posts, and I see the one about asymetric voxel display... I have this issue as well. you can't really see it in this picture, but I was looking at it and trying to figure out the cause last night. I thought maybe I had just placed some parts crooked or something.

Edited May 23, 2015 by Bit Fiddler

[Crzyrndm]

Black Lines are for scale

Green Line is X-Section area at that location

Yellow Line is the 2nd derivative of X-Section area (rate of change of slope of the green line)

You want to minimise the magnitude of the yellow line, to do so you smooth bumps out of the green line. Yellow magnitude is proportional to the Wave Drag area the window tells you, and how small is "good" depends on how large your craft is (the ratio of area to wave drag area *may* be a fairly consistent measurement, but I don't have any number for that either)

Edited May 23, 2015 by Crzyrndm

[Bit Fiddler]

Ok, well I will have to go try some things as this craft maxes out at about Mach .9 until I get very high altitude. like say 20KM

I assume this is from the oscillations in the yellow line at the engine section?

Once I get it up to 25Km or so it will easily cruise at Mach 5+

which brings me to another point...

How do Air scoops work in KSP with FAR installed. I assume some work better at high speeds and or high altitudes, while other work better al low speeds etc. Does it hold true that the "area" is the altitude/speed factor. as in high area scoops will provide more air at high speeds and altitudes? yet also cause more drag? while the "Amount" is some multiplier of this area that determines the over all resource available? Thus 2 scoops with same Area but different amounts will be the same as far as drag goes but the one with a higher amount will give more air? While 2 with the same amount but differing areas will vary in that the higher area will multiply with the amount to get more air when it is thin, at the cost of more drag?

Edited May 23, 2015 by Bit Fiddler

[Crzyrndm]

Ok, well I will have to go try some things as this craft maxes out at about Mach .9 until I get very high altitude. like say 20KM

I assume this is from the oscillations in the yellow line at the engine section?

That's not going to be helped by the low sub/tran-sonic thrust of the rapiers. Get it up to 10-15km and then level off/dive slightly until you are above ~Mach 1.5. From there you may have to throttle back as the rapiers build up thrust

How do Air scoops work in KSP with FAR installed. I assume some work better at high speeds and or high altitudes, while other work better al low speeds etc. Does it hold true that the "area" is the altitude/speed factor. as in high area scoops will provide more air at high speeds and altitudes? yet also cause more drag? while the "Amount" is some multiplier of this area that determines the over all resource available? Thus 2 scoops with same Area but different amounts will be the same as far as drag goes but the one with a higher amount will give more air? While 2 with the same amount but differing areas will vary in that the higher area will multiply with the amount to get more air when it is thin, at the cost of more drag?

The same as always. Area governs the flow / second, amount is just temporary storage required by KSP's resource system to function. Area may not factor into FAR's drag calculations since it does everything off part geometry.

[Flashblade]

@ferram 4 about the 0 drag issue, I wonder whether there is anything for you to fix there at all. I kind of have the sneaking suspicion that people ran out of memory before re-entry and that is why there is no atmosphere drag when they enter it again, because FAR has no free memory to work with. The reload then frees up just enough memory for the atmosphere to work again although when I was running out of memory a reload would cause my game to crash, but I have read that on a linux machine a crash won't happen instead ksp would be just very very slow. Something to consider as a cause. I have no prove that this is so but a posibility that needs to be eliminated me thinks.

[kcs123]

When you reach memory limit near 3.5 GB, game will going CTD. I use GCMonitor all times to keep tracking when it is going to happen. On heavy moded game, each scene change KSC->SPH-FLIGHT->KSC or reloading quick save only add small amount of memory leak.

It is somewhere between 30 MB and 150 MB, depending on parts used for craft. With reloading, memory used always goes up, never lowering down, so reason behind is most probably something else.

EDIT:

I haven't expirienced that zero drag issue by myself, but I will certainly keep eye on that if that happens. To be able for ordinary user to detect problem with voxalization, is it possible to show those in flight ?

Just for debug purpose in dev version, until it is figured out real reason behind it. This one will probably cause serious FPS slowdown and it is not for regular usage, but for less expirienced people it could be a tool to detect that bug faster.

Edited May 23, 2015 by kcs123

[eddiew]

New CoL indicator in 15.2 is much closer to where my brain thinks it should be, thanks Ferram

[kcs123]

On the voxelization errors on certain parts: They're all the same issue, I just need to re-implement the fix from before I ported to 1.0. Already fixed in the dev build, everything should be fine.

Is that dev build updated ? I still see "76f8c87f37" commit authored 2 days ago, and voxelization errors are still in that build. Am I missed something obvious ?

[Bit Fiddler]

That's not going to be helped by the low sub/tran-sonic thrust of the rapiers. Get it up to 10-15km and then level off/dive slightly until you are above ~Mach 1.5. From there you may have to throttle back as the rapiers build up thrust

The same as always. Area governs the flow / second, amount is just temporary storage required by KSP's resource system to function. Area may not factor into FAR's drag calculations since it does everything off part geometry.

So then the only difference in any of the air scoops, no matter what the description seems to imply in their fancy talk, is the "Area" value? so basically just stack on as much "Area" as possible and ignore all the text that seems to imply aerodynamic differences at speeds or altitudes?

[Wanderfound]

So then the only difference in any of the air scoops, no matter what the description seems to imply in their fancy talk, is the "Area" value? so basically just stack on as much "Area" as possible and ignore all the text that seems to imply aerodynamic differences at speeds or altitudes?

No, there's a speed curve involved in the intakes air delivery. Can't remember exactly how it works, though. There are also differences in heat tolerance.

The simplest way to reduce the drag on your ship would be to get rid of the structural intakes at the back. You don't need them, and they're in the worst possible place for drag on that design. About 1.5 shock cone equivalents per engine is plenty.

Even with them in place, though, you shouldn't have trouble going supersonic if you just level off a bit at lower altitude. If you have Kerbal Flight Data or something else that shows engine thrust, try to climb at an angle such that your engine power slowly increases rather than decreases. Thrust is a function of speed and altitude; you want the increasing speed to just outweigh the increasing altitude.