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

[ferram4]

@CrisK: And I am telling you, no I cannot reproduce deploying/undeploying gear changing AoA, and the graphs that you are showing in the latest pictures are correct. I have been unable to create any vehicle that suffers from the issues you describe in the dev build. AFAICT, there are no issues to solve.

@123nick: Yes, and I believe them just as much as the people who were saying the original 0.23.5 win64 hack was stable. Those people downplayed and made excuses for any instability, blaming mods for all of it, and I know that the same will occur now. No win64 support from FAR until a confirmed-stable official win64 KSP build exists.

@Johnhii: It works perfectly fine assuming you follow the instructions in the message and place the mod directory in the correct place. That's why that message is there; to tell you how to make it work correctly.

@zomos: Read the first post; CKAN installs are not supported here thanks to frequent screwups on their part. Go complain to them, not me.

[cantab]

Does this mod work with steam on macs? I cant get it to work as there is a file in the folder that is not working with the my KSP. I tried removing all my other mods but still get this message.

You've got

(ksp folder)/GameData/GameData/FerramAerospaceResearch

and you *should* have

(ksp folder)/GameData/FerramAerospaceResearch

[123nick]

but you see, im using the ksp 64 unfixer, which makes all mods which disable themselves on 64-bit ksp to not disable themselves. it worked with FAR, and it worked when i flew a pre-built airplane. but when i tried building a new one, the center of lift didn't show up, i got arithmetic exceptions, and an out of index or array exception, or similar, and the calculate aoa button didn't work either.

[NathanKell]

So, let's review.

FAR doesn't support win64 because win64 is buggy.

So you used someone else's hack to get around that lock, and now you're claiming things are buggy?

Do you see the problem here?

[cantab]

but you see, im using the ksp 64 unfixer, which makes all mods which disable themselves on 64-bit ksp to not disable themselves. it worked with FAR, and it worked when i flew a pre-built airplane. but when i tried building a new one, the center of lift didn't show up, i got arithmetic exceptions, and an out of index or array exception, or similar, and the calculate aoa button didn't work either.

An excellent demonstration of why ferram doesn't support Windows 64-bit versions of KSP, and indeed why Squad stopped supporting it or even releasing it with 1.0.

[chrisl]

I originally posted this on the DRE forum thinking my heating issue was related to that mod. But with some assistance from Starwaster, it looks like the problem is actually with FAR. Here's what I'm experiencing. I'm playing with RO/RSS/RP0, all their respective required mods and most of their suggested mod (plus FASA). I recently upgraded from FAR 0.15.4.1 to 0.15.5. Prior to the upgrade, I had successfully launch and recovered 6 Mercury Atlas rockets. After upgrading to 0.15.5, however, I launched a 7th and have been experiencing issues during recovery. Reentry seems to be going initially fine. Skin temp will slowly increase from space to around 1600 at 62km (speed: 7km/s, vert speed: -238m/s, 2.1375g). At this point, skin temp starts to slowly drop until its down to under 1350 at just over 50.5km (speed: 5.6km/s, vert speed: -305m/s, 5.1374g). But as soon as I hit 50.5km, skin temp immediately jumps back up to over 1950 and begins climbing. Without the "Ignore Max Temperature" cheat turned on, the Mercury capsule explodes moments after falling below 50.5km do to overheating. With the cheat turned on, skin temp continues to climb until it peaks at about 2550 at 45.6km. Obviously, the issue is this phantom +600 in skin temp that seems to be added as soon as I hit 50.5km.

If I remove FAR and reinstall the older 0.15.4.1 version (and Starwaster was using 0.15.3 which worked for him), then reload the exact same save that resulted in the failed reentry above, the reentry works just fine. The Mercury pods skin temp slowly increases to just shy of 1700 but that doesn't happen until I'm already below 15.5km. And when skin temp starts to fall, it never has any sudden increase and makes it all the way down to the ground. I don't know enough about modding to have the first clue as to what changed between 0.15.4.1 and 0.15.5 that might be causing this strange heating issue, but I wanted to report it so it can be investigated.

[zomos]

