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

[Volt]

Repost this to the FAR design thread (http://forum.kerbalspaceprogram.com/threads/121176-Official-FAR-Craft-Repository) and there are a bunch of people who would be happy to help you out.

You know I had no idea that existed. I'll post next time I get a chance to get on the PC. Thanks!

[Wanderfound]

Where can I download the dev build then? Is it in github?

Yes, Github. Be aware that the dev build is a work in progress; there will likely be bugs, and don’t expect all the bugs to be fixed until it hits the official release.

[kcs123]

You're not getting a voxelization debug display in flight because there's nothing to display. The voxel is destroyed within ms of it being created because it's not needed, the debug display is laggy as all hell, and all indications at this point are that that isn't the problem, because none of the reports of aero breaking have been accompanied by reports of log spam, which would happen if the voxel wasn't being built.

Given the fact that the "accepted" reproduction steps seem to be, "play a bit, it'll happen eventually" and that no one ever posts the logs right after they manage that that the true cause is probably never going to be determined; I'm just going to continue fusing with some possible errors and magically hit it and no one will ever know the true cause.

My thoughts behind it was that craft was having some loose joints while still in space, FAR voxelized it and remember it like hollow hull due to loose joints between parts.

Due to this and FPS slowdowns caused by other mods, mostly animations that forces FAR voxelization, maybe it wil lbe good idea that FAR disable voxelization while craft is in space, and force voxelization once again, as soon as craft enter atmosphere.

Don't know if it is realy a case, just throwing ideas what could be possible reasons behind it.

Another question, though, how FAR recognize landing gears as landing gears ? Asking beacause Adjustable landing gears could not be toggled like stock ones can, trough FAR SPH/VAB user interface.

Is it possible to add missing info trough MM config, or something else is needed to tell FAR what API function to call when landing gears need to be toggled.

Probably landing gears from other mods could suffer from this anoying bug if does not tell properly to FAR what is needed to do.

[Shaman]

Sorry, I didn't mean to come off as complaining. I know you guys put a lot of work and effort into this so please don't think I'm not appreciative. It gets kind of confusing when you use the CoL and CoM indicators and then you are no longer suppose to use it. It also doesn't help when there are post depicting the same indicators and how they should be used for design.

Someone new to this mod, like me, may not realize that you should use the graph now instead of the indicators. I also read through your wiki and nothing about disregarding the CoL indicator is in there. In fact, it says to click the "Update CoL" button which I guess is no longer in the mod.

"Update CoLBecause FAR overrides the stock game's aerodynamics, it also needs to override the code that draws the "Center of Lift" (CoL) indicator, which indicates the Center of Lift, or Neutral Point, of the aircraft. Sometimes, however, the game still draws this indicator as if the stock aerodynamics were in effect. If this happens, users can click the "Update CoL" button to redraw the indicator with FAR aerodynamics."

[tetryds]

For once I am here to ask for building advice! I've been studying subsonic and transonic flight but I still don't know nearly all I want to. I have a problem with my current aircraft; even after tuckunder, coming up as high as Mach 2 (I lost pitch control at that point) it continually gains more and more of a pitch-down tendency, eventually becoming too much to handle. What could be causing that? I was under the impression the major factor in loss of pitch control was only really a problem between Mach crit and just after Mach 1?

Edit: Could it be crzyrndm's dynamic deflection? So the pitch-down tendency is staying the same, but the pitch authority allowed for my all-moving tail is getting too small to handle it?

The faster you go, the more your aerodynamic center moves back, and the less lift you get, your pitch down tendency and pitch stability increases, your control and roll and yaw stability decreases.

[hahawin]

Is it ok if I post bug reports on the most recent dev built here, or does ferram4 not like getting bug reports for dev versions mixed in with those on releases?

[blowfish]

Is it ok if I post bug reports on the most recent dev built here, or does ferram4 not like getting bug reports for dev versions mixed in with those on releases?

You can post bug reports here, but make sure you're thorough about it (as with anywhere). Provide full, reliable reproduction steps. If it requires a certain craft, make sure that craft has no mods (or as few mods as possible at the very least). And probably post your output_log.txt just for good measure.

[ArcFurnace]

Also, specify which dev build you're using, by version number or similar - "most recent" works at the time you post it, but it's possible that Ferram could push another update before he sees your report, in which case confusion might result if you don't clearly specify the version.

[B15HOP_xmen]

See http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 for how to find the logs that are needed.

The zero drag thing is a known bug. Unfortunately, it's hard to squash because it's transient.; it only happens occasionally. If you can find some method of reliably causing the bug to occur, then reporting that here would be helpful (but please follow the steps outlined in the link above if you do so).

KSP: 1.02 Windows 32bit (Win7 OS is x64 bit)

Problem: Re-entry has no drag on craft, eventually crashing into kerbin at crazy speeds.

Mods installed:

Ferram Aerospace Research "Ferri"

Kerbal Engineer Redux 1.0.16.6

Reproduction steps:

All I did was start career mode on normal difficulty. After about a few hours into playing and going back to the launch a couple of times as well as reverting back to construction a few times as well. Once I got into space at about 80km, I got up to about 1300 m/s and then started coming back down. But the problem was that I kept going faster and faster as if there was no drag. Eventaully crashing at 1612m/s (surface speed) into Kerbin.

Log:

Here is a file from dropbox: https://www.dropbox.com/s/ribuduachcqekoe/output_log.txt?dl=0

But first I want to verify that I reproduced this with Far and here is another screenshot.

I only use 32bit and on win7 and win8.2 - (Both OS are x64 bit) Shame because both of my machines have 16GB of ram.

Hope this helps.

EDIT: HEh While in KSP I tried it one more time and then the game crashed.

Edited May 28, 2015 by B15HOP_xmen

[hahawin]

So while the dev build seems to have fixed the issue with the mk II cargobay and bicoupler not voxelizing properly, a new issue seems to have popped up. When attaching identical fuel tanks to each other, the cross section graph is no longer smooth as in previous versions, it flucuates around the attachment points.

I made some images clarifying the issue:

[spoiler=]

FAR 15.2, everything looks normal:

Same craft, dev build:

Note how not only the cross section curve has changed, the wave drag area is also significantly different.

The problem isn't restriced to mk2 parts either, its happening on all tanks I've tested:

[spoiler=]

Mk3, dev build:

Adding wings also seems to do something strange, the entire shape of the graph is affected by them:

[spoiler=]

Images were taken on a clean install of ksp 1.0.2 with no mods other than FAR, MM and MFI using FAR 15.2 and the latest dev build (commit 8ba2f4f in the git repo).

Reproduction steps are fairly straightforward: just slap a few fuel tanks together and enable the cross-section curve.

EDIT: Log file can be found here: http://pastebin.com/2GmmcZGv

Edited May 28, 2015 by hahawin

[ferram4]

@B15HOP_xmen: You and I both know that those reproduction steps are basically a lot of fluff immediately followed by, "and then it randomly breaks." Also, your log states that you have JSI installed and probably some other mods, and those are throwing exceptions. I can't tell if those are related to the issue or not, but given that the only time things break there are a ton of exceptions from JSI, I have to assume that it's implicated somehow. And since it's breaking, there's nothing I can do to fix it, because not my code.

Come up with the reproduction steps that actually reproduced the bug, sans the hours of pointless messing around and only what actually caused the final issue. Again, actual reproduction steps.

@hahawin: Your reproduction steps aren't. The issue does not occur, regardless of what fuel tanks I use or in what configuration, using the latest dev build. In addition, the minor changes when attaching wings are a result of the voxel resolution needing to change, and there's nothing I can do to fix that unless you want the game to crash constantly from too much memory usage and make voxelization take minutes.

Edit: I have re-found a gif explaining my frustrations:

Edited May 28, 2015 by ferram4

[Bushi]

So while the dev build seems to have fixed the issue with the mk II cargobay and bicoupler not voxelizing properly, a new issue seems to have popped up. When attaching identical fuel tanks to each other, the cross section graph is no longer smooth as in previous versions, it flucuates around the attachment points.

I made some images clarifying the issue:

[spoiler=]

FAR 15.2, everything looks normal:

http://i.imgur.com/veIT1NH.png

Same craft, dev build:

http://i.imgur.com/1JXvzGb.png

Note how not only the cross section curve has changed, the wave drag area is also significantly different.

The problem isn't restriced to mk2 parts either, its happening on all tanks I've tested:

[spoiler=]

Mk3, dev build:

http://i.imgur.com/K69p4Fh.png

Adding wings also seems to do something strange, the entire shape of the graph is affected by them:

[spoiler=]

http://i.imgur.com/EGVcqCH.png

Images were taken on a clean install of ksp 1.0.2 with no mods other than FAR, MM and MFI using FAR 15.2 and the latest dev build (commit 8ba2f4f in the git repo).

Reproduction steps are fairly straightforward: just slap a few fuel tanks together and enable the cross-section curve.

EDIT: Log file can be found here: http://pastebin.com/2GmmcZGv

Just wanted to confirm I am also getting this bug so you aren't alone. Unlike you, I have a bunch of mods installed but I am using the latest available github dev build. I even deleted the ferram folder and reinstalled fresh just incase something got messed up when I installed the newest version the first time. It seems to voxel in between the parts (and possibly inside accounting for the really low cross section area?). Attached is a picture of the voxels from inside one of the fuel tanks of a simple ship consisting of a mk2 pod and two liquid mk2 tanks.

[spoiler=]

Edited May 28, 2015 by Bushi

[thaflya]

Oh, ferram4 is fighting a hard war here. Hang on.

[Ravien]

Is there any way to make part transparent to FAR?

[B15HOP_xmen]

@B15HOP_xmen: You and I both know that those reproduction steps are basically a lot of fluff immediately followed by, "and then it randomly breaks." Also, your log states that you have JSI installed and probably some other mods, and those are throwing exceptions. I can't tell if those are related to the issue or not, but given that the only time things break there are a ton of exceptions from JSI, I have to assume that it's implicated somehow. And since it's breaking, there's nothing I can do to fix it, because not my code.

Come up with the reproduction steps that actually reproduced the bug, sans the hours of pointless messing around and only what actually caused the final issue. Again, actual reproduction steps.

@hahawin: Your reproduction steps aren't. The issue does not occur, regardless of what fuel tanks I use or in what configuration, using the latest dev build. In addition, the minor changes when attaching wings are a result of the voxel resolution needing to change, and there's nothing I can do to fix that unless you want the game to crash constantly from too much memory usage and make voxelization take minutes.

Edit: I have re-found a gif explaining my frustrations:

http://cdn2.edgement.com/wp-content/uploads/2015/05/Cant-reproduct-bug.gif

I'm not sure what the JSA mod is. But here is another output log from my other machine which has a fresh install of KSP with just Redux and Ferram. Same bug.

https://www.dropbox.com/s/ribuduachcqekoe/output_log.txt?dl=0

And a pic of the Gamedata folder:

Fresh career mode, normal difficulty, built a basic rocket that got me above 70km and then re-entry fails to allow drag.

By JSA do you mean this MOD:

http://forum.kerbalspaceprogram.com/threads/117471-1-0-RasterPropMonitor-still-putting-the-A-in-IVA

Because that mod was broken so I thought I had removed it. :/

Edited May 28, 2015 by B15HOP_xmen

[kcs123]

Edit: I have re-found a gif explaining my frustrations:

http://cdn2.edgement.com/wp-content/uploads/2015/05/Cant-reproduct-bug.gif

And I have recalled of old link describing

Six Stages of Debugging

That is something to cheer you up. All software developers pass trough those stages sooner or later.

While we all wait to reach step No.5. it will be good just to put it in "Known issues" part and provide "lame" workaround: save and reload game before making re-entry, because kraken may came nearby and push your craft hard into surface.

Not realy a fix, but, when users are aware that such thing can happen there will be less complains about it each day, until it is properly fixed, usualy while working on something completely irrelevant to this bug.

[ferram4]

@Bushi: And once again, I cannot reproduce the issue. You had better be able to provide good reproduction steps that will work for me if you're gonna go and confirm an issue that doesn't exist.

@B15HOP_xmen: I mean whatever mod still exists in your GameData somewhere such that exceptions thrown from it ended up in the log that you uploaded. Which you apparently deleted from your install only after causing the bug and uploading the log, not before. Seriously, don't lie to me about what's in your install when you cause the bug, because the log will tell me what's up.

@kcs123: It's not worth it, the unaware users suffering from that won't look for workarounds, they'll just report the bug and never check back. Or report the bug, have me reply that I can't reproduce it, and then confirm it again, and we'll just end up in the same loop again.

Seriously, for all of you, your bug reports are not actionable unless I can reproduce the issue. It doesn't matter how many of you can reproduce an issue on however messy and convoluted an install that you can manage, if I can't reproduce it I can't fix it. Do none of you want me to fix the bugs? Because this is how you make it impossible for me to fix the bugs.

[Bushi]

Edit: the latest commit just fixed things again. Ignore the rest of this.

---

Sorry Ferram, just meant to encourage him to keep digging as he isn't alone. The best I can do as far as reproduction is just as he said.

To try a little harder, I opened the gamedata folder and deleted everything but FerramAerospaceResearch, ModularFlightIntegrator, Squad, and the Module Manager files. Then I started a new game, opened the SPH and added a MK2 cockpit and some fuel tanks. Get voxelation between/inside parts and the cross section area is very low, just as shown before.

Here's a log: http://pasted.co/c5822276

The only things that sticks out to me: "Part Warning: part mk2FuselageLongLFO is not a child of mk2Cockpit.Standard" and "Part Warning: part mk2FuselageLongLFO is not a child of mk2FuselageLongLFO" but I honestly don't know if that's normal or not. I think I was reading the voxel method starts with child parts and works to the parents but I really don't know.

If I just copy the FerramAerospaceResearch.dll from the official newest release and replace the dev branch one, it goes back to normal.

Really I don't know if I could do more than that, sorry. At least I haven't experience the no drag bug...

Edited May 29, 2015 by Bushi

[Gryphon]

Seriously, for all of you, your bug reports are not actionable unless I can reproduce the issue. It doesn't matter how many of you can reproduce an issue on however messy and convoluted an install that you can manage, if I can't reproduce it I can't fix it. Do none of you want me to fix the bugs? Because this is how you make it impossible for me to fix the bugs.

Personally, I just hope that you will be able to fix any bugs that you can reliably reproduce. If you can't reproduce a reported issue, then ipso facto, you cannot fix it.

@everyone else: In general, ferram is the most important person involved in this mod. However, when you experience a bug that hasn't been reported(with steps for reproduction), then you the person who has exposed the bug, are the most important person for fixing that bug. You can make an important contribution to the mod and all the people who use it by diligently hunting down the minimum set of mods, parts, and situation which show it, along with a set of instructions for reproducing the problem (which you have tested, to make sure that following the steps as written causes the problem reliably). It may not be easy, but it is important, and it's something most anyone can do.

ETA: I'm a developer, and I've done paid remote tech support. It's the most difficult way of solving software problems.

Edited May 29, 2015 by Gryphon

[Mipe]

I'm a developer and bugs don't exist.

They're features.

[hahawin]

The latest commit (7cfbc6a899) has fixed things for me as well. I assume the reason ferram4 couldnt reproduce was because he was using this version to test it?

Anyway, I'm glad its fixed

[sam.johnson841]

Sorry to bother you, is NuFar disabled on the x64 community hack?

-Sam

Edited June 1, 2015 by sam.johnson841
Im an idiot

[kcs123]

Sorry to bother you, is NuFar disabled on the x64 community hack?

-Sam

From the OP:

Note: This mod disables itself on 64-bit Windows builds of KSP to avoid exacerbating the win64 build's inherent instability. Users are encouraged to switch to either the 32-bit Windows build or the 64-bit Linux build, which are far more stable.

Ferram is right, no metter how much info someone provide, there will always be people who are not bothered to read at all.

Seriously, don't start this x64 topic again.

[B15HOP_xmen]

@Bushi: And once again, I cannot reproduce the issue. You had better be able to provide good reproduction steps that will work for me if you're gonna go and confirm an issue that doesn't exist.

@B15HOP_xmen: I mean whatever mod still exists in your GameData somewhere such that exceptions thrown from it ended up in the log that you uploaded. Which you apparently deleted from your install only after causing the bug and uploading the log, not before. Seriously, don't lie to me about what's in your install when you cause the bug, because the log will tell me what's up.

@kcs123: It's not worth it, the unaware users suffering from that won't look for workarounds, they'll just report the bug and never check back. Or report the bug, have me reply that I can't reproduce it, and then confirm it again, and we'll just end up in the same loop again.

Seriously, for all of you, your bug reports are not actionable unless I can reproduce the issue. It doesn't matter how many of you can reproduce an issue on however messy and convoluted an install that you can manage, if I can't reproduce it I can't fix it. Do none of you want me to fix the bugs? Because this is how you make it impossible for me to fix the bugs.

I did a fresh install and did it again but on a different PC. Not a case of lying. Sorry to confuse you.

[BudgetHedgehog]

I did a fresh install and did it again but on a different PC.

And you didn't post THAT output log because....?