Pehvbot

Experiment Report #1: ModuleCommand I started by stripping out all ModuleCommand modules from the parts and created an inventory item I could add back in. While it sort of works, dynamically adding ModuleCommand has a couple of glitches. Some of them are expected, some of them are a bit surprising. The VAB check will fail, telling you you can't control the craft, even if you have mounted the ModuleCommand (annoying but likely fixable) Kerbals will not be automatically added to manned parts. This is expected. Removing ModuleCommand makes these parts act like crew cabins. Adding ModuleCommand adds the Rename Vessel button but does not put it in the Vessel Naming group as it would with a pre-built ModuleCommand part. The weird one: If you add an unmanned (e.g. minumumCrew = 0) ModuleCommand to a crewable part, ModuleCommand acts as if there's a crew onboard regardless of crew or communications. I assume others have run into this glitch before since it does this even if you add this 'normally'. EDIT: It also borks the alternate control points. It's pretty clear that some MODULEs will need some additional logic get the them working correctly. Anyway, back to the laboratory!

Version 0.03 is now updated on github https://github.com/pehvbot/RackMount It's just a few minor fixes. It adds a requirement for crew and possibly engineers to be able mount and unmount parts. It also adds a broken but functional part lock. If parts are locked, the tooltip (right click) menu for locked parts doesn't work correctly. It will either throw a [EXC error because it can't find the tooltip or it will display the last accessible stored part. Annoying but not fatal, so I'm going to go with it until I can figure out a fix. Now that I have a reasonably functional prototype I'll start really testing things to see how various stock and custom modules work. As expected stock Kerbalism science experiments only work while the craft is active. I'm assuming Kerbalism uses the protopart definition to find available modules when vessels are not active. This probably means processors are also broken. Disappointing but not at all surprising. I expect basically any rackmounted module that runs while a part is on rails won't work.

I think that's a good idea. Implementing it is going to be a bit of a project though. TestFlight simply doesn't have the tools since it wasn't designed with this in mind so it means building it from scratch. It also means I need a better understanding of what KCT does when it recovers a vessel to the VAB. In some ways this is good timing though. I've been working on yet another mod. I'll need to dig into how the VAB/SPH works and how it might interact with KCT in any case. No timeline for this, but it's on my radar. The save game info was very useful. Yes, there's something wrong with the randomizer. Having a good example will help figure it out.

Version 0.02 is now updated on github. https://github.com/pehvbot/RackMount This is a much improved version of the original idea. It's added several new features including The ability to rackmount parts in the VAB/SPH The ability to dynamically rack and unrack parts in flight without removing the part from inventory preliminary RESOURCE support So what's changed? Mostly this adds buttons to mount and unmount parts in the VAB and while in flight, so the PAW would look like this: This removes the need for a custom ModuleCargoPart. To rackmount a part you currently need to add 'rackMountable = true' to both the part and to the modules/resources you plan on mounting, so something like this: //adds reaction wheels to RM @PART[*]:HAS[@MODULE[ModuleReactionWheel],@MODULE[ModuleCargoPart]] { rackMountable = true @MODULE[ModuleReactionWheel] { rackMountable = true } } //batteries @PART[*]:HAS[#category[Electrical],@MODULE[ModuleCargoPart]] { rackMountable = true @RESOURCE[ElectricCharge] { rackMountable = true } } Some of this will likely change in the next update. So how does it work right now? Fairly well. Modules are added and removed dynamically, save their state between loads, retains settings from the VAB (at least for the stock modules I've tested) and resources mostly work. The one, likely unfixable, restriction is that if you are in the VAB, mount a part, adjust the settings, then unmount the part, your changes are lost. When you mount the part again it won't retain your settings. This is a fairly uncommon case and I don't consider this a 'bug', just a minor annoyance. What's still broken? The biggest unresolved issue is the ability to 'lock' parts into place. Currently nothing stops you from moving or removing a part from the rackmount inventory which will break things pretty horribly. I've been experimenting with ways to lock parts but my current approach of setting the UIPartActionInventorySlot 'button' to enabled=false does lock the part in place but it has some nasty limitations and side effects. It breaks the tooltip (i.e. right click) menu for that part and has lots of issues when loading the vessel or changing context such as going on EVA or being in Engineering mode. RESOURCES support is also not quite working. The PAW doesn't seem to update if you add a resource while in the VAB. It works if you launch the vessel or even if you save and reload the craft file, but I haven't been able to force the PAW info to update yet. Simply running UpdateWindow() doesn't seem to work. What's next? Besides fixing the above issues I would like to make it so mounting or unmounting parts in flight needs an Engineer. I'll also be changing how the mod keeps track of mounted parts and some settings. Do you think this thing can actually work? I'm not sure yet but it's looking fairly good. The real problems will happen when vessels are unloaded but still accessed. The biggest test will be something like Kerbalism. I'm pretty sure stock KerbalismConfig will break in all kinds of ways, but if a custom config can be created I would consider that 'working'.

