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

[kcs123]

 

 

Found similar issue as Bokstore44. It is official FAR release, not developer version.
I can only provide craft file if needed, output log is overwritten, can't provide that and I can only speculate about reason behind it.
I think gong to test flight and reverting to SPH somehow trigers it, but I need to do more tests to find out reliable reproducing steps.

[ferram4]

@Gordon Dry: "Already implemented" as in "was implemented several versions ago."

@Bookstore44 & @kcs123: Both of those look like cases where you attached the parts and then rushed to simulate before the voxelization was complete, so the wing parts hadn't had their setup code run yet.  In any case, bugs like that will not be fixed until the wing overhaul happens, because spending time fixing code that will be completely replaced is silly.

[kcs123]

It is not a big deal, no need to spend time on it, especialy if you have plan to replace it with new wing code.
Narrowed down problem slightly. It hapens with crafts that have high stall AoA, around 30 or more degrees. "Bad info" happen imediately after I load previously saved craft in SPH, without moving ore reattaching any part.

Does not metter how long I wait, or how many times I repeat AoA sweep, always show same bad result. Raising/lowering landing gears does not help either, but when I re-attached some parts, for example one part of hull that have some wing surfaces on it, and attach again on exact same spot, craft shape is not changed at all, but it seems that it trigers voxelization somehow to display good data on AoA sweep.

Does not bother me much, in flight plane behave correctly as assumed based on graph info.

[Gordon Dry]

8 hours ago, ferram4 said:

@Gordon Dry: "Already implemented" as in "was implemented several versions ago."

Okay, repeat is as much as you want, but since I started using this mod it never remembered the window positions and I always had to take care not to do a click-through disaster.

[Jacke]

2 hours ago, Gordon Dry said:

Okay, repeat is as much as you want, but since I started using this mod it never remembered the window positions and I always had to take care not to do a click-through disaster.

So maybe you would get better results, once you've been told by the mod designer (who does this out of the goodness of his heart and in his spare time) that the features are implemented, but you're still having the issues, by asking nicely what would lead to you still having these issues.  And perhaps going through your install checking for cruft.  You expect a lot of snark (apologies, @Snark) to get you better results?

[Gordon Dry]

No snark, I just wanted to tell that I was used to that from the beginning.

[tetryds]

@Gordon Dry That is not how it works, if you find an issue and want it fixed you need to give a full report, logs and explain every step you took to have it to happen.

Then ferram can reproduce it on his side and figure out what is going on.

If you don't plan to do that there is no point in reporting the issue, it's incredibly hard to simply magically reproduce something out of nowhere.

Also bear in mind that the windows positions are saved on the persistent file, so if you revert they will revert as well.

[kcs123]

1 hour ago, tetryds said:

Also bear in mind that the windows positions are saved on the persistent file, so if you revert they will revert as well.

I think that is main issue why people get a feeling that it does not work properly. For example, you need to go in flight, set window position as you pleased, recover craft and save your game, without reverting flight. Save your game once you are in space center, or exit to main menu at least once.

Only after that changes will be visible as expected on any further flights. Small piece of info how things works can help to avoid confusion and false bug reports.

[starikki]

Is it possible to reduce the delay of the %AOA responce on control surfaces?

and add options to scale deflection angle by Q for each control surface?

[habix]

I'm quite new to ksp, but already feel like this mod should be in vanilla!
I did manage to break it a bit.. Besides FAR I'm also using Mod "Bluedog Design Bureau". Everything works fine, except for when I put any of the antennas or dishes from that mod on a ship. It just spams the log with "[Log]: Updating CommSat" - it never finishes voxelization process. 
I searched on forum and didn't find anyone mentioning it.

Is there a way to run FAR in more verbose debug log?

*****EDIT

There is a "try - finally" block in code that suppressed the exception. I put a log on exception and this is what I get in a loop:

[LOG 23:31:25.126] Updating LR CommSat
[LOG 23:31:25.126] We're not ready!
[EXC 23:31:25.128] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GetVisibleMeshData (UnityEngine.Transform t, Boolean onlyMeshes)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.CreateMeshListFromTransforms (System.Collections.Generic.List`1& meshTransforms)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData ()
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.FixedUpdate ()
[EXC 23:31:25.135] NullReferenceException: Object reference not set to an instance of an object
    TweakScale.TweakScale.UpdateByWidth (Boolean moveParts, Boolean absolute)
    TweakScale.TweakScale.OnTweakScaleChanged ()
    TweakScale.TweakScale.Update ()
[EXC 23:31:25.148] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GetVisibleMeshData (UnityEngine.Transform t, Boolean onlyMeshes)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.CreateMeshListFromTransforms (System.Collections.Generic.List`1& meshTransforms)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData ()
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.FixedUpdate ()
[EXC 23:31:25.158] NullReferenceException: Object reference not set to an instance of an object
    TweakScale.TweakScale.UpdateByWidth (Boolean moveParts, Boolean absolute)
    TweakScale.TweakScale.OnTweakScaleChanged ()
    TweakScale.TweakScale.Update ()
[EXC 23:31:25.172] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.GetVisibleMeshData (UnityEngine.Transform t, Boolean onlyMeshes)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.CreateMeshListFromTransforms (System.Collections.Generic.List`1& meshTransforms)
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData ()
    FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.FixedUpdate ()
[EXC 23:31:25.179] NullReferenceException: Object reference not set to an instance of an object
    TweakScale.TweakScale.UpdateByWidth (Boolean moveParts, Boolean absolute)
    TweakScale.TweakScale.OnTweakScaleChanged ()
    TweakScale.TweakScale.Update ()
[LOG 23:31:25.191] Updating LR CommSat
[LOG 23:31:25.192] We're not ready!
... repeats

Not sure if it's problem in combination with TweakScale? Is there a way to ignore parts that break the voxelization process? 

Thanks for help

*****EDIT 2

Same trouble appears if I use mod "Antennas" and put any part of it on ship. Wasn't able to reproduce with a clean install of ksp, FAR+bluedog tho. Must be combination of mods.. something to do with antennas. Will investigate more. 

 

Edited May 29, 2016 by habix
new info

[Gordon Dry]

"Updating vessel voxel for" spam after I deployed the IR extendatrons with OKEB-500 attached to, still spamming after deployment finished.
The OKEB-500 all claim to be blocked by themselves...

Log:

https://www.dropbox.com/s/qmz3an4nbyw71jd/2016-05-29-2%20FAR%20Updating%20vessel%20voxel%20for%20spam.7z?dl=0

Edited May 29, 2016 by Gordon Dry

[habix]

21 hours ago, habix said:

I'm quite new to ksp, but already feel like this mod should be in vanilla!
I did manage to break it a bit.. Besides FAR I'm also using Mod "Bluedog Design Bureau". Everything works fine, except for when I put any of the antennas or dishes from that mod on a ship. It just spams the log with "[Log]: Updating CommSat" - it never finishes voxelization process. 
I searched on forum and didn't find anyone mentioning it.

Is there a way to run FAR in more verbose debug log?

*****EDIT

There is a "try - finally" block in code that suppressed the exception. I put a log on exception and this is what I get in a loop:

... repeats

Not sure if it's problem in combination with TweakScale? Is there a way to ignore parts that break the voxelization process? 

Thanks for help

*****EDIT 2

Same trouble appears if I use mod "Antennas" and put any part of it on ship. Wasn't able to reproduce with a clean install of ksp, FAR+bluedog tho. Must be combination of mods.. something to do with antennas. Will investigate more. 

 

OK, found out what is going on. The real problem is mod "Connected living space" in combination with "RemoteTech" - it raises some exception when attaching antenna or command pod and breaks voxelization process. Long story short: removing CLS fixes voxelization process for me.

[Gordon Dry]

13 minutes ago, habix said:

OK, found out what is going on. The real problem is mod "Connected living space" in combination with "RemoteTech" - it raises some exception when attaching antenna or command pod and breaks voxelization process. Long story short: removing CLS fixes voxelization process for me.

I don't use these mods but since today I get these voxelation stuff and very low fps because of that.

I just didn't change anything since the last session it worked, so it's like "everyday a new issue no matter what" ...

Edit:

but I have this idea that the default texture of the procedural tanks that has kinda bump map calculates many tiny rhombical shadows... could be some, but my GPU usage is very low, about 12-20% ...

Edited May 29, 2016 by Gordon Dry

[ferram4]

@habix: Provide full reproduction steps, the full log, and the problem craft please.

@Gordon Dry: Full repro steps all the mods you're using, and the craft file.

Also, if you did exactly the same thing as you did yesterday, then the behavior is exactly the same; if it's different, then you did something different.  To fix bugs, I need to know what it is you did differently.

Also, no, textures have nothing to do with what FAR voxelizes.  Just provide the info I ask for.

[habix]

reproduction:

Installed mods:

FAR
RemoteTech
Connected Living Space
Bluedog Design Bureau 

Place command pod in VAB, attach any antenna from BDB or command pod to it - the voxelization doesn't finish after attach.

The author of CLS is already investigating the problem, but maybe you can look it up too, to handle cases like this.

Log looks something like this:

[LOG 19:43:52.258] RemoteTech: ModuleRTDataTransmitter::OnLoad
[LOG 19:43:52.259] RemoteTech: ModuleRTAntenna: Find TRANSMITTER success.
[LOG 19:43:52.259] RemoteTech: ModuleRTAntenna: Add TRANSMITTER success.
[EXC 19:43:52.261] NullReferenceException: Object reference not set to an instance of an object
    ConnectedLivingSpace.CLSAddon.RebuildCLSVessel (.Vessel newVessel)
    ConnectedLivingSpace.CLSAddon.OnVesselWasModified (.Vessel data)
    EventData`1[Vessel].Fire (.Vessel data)
    RemoteTech.Modules.ModuleRTAntenna.AddTransmitter ()
    RemoteTech.Modules.ModuleRTAntenna.SetState (Boolean state)
    RemoteTech.Modules.ModuleRTAntenna.OnStart (StartState state)
    Part.ModulesOnStart ()
    Part+<Start>c__Iterator25.MoveNext ()
[LOG 19:43:53.661] bluedog.Diamant.Asterix added to ship - part count: 2
[LOG 19:43:53.674] RemoteTech: ModuleRTDataTransmitter::OnSave
[LOG 19:43:53.694] Updating Untitled Space Craft
[LOG 19:43:53.727] Updating Untitled Space Craft
[LOG 19:43:53.789] Updating Untitled Space Craft

 

Edited May 29, 2016 by habix

[AccidentalDisassembly]

Hi @ferram4,

The latest dev version of FAR (the build from 4 days ago I think) does not seem to enjoy fairings being placed in the editor. Log: https://dl.dropboxusercontent.com/u/59567837/output_log_FARDevFairings.txt

Reproduction:

1. Start sandbox
2. Enter VAB
3. Place something, then place fairing part, then begin to build fairing: exceptions

Edited May 29, 2016 by AccidentalDisassembly

[ferram4]

@habix: FULL log, not snippet.  I need to have EVERYTHING.

Does it work without Remotetech, but still with BDB?  Does it happen with any other part in any way?

@AccidentalDisassembly: Confirmed, I know what's causing it.  Stupid fix that I had to add to fix a bug introduced in part transform layers for KSP 1.1.2.

[Gordon Dry]

By removing TweakScale (again) and also the RVE suite and using DirectX11 this issue is gone.

Double the frame rate (still low but...) and no log spamming.

[ferram4]

@Gordon Dry: If you're not going to provide me reproduction steps, logs, and a mod list you can't expect to get any support.  Bugs don't get fixed with absolutely no information.

[ratchet freak]

On 27-5-2016 at 8:50 PM, ferram4 said:

 

@Bookstore44 & @kcs123: Both of those look like cases where you attached the parts and then rushed to simulate before the voxelization was complete, so the wing parts hadn't had their setup code run yet.  In any case, bugs like that will not be fixed until the wing overhaul happens, because spending time fixing code that will be completely replaced is silly.

As a possible quickfix: if voxelization/wingsetup is still going on, then delay the sim until it's done? Even after the overhaul that will probably be necessary.

 

A few seconds extra delay right after manipulating a part is less of an issue than wrong sim output.

Edited May 30, 2016 by ratchet freak

[kcs123]

4 hours ago, ratchet freak said:

A few seconds extra delay right after manipulating a part is less of an issue than wrong sim output.

Unfortunately, no, in this case does not help. At least not with my case that i encountered. For some reason, some part on craft is not voxelized properly, although, voxelization looks fine to me when displayed. "Bad" info happens as soon as I load craft in SPH, when just started to play game. You can wait forever, but graph will look always the same.

When you attach/de-attach something on craft, you get proper data on graph. For things to be even more strange, it happens only with craft that have high AoA stall angle, above 25 degree. On crafts that have lower, less insane AoA stall angle, it behave as expected. Things happen quite randomly when you get good or wrong data, so it is hard to enlist proper reproduction steps.

Without proper reproduction steps it will be nearly impossible to fix bug. It is better to spent time and effort to write wing overhaul code and chase down same bug if it persist after new wing code. It is more/less easy to get workaround of this bug, does not influence craft behaviour in flight at all, have to learn to live with it for now.

[ferram4]

@habix: I have investigated and determined that this isn't a FAR bug.  This is an interaction between CLS and RemoteTech breaking all PartModule.Start() functions that are set to happen after RemoteTech's.  While this breaking FAR's aerodynamics might be the most noticeable effect, there should be other broken behaviors as well.  Unfortunately, nothing I can do here.

[Van Disaster]

On 28/05/2016 at 10:59 AM, starikki said:

Is it possible to reduce the delay of the %AOA responce on control surfaces?

and add options to scale deflection angle by Q for each control surface?

Crzyrndm has a mod called "Dynamic Deflection" which will do the second part of that - you might find you want a little more than just Q involved though, seeing as high altitude supersonic flight & low altitude subsonic will share Q figures.

[Gordon Dry]

So, here it is, the game is still running, I'm trying to secure my orbit with the probe, actual altitude 490km (Earth) and still "Updating vessel voxel for" and "Std dev for smoothing".

I guess actually KSP is in the state of memory leaking, reason unknown (beside the reasons that are my humble subjective opinion)...

Log:
https://www.dropbox.com/s/ipw933ighm4qal4/2016-05-30-3%20FAR%20Updating%20vessel%20voxel%20for.7z?dl=0

[Bookstore44]

@ferram4

In your last response to me, you answered one of my questions about strange static analysis results, saying that it would wait until the wing overhaul.

However, there were two other questions/concerns in my last post, on May 25th, which I believe are important:

1. The structural panels produce a strange pitching moment, as if they produce lift backwards or at 90 degrees or something. maybe the pitching moment is calculated backwards.  (screenshots etc. in aforementioned post.) Note how a rocket with mass in the back and fins in the front is stable using this method, whereas a rocket with mass in the front and fins in the back would be unstable, in violation of everything taught in ksp rocket-school. These effects occur in flight test, and after waiting several minutes before simulating/running (even though really just 1 or 2 seconds would suffice for voxelization). Further testing shows that other objects, such as structural fuselages placed parallel to the rocket, large landing gear with wheels to the side and facing backwards, and modular girder segments pointed outwards from the body also exhibited this effect. I believe any non-wing part, if oriented correctly, has this effect. 

2. Is there a way to see/calculate the reference area of the craft?

 

 

Edited May 31, 2016 by Bookstore44