soundnfury

Members
  • Content Count

    130
  • Joined

  • Last visited

Community Reputation

194 Excellent

About soundnfury

  • Rank
    Modder and Toolsmith

Contact Methods

  • Website URL Array

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think all you need to do is to use reflection to get the TestLiteGameSettings type, then (somehow) the equivalent of: TestLiteGameSettings settings = HighLogic.CurrentGame.Parameters.CustomParams<TestLiteGameSettings>(); if (settings != null) { /* Do things with: * settings.preLaunchFailures; * settings.determinismMode; * settings.disabled; */ } as per the code in TL that does this. However I don't know exactly how one does that in looking-glass-land, as I've never really used reflection.
  2. 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.
  3. 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).
  4. 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...
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Interface screenshots The SPEngine browser; examine families, and designs within each family. Note the tooltip showing Isp, mass and cost. Configuring an engine with a specific design.
  10. TestLite 0.2.1 fixes the cost calculations for the Extra Telemetry and Extra Preflight Check options. Download TestLite 0.2.1.
  11. Now out: S. P. Engine 0.1.1. With six new engine families, and a bunch of quality-of-life bugfixes. E-class: Large hypergolic vacuum engine. (Like LR91, Titan II and later.) N-class: Large staged-combustion kerolox engine. (Like NK-15 family.) T-class: Large hypergolic atmospheric engine. (Like LR87, Titan II and later.) X-class: Kerosene/peroxide pump-fed engine. (Like the British Gamma and Stentor.) Y-class: Large staged-combustion kerolox vacuum engine. (Like NK-15V family.) Z-class: Throttleable hypergolic vacuum engine. (Like LMDE.) Supports TestLite ≥ 0.2.1. For KSP 1.3.1 with RealFuels 12.6. Download Simple Proc Engine 0.1.1.
  12. 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.
  13. 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
  14. I've just finished work on the X-class: HTP/Kerosene engines based on the Bristol Siddeley Gamma. An interesting quirk of the Gamma is that it only has one-axis gimbal: Gamma chambers were clustered in opposed pairs to give roll-and-pitch control (Gamma 2 upper stage) or three-axis control (Gamma 8 booster). So here's a procedural Black Arrow I've been experimenting with: I've found, sadly, that neither stock SAS nor RemoteTech can figure out how to control the upper stage; smarter avionics will be required. The Z-class throttleable hypergolic engine (LMDE) is also in for the next version.
  15. Yep, LR87 is already in for the next version (T-class, along with the E-class LR91), and Proton's closed-cycle hypergolics are on the roadmap as the P-class. (It took me a while to get round to them, as I don't tend to use big hypergolic stages when I play.)