There are a couple of things you can try. The first one is to turn down the randomization by a notch. The setting slider is in the Game Settings->Test Flight. This should do it. You could also change the persistent.sfs 'Seed' value to something else. This will change all the failure curves. It doesn't matter what you change it to. I would just add 1 to the number. Before you do that though, would it be possible for you lot load a craft with that part on it and do a quicksave? If you send me the quicksave.sfs file I can take a look to see why it might be failing.

The planet is round (as far as I can tell) and the stars are symmetrical, so while it's possible the Kerbals have been stretched, the image itself isn't.

Thanks! Yes, it think it could open up a lot of interesting game play options. I'm still banging around with the basic code but I would like to start really testing it soon, especially with third party apps. I did manage to test it on Kerbals themselves and had them running around the KSC taking the temperature of everything :-) There are a few problems because Kerbals are essentially inventory items themselves when on board a craft, but I'm pretty sure it can be made to work. Next up, giving them reaction wheels! Adding arbitrary modules to Kerbals should break the game in all kinds of interesting ways. I'll take a look at your code when I get the chance!

Yes, it can be done that way but there are some problems. The issue with supporting third party mods is that your mod needs to 'understand' the third party mod. There are a couple of ways of doing this but the easiest and most efficient is to add the third party dll into the list of dlls your mod is using. However this creates a problem when you load your game if the dll isn't installed, so it's not good for optional mods. One way to get around this is to create a second dll (called lrtffar.dll for example) containing the needed third party support and only use it if the third party dll exists. Another option is to use something called 'Reflection' which allows you to use a dll you haven't added to your list of dlls at the cost of less efficient and more brittle code. I'm still very much learning as I go forward and I've never used either of these options yet. I would like to add FAR and RealChute support since it's a good way to learn how to do this stuff. I'm leaning towards the first option above which would mean creating a completely new set of modules that get used instead of the stock modules (so something like LRTF_Failure_RealChuteFAR for example). This is the programmatically 'proper' way to do it. Reflection is normally reserved for when you don't have a choice so it's my backup plan in case I can't figure out the first option. Reflection would use the stock MODULE with code more or less as you described (with a lot of fiddly bits in between). Oh and I'm definitely not a programmer either, I just play one in Kerbal Space Program! This is all a learning experience for me.

RackMount is a mod that allows you to dynamically add and remove part modules, resources, and even crew seats by extending the stock inventory system. The current version includes command, SAS, kerbnet access, probe control points, as well as reactions wheels, science experiments and scanners. It uses two possible configurations, RackMountBasic and RackMountAdvanced, set from the GameData/RackMount/settings.cfg file (instructions in file). RackMountBasic is more or less feature complete, it should work with most stock and stock-ish games and in general is meant to play nice with other mods. RackMountAdvanced is much more ambitious, but also much more brittle and still incomplete. It needs much more testing and using it will absolutely break existing saves, so be sure not to open them if you want to try using this. Feel free to play with it, but expect problems with untested mods. https://github.com/pehvbot/RackMount/releases/latest Requires: ModuleManager,Harmony Recommends: KSPCommunityFixes Compatible: Restock,, as well as many parts mods. Tested With: Kerbalism, B9PartSwitcher, Tweakscale Rescaled. They work, but with some limitations and a good chance specific untested configs will break RM. Conflicts with: Tweakscale How does it work? RackMount extends the stock inventory system. The mod looks at parts stored in the inventory. If a part has the ModuleRackMountPart module it will create a 'Rackmount' button for the part. When a part is mounted, any MODULES or RESOURCES in that part with 'rackMountable = true' will be added to the host part. Dynamically adding and removing modules is a big hairy mess. Using the stock inventory system solves a number of the problems with doing this, including: Keeping track of cost, mass, and potential volume issues of adding modules. Retaining 'state' information such as whether experiments have been run, settings for reaction wheels, etc. Because it uses actual parts it's accessible to ModuleManager patches for integration with other mods. What is the current state of the mod? v0.3.1 is a major rewrite of the base code, with a bunch of bug fixes, mod support, and improvements to the UI. What's new? It now requires the Harmony mod to work and changes how you add third party MM configs (see below). It includes a new ModuleCommandProbe part you can add to crewed parts which will give you ground control of parts if the crew are not present. You can now add extra seats in capsules that are large enough to store the new Mk1 Crew Seat part. Just put it in the inventory and rackmount it! It does not adjust the IVA so you will not see your extra kerbals in the crew windows or internal view but they are there somewhere, likely inside a storage closet or behind some of the stowed gear. In addition it now has two 'profiles'. The default RackMountBasic profile allows you to simply add modules to existing parts. The highly experimental RackMountAdvanced profile strips out virtually everything (modules, resources, crew) from a part and allows you to build a custom load out for each part. You can set these profiles in the GameData/RackMount/settings.cfg file. Notes for each below: RackMountBasicProfile RackMountAdvanced Profile [Experimental!] Can I make my own MM patches? Yes, but not every MODULE works correctly and you will need to experiment. A rackmountable part cannot have an inventory of its own (no nested inventories) and must be an inventory item. To create a rackmountable part you need to apply a patch similar to this: @PART[-part-name-here-]:FOR[RackMountConfig] { @MODULE[-module-name-here-] { %rackMountable = true } @MODULE[-some-other-module-name-here] { %rackMountable = true } @RESOURCE[-resource-name-here-] { %rackMountable = true } //needed so only one instance of the ModuleRackMountPart module gets added //actual module is added at the end of the MM patching %addModuleRackMountPart = true } What are your future plans for this? I'm not sure. It's looking a bit more like a viable mod, at least for the basic profile. I'll need to add a few more parts to fill out the parts roster for the advanced profile and do lots and lots of testing. I'm cautiously hopeful. The next step will be to test the basic configuration on as many different mods and setups as I can, figure out what will and won't work, etc. I'll also be working on the advance profile in parallel, but that's much more of a long term project.

