[WIP] RackMount - Inventory based Module Management - v0.2.0

[Pehvbot]

RackMount is a mod that allows you to dynamically add and remove part modules 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.   While functional, this is a very early and incomplete version of the mod.

https://github.com/pehvbot/RackMount/releases/latest

Requires: ModuleManager,Harmony
Recommends: KSPCommunityFixes
Conflicts with: Kerbalism

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.2.0 is a significant update to the mod.  It includes parts for mounting most command style MODULEs, fixes lots of bugs and issues.  It will enable you to rackmount command, SAS, kerbnet access, and probe control point modules as well as science and scanner parts in to command parts and add extra crew seating to larger crewed parts.  It should now be stable enough to use without fear of ruining a save game.

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

Spoiler

This is the default profile and should work relatively well with stock and stock-alike games.  It modifies existing command parts by either adding or slightly expanding their inventories.  It includes a number of specialized parts.  Parts vary in size and weight depending on their era and capabilities.

• Telemetry and Launch Control Units (Mk I, Mk II, and Mk III).  These will enable probe control on manned parts and because of some issues with the stock ModuleCommand module, it uses a custom ModuleCommandProbe module instead
• Mk I Crew Seat.  This can be added to parts that are large enough to create a 'jump seat' to add an extra Kerbal or two for that part
• KerbNet Access (Mk I, Mk II, Mk II BIOME,  Mk III, Mk III GROUND, Mk IV, and Mk IV FLIGHT) allow you to add KerbNet access to manned parts
• Stability Assist (Mk I Level 0, Mk II Level 1, Mk III Level 2, and Mk IV Level 3) allow. you to add SAS to manned parts.
• Probe Operator Navigation Guide (Mk I and Mk II) allow you to place probe control points to parts without them.

It also allows you to add some resources and resource converters to command parts, including mono propellent, liquid fuel and oxidizer,  electric charge,  and fuel cells.  Non-stock resources will be tested and added over time.

RackMountAdvanced Profile [Experimental!]

Spoiler

The advanced profile is incomplete and highly experimental.  It removes virtually all components from a part (modules, resources, crew seats) and adjusts the mass and inventory space based on the size of the model.  It also adds several new parts:

• Crew Controls (Mk I, Mk II, and Mk III) to add ModuleCommand to parts (you will need to add seats since these are for manned parts only)
• Airlock (Mk I).  You cannot exit parts above 20,000 without installing an airlock.

