Test of continuing KER developments [0.24.2]

[NathanKell]

Found it:

The RF modules all sit beside the ModuleEngines[FX] module or ModuleRCS module. They directly change the engine's maxThrust (and minThrust if >0) or thrusterPower based on realIsp. Here is how I would suggest you proceed (it's how I wrote the patch for MJ): You already check both atmospheric (i.e. sea level) and vacuum performance. When you do so in the VAB, you need to (in atmo stats) multiply the engine's thrust by IspSL / IspV. You should also output a column for "sea level TWR" and use that modified thrust instead of the actual maxThrust. Vacuum stats will be correct. When you do so in flight, when getting thrust for the atmosphere (i.e. sea level) stats, you need to multiply the engine's current maxThrust by IspSL / engine.realIsp. When getting thrust for the vacuum stats, you need to multiply the engine's current maxThrust by IspV / engine.realIsp. You need to decide whether, in reporting an engine's max thrust in your inflight GUI, you want the max thrust at current Isp/atmo density, or the max thrust period. If the latter, do the vacuum stats conversion. Finally, if you do anything in regards to RCS deltaV, you need to check what fuel type the thruster actually uses, not just assume it's MonoPropellant. Now, regarding implementation, just seeing if part.Modules.Contains(a RF module) should be enough. If you create a confignode-based list of modules which, if detected on a part, will tell you that the engine has thrust correction enabled, that would probably be the easiest. Then when I add my new MultiMode-supporting module I can just use an MM patch to update that list, or you can, without needing to change code. There is one wrinkle with all this. While it's not really used yet, I added support for locally disabling thrust correction (also globally disabling it, but the same var can be checked). You need to check public bool ModuleEngineConfigs.localCorrectThrust (or ModuleHybridEngine.localCorrectThrust) and if false, don't correct thrust.

[Padishar]

Ok, thanks for that. When I said about directly changing the engine's thrust members, I meant does RF actually change the thrust members in the ModuleEngine[sFX] objects on the fly. I guess not from the description you've given of how to adjust the thrust...

I've had very little experience of KSP/Unity modding, I only started playing in the last week of 0.22, so I'm going to have to take a careful look at how KER behaves with RF (add lots of logging to the engine setup code) and how best to make the changes to fit in with the way the simulation currently works. I'll also need to work out exactly what the various thrust values KER displays are as only some of them should probably be changed. I'll set up a separate install for testing with RF so are there any other mods that you would recommended I run with it or that will definitely need explicit testing, e.g. certain new engines (ModuleHybridEngine) etc.? I'm using a 32bit windows laptop so I may not be able to run a lot of big mods.

[Padishar]

Another optimisation update. Avoids 3 scans of the entire part list on every iteration of the simulation.

[NathanKell]

Sorry, I wasn't clear. It does do this by directly changing the ModuleEngines[FX].maxThrust field. That's why the instructions for how to calculate stuff for KER in-flight is different than in VAB/SPH; in the editor, the engine maxThrust is its actual max (i.e. in vacuum), whereas in flight engine.maxThrust is set (by the ModuleEngineConfigs that sits beside the engine module on the part) based on realIsp.

I've been forced to run KSP on my 2.5-year old (and slow then) laptop with no real issues, other than yellow MET and the slowdown that implies, for much of the last six weeks. It's certainly possible. For that reason you might want to just try the whole Realism Overhaul pack from the Bundler thread: http://forum.kerbalspaceprogram.com/threads/67668

[Padishar]

Ahhh, I see, that makes more sense, thanks. I'll have a go at setting up the realism overhaul pack and see how my machine copes...

[malkuth]

going to try this out. Engineer seems to be behaving worse and worse as I add more types of engines. And it seems to not like Stretchy tanks much.

[maabaa]

Edit : no problem, piping was wrong.

It works great, thank you !

Edited March 31, 2014 by maabaa

[BudgetHedgehog]

I think this version works for 0.23.5... I'm getting a readout on those LFB's, at any rate and as far as I can gather, it doesn't do that in the normal KER code.

[Padishar]

I think this version works for 0.23.5... I'm getting a readout on those LFB's, at any rate and as far as I can gather, it doesn't do that in the normal KER code.

Yes, I can confirm this. The new code doesn't suffer from the problem with the LFBs in 0.23.5 (and is generally more stable in a number of other areas).

Edited April 2, 2014 by Padishar

[AgentPaper]

"It works great. Thanks"...

[AlexinTokyo]

Posting to flag this thread for myself.

Actual testing will occur when I get home from work.