You say the FAR is unsupported when downloaded from CKAN. I got rid of FAR installed with CKAN. Downloaded the FAR "Haack" and installed it manually. Nothing has changed. The plane gets rip apart due too aerodynamic stress for no reason, randomly during flight. Sometimes at 40km sometimes at start. I made a 3 videos of this happening. A lot of FAR null reference errors. Sometimes it drops a few parts... I even removed the thermalnuclear jets cause I thought they can be the reason... at 40 km the plane ripped apart and dropped the gears at lift off... I flew it gently.

With last FAR about 3 weeks ago when i played it was ok...

without thermalnuclear engine rips at ~40km...

Every single plane rips apart at some point...

EDIT:

Most of my planes use the OPT parts such engines. Removed the OPT ScramJet Engine and no log issues. Also no problem with catastrophic failures at flight. How to make the OPT Space Plane parts repaired ?

Edited September 6, 2015 by zomos

[zomos]

Some nasty thing happen when i put the OPT TurboRamJet on a plane... Even at runaway when standing there are multiple errors... While flying no matter using the OPT engine or not. At some random point your plane will be broken to pieces... Without the part everything is ok...

http://forum.kerbalspaceprogram.com/threads/97525-1-0-4-WIP-OPT-Space-Plane-v1-7?p=2181308&viewfull=1#post2181308

[CrisK]

Ferram, I'm not sure what I can do to convince you. Here's a series of screenshots.

Plane A. I can raise and lower the landing gear and the AoA chart is the same. I can load the file, raise and lower the landing gear, and the chart remains consistent.

Plane B. This is the exact same body and wings. The bug has occurred, god knows why. The body is identical in every way other than BDArmory missiles being added.

Now if I reload plane A I get this:

Again, that's the same craft file. Then every time I raise and lower the gear I get a different graph.

Now if I load craft C, a completely different design, the same graph shows.

Here is craft C's graph when the bug is NOT occurring. I can raise and lower the landing gear all day, reload the craft, etc. and the analysis remains consistent:

[123nick]

An excellent demonstration of why ferram doesn't support Windows 64-bit versions of KSP, and indeed why Squad stopped supporting it or even releasing it with 1.0.

you know, i think your right. i should probably just dualboot linux, run ksp 64bit on that, and then play ksp 64bit with all the cool mods.

[Wjolcz]

Can someone tell me how to change the speed from m/s to km/h?

[ferram4]

@zomos: 1) OPT does not appear to have any nuclear thermal jet parts, so until you tell me which mod includes that, I can't hope to test what's up with that part.

2) The remaining OPT parts show no issues and I could not reproduce any errors with them.

Your reproduction steps are incomplete; provide more complete steps and a problem craft file with no extra mod parts.

@CrisK: Here's what you can do: provide reproduction steps that function. Absolutely none of yours have. I covered a plane in BDArmory missles seeking differences after loading and the only difference I found is that I had added enough missiles for them to interfere with the lift on the wing they were mounted under; other than that, nothing. Provide your craft files with every non-necessary mod part removed, and complete and exact reproduction steps. As of right now, I haven't managed to reproduce anything that indicates that there is an issue.

@Veeltch: FAR GUI in flight -> Settings -> Dropdown -> AirSpeed Settings

[zomos]

@ferram4: Maybe I spoke unclear sorry. Problem is with OPT TurboRamJet. Not tried other OPT parts with FAR "Haack" yet. Thermalnuclear is other mod I thought was causing the issue(beta version). Other engines than OPT, stock or mods work good and I do not get random catastrophic failures in-flight.... OPT TurboRamJet causes the problem even when it is not working. It is needed to only have OPT TurboRamJet attached and I get plane broken in multiple parts at random time. I will try to make logs next time i will play. When I have OPT TurboRamJet attached to any ship I see in log(game F2 log, KSP.log) a lot of FAR null reference errors or argument out of range errors.

Craft I built and disintegrates for me a lot:

http://kerbalx.com/zomos/Passanger-SSTO---tst

I think I need to disable the FAR aero failures...

Edited September 6, 2015 by zomos