In order for this config to work it needs to dynamically create a part based on the original 'empty' part.  This is still very experimental since it in effect adds new parts to the game as you go along.  For example if you select a Mk1 Lander Can in the editor, add a seat, crew controls, etc and launch the vessel, it creates a part called something like landerCabinSmall-f71cab36-fa81-4583-923e-739fd9eaf61b, a second part might be called  landerCabinSmall-a3a445f8-53ca-4d5a-a334-1428f27fe4b3.  As far as KSP is concerned these are completely different parts with completely different configurations (e.g. it's AvailablePart).

Using the RackMountAdvanced profile will absolutely break an existing save game, so use it with care and don't expect it to work well in 'real' game play.

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.

 

Edited March 29, 2023 by Pehvbot

[610yesnolovely]

This is a very cool idea indeed! I could see a whole host of things that could be used for this - rack mounted science is the obvious one, but also EVA fixing of satellites - eg. telescopes. One mod (Cacteye I believe) sort of does something like that.

Quote

• Removing modules throws an ArgumentOutOfRangeException exception for the first ModulesOnUpdate call.  It seems mostly harmless, but it will need to be fixed.

I had a somewhat similar "could be an issue" in Reviva, which dynamically adds/removes RPM and/or MAS computer modules in-flight - in order to remove or add modules, I made sure to keep them at the same module index - from memory the module add/remove operations are kinda weird, and I'm not 100% sure, but I think module indices may be used by some systems:

https://github.com/harveyt/reviva/blob/bd3c8f96a67f62cb5691abf6aa23f1cce552acfd/plugin/BaseComputer.cs#L185

This might help (or might not), feel free to copy any code (a comment to say where from might be good though). The idea was to first destroy the module, which probably leaves a gap in the module list, then add the module using the API which would correctly updating counts and table sizes, but would always appened.  Then if it wasn't at the right index, to remove it and manually add it back at the right index if possible. Kinda hacky, but it seems to work. The above code probably only works because the previous module is always destroyed, for your case adding/removing dynamically is probably much more complex because there might only be adds or removes.

It's somewhat complicated by the fact the part.Modules is actually a class PartModuleList and you can either use Part.RemoveModule() or PartModuleList.Remove() - brain cannot remember, but they're slight different in what they do. Lots of trial and error :-(

My guess is somebody like @blowfish(author of B9PartSwitch) will probably know way more (and more accurately/correctly) about such things.

Edited July 25, 2022 by 610yesnolovely

[Pehvbot]

On 7/25/2022 at 2:41 AM, 610yesnolovely said:

This is a very cool idea indeed! I could see a whole host of things that could be used for this - rack mounted science is the obvious one, but also EVA fixing of satellites - eg. telescopes. One mod (Cacteye I believe) sort of does something like that.

I had a somewhat similar "could be an issue" in Reviva, which dynamically adds/removes RPM and/or MAS computer modules in-flight - in order to remove or add modules, I made sure to keep them at the same module index - from memory the module add/remove operations are kinda weird, and I'm not 100% sure, but I think module indices may be used by some systems:

https://github.com/harveyt/reviva/blob/bd3c8f96a67f62cb5691abf6aa23f1cce552acfd/plugin/BaseComputer.cs#L185

This might help (or might not), feel free to copy any code (a comment to say where from might be good though). The idea was to first destroy the module, which probably leaves a gap in the module list, then add the module using the API which would correctly updating counts and table sizes, but would always appened.  Then if it wasn't at the right index, to remove it and manually add it back at the right index if possible. Kinda hacky, but it seems to work. The above code probably only works because the previous module is always destroyed, for your case adding/removing dynamically is probably much more complex because there might only be adds or removes.

It's somewhat complicated by the fact the part.Modules is actually a class PartModuleList and you can either use Part.RemoveModule() or PartModuleList.Remove() - brain cannot remember, but they're slight different in what they do. Lots of trial and error :-(

My guess is somebody like @blowfish(author of B9PartSwitch) will probably know way more (and more accurately/correctly) about such things.

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!

[Pehvbot]

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'.

 

[Pehvbot]

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. 

 

[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!

Edited August 4, 2022 by Pehvbot

[Pehvbot]

Experiment Report #2: Experiments!
ModuleScienceExperiment was used for my first tests and they seem to work just fine.  There are a couple of interesting quirks.  Science parts with interactions throw an error if I don't remove the  FxModules values from them.  Also the interactionRange is too short for some experiments if you place experiments inside 2.5 size parts such as the mk2 lander can.  It took me a bit to figure that one out. 

ModuleScienceContainer also seems to work fine (again with the range issues).  Containers can be unmounted and move and will retain all their stored data, etc.

ModuleScienceLab.  ModuleScienceLab requires a ModuleScienceContainer in the same part and it needs to be hard coded for the index number, something that will change depending on the other rackmounted parts.  Another example of a MODULE needing some logic to work. 

ModuleScienceConverter.   I never had a chance to test this due to the index issue above and just running out of time today.  Maybe later.

[Stone Blue]

10 hours ago, Pehvbot said:

...and it needs to be hard coded for the index number, something that will change depending on the other rackmounted parts.  Another example of a MODULE needing some logic to work.

yeahhh... just in my amateurish dabbling in modding, I've run up against module indexing issues...
It really *IS* a big PIA for modding

[Pehvbot]

Experiment Report #3: Communications and Scanning
Both ModuleDataTransmitter and ModuleKerbNetAccess seem to work normally. 

ModuleGPS, ModuleResourceScanner,  ModuleBiomeScanner, and ModuleAnalysisResource seem to work correctly.  However both ModuleAsteroidAnalysis and ModuleCometAnalysis throw System.NullReferenceException exceptions when first launched, but not when unmounting/remounting a part, loading from a saved game, or even reverting to launch.  It doesn't seem to cause problems, but it would be nice to know what's going wrong here.

One side note:  Adding or removing MODULEs from vessels with existing and mounted rackmount parts cause index issues, including craft saved in the VAB and presumably sub-assemblies as well.  I'm not sure if this would be a case of doing things smarter in the DLL or just saying "don't do that" to mid game changes to rackmountable parts.

On another side note:  If you try to rackmount a part with it's own rackmounted modules, it dies a horrible death.  You can build pre-assembled parts such as a probe core or science bay, but you would need to add it as a separate part using engineer construction mode.   I don't plan on fixing this since recursive inventory and module management is the stuff of nightmares.

Edited August 5, 2022 by Pehvbot

[Pehvbot]

Version 0.04 is now updated on GitHub.

https://github.com/pehvbot/RackMount

This has a few ModuleCommand fixes including adding the Vessel Renaming  menu for command parts and enabling control points.

It also dynamically generates volume info for both RackMount inventories and for rackmountable parts.  These values can be overridden of course.

[Pehvbot]

Experiment Report #4:  Misc and final conclusions for stock modules
I tested basically every applicable stock module.  Most worked fine.  Only three of them had significant issues. 

• ModuleCommand has a few problems:  Control points don't work by default but can be added in by this mod.  Similarly the Vessel Rename widget doesn't appear by default but can be added by this mod, with the small glitch that removing the ModuleCommand does remove the Event button but it does not remove the group, so you end up with an empty group in the PAW.   There's also an issue with unmanned ModuleCommand in parts with a crew capacity.  Setting minimumCrew=0 in a crewable part allows it to be commanded as if crew were present regardless of actual crew.  This can be fixed a bit by restriction some rackmountable part to specific categories of host parts.  So a rackmountable part can be restricted to only crewed host parts.
• ModuleScienceLab (the manned science module) likely won't work.  It is hard coded to a ModuleScienceContainer and even if this is changed in code, it throws OnLoad and OnSave errors. 
• ModuleDataTransmitter only operates when the craft is active. 

Overall I found that:

• ModuleAblator - works but might be useless.  It didn't seem to do much.
• ModuleAnalysisResource - works
• ModuleAsteroidAnalysis - works
• ModuleBiomeScanner - works
• ModuleCometAnalysis - works
• ModuleCommand - works but requires extra logic
• ModuleDataTransmitter - only works when active.  does not work when 'on rails'.
• ModuleEnviroSensor - works
• ModuleExperienceManagement - works
• ModuleGPS - works
• ModuleGenerator - works
• ModuleKerbNetAccess - works
• ModuleOrbitalScanner - works but throws a NullReferenceException (no animation?)
• ModuleOrbitalSurveyor - works
• ModuleReactionWheel - works
• ModuleResourceConverter - works, even when on rails!
• ModuleResourceDrain - won't find resources to drain
• ModuleResourceScanner - works
• ModuleSAS -  works
• ModuleScienceContainer - works
• ModuleScienceConverter - unclear, ModuleScienceLab didn't work
• ModuleScienceExperiment - works
• ModuleScienceLab - doesn't work.  Problems with index for container and onload errors.

Overall this means that the mod might be useful for some MODULES but with some obvious restrictions. 

There are still some unresolved problems.  The biggest one is that I still don't have a good way to lock rackmounted parts into place.  There doesn't seem to be a way to disable the slot without disabling its ability to supply tooltip info for that part.   This isn't fatal, but it's not good enough for an actual mod. 

[SkyFall2489]

What would it take to rack-mount RESOURCE nodes as well as MODULE nodes? Doesn't seem to be much harder, but I have 0 experience with DLLs.

[Pehvbot]

11 hours ago, SkyFall2489 said:

What would it take to rack-mount RESOURCE nodes as well as MODULE nodes? Doesn't seem to be much harder, but I have 0 experience with DLLs.

It's pretty easy actually.  The current version has a bare bones version of this.  The hard part is removing it again after its values changed.   If it's just one mounted part, you just remove the resource from the host part and update the stored value in the inventory.  If you have more than one mounted part or the host part also has a built in value, you need to figure out how to distribute the total between what's still on the part and the stored item.  Right now the mod just distributes it proportionally but it should also know how to favor the host part or favor the stored part.

[Pehvbot]

Version 0.05 is now available on GitHub. 

https://github.com/pehvbot/RackMount

This is mostly a cleanup and refactor of some of the code with no new features added.

[Pehvbot]

Version 0.06 is now available on GitHub

https://github.com/pehvbot/RackMount

This update fixes the ModuleCommand issues with a slightly ugly workaround.  It doesn't remove the existing ModuleCommand but it does disable it OnLoad.  If a ModuleCommand part is rackmounted it adds a new and working ModuleCommand.  This solves the issue where a part without ModuleCommand fails the craft check when launched.  It also adds in partType and requiresPartType.  For example 'requiresPartType = Unmanned' rackmount parts can only be mounted in 'partType = Unmanned' host parts.  Finally it also retains the INTERNAL ModuleDataTransmitter modules to get around the problem with transmitters not working while on rails.  Since it only works when there's a working ModuleCommand we can assume for game play that the rackmounted part has both the command and the communications all in one part.  It's not as flexible as I would like but it solves more problems than it creates.

[Pehvbot]

Version 0.07 is now available on GitHub

https://github.com/pehvbot/RackMount

This update (finally!) fixes the problem with throwing an exception when mousing over rackmounted parts by... ready for this...hiding the part when it is mounted.  Ta Da!  I wasn't able to slay the dragon but I was at least able to hide from it.  I think this means making a few changes to how the mount/unmount button looks, but it's probably better this way in any case.

This was the last piece of the puzzle for creating an actual mod.  I think with the next update this will be moved into a work in progress.  It'll be slow progress to be sure, but progress.

Edited September 13, 2022 by Pehvbot

[Pehvbot]

Experiment Report #5:  Making a functional mod?

I created a minimalistic version that only added science experiments and sensors from science parts as a sort of first draft of an actual functioning mod.  It converted existing inventory slots in manned parts and added small inventory slots in unmanned parts.  For stock science this seems to work quite well.  I started throwing other mods at it just to see what happens. 

• Kerbalism:  As I discovered earlier, Kerbalism experiments won't work while the vessel is on rails (unloaded).  It also throws a null reference error for modules HardDrive and Habitat if a Science module is rackmounted when the craft is first launched.  It's unclear if this can be fixed without either changing Kerbalism itself or creating a Kerbalism add-on dll.  That's a problem for another day. 
• KSPCommunityFixes:  KCF's fix for properly adding MODULEs mid game interferes with RackMount adding modules.  This feature can be disabled by MM patch but it would be nice to be able to do this on a part by part basis with something like 'ignoreModuleIndexingMismatch = ModuleRMInventoryPart'.  Again a problem for another day.  KCF also has a fix for ModuleInventoryPart in 1.12.3 which are not properly updating.  This update needs to be applied to ModuleRMInventoryPart.  Finally it adds some extra info on inventory parts in the Inventory Group it creates.  I should add this as well.
• ScienceAlert:  I wanted to test if a mod like this sees rackmounted experiments and it does!  The only issue I found was that if you mount a part in flight you would need to re-enter the vessel (going to another craft, EVAing, going back to the KSC) for the new experiment to be seen.
• SETI-MetaModPack:  Figured I would throw the kitchen sink at it and see what happens.  It seems to work just fine.
• DMModuleScience:  Finally, I threw Less Real Than Real(ism) just to see what happens when you use DMModuleScience experiments.  That worked as well, it also showed that rackmounted experiments can be added to Action keys.

 

[Rutabaga22]

The way I see this being useful is in sounding rockets. Imagine you have a rackmount nose cone, then you can add avionics, science, power and a parachute all in one part!

[Pehvbot]

Version 0.1.0 is available for download.  This is the first 'working' version of the mod and makes a few changes to how things work.

https://github.com/pehvbot/RackMount/releases/tag/v0.1.0

This makes science and scanner parts rackmountable and adds a small amount if inventory to unmanned command parts so smaller science parts can be mounted.  Unfortunately parts with inventories can't be cargo, so small probes can't be stored in other parts.

Edited September 16, 2022 by Pehvbot

[Pehvbot]

Inventory shenanigans:  The KSP inventory system is peculiar and, well, buggy.

Exhibit #1:  KSP 1.12.3 has a fairly significant bug addressed by KSPCommunityFixes.  I even rewrote the mod for v0.1.0 to take advantage of these fixes.  The strange thing to me is that the changes I made to enable this bug fix... fixed the bug without needed the KSPCommunityFixes bug fix.  Frankly I have zero idea how this fixed things.  I think the bug is related to the inventory module not properly running updates, so my guess is my mod is forcing updates to happen in order to keep track of changes to the inventory.

Exhibit #2: KSP does not allow you to store a part in the inventory if it can itself store parts in it's inventory.  It simply disables the ModuleCargoPart MODULE (the one that allows you to store a part) when the game loads.  However, if you create and use a copy (subclass in c# speak) of the ModuleInventoryPart MODULE, then it doesn't get disabled so the part can be stored in inventory so you can have nested inventories.  I'm assuming Squad disabled this feature because it creates a bug or exploit.  I haven't looked deeply enough into this yet to figure it out but being able to store rackmounted sub-assemblies would be super useful.  I need to dig a bit more to see what exactly is going on.

Exhibit #3: The inventory for Kerbals is the same as for parts.  In theory you can rackmount items onto Keberals.  I've already experimented with them running around the KSC taking the temperature of everything.  However for some reason KSP adds an extra step for Kerbals where it seems to unload inventory parts and reloads them again.  Normally this is invisible but it has the effect of resetting the part's peristantId.  RackMount uses the persistantId to keep track of things so changing this number screws up the mod.  I would need to rewrite how it keeps track of parts  to allow Kerbals to rackmount things.

[JadeOfMaar]

On 9/14/2022 at 6:19 PM, Rutabaga22 said:

and a parachute all in one part!

Umm, no. The parachute is not going to pop open from inside the inventory. And the parachute is not going to have inventory slots for you to rackmount into it.

[Pehvbot]

Version 0.1.1 is available for download. 

https://github.com/pehvbot/RackMount/releases/tag/v0.1.1

This version adds a new version of ModuleCargoPart which allows parts with an inventory to be manipulated in construction mode.  It also has an advanced tweakable option to allow the part to be stored in another inventory part.  This is experimental and likely has some game play issues, including losing funds if a part is stored in an inventory and has inventory items itself when it's recovered.  

It also adds support for KerbalEngineer parts.

[Pehvbot]

Experiment Report #6:  Crew Seats.

No published updates for the mod, but some interesting results with dynamically adjusting crew capacity.  It turns out you can dynamically change seating but it comes with some significant restrictions. 

It's fairly easy to use RackMount to add in 'seats' that dynamically change crew capacity and the game respects the seating in terms of boarding a craft in flight.  Adding and rackmounting a seat part (I'm using the external command seat as a placeholder for this but it needs it's own part) adds an available crew spot, removing it removes the crew spot, and it's pretty easy to make sure you don't pull out a seat if a kerbal is using it.  So far so good.

The problem is the KSP crew slots for each part as seen in the VAB crew selector are set when the game launches and I'm not sure it can be changed (or even should be).   This means when you build and launch a craft you will see crew slots in the VAB for the CrewCapacity available when the game was first loaded not what it is based on the number of rackmounted seats.

Interestingly it will only 'board' up to the rackmounted crew capacity when the vessel is launched so it *almost* works correctly.   For example if you have a 3 crewed part, the mod will first set CrewCapacity to 0 then add in any rackmounted seats.  When you build your craft you will see 3 slots in the crew selector but when you launch you only get up to the number of rackmounted seats (including none).  In theory this means you can have more rackmounted seats than visible crew slots (so you can't board those seats and they are empty) and you can definitely try to add more crew than you have seats (so they just don't show up in the launched vessel).

In practice this means parts should start the game with the maximum number of seats that can fit so you can always 'board' every seat you rackmount.  I haven't figured out how to hide slots dynamically in the VAB crew selector but I *think* I can empty and block them from use dynamically, so you will see the empty slot but if you try to add someone it will block you and message you that you can't do that without rackmounting a seat.

There are some mods that change how crew are loaded, which may get broken.  BetterCrewAssignment doesn't work if there is a mismatch between the expected number of crew (as seen in the VAB crew selector) and the actual number of seats available, and throws an error when this happens.  I haven't tested Kerbal Construction Time yet.  There may be others I don't know of.

Finally of course there's the problem of the IVAs.  The internal model doesn't change based on the seat count and I haven't experimented with dynamically changing IVAs yet.  No idea if this is possible and it would mean building LOTS of custom IVAs which is beyond the scope of this project.  That's likely a 'just live with it' issue.

I like the idea of this.  There are two real world examples I would love to be able to model.  The original Vostok capsule had 1, 2, and 3 crew variants (Vostok and Voskhod) as well as an uncrewed variant (the Zenit program) and Apollo had a 5 crew variant that would have been used as a rescue craft for Skylab.  It also allows for returnable cargo vessels like the Dragon for example.  I'll have to see if it breaks too many things to be practical though.

 

[Pehvbot]

Version 0.1.2 is now available for download.

https://github.com/pehvbot/RackMount/releases/tag/v0.1.2

It now includes seats!  You can now rackmount the EAS-1 External Command Seat to gain extra seating.  It won't adjust the IVA so that is still a bit broken, and it really needs its own part and have more volume to account for the kerbal itself, but this is a good start.

I was able to solve basically all the issues mentioned above.  The only real glitches are the IVA problems and that it is slightly buggy when using Better Crew Assignment.  BCA uses a small hack to constantly update the crew assignment window.  This causes the PAW inventory window to constantly update which 'flickers' rackmounted parts as they are made visible and invisible by this update.

It turns out the crew assignment stuff is a bit easier to manipulate than I thought.  Mostly it's just that it's done from two separate parts of the program, the parts using CrewCapacity, and the crew assignment window using the VesselCrewManifest object.  You just need to make sure to manually adjust both of them to keep them in sync.

[Pehvbot]

Experiment Report #7:  Have a seat and turn up the volume

There were some pretty significant bugs in the crew seat code in v0.1.2 (no surprise there) which will be fixed on the next upgrade.  In the mean time I decided to try my hand at creating a chair part.  I tried doing a few things including a close analog to the Apollo seats and using the KSP seat props (the ones used in the stock IVAs)  but finally decided to go with something a bit simpler than the props and more 'Kerbal' than the Apollo style seat.  It's only my second attempt at making a model and is purposely simplistic since it's mostly going to be seen as a thumbnail in any case.  Introducing the Mk1 Crew Seat!

  

It's purely coincidental that Bob's office chair has gone missing.   It doesn't work like the external command seat, it won't attach to anything and you can't sit in it.  It's just there so you can potentially toss it out the airlock if you want to get rid of it in flight.

But having created a part and gotten the crew capacity code to almost work properly, it brings up the issue of the seat volume and the available volume in a given capsule or pod.  My eventual goal is to be able to completely customize the 'load out' for any given capsule , with seating, resources, and various modules so that a capsule or pod is simply an empty shell to be filled with whatever technology is currently available. 

As a baseline I'm using the interior crew volume of the Mercury capsule, which was something like 1.7m³.  That's about the smallest you can squeeze someone into.  Scaled to kerbal size that's about 0.425m³, or 425 liters.  The volume of the chair itself is something like 180 liters.  That gives a crew seat the ModuleCargoPart packedVolume = 605. 

I also automatically calculated the 'empty' volume for these parts using the Mesh properties.  You can also use something called Bounds, but that makes it harder to get an accurate number based on the shape (cylinder, cone, sphere) of the capsule since this is basically just a cube containing the part.  The down side to using the Mesh is that... I don't really understand the Unity Mesh stuff.  The numbers I get seem correct in value but some parts seem to use the wrong scale, so the volume is several orders of magnitude too small.  So for now I'm just faking it by scaling it up to a 'sane' number.  It really needs to be done better.

Finally I compared these numbers to some back of the envelope calculations based on the shape and dimensions of the parts.   Some examples:

• Mk1 Command Pod: 820L
• Mk2 Command Pod: 2080L
• M1-3 Command Pod: 5030L
• KV-1/2/3 Reentry Modules: 2780L

These numbers are fairly close to the platonic ideal volume for their shape and size.  Well close enough for government work anyway. 

It became pretty clear that if you strictly use the part's size there's no way to make something that is fully game balanced.  A baseline Mk1 with a single seat has 215L left for everything else (control, battery, reaction wheel, etc) but a baseline Mk2 with two seats has 870L left.  Other parts have similar balance issues.

It's pretty clear that all these numbers will need to be manually adjusted a bit in order to make things real world adjacent.