[1.8.1] TestLite: TF replacement for RO

[soundnfury]

For a while now, the RealismOverhaul group have been getting frustrated with TestFlight — it's complicated and (at least according to some) hurts performance.  It also has bugs, particularly in techTransfer handling.

So I've created TestLite, a ruthlessly simplified replacement.  It only deals with engines (because those are the only type of failure RO ever used), and it doesn't have the massive extensibility and configurability of TF.  But it's much simpler, and hopefully should be easier to evolve for RO's needs (already it has a feature TF doesn't, "Deterministic Mode", where all engines fail at exactly rated burn time plus 5 seconds, selectable through difficulty options).

It's still quite rough around the edges (in particular, rather than a friendly UI it just dumps a lot of internal variables as KSPField()s into the right-click menu), but it seems to be working.

https://github.com/ec429/TestLite

Edited July 2, 2020 by soundnfury
title - now for 1.8.1

[Nightside]

Great idea. TF always felt unfinished. I look forward to trying it out. 

[soundnfury]

TestLite 0.2 now available.  Main changes:

• More reasonable UI (still PAW-based, but now human-readable).
• Extra Telemetry: option to instrument an engine to get more du out of it.  Useful for development test flights of new engines.  Doubles dataRate, trebles cost.
• Extra Preflight Check: option to carefully check out an engine before launch; useful for manned flights, crucial probe launches etc.  Reduces failures (within burn time) by 25%, doubles cost.

[soundnfury]

TestLite 0.2.1 fixes the cost calculations for the Extra Telemetry and Extra Preflight Check options.

Download TestLite 0.2.1.

[Rauko]

Wonderful!

Can I uninstall TestFlight and install this in a save? Will it use the same "du"s previously gathered with TestFlight?

[soundnfury]

9 minutes ago, Rauko said:

Can I uninstall TestFlight and install this in a save? Will it use the same "du"s previously gathered with TestFlight?

It won't use the same du, no (they're stored in different SCENARIO nodes with a different format).  If you really want to convert a save over, it should be possible to do it (either by hand or with a script); the TestFlightManagerScenario will need to be turned into a ScenarioTestLite.  A short example follows:

        SCENARIO
        {
                name = TestFlightManagerScenario
                scene = 7, 6, 5, 8
                saveData = 
                partData
                {
                        partName = WAC-Corporal
                        partData = flightdata:11086.69,flighttime:610.5604,
                }
                partData
                {
                        partName = SolidFuel
                        partData = flightdata:6414.666,flighttime:188.1555,
                }
        }

would become

        SCENARIO
        {
                name = ScenarioTestLite
                scene = 7, 6, 5, 8
                du
                {
                        WAC-Corporal = 11086.69
                        SolidFuel = 6414.666
                }
        }

Technically this won't be perfectly correct, because TF and TL handle techTransfer differently, but it should be mostly close enough.

[Rauko]

Awesome! Thank you! I will try.

[Flibble]

Hmm interesting, I might give this a go, as you say TF is a bit clunky.

Can I make a request? Can we have static fire testing? So you can get some du on the pad by just firing the engine (maybe capped at half of max or something?) TF doesn't seem to like this - it only updates du once you're actually in flight.

[soundnfury]

4 minutes ago, Flibble said:

Can we have static fire testing?

At least in RO, the reliability configs were all written on the assumption that "0 du" is after static firing.  TestLite does not accrue du until you leave PRELAUNCH.

So if you want additional testing before launching payloads, the realistic thing to do is test flights with boilerplate payloads, battleship upper stages etc.  Those are usually quite quick & cheap to build (payloads are expensive!) and you can turn on Extra Telemetry to get even more du.  Historically, most rockets were first tested in this manner — one of the better-known exceptions was Ariane 5, and we all know how that turned out.

[Flibble]

Just now, soundnfury said:

At least in RO, the reliability configs were all written on the assumption that "0 du" is after static firing.  TestLite does not accrue du until you leave PRELAUNCH.

So if you want additional testing before launching payloads, the realistic thing to do is test flights with boilerplate payloads, battleship upper stages etc.  Those are usually quite quick & cheap to build (payloads are expensive!) and you can turn on Extra Telemetry to get even more du.  Historically, most rockets were first tested in this manner — one of the better-known exceptions was Ariane 5, and we all know how that turned out.

Ahh, fair enough, I didn't realise that was the assumption! I normally test by firing off a test rocket as you say, lead ballast is a handy cheap payload.