EDIT: Downloaded, testing to start after food

Edited April 2, 2014 by AlexinTokyo

[zeppelinmage]

Tonight I was playing around with the new ARM patch and the Kerbodyne large rocket parts. I built an asteroid encounter craft and a way over-engineered lifter. I found a small issue with KER displaying delta-V values for all my stages. I was able to fly the craft fine, and the delta-V value for "stage 5" read properly as it launched, with a final in-orbit delta-V that made sense.

Pic in the VAB, displaying delta-v values as expected:

Pic on the launch pad, only displaying delta-v for stages 5 and 1. The numbers look like it's not "asparagusing" the stages properly. It should read ~5000 (atmospheric) delta-V if it was adding them up into one stage.

And for completeness, here's my craft.

(Also, I'm pretty sure I'm about a version behind on these updates... but this behavior is definitely just since 0.23.5.)

Edited April 2, 2014 by zeppelinmage

[Padishar]

Thanks, zepplinmage, I noticed something similar myself last night. I was running a special version that outputs lots of logging but it was in the middle of quite a long session (4 trips to asteroids), my output_log.txt was over 70 meg in size and it was a bit late to go hunting through it to find the problem. I'll try and take a look at it later today...

[AlexinTokyo]

Initial testing completed (VAB and Launch - Vessel Stats):

ÃŽâ€v calculations appear fine for both old and new parts.

Simple staging appears OK.

Asparagus staging appeared OK for me at first, but zeppelinmage's issue was reproduced.

Detailed testing reveals that struts seem to be the culprit:

Asparagus test craft in VAB:

Same vehicle on pad:

Same vehicle on pad with all struts removed:

Craft File with struts.

Please feel free to PM me if you need any further details.

Testing continues:

Definitely struts causing the problem:

Basic testbed vehicle in VAB:

Same vehicle on the pad - correct ÃŽâ€v stats:

Added lateral struts only (VAB):

On the pad - still correct:

Added radial struts (VAB):

Broken (pad):

Removed the lateral struts (VAB):

Still broken:

Craft File

*If all the relevant data is cut off in the forum images, you can 'open' them to view the whole pic.

In unrelated testing:

SRBs result in NaN for Isp:

Edited April 2, 2014 by AlexinTokyo

[Padishar]

Thanks for the detailed report, it should make it much easier to work out where the problem is. It looks like, in flight (or on the pad), the struts are allowing fuel to flow so stage 3 burns all the fuel from the central tank first and then burns the radial tanks. After staging there is no fuel left in the ship so no more stages show up...

I'll check it out later this evening. I haven't seen this in 0.23 but there have been some reports of strange asparagus behaviour so it may be a core game change but is probably just an oversight in the new simulation code...

[Daze]

Good job, it works perfectly on ARM Patch

[TheSpaceKing]

It doesn't seem to like non-standard-fueled engines - I.E the monopropellent engines from RLA Stockalike won't display.

Edited April 2, 2014 by TheSpaceKing

[Padishar]

I have just updated the download link in the first post. The main change is to fix the strut fuel flow issue reported by zepplinmage and AlexinTokyo. There are also some other tweaks and the beginnings of the RealFuels support (no visible change yet but it should detect RF correctly).

[AlexinTokyo]

Wow, quick fix!

I'll test again this evening and report back.

[zeppelinmage]

Looks to be working on my side. Nice work!

[AngusJimiKeith]

It doesn't seem to like non-standard-fueled engines - I.E the monopropellent engines from RLA Stockalike won't display.

I can confirm this. It doesn't like Monopropellent fueled engines OR Xenon fueled (Ion) engines anymore. There was I line in the .23.5 changelog that stated Squad tweaked fuel flow for Monoprop and Xenon, that's probably the culprit.

[bwheatley]

Works for me!

[AlexinTokyo]

Confirmed that the struts/asparagus issue is fixed.

Confirmed that the SRBs show NaN for Isp is fixed.

Unfortunately, also confirmed that no reading at all is given for ion engines, both in the VAB and in flight/on the pad.

[Padishar]

I have already implemented the fix for the Xenon (and monopropellant) fuel flow changes but it hasn't been tested at all so the release won't happen until this evening sometime.

The changes are available in my GitHub branch if you're desperate but, as I knocked up the fix in a spare 10 minutes during lunchtime, don't be surprised if it doesn't work properly...

[Padishar]

I managed to find a spare few minutes to give it a quick test and it appears to work correctly with ion engines (I haven't tested monoprop engines but they should work exactly the same) so I have updated the zip linked in the first post...