[cantab]

Been having troubles with engines counted as occluded, seemingly randomly sometimes but not always when I go to the ship.

Any workarounds for this, like a way to make engines activate and thrust ignoring that they're supposedly blocked?

[ferram4]

@zomos: Well, if it's supposed to be the turboramjet that's the problem, it certainly doesn't seem to be. Can't cause any issues with it. I'd suspect problems with something else breaking and then causing FAR to break once everything else is broken.

@cantab: If they're occluded, there are two options: A) main axis error somewhere, but that should be fixed with being occluded when they shouldn't be in the next update. they actually are completely occluded, in which case, intended behavior.

[CrisK]

@ferram4, Okay, here are a couple of bugged craft files.

Craft A: This craft sometimes loads with a Mach 1 wave drag area of 0 m^2. The only mod is b9 wings. The analysis lines do not display at all. To be 100% perfectly clear so that there is zero confusion, here is a screenshot:

Sometimes the AoA displays properly, other times it displays the same chart that I already posted with the AoA capped at roughly 20.

Steps to reproduce: load this craft file. Load ANY OTHER craft file in the SPH afterwards. The analysis for the other crafts will also be bugged. You can also raise/lower the landing gear (there is none) and the static analysis and transonic design numbers will change. Again, there is no landing gear.

Craft B. This craft sometimes loads correctly, other times the AoA is capped at 20. Steps to reproduce: change the root. Load any other craft in the SPH. Load this craft again. Raising and lowering the (non-existent) landing gear causes the analysis numbers to change.

Sometimes you see this:

Other times you see this (AoA capped at 20):

I can provide more examples if they would be helpful.

[ferram4]

@CrisK: I can reproduce the craft second craft, which I see is a main axis error; I'll look to add something to make it more consistent. Not sure why it's affecting the wings though, but the stall at 20 degrees AoA is correct. Even highly swept delta wings stall at 30-35 degrees, they don't maintain it to 45 degrees, that's just wrong.

I can't reproduce any errors with the first craft. "sometimes" is a cop-out reproduction step; you did something different when it loaded broken, what was it?

Edit: if this can't be reproduced without pWings, then it's likely a pWings issue and I can't fix anything then. So far I've seen no indication that stock wings show behavior like this, so it's likely a pWings issue then.

Edited September 7, 2015 by ferram4

[CrisK]

@CrisK: I can reproduce the craft second craft, which I see is a main axis error; I'll look to add something to make it more consistent. Not sure why it's affecting the wings though, but the stall at 20 degrees AoA is correct. Even highly swept delta wings stall at 30-35 degrees, they don't maintain it to 45 degrees, that's just wrong.

I can't reproduce any errors with the first craft. "sometimes" is a cop-out reproduction step; you did something different when it loaded broken, what was it?

Edit: if this can't be reproduced without pWings, then it's likely a pWings issue and I can't fix anything then. So far I've seen no indication that stock wings show behavior like this, so it's likely a pWings issue then.

I agree with you that it's a b9 wings issue and not a FAR issue.

I did not do anything different with the first craft when it loaded broken. I opened KSP, loaded the craft, and opened the FAR screen.

Out of curiosity, I flew two versions of the exact same craft file. They both flew differently: one stalled properly at an AoA of 30 degrees, one didn't stall until 65 degrees (based on the FAR flight data screen). Same craft file.

I'm trying to be helpful by reporting this. I feel a little bit as though you and others in the thread have jumped on me for daring to report a bug. My intention is to be helpful and contribute to a great mod, not to criticize your work.

[ferram4]

I understand that you're trying to be helpful, but the problem with any report that includes "I did the absolute same thing and got different results" is that since computers are deterministic, that can't happen in this situation. If this involved multithreading here, I'd see, but this particular situation doesn't, which means that some step is missing. Unfortunately, nearly every bug report that I can't reproduce always involves people leaving out the crucial step in causing it, which puts fixing the bug off for over a month in some cases. It's incredibly frustrating for everyone, which is why I keep asking about that because there has to be something different if I can't reproduce it.