v0.7.2 is available. It has a few adjustments to some parts failures, including wheels and aerodynamics. It also improves error handling when a MODULE is changed by ModuleManager after LRTF configs have been processed. It removes parachute failures when FAR is installed until FAR specific failures can be added. https://github.com/pehvbot/LRTF/releases/tag/v0.7.2

Yep, it's FAR replacing ModuleParachute with RealChuteFAR all right. LRTF configures itself for the stock parachutes but can't find ModuleParachute and can't use RealChuteFAR, so it fails. In this case it fails pretty badly. There's a lesson here about doing more error checking in my code that I'm sure I'll forget for my next project. I've updated the LRTF dll so it fails a bit more gracefully (the update will be published in the next day or so) and I'll also see if I can change the MM patches to avoid this problem in the first place, but unless/until I add in support for RealChuteFAR modules, LRTF just won't have working parachute failures. In the mean time this patch will at least clean things up so things will more or less work: @PART[*]:HAS[@MODULE[RealChuteFAR]]:FINAL { !MODULE[LRTFDataRecorder_Parachutes] {} !MODULE[LRTFFailure_ParachuPartial] {} !MODULE[LRTFFailure_ParachuteFail] {} !MODULE[LRTFFailure_ParachuteDeploy] {} }

Thanks for the report! The error comes from the mod looking for the stock ModuleParachute MODULE but not finding it. My first guess is that there's a custom parachute mod such as RealChute installed. If this mod is being configured after LRTF then LRTF sees the stock MODULE, loads all the failure info, but the stock MODULE gets replaced by the new mod later. LRTF doesn't know it's been replaced so it just tries to run, can't find ModuleParachute and poops its pants. If you can send me a link to your ModuleManager.ConfigCache file I can check to see if that is what's happening. If that is the issue then the immediate solution will be to disable parachutes in the Settings/TestFlight window. You won't get parachute failures but your game should work otherwise. Moving forward I'll add in some error checking so if something like this happens it will fail a bit more gracefully. In a perfect world I should add failure modules for things like RealChute but I just may not have the time. Even if this isn't whats going on, I do need to add more error checking for issues like this.

My first guess is that this may be an ordering issue with the part you created. Since it's being created FINAL, after all the LRTF configs, it may be trying to use radialDecoupler for all the configs. It's probably safe to create the part much earlier. See if removing FINAL fixes things. If that's not it, send me the ModuleManager.ConfigCache file and a saved game with an active vessel with this part. I'll see if I can figure out what's going on.

Thanks! I've had a blast (pun maybe intended?) working on it. I'll take a look at Pay To Play when I get a chance. Adding in a built in repair/replace feature is likely outside of my ability and/or time. TF does all the user interface work and doesn't have VAB tools. I do think it might be possible to create a simple button to open the PAWs (part action window) for all the failed parts. This would make it much easier to locate and fix any failed parts with something like PtP.

