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.

It's fairly easy since all of the major components are baked in. Take a look at this and search for GameParameters.CustomParameterNode: You access these values by using 'HighLogic.CurrentGame.Parameters.CustomParams<MyGameSettings>().myGameValue' (the example on the page above uses TestCustomParams for the game setting name and has several values including MyBool). So your module would look something like this: public class ExplodeParams : GameParameters.CustomParameterNode { ... bunch of stuff to name and define the difficulty parameter node [GameParameters.CustomParameterUI("Allow Explosions?", toolTip = "Enable explosions!")] public bool explosionsEnabled = true; ... more stuff for difficulty presets } public class ModuleExplode : PartModule { ... bunch of stuff about when to trigger explosions public void ExplodeIt() { if(HighLogic.CurrentGame.Parameters.CustomParams<ExplodeParams>().explosionsEnabled) this.part.explode(); } }

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.

Less of a direct dev questions and more of a design philosophy and good practices question. I'm working on a mod that uses the stock inventory system for module management. The goal is to eventually make a much more modular (no pun intended) command part system where pods and probe cores are basically just empty shells you fill out using the inventory system. So far it's working pretty well. However by default KSP disables parts with an inventory (ModuleInventoryPart) from being a storable part itself (ModuleCargoPart), so no nested inventory parts. This would be a super useful and likely necessary feature and it can be gotten around. If you create and use a subclass of ModuleInventoryPart, the new subclass won't trigger this restriction so you can in theory store an inventory within an inventory. The stock game will properly keep track of build cost and mass but it won't see the nested inventory part costs on recovery. The parts are there but you lose the money for any part stored in a stored part. Rather than dig into the recovery code or mess too much with the ModuleInventoryPart class I was thinking of just adding in a hidden RESOURCE (call it 'Components' or whatever) and simply adjust the amount based on the cost of the stored parts. On recovery this 'resource' gets added back into the recovery cost so in theory it all comes out even. Is this too kludgy? I feel like it should work just fine but it seems a bit of a cheat somehow. Any thoughts?

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.

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.

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.

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.

That's actually normal and your script is working as intended. Parts like this don't have a 'ratedBurnTime' (only engines have this) so the calculation you are seeing can't tell you how likely it is to fail 'at full burn'. In effect it's 100% reliable with 0 seconds of use. However, it will tell you how long it's likely to go before failure (7.27 seconds at 0 du and 14.69 seconds at full du). [EDIT] Oh and if TestFlight is something you are interested in I would point you to one of my current projects Less Real Test Flight. It's a stock/stock-alike config and addon mod for the core TestFlight. It's not intended for RO/RP-1 though.

v0.9.0 is available. This adds parachute support for both RealChute and RealChuteFAR. It uses separate dlls that load if they can find their dependent dlls (AKA assemblies) from Ferram or RealChute. It also renames the VAB/SPH 'replace' button to 'rebuild', to better reflect what it is doing. https://github.com/pehvbot/LRTF/releases/tag/v0.9.0

In short: Start simple Have specific goals Look at how others have solved the same problem Ask specific questions It's a big topic with lots of different areas. The easiest way to start is to learn ModuleManager patching first. Begin by modifying existing parts to do what you want. Look at other mods that do more or less what you want, read up on how patching works (this site and the MM wiki), etc. Next learn about 3d modeling. Blender is free and there are plenty of tutorials. It's a steep learning curve so be prepared for some frustration. With KSP you first create the 3d model, then you prepare it for the game using the Unity tools, finally you create a configuration file that defines all it's game attributes. There's a more or less current thread with some good pointers. Start with simple parts, even just a cube with attachment points can be a bit of a challenge at first. If you find you want to dive into the programming side, that's an even steeper learning curve, especially if you don't have a programming background. Personally I learned by picking apart other people's code and modifying it, asking specific code questions here, etc.

Version 2.0.5 of LRTR and version 1.0.7 of it's KerbalismConfig are now available. They fix some issues with science, including problems with low atmosphere science in RSS. https://github.com/pehvbot/LRTR/releases/tag/v2.0.5 https://github.com/pehvbot/LRKerbalism/releases/tag/v1.0.7

v0.8.5 is available. This has a bunch of fixes and refinements for the VAB/SPH replace/repair handling. This includes changing how the 'replace' button looks, making sure that some of the part failures are properly remembered and repaired when in the VAB/SPH. https://github.com/pehvbot/LRTF/releases/tag/v0.8.5

v0.8.4 is available. This one actually fixes button replication issue. I hope. https://github.com/pehvbot/LRTF/releases/tag/v0.8.4

v0.8.2 is available. This fixes the problem with replicating VAB/SPH buttons. It also changes the way part replacement costs are handled and (properly!) adds the cost to the vessel itself which increases the build time. Later versions should add refinements like adding a visual cue to the button if there are not failed parts and a mouseover message. https://github.com/pehvbot/LRTF/releases/tag/v0.8.2 Dang it. Replication problem not fixed yet!

Thanks for the heads up. It's likely a bug in my code. I won't have time to look at it until next week but I expect it's an easy fix.

v0.8.1 is available. The v0.8.0 zip file had the wrong DLL. Download this one instead. https://github.com/pehvbot/LRTF/releases/tag/v0.8.1

v0.8.0 is available. As suggested by @Strych74 this update adds preliminary support for either repairing or 'replacing' (see below) failed parts if the vessel is rolled back using something like KerbalConstructionTime. It also includes the Solids fix above from @hermano for RealFuels SRBs (thanks!). https://github.com/pehvbot/LRTF/releases/tag/v0.8.0 (link removed, wrong dll in zip file) There's now a TestFlight button in the VAB/SPH. Pressing it will bring up the PartActionWindows for every failed part. You will have the option to either attempt to repair the part for free or replace the part at the cost of a new part. The repair chance will be based on the failure curve for the part and the number of du it has accrued and adjusted by best VAB/SPH level you have. In general this will be significantly better than your in-flight repair chances. If you fail, in theory you can only try again once you improve your repair chance. However because KCT allows you to revert your game by canceling the edit, you can effectively cheat by reverting and trying again as much as you want. I don't think I will fix this issue so no cheating! Replacing a part costs the price of a new part. Technically it doesn't actually replace the part, it simply clears out all TF/LRTF data. There are a couple of reasons for this. The first is it's easier and I'm lazy, the second is that replacing a part will clear any configurations for it, which can create its own problems. I haven't done a huge amount of testing for this so use with caution. I still need to fix the NaN issues with the failure curve code and I would also like to add some hooks into the repair/replace functions so they add construction time but I'm not sure how to do this yet.

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.

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.

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.

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.

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.

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.

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.