[1.8-1.12] Ferram Aerospace Research Continued: v0.16.0.5 "Mader" 03/04/22

[Jacke]

8 hours ago, taniwha said:

...if a part's mass is 0 (let alone the entire vessel's mass), or negative masses are present, really weird things will happen whether FAR tries to mask them or not. It's just not worth cluttering up the code making it harder to read and slower. Rhinodaemons.

I thought all parts have non-zero mass (and drag and thermal numbers).  And if physicsless, the part's mass and drag pass back up to its parent part.

[Lisias]

10 hours ago, taniwha said:

@Lisias: I disagree. I find it to be far better for these problems to rear their ugly heads as soon as possible, so masking over them with such bandaids is counter productive.

Unfortunately, this logic didn't worked at all on TweakScale. Allowing mass to be zero was the root cause of all the problems that was plaguing the game (both on TweakScale as with Fuel Switches - or the interaction of both).

Somewhere on the KSP guts (and I don't have access to that code, so I can say where and why), divisions by zero are rendered to NaNs or INFs, and cascaded to the internal data structures - it was that exploding the launch-pad statics as well "anchoring" some parts on the 3D world (that so would explode when being pushed by the engine).

And since this problem is scattered on the game, it was extremely hard to detect it. It took me months chasing my tail, and yet I got the problem "luck", as another guy with a completely unrelated setup but two Add'Ons

 

10 hours ago, taniwha said:

It's for this reason my mods (in particular, EL) almost never catch exceptions: one of I've done something wrong and need to know, the mod triggering the exception is doing something wrong and needs to be fixed (thus I need to know so I can pass the info on to the relevant developer), or the mod is doing things right but not in the unusual context I've created (thus the ref to EL) and I need to know. Although deciding between the latter two cases can be difficult, I would far rather get a pile of reports that "EL is broken" than complaints of things mysteriously failing to do anything.

I disagree with that practice.

Error handlings (specially try-catches) are expensive, but I use them on non performance critical sections of the code (or in non performance critical Add'Ons) exactly to register the problem as soon as I can.

But something will always got through, so some defensive programming are needed to withhold them and preventing them to cause problems that are almost impossible to detect later (and it's very hard to identify the root cause of a huge chain of events that are usually initiated by a third-party most of the time completely unrelated to the poor stand-up guys that got the ticking bomb with the timeout ran out).

 

10 hours ago, taniwha said:

Anyway, if a part's mass is 0 (let alone the entire vessel's mass), or negative masses are present, really weird things will happen whether FAR tries to mask them or not. It's just not worth cluttering up the code making it harder to read and slower. Rhinodaemons.

And that's the reason FAR should take precautions to be not included on the chain of events, and so people would waste time thinking the messenger was the culprit. Ideally some mechanism should log the problem and warn the user that his instalment is compromised and he should seek help. but that code is performance critical and it's unwise to shove this there.

Anyway, if you think a simple ternary operator is something hard to read, I'm afraid you should not be writing games using C# - get in touch with people working with Frostbite and ask them about. Games are not "ordinary code", where easy maintenance by less skilled workforce is a desirable feature. Games as artefacts that need to deliver the job in the most efficient way possible in order to reach people with the lowest hardware as possible - and, weirdly enough, are also artefacts those users are way less prone to forgive crashes than comercial grade code: people value more their free time due scarcity.

Minimal is not the same as "minimalist".

 

-- -- -- POST EDIT -- -- -- 

There's an addition reason to avoid Divisions by Zero on the code. Unhandled Exceptions on some Event Handlers on KSP are known to kill the thread, stoping all the chain of events being called from that point. This is also something very annoying to detect and fix.

Edited December 29, 2019 by Lisias
post edit

[Glassius]

I'm having problem with loading Scenario scenes. After hitting the start button, the background buttons are becoming active and clickable trough scenario choose dialog. Scenario choose dialog becomes inactive, yet still visible. Training choose dialog works without problem.

This is happening for "Dynawing final approach" and "Final Ending" scenarios.

Other scenarios are running, but it seems aero drag is broken. In "EVA in Kerbin orbit", after i return to vessel, it is not aerobraking.

I am running Ferram 0.15.11.3 using CKAN. I see in commit history a similar issue was solved between Ferram-Aerospace-Research-0.15.5.4_Hoerner and Ferram-Aerospace-Research-0.15.5.5_Hugoniot.

[kcs123]

10 hours ago, Glassius said:

I'm having problem with loading Scenario scenes.

That is main issue. And it is not only with FAR. Quite a lot of mods does not work properly with scenarios. It is being like that since first KSP release. At least it was with tutorials and such. Can't tell much about mission history DLC, though.
Your best bet is to play stock only game and pass trough scenarios. After that try mods and fun with sandbox and career game.

And, welcome to forums,btw.

[Glassius]

I've tried to stick to the topic. I suppose you're right, I'll install/uninstall Ferram depending on what I want to play. Thanks for your welcoming, btw

[The-Grim-Sleeper]

On 11/11/2019 at 2:08 PM, CorvusCorax said:

Cool stuff

On 11/11/2019 at 5:43 PM, kcs123 said:

What you see on the picture, that forces are changed is due to random events(triggers) in the game that caused FAR to re-calculate something. So, you can get wrong impression that DLC parts work, but you don't get expected lift/drag/thrust forces. You got wrong calculated values because FAR was not able to calculate everything on time.

What are the 'Do's and 'Don't's of 'Breaking Ground' + FAR (+ IR)?
I've been making helicopters both with and without the BG-propellors, and they went "up-ish". From what I understand, it's because BG-prop + BG-engines operate completely beyond the scope of FAR. But servo's+FAR-wings (stock parts with FAR active) seem like a working option but servo's + FAR-control surfaces do not. What would be the thing that makes a helicopter work vs a kraken-copter?
I've never made a variable wing craft, but do I understand correctly that, with regards to FAR calculating the change in forces, that it "would only work if there is at least 1 IR-part that moves when the wings move"?
What's all this I keep reading about Fairings?

Is there any kind of craft design you would say 'FAR or Robotics, but not both if you want it to "not explode/nose-dive/disintegrate from aerostress"'?

Edited January 3, 2020 by The-Grim-Sleeper
Better readablilty

[kcs123]

4 hours ago, The-Grim-Sleeper said:

What are the 'Do's and 'Don't's of 'Breaking Ground' + FAR (+ IR)?
I've been making helicopters both with and without the BG-propellors, and they went "up-ish". From what I understand, it's because BG-prop + BG-engines operate completely beyond the scope of FAR. But servo's+FAR-wings (stock parts with FAR active) seem like a working option but servo's + FAR-control surfaces do not. What would be the thing that makes a helicopter work vs a kraken-copter?
I've never made a variable wing craft, but do I understand correctly that, with regards to FAR calculating the change in forces, that it "would only work if there is at least 1 IR-part that moves when the wings move"?
What's all this I keep reading about Fairings?

Is there any kind of craft design you would say 'FAR or Robotics, but not both if you want it to "not explode/nose-dive/disintegrate from aerostress"'?

Stock robotic parts(rotatrons) would not properly work with FAR because stock robotic parts does not update necessary FAR functions on physics tick on time. It may work with IR rotatrons + wings/control surfaces that have proper FAR configs. I say "may", because IR rotatrons have low rotation speed that might not be enough for lift off.

AFAIK, stock propelers don't have proper FAR configs, so it would not work with any combination of propeler + rotatron part, being from IR or stock.

Variable wing craft with IR parts can work, but have to keep wing load light and you my want to use some trick with locking/unlocking joints to reduce wobling. I'm not 100% sure if necessary updates for FAR are executed for each IR part. Meaning, I'm not sure if it will work with combination of uncontroled IR part + stock robotic part, it might be necessary to have at least one powered IR part for proper trigger for FAR.

There is no unexpected kraken-like issues with FAR + robotic parts that would cause things to explode. Issue that you may got is that you don't have proper lift/drag forces calculations and therefore craft may not work as expected. Can't tell anything about fairings, I didn't tested those much from other mods, but stock fairings work properly for me. Sorry, don't have any decent aircraft example for latest KSP versions, those that I have are made long time ago for KSP 1.2.x up to 1.4.x.

[The-Grim-Sleeper]

1 hour ago, kcs123 said:

Variable wing craft with IR parts can work, but have to keep wing load light and you my want to use some trick with locking/unlocking joints to reduce wobling. I'm not 100% sure if necessary updates for FAR are executed for each IR part. Meaning, I'm not sure if it will work with combination of uncontroled IR part + stock robotic part, it might be necessary to have at least one powered IR part for proper trigger for FAR.

Are there any (stock) parts that (can reliably) trigger the mesh-update? Like landing gear, decouplers or fairing discarding?
Is there any way to see the mesh-update as it happens? Or is it browsing through logging statements the only thing for it?

Edited January 3, 2020 by The-Grim-Sleeper

[kcs123]

27 minutes ago, The-Grim-Sleeper said:

Are there any (stock) parts that (can reliably) trigger the mesh-update? Like landing gear, decouplers or fairing discarding?
Is there any way to see the mesh-update as it happens? Or is it browsing through logging statements the only thing for it?

I think that any stock part that have animation event also trigger FAR updates. Robotic parts, IIRC use mesh transform or something similar, can't recall exact term from top of my head, that can't be used for trigger for proper update. I think that is only way to see when voxel calculations happen is trough log files or if you have opened console window all time. For more accurate and detail answer you will have to ask @dkavolis for it. This is much as I know and can recall right now.

[dkavolis]

20 hours ago, kcs123 said:

Stock robotic parts(rotatrons) would not properly work with FAR because stock robotic parts does not update necessary FAR functions on physics tick on time. It may work with IR rotatrons + wings/control surfaces that have proper FAR configs. I say "may", because IR rotatrons have low rotation speed that might not be enough for lift off.

AFAIK, stock propelers don't have proper FAR configs, so it would not work with any combination of propeler + rotatron part, being from IR or stock.

Variable wing craft with IR parts can work, but have to keep wing load light and you my want to use some trick with locking/unlocking joints to reduce wobling. I'm not 100% sure if necessary updates for FAR are executed for each IR part. Meaning, I'm not sure if it will work with combination of uncontroled IR part + stock robotic part, it might be necessary to have at least one powered IR part for proper trigger for FAR.

There is no unexpected kraken-like issues with FAR + robotic parts that would cause things to explode. Issue that you may got is that you don't have proper lift/drag forces calculations and therefore craft may not work as expected. Can't tell anything about fairings, I didn't tested those much from other mods, but stock fairings work properly for me. Sorry, don't have any decent aircraft example for latest KSP versions, those that I have are made long time ago for KSP 1.2.x up to 1.4.x.

18 hours ago, kcs123 said:

I think that any stock part that have animation event also trigger FAR updates. Robotic parts, IIRC use mesh transform or something similar, can't recall exact term from top of my head, that can't be used for trigger for proper update. I think that is only way to see when voxel calculations happen is trough log files or if you have opened console window all time. For more accurate and detail answer you will have to ask @dkavolis for it. This is much as I know and can recall right now.

Stock robotics modify mesh transforms to get the animations and the last time I tried (1.7) there was no simple way to check if parts were moving or not. Animations that use common field names are automatically handled by FAR unless disabled through MM. IR uses uses builtin Unity functionality to update voxelization. FAR has no support for any propellers, it only handles thin wings and body aerodynamics.

foreach (PartModule m in part.Modules)
{
  FindAnimStatesInModule(animations, m, "animationName");
  FindAnimStatesInModule(animations, m, "animationStateName");
  FindAnimStatesInModule(animations, m, "animName");
  FindAnimStatesInModule(animations, m, "deployAnimationName");
}

Regarding voxelization of animated parts, I think the current implementation can be vastly improved using job system which significantly simplifies writing multithreaded code with dependencies. FAR uses multiple threads to voxelize but writes to same memory locations from them and reference objects add unnecessary indirections in some places. I think voxelization can be redone with partial volume update support for animations and possibly lower memory usage.

[The-Grim-Sleeper]

21 hours ago, dkavolis said:

foreach (PartModule m in part.Modules)
{
  FindAnimStatesInModule(animations, m, "animationName");
  FindAnimStatesInModule(animations, m, "animationStateName");
  FindAnimStatesInModule(animations, m, "animName");
  FindAnimStatesInModule(animations, m, "deployAnimationName");
}

 

animationName = LightAnimation is found in most cockpits and the spotlights, and can be toggled with a KAL-1000 controller.
I've tested this with a simple variable wing craft, and sure enough, turning the lights on or off de-bricks the craft.
The animation speed of the spotlights seems to be almost instant, and you can stager several of them for even more spam.

So for anybody desperately wanting to build a Stock+DLC-parts only ornithopter, but somehow also using FAR, that will keep you going. Be sure to share your .craft (on the appropriate thread)!
As for the propellers, they won't have FAR physics anyway, but they still do have Stock-physics; It will fly just fine, but also work fine in very unrealistic situations.

[Sahadara]

Really minor thing I noticed. In the toolbar the button to bring up the FAR menu is there, but it doesn't have its icon, it's just black. Tiny issue so I'm not sure if I need to post logs or anything because it doesn't affect gameplay at all, it's just kind of annoying. If logs are needed I can post them. If this is just the way it is I can deal with it but I was curious if there was an easy fix. (Tried installing through CKAN as well as manually).

[TOMMY (JEB 2.0)]

is this mod supposed to make the water a paste

[steve_v]

On 1/13/2020 at 6:05 AM, TOMMY (JEB 2.0) said:

is this mod supposed to make the water a paste

Unless you've installed it incorrectly, no. It does make water drag somewhat higher than stock, because that's what fluid dynamics says it should be.

If you feel it needs balancing (and it quite possibly does TBF), the source code is freely available here. I look forward to your contribution.
 

[steve_v]

I'm not sure if it's FAR or MechJeb, but something is freaking out and spamming the log constantly when a vessel crashes. This tanks framerate to ~0.5FPS for the duration of the RUD.

[EXC 18:18:33.833] NullReferenceException
	FerramAerospaceResearch.FARAeroComponents.FARVesselAero.SimulateAeroProperties (UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0)
	FerramAerospaceResearch.FARAPI.CalculateVesselAeroForces (Vessel vessel, UnityEngine.Vector3& aeroForce, UnityEngine.Vector3& aeroTorque, UnityEngine.Vector3 velocityWorldVector, System.Double altitude) (at <6338ca968c7c4c8a971a01d858e759df>:0)
	MuMech.VesselState.AnalyzeParts (Vessel vessel, MuMech.VesselState+EngineInfo einfo, MuMech.VesselState+IntakeInfo iinfo) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0)
	MuMech.VesselState.Update (Vessel vessel) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0)
	MuMech.MechJebCore.Drive (FlightCtrlState s) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0)
	MuMech.MechJebCore.OnFlyByWire (FlightCtrlState s) (at <3ddb09b54c5e42379c1671957c9d0f6f>:0)
	Vessel.FeedInputFeed () (at <2c9e31d65a604d1980fb0cb89728fc1e>:0)
	FlightInputHandler.FixedUpdate () (at <2c9e31d65a604d1980fb0cb89728fc1e>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Any idea who I should be punting this one to?

----Updated----

FAR, Mechjeb, MM and MFI alone reproduce this reliably now.
Without MechJeb installed FAR produces no exceptions at all, so the theory that FAR is borking and the exceptions from MechJeb are caused entirely by this doesn't seem likely.
MechJeb is likewise quite happy without FAR installed. It's only the two together that cause a problem.

KSP.log
Player.log
Test craft used (also reproduced with the FAR "E42" example craft).
Save file
Repro: Take off from the runway and immediately bank hard to have the port wingtip hit the ground.
Expected result: RUD.
Actual result: RUD at 0.5FPS, exceptions logged.

Halp?

Edited February 5, 2020 by steve_v
Better info, mod combination isolated. Finally.

[TOMMY (JEB 2.0)]

On 1/31/2020 at 11:35 PM, steve_v said:

Unless you've installed it incorrectly, no. It does make water drag somewhat higher than stock, because that's what fluid dynamics says it should be.

If you feel it needs balancing (and it quite possibly does TBF), the source code is freely available here. I look forward to your contribution.
 

i know nothing about modding (or realy programing tbh) so what should i change/how?

[steve_v]

4 hours ago, TOMMY (JEB 2.0) said:

what should i change/how?

Sorry bud, you're on your own. I was planning on looking into this myself at some point, as I kinda like seaplanes and all, but now I'm outta here.

If I were you, I'd check out the repo from github and have a poke around the math involving waterDragForce and hackWaterDragVal.
It looks like there may have been some fudges installed to make water behaviour reasonable, by ferram''s definition of reasonable, and as much as that is based on real physics it doesn't always balance nicely with the rest of the unrealistic physics in KSP... Such as it being nearly impossible to build an aircraft as light and buoyant as the real thing. Parts in this game are apparently made of depleted uranium.

The code is GPL so you can muck with it all you like, but you'll need to learn a bit of C# to make sense of it.

Edited February 4, 2020 by steve_v

[Toonu]

Hello guys, I am using FAR 0.15.11.2 and it lags the game in flight every 2 or 3 seconds no matter what while flying in plane. Console shows no errors, anyone encountred similar issue or so? Any help would be appreciated.

You can see the 2-second periods between the lags here.

 

Edited February 7, 2020 by Toonu

[kcs123]

5 hours ago, Toonu said:

Hello guys, I am using FAR 0.15.11.2 and it lags the game in flight every 2 or 3 seconds no matter what while flying in plane. Console shows no errors, anyone encountred similar issue or so? Any help would be appreciated.

You can see the 2-second periods between the lags here.

 

Have you tried same plane, but without advanced landing gears ? IIRC, I was having similar problem in the past, I narrowed it down to issues with KSP garbage collector and ALG in combo. I tried using MemGraph mod that track down memory usage and disposal and help to some degree with garbage collector slowdowns. But, could not make it run completely smooth in KSP 1.7.x
I don't think that issue is with FAR, it is something else involved or some combo of different mods used.

[Toonu]

5 hours ago, kcs123 said:

Have you tried same plane, but without advanced landing gears ? IIRC, I was having similar problem in the past, I narrowed it down to issues with KSP garbage collector and ALG in combo. I tried using MemGraph mod that track down memory usage and disposal and help to some degree with garbage collector slowdowns. But, could not make it run completely smooth in KSP 1.7.x
I don't think that issue is with FAR, it is something else involved or some combo of different mods used.

Thanks a lot! I haven't removed KF from my modpack but only from the plane and it fixed the issue! On the other side of the thing, do you know any good modular/procedural replacement like the AGL was? I am now really lost without proper resizing aligning wheels haha !   Do you think submiting bug report to current developer will fix it in reasonable amount of time or is it more bug of KF....probably KF due to no other mod causing that, so yeah, will submit bug report probably.

 

Thanks again! Finaly smooth flying!  

[kcs123]

Just now, Toonu said:

Thanks a lot! I haven't removed KF from my modpack but only from the plane and it fixed the issue! On the other side of the thing, do you know any good modular/procedural replacement like the AGL was? I am now really lost without proper resizing aligning wheels haha !   Do you think submiting bug report to current developer will fix it in reasonable amount of time or is it more bug of KF....probably KF due to no other mod causing that, so yeah, will submit bug report probably.

 

Thanks again! Finaly smooth flying!  

Unfortunately, no, I also like those AGL, but could not find alternative to those. And AGL is not originaly developed by current maintainer, so there is quite a lot possible issues coming from this and from integration with KF or KSPWheels. I'm not sure how much can be done with that bug, but if you report politely and provide as much as info as possible, including that video it is more possible for Shadowmage to investigate it and eventualy make a fix for it. Quite a lot was changed trough KSP developement and mod development, so it can be anything causing it. I was not 100% sure about exact reasons behind it and didn't want to bother developers with false bug reports if I'm wrong.

[kcs123]

11 hours ago, Toonu said:

Do you think submiting bug report to current developer will fix it in reasonable amount of time or is it more bug of KF....probably KF due to no other mod causing that, so yeah, will submit bug report probably.

There seems to be already opened issue on github:
https://github.com/shadowmage45/KerbalFoundries2/issues/42

You may want to post your craft example and issue description too on github or in KF thread.

[Athur Dent]

is it possible to uninstall this mod without breaking a save? I uninstalled to see the difference for a plane I made, and now my parachutes won't open anymore...

[kcs123]

36 minutes ago, Athur Dent said:

is it possible to uninstall this mod without breaking a save? I uninstalled to see the difference for a plane I made, and now my parachutes won't open anymore...

Yes, but exception might be parachutes. After you uninstall FAR, make sure that FerramAerospaceResearch folder is deleted from Gamedata folder, otherwise MM could apply patches on parts unproperly.
Now, parachutes may be exception because FAR use light version of realchute parachutes. You may want to remove those from craft and put stock counterparts.
Next thing to pay attention is that wings/control surfaces may have different weights due to FAR feature of increasing wing strenght and mass vs stock default fixed weight. therefore COM may shift and planes could not behave properly.

In conclusion, comparing two "same" craft with and without FAR could be like comparing oranges and apples.

[qromodynmc]

I just slapped my 1.8.1 mod folder to 1.9 and it was pretty much working well, except far. So how's everyone doing with 1.9?