Yep, the pressure curve is hard coded and the same for all engines. The module looks for dynamic pressure (specifically the Part.dynamicPressurekPa attribute ). It uses this to modify the base ignition failure chance which is based on du. The curve values were lifted directly from StarStrider42's original code and I'm not entirely sure how well they match with real world engines. I've actually removed the dynamic pressure failure from SRBs in the current dev version. I can't find any documentation on this being an issue and it I don't think it makes much sense in any case. Solids typically ignite form the top of the motor and once lit nothing will put it out. You can still get ignition failures, they just won't get worse based on dynamic pressure. If you wanted to keep them you can add in the following script somewhere. @PART[*]:HAS[@MODULE[LRTFFailure_IgnitionFail],#lrtfConfName[Solid]]:AFTER[zTestFlight] { @MODULE[LRTFFailure_IgnitionFail] { pressureCurve { key = 0 1 0 0 key = 5000 1 0 0 key = 15000 0.85 -2.25E-05 -2.25E-05 key = 30000 0.4 key = 50000 0.15 0 0 } } } You can make simple adjustments by tweaking the second values in the keys (0.85, 0.4, 0.15). The higher the values the more reliable the engine. I use this super useful mod to help visualize these curves. You may want to wait until the next version is published though, I've made a few changes in how it orders things.

Got it! It was a bug in my code, but not what I first thought. Your fix pointed me in the right direction: @PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]:HAS[#baseVolume]]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] The script was supposed to look for the amount of fuel stored by ModuleB9PartSwitch using the baseVolume and using that to calculate expected burn times. The problem was it was only looking for the module itself. Because RealFuels sometimes no longer uses baseVolume, the script was trying to do math on something that doesn't exist.

Looking deeper into it, it looks like the original MM script is correct so there may be an issue somewhere else in the process. I'm not getting any error messages and the Bluedog SRBs I looked at seem to work. Do you know which part(s) were not working correctly? I'm not sure if this is related, but one rare problem that's come up is the failure curve isn't calculated properly. LRTF creates a random failure curve for each part in each new save game and once in a while it fails to make a valid failure curve. The TestFlight window gives a 'NaN' (not a number) error for that part.

There isn't much to see in the VAB. If you center click on a placed part you should see things like the number of data units ('du') collected so far for that part and the failure chance but that's about it. This is how TF is designed. The latest versions of TF have removed the (apparently problematic) R&D options. KCT will remember your parts so yeah, there's currently no method for 'clearing' the error simply by recovering it. What I do is reload the entire craft from the saved vessel. Interestingly, by doing this it tends to add some time back to the build process which is a pretty good approximation for the time it takes to fix the part. Ideally there should be an option to reset parts in the VAB but this may be a bit beyond my skill level. Maybe something for a future update?

Good catch! Yeah, that was a typo and your fix is correct. I'll roll it into the next update. Let me know how it goes. Any feedback is super useful. This is still deep in the 'work in progress' phase.

I'm adding this mostly for myself, so I can remember where to look if I need to do this again. The latest version of MacOS has removed the 'checkbox' that allows you to run MacOS apps in lower resolution mode. This means if you run KSP on a Mac with a Retina style screen it can't be upscaled by the OS and will appear very small. The solution is to right click on the KSP.app and select 'Show Package Contents'. This will show the hidden parts of the KSP.app. Open 'Contents' and then open the Info.plist file with a text editor (TextEdit will work). Scroll to the bottom of the document and just before the final two lines insert <key>NSHighResolutionCapable</key><false/> It should look something like this: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> ... [A bunch of stuff up here] ... <key>NSHighResolutionCapable</key><false/> </dict> </plist>

It looks like a glitch to me so I would say 'Cheat'. Open the cheats->contracts menu and complete it that way.

You can disable it from the TestFlight panel in the KSC view. Look for the pull down menu in the bottom right to find panel with the toggle. I forgot which pane it’s in. Look around and you should find it.

Yep. It gives the RP-1 tech tree, contract tree, etc for stock sized worlds.

Yes, but doing this will also break your craft builds and it’s completely untested and means editing the rescale.cfg file. I think there’s a description up thread on some pointers to how to do this A good option might be to use KSRSS, the Kerbal Sized Real Solar System mod instead of RSS. Existing craft should work just fine and LRTR is fully balanced for it.

For what it’s worth the config.cfg file controls most of the RP-1 features and KCT can be turned off from its KSC scene menu. It’s a round about way to do it but you can run it in more or less stock that way.