I wasn't sure which version of KSP you had built against, so I forked your repo and set up a build config for VS2017 on windows so I could build my own. Worked like a charm.

[Flibble]

Ok, I installed this today, and it;s crashing on load.

Quote

AssemblyLoader: Exception loading 'TestLite': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

Additional information about this exception:

 System.TypeLoadException: Could not load type 'TestLite.UI.AbstractWindow' from assembly 'TestLite, Version=0.2.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'TestLite.Core+<>c' from assembly 'TestLite, Version=0.2.0.0, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type '<>c' from assembly 'TestLite, Version=0.2.0.0, Culture=neutral, PublicKeyToken=null'.
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Full output log: https://1drv.ms/u/s!ApWZXOEZJxA5goJKOxyVmiOKzVRldQ

[Rauko]

It worked perfect for me.

[soundnfury]

44 minutes ago, Flibble said:

Ok, I installed this today, and it;s crashing on load.

Is this the DLL I shipped, or the one you built yourself?  If the latter, are you sure you included UI/AbstractWindow.cs in your build sources?  (It's rather hard for me to debug, sight unseen, a build process I'm unfamiliar with — I've never used VS.)

The DLL I shipped ought to work for you; it was built against 1.3.1.1891 and RealFuels 12.6, which appears to be exactly what you have.

I also notice from your log that you appear to still have TestFlight installed.  While that's not likely to cause this error, it's a bad idea: install either TF or TL, not both.

Edited May 15, 2019 by soundnfury
Instead of, not as well as.

[Flibble]

It's my own DLL. I have UI/AbstractWindow.cs, Core.cs, ModuleTestLite.cs, Util.cs. All builds without any compiler errors.

I'll give your DLL a try to see if there's any differences.

I originally ran it without TestFlight present, I had the same error. That log was from when I tried both, which as you say, was a bad idea.

[soundnfury]

It's since occurred to me that I ended up with a fully PAW-based interface, never used the GUI window bits, so don't actually need them.

Latest push removes them, which might conceivably solve your problem.

[Flibble]

Interesting. I'll give your dll a try anyway (not had time to check it) before I update to the latest version.

[Flibble]

Well, your DLL loads fine, however my flight scene is completely broken with it installed.

[Gordon Dry]

So this is strict for KSP 1.3.1?

No chance to get it for KSP 1.6.1 because there actual RO is?

[soundnfury]

It will need a recompile for 1.6, which will happen when I get around to KSP things again (no idea when that'll be).

@pap1723 did a build and reports that it works fine there, maybe he can hand out his DLL...

[TheRealWiwaxia]

Nice, always thought Testflight was the one causing massive lag when I ignite my engines.

[Flibble]

I built for 1.6.1 and it seems (mostly) fine. I'm still getting odd camera glitches with it installed though - especially when returning to the main KSC scene.

Also, it would be useful to have it disabled when using Krash similar to TestFlight.

[soundnfury]

4 hours ago, Flibble said:

Also, it would be useful to have it disabled when using Krash similar to TestFlight.

I've done what I can towards that already — there are difficulty options to disable or set deterministic mode; Krash just needs to prod them on entering a sim.  That'll be up to @linuxgurugamer to do; I would suggest that by default sims ought to use deterministic mode (but with a setting in Krash to change that to fully disable or leave enabled).

[linuxgurugamer]

1 hour ago, soundnfury said:

I've done what I can towards that already — there are difficulty options to disable or set deterministic mode; Krash just needs to prod them on entering a sim.  That'll be up to @linuxgurugamer to do; I would suggest that by default sims ought to use deterministic mode (but with a setting in Krash to change that to fully disable or leave enabled).

Explain, please

 

[soundnfury]

8 hours ago, linuxgurugamer said:

Explain, please

TestLite has two (relevant) difficulty options, `disabled` and `determinismMode`.  See `TestLiteGameSettings` in Core.cs.  I don't know how to alter these from another mod without a hard dependency, you'll have to work that out yourself.

I think Krash should have a three-way setting:

• default behaviour: in sims, set determinismMode to true.
• full TestLite: leave TL options unchanged.
• no TestLite: in sims, set disabled to true.

If you still have questions, consider asking me on the RO discord for a quicker response.

[linuxgurugamer]

It would be better if you were to provide a public method to set the data.

An additional one to return the current value would also make it easier.

It can be done with Reflection or I can have a separate method which would only be used if this was available

You should also add a setting which says what KRASH should do when starting a sim.