Aelfhe1m

Release: v.1.2.6 Recompiled for KSP 1.2.1 Updated toolbar wrapper Toolbar PR #39 Not tested with Kerbal Konstructs or KSCSwitcher This build was a bit delayed as I was also playing around with optimising performance and garbage collection but those aren't ready yet so I decided to just push a minimal update in the meantime.

LOL the AVC warning list was taller than my screen and checking the summary window in the top left almost everything was yellow with only a handful of green entries. Would have been alarming if I wasn't expecting it.

Looks good so far. I gave it a try on a clone of my heavily modded 1.2 save and apart from a wall of AVC compatibility warnings on loading (which I expected) everything looks fine. One mod was throwing exceptions into the log for OnGameSettingsApplied events but it didn't appear to affect the functionality of its parts or UI. Seems to have worked. Spent a bit of time in the VAB and where before the parts list flickered regularly and the App buttons were permanently glitched, I saw no problems with the new version. Thank you! Thank you! Thank you! Not being able to adjust manoeuvre nodes easily with window based editors was really frustrating - now it works like it used to.

@taniwha Just an FYI that the latest EPL is throwing an exception in the KerbalStats wrapper that looks very similar to the toolbar one from a few posts ago:

Update to EPL 5.5.2. It has a fix included for the toolbar button issue.

No, they don't

Recent changes to USI seem to have broken the BaseSelfSufficiency contract. Log snippet below: There's no longer a USILS_Greenhouse part but instead USILS_Greenhouse_Sm, USILS_Greenhouse_250, USILS_Greenhouse_Cupola, USILS_Greenhouse_Inline, USILS_Greenhouse_Lg, and USILS_Greenhouse_MiniCupola. There are also various agriculture modules in the MKS package.

@RoverDude First of all thank you for your rapid update of all the USI mods for 1.2. But ART still seems to have a reference to KSPUtils - log extract follows:

Looks interesting. If I'm reading the code right this takes the training cost from your "banked" science rather than the science generated in the lab. I've finished the tech tree and have turned on the "patent licensing" strategy to convert science into funds so I'm not generating any new banked science. It would be nice to have an option to take from the generated science instead of the banked total.

Well since no flown F1 ever had a failure (that I can find) what would you set the TestFlight values to?

Everything except the Squad folder from GameData.

Another option is Atom which also has a syntax highlight package for kOS.

Real Fuels is licensed as CC-BY-SA so you can reuse and re-purpose their code provided you give appropriate attribution. Whether it's useful will depend on just what your own plugin is trying to do.

In principle. Real Fuels does this based on chosen settings within the engine part itself but there's no reason you couldn't get your custom engine module to read values from another part instead. You would of course need robust error handling for a case where user forgot to add a needed part to the vessel or tried to configure things out of the intended sequence.

From within a PartModule you can do: this.part.parent to get the parent part in the hierarchy.

I was able to mitigate this using Memgraph. Using the pad heap feature my RP-0 went from a 2-3 second interval between garbage collections in flight to over 70 seconds. Much more playable.

For saving to/loading from the save file use a scenario module. A simple example would be KSC Switcher which loads and saves a single value using this code. Current level of building: I've never tried but a quick look in VS object browser suggests ScenarioUpgradeableFacilities.Instance.GetFacilityLevel(BuildingName) I generally look at existing mods that I think might be doing something similar or manipulating objects I need. Also object browser and intellisense in Visual Studio Not from the save file but the mod TotalTime keeps track of this.

You could maybe use a custom date formatter. Like RSSTimeFormatter. I haven't looked into whether this affects the internal stored days in year etc. or just how they are formatted for display.

Each of the :partstagged(), :partstitled(), :partsnamed() and :partsdubbed() suffixes always returns a list. In the RemoteTech example it assumes you want to target the first item in that list directly hence the set p to ship:partsnamed("mediumDishAntenna")[0]. syntax. Your final working code is almost the same just using tagged instead of named and with a temporary list instead of a direct reference. Re-writing it more like the example we get: set p to ship:partstagged("ant25")[0]. // get first part with the tag "ant25" set m to p:getmodule("ModuleRTAntenna"). // get the antenna module m:doevent("activate"). // send command to module to activate antenna It's the same code really. Just phrased slightly differently. There is no real difference in the documentation between :suffix("x") and :suffix(y). The first example is just using a literal string and the second a string variable that is presumed to have been set to the correct value. Commonly in documentation a dummy variable is used like this instead of a literal string to represent the range of possible values rather than one specific example i.e. set p to ship:partstagged("ant25"). is the same as set tagName to "ant25". set p to ship:partstagged(tagName). but if the documentation refers to :partstagged(tagName) then it should be clearer that the string parameter is a "tagName" rather than just some arbitrary string.

Well it is optional in that there's an alternative model pack

Assuming you also installed a part pack (IR has been split into main mod + parts) then you should find them in the three Actuators nodes

For RemoteTech antennae: https://ksp-kos.github.io/KOS/addons/RemoteTech.html

@nightingale I tried to test the microstutter issue on a clean install of a minimum set of RP-0 mods but nothing very definitive I'm afraid. Set-up: totally clean copy of 1.1.3. Using CKAN add RSS with low-res textures; add RO (required mods only no recommended or suggested) and then RP-0 (again required only). Ran the game three times creating a new normal difficulty career save each time. The same simple sounding rocket craft file was copied into each save after it was created. Save A. Left everything at defaults and accepted initial contracts (launch vessel and pass Karman line). Perceptible microstutters approx every 4 seconds Save B. Used CC toolbar icon to disable all contracts immediately after load. Microstutters still present could not detect any difference in duration or spacing. Save C. Deleted CC folder from GameData before launching KSP. Could not detect microstutters on initial rocket launch.

You can use ModuleManager to clone an existing part to create a new named part and add the new science module to that. Or write a new science module that defaults back to the stock behaviour when not in your custom biomes and use MM to replace the existing science module in parts with your module.

The situations used by the default science experiment module are hard coded and can't be modified. For what you appear to be planning you'd need to write your own science module and add custom biome detection code to it. For example look at DMagic Orbital Science's code for the bathymetry experiment.