Okay, so I made some changes that makes the second plane consistent; although I think it's wrong, apparently my code reports that the stall-at-45-degrees solution is correct (this hints at some errors in the large-sweep lift calculations though, but that's for another fix down the road). The other one, no idea, can't reproduce it.

I hope you'll understand if I don't follow up much more on these issues; both look like bugs that run into the legacy wing code, which is slated to be replaced for the next big FAR release, so more time wasted on that means more time until awesome good wing code. Thanks for the report, at least it's consistent again.

Anyway, v0.15.5.1 Hayes is out, which has some very nice bugfixes, changelog knows all.

[linuxgurugamer]

Just want to say thank you for such a great mod.

[CrisK]

I understand that you're trying to be helpful, but the problem with any report that includes "I did the absolute same thing and got different results" is that since computers are deterministic, that can't happen in this situation. If this involved multithreading here, I'd see, but this particular situation doesn't, which means that some step is missing. Unfortunately, nearly every bug report that I can't reproduce always involves people leaving out the crucial step in causing it, which puts fixing the bug off for over a month in some cases. It's incredibly frustrating for everyone, which is why I keep asking about that because there has to be something different if I can't reproduce it.

Okay, so I made some changes that makes the second plane consistent; although I think it's wrong, apparently my code reports that the stall-at-45-degrees solution is correct (this hints at some errors in the large-sweep lift calculations though, but that's for another fix down the road). The other one, no idea, can't reproduce it.

I hope you'll understand if I don't follow up much more on these issues; both look like bugs that run into the legacy wing code, which is slated to be replaced for the next big FAR release, so more time wasted on that means more time until awesome good wing code. Thanks for the report, at least it's consistent again.

Anyway, v0.15.5.1 Hayes is out, which has some very nice bugfixes, changelog knows all.

In the future, I'll snap a video of any bugs that I find, post it privately on YouTube, and direct message it to you.

Thank you for giving my bug report the attention that you did, and for continuing to develop FAR!

[chrisl]

I originally posted this on the DRE forum thinking my heating issue was related to that mod. But with some assistance from Starwaster, it looks like the problem is actually with FAR. Here's what I'm experiencing. I'm playing with RO/RSS/RP0, all their respective required mods and most of their suggested mod (plus FASA). I recently upgraded from FAR 0.15.4.1 to 0.15.5. Prior to the upgrade, I had successfully launch and recovered 6 Mercury Atlas rockets. After upgrading to 0.15.5, however, I launched a 7th and have been experiencing issues during recovery. Reentry seems to be going initially fine. Skin temp will slowly increase from space to around 1600 at 62km (speed: 7km/s, vert speed: -238m/s, 2.1375g). At this point, skin temp starts to slowly drop until its down to under 1350 at just over 50.5km (speed: 5.6km/s, vert speed: -305m/s, 5.1374g). But as soon as I hit 50.5km, skin temp immediately jumps back up to over 1950 and begins climbing. Without the "Ignore Max Temperature" cheat turned on, the Mercury capsule explodes moments after falling below 50.5km do to overheating. With the cheat turned on, skin temp continues to climb until it peaks at about 2550 at 45.6km. Obviously, the issue is this phantom +600 in skin temp that seems to be added as soon as I hit 50.5km.

If I remove FAR and reinstall the older 0.15.4.1 version (and Starwaster was using 0.15.3 which worked for him), then reload the exact same save that resulted in the failed reentry above, the reentry works just fine. The Mercury pods skin temp slowly increases to just shy of 1700 but that doesn't happen until I'm already below 15.5km. And when skin temp starts to fall, it never has any sudden increase and makes it all the way down to the ground. I don't know enough about modding to have the first clue as to what changed between 0.15.4.1 and 0.15.5 that might be causing this strange heating issue, but I wanted to report it so it can be investigated.

Just wanted to report that 0.15.5.1 seems to resolve the issue I reported.

[p1t1o]

Hi All,

Im not sure if Im experienceing a bug or just seeing physics at work, I assume its the latter, but...

So basically I can't really get any benefit out of fairings at all, every rocket I build has worse characteristic with a fairing deployed.

At first I thought, well, my fairings are usually quite wide, wider than the payload, that thing must be draggy, but it happens for every craft. Yesterday I launched a probe with the M700 survey dish (+solar panels, orbital telescope, RTantenna+some other science experiments) on top unprotected, perfectly stable without a fairing, needs 8 fins to stabilise with the fairing (fairing just wide enough to enclose the folded M700 dish). In fact, any rocket I build with a fairing needs a complex rosette of fins at the base to keep from tumbling.

The change in stability is reflected both in the stock CoM/CoL behaviour, and also in the FAR static analysis tools. FAR also shows base drag is much higher with a fairing as well.

So I have started just ignoring fairings and launching unprotected, messy payloads without them, and I get better performance and better handling.

I take it fairings are supposed to be significant and not just window dressing, so am I just designing the worlds most streamlined spacecraft or is something awry? I'd really like them to be useful, everyone loves that part where you jettison the fairing! Ptshhhhhhhh!

Next time I have a craft that demonstrates it well, I can take some screenies, if there is any other information that could help let me know and I'll see what I can do.

Its almost like my payloads have no aerodynamic presence at all...and that fairings have a ridiculous aerodynamic cross section...thats what it feels like.

Am I missing something obvious? Does it sound like there is something wrong? Are there any mods that are known to mess with fairings or that could otherwise exhibit an effect like this?

(I have been in KSP for years - has it been years? - I know all the basics, lift, drag, fins, atmosphere, dV, gravity turns, pressure, all that stuff, I don't think Im making basic mistakes, Im not trying to blast through the atmosphere at 10Gs or anything)

Thanks!

**edit**

Uhh..I just realised this might not be the best thread to post this in, if it isn't FAR causing it (if it is even a thing that is being caused at all)

Edited September 7, 2015 by p1t1o

[ferram4]

If you're throwing on the smallest, most blunt fairing you can, yes, the payload might be more streamlined, especially if it's a typical KSP payload, since then what you're putting in a fairing doesn't really need the fairing. If you're making a longer, more smoothed out fairing, especially one that isn't significantly wider than the vehicle, then you won't get more drag. If your fairing's radius is twice that of the rest of the rocket (read: you made the stock fairing as wide as you could), you're talking about taking up 4x the area of the rest of the rocket cross-section, which should be a sign that your fairing design is silly and will produce a lot of drag at transonic and supersonic speeds.

Finally, stability is not a sign that the fairing is poor at it's job. Its job is to reduce drag and to protect the payload; the engines have enough control authority to keep the rocket on course with thrust vectoring. Extra stability is nice, but a properly designed fairing will probably produce more body lift than the payload will and make the rocket less stable.

I guess I'll have to add some extra code to make unstreamlined payloads really come apart at high speeds then just to make things absolutely sure.

Pictures are helpful. Pictures tell us if you're doing something reasonable and that there's a bug or if you're doing something really silly.

[Drew Kerman]

I know that Roverdude has stated there is no FAR support for his Sounding Rockets mod, but with the recent FAR versions the only thing that should require specific configs are the rocket fins correct? Because I have this rocket that keeps flipping after takeoff, and it seems to have a high amount of cl and cd on its nose immediately when it launches:

Here is the full raw launch video:

Also as soon as I launch I'm way off my prograde vector for some reason. This is a ballistic rocket, I'm using these FAR configs for the fins, they are pitched 1.5 degrees I was hoping to get some spin going but that didn't work either.

When I remove FAR, the rocket flies a proper parabolic arc and does not flip.

output_log after a launch (not the original, but the same thing happens every time I launch).

Also, I recall now that when I first flew this rocket design in 0.90 once before upgrading to 1.0.4, the rocket flew fine with FAR installed. In fact when I took the same craft file from my 0.90 game into 1.0.4 it flipped out, despite the 0.90 version flying fine (albeit unsuccessfully in arcing high enough). I completely forgot to go back and confirm if it was a FAR issue - I was still getting my 1.0.4 install set up and at that time it could have been any number of things causing the rocket to be unstable.