Pehvbot

Absolutely, the default placement isn't great. I'll be back in the real world in a week or so.

Unfortunately I won't have time to work on this for a while so I would say give it a shot. I don't know where CryoTank changes the dry mass but it may be basing the numbers on a stock sized tank. If you can find where it does this you might be able to adjust these number either directly or using a MM patch.

There may be two things going on here. One is that mechjeb is removed form most parts and you need to use the mechjeb part itself. The other (and I'm not sure if this is a problem in sandbox) is that the techtree info is somewhat broken. Try removing GameData/LRTR/support/mechjeb.cfg to see if things work as expected.

If you center click on a part in the VAB it will give you the TF stats. The expected run time tells you how long the engine uses the nominal failure curve, but once you exceed that time the chance of failure goes up pretty quickly. If you open the TF menu in flight you can see how the chance of failure goes up dramatically once you exceed this time. It's roughly modeling things like engine burn through or parts wearing out. A better understood engine can certainly be 'over burned' more than a new one, but there are limits.

The TF 'failure curve' is hard wired but each flight moves you along this curve by collecting 'data units' (du), so each flight improves your chances. Each part will have it's own failure curve but as far as I know none start at 100%. Typically they start at a 70%ish chance of failure and go down to 1% or so. These ignition failures also give you du and if it's an ignition failure you can simply roll it back and try again with a better chance of success. You won't get du from reverting the flight though. You can disable failures in the TF menu if you like, but honestly this is doing exactly what it's supposed to be doing.

Have you enabled Advanced Tweakables in the main Settings menu?

You can change the settings in CKAN to allow it to install as if you have an earlier version of KSP.

I really like the looks of the new VAB and KSC, the build procedure looks miles better than KSP1 and the KSC looks both epic and Kerbal.

Following up with AVaughan above: CKAN on a Mac it can be a bit tricky to get it running at first and it will only run in console mode (i.e. run in the Terminal) but it does work and will install RO/RP-1 correctly. CKAN is an 'unsigned' app so when you try to run it the first time, it will fail. You'll need to go to your System Preferences->Security & Privacy settings to allow it to run. Also I would suggest avoiding the visual mods at first. They don't do all that well on a Mac.

I've tested, but not extensively used, mods on M1 Macs and they worked without issues, at least for the testing I did. Not all visual mods will work but that's a Mac thing not an M1 thing. You can install mods either manually (e.g. downloading each mod, the mod's dependencies, and copying them *correctly* into the GameData folder) or use CKAN in console mode. CKAN is the better option once you get over the learning curve and install issues. I installed ckan using something called 'brew', a command line app used to install UNIX like programs but there's also the downloadable app from the dev's site. I haven't tested it, but it should work. You may need to authorize the App to run from the System Preferences->Security & Privacy since it's unsigned. https://github.com/KSP-CKAN/CKAN/releases It will load in your Terminal so it won't work quite like it does on a PC but it's functional enough once you get used to it.

I had a similar problem with one of the RestockPlus landing legs in a non-RP-1 RSS game. As long as they were deployed, things would instantly shoot upwards.

It's actually pretty easy to create one yourself using ModuleManager patches. All you need is to install the ModuleManager mod and then create a text file in your game's GameData folder with the name ending in .cfg [e.g. ReactionBork.cfg] @PART[mk2Cockpit_Inline|mk2Cockpit_Standard|Mark1Cockpit|Mark2Cockpit] { -MODULE[ModuleReactionWheel] {} } @PART[*]:HAS[@MODULE[ModuleReactionWheel]] { @MODULE[ModuleReactionWheel] { @PitchTorque *= 0.1 @YawTorque *= 0.1 @RollTorque *= 0.1 } } The first 'block' removes all reaction wheels from the four parts inside the brackets. The second 'block' looks at all the parts that have reaction wheels and reduces their power to 10% of the original (you can change this to whatever you like).

Version 1.0.9 of the KerbalismConfig is now available. This fixes an issue where monoprop is not being loaded onto a Kerbal on EVA. https://github.com/pehvbot/LRKerbalism/releases/tag/v1.0.9

No worries. You can do a google search for this but the basic idea is you move your current game folder to another spot then install the game as if it was a new game. If you are using Steam you would open Steam, right click on Kerbal Space Program and select Manage->Browse local files. If you go 'up' one level to the Kerbal Space Program folder you can then move it anywhere you want on your hard drive. Move it rather than copy it so your default KSP directory location is now empty. It doesn't use DRM so you can run this copied game without going through Steam. Next from Steam right click on KSP again and select Manage->Uninstall. Finally reinstall. Pro tip: You can have any number of KSP games installed and it's a good idea to move your RP-1 save to another location so Steam doesn't automatically update it, which can break RP-1.

Yep, you can't use the stock-ish save or craft files in RO/RP-1. It's always better to install RP-1 on a completely clean download of KSP.

v0.9.3 is (finally!) available. https://github.com/pehvbot/LRTF/releases/tag/v0.9.3 This adds RealAntenna support, removes two non-working failures (LRTFFailure_EngineCoolant and LRTFFailure_CommDeploy), fixes a bug with ModuleB9PartSwitch solid rockets (thanks Gordon-Dry!) and adjusts some of the failure curves based on play testing.

Yeah, somehow I forgot to upload the actual release , thanks for the heads up, I'll try and get it fixed today. Honestly I haven't been giving this mod as much attention as it deserves but I've finally had time to playtest things a bit more and I'll be making a few adjustments in any case.

One possible issue is that sandbox does not turn off the Kerbal Construction Time feature automatically. If you want to turn that off, go to the main KSC scene, right click on the KCT icon at the bottom, and de-select the 'Mod Enabled' button. Another is the crew training. To disable crew training go to the game Difficulty Options, look for LRTR, and unclick the crew options. If it's something else, let me know.

Version 0.01.3 is now available for download. https://github.com/pehvbot/RackMount/releases/tag/v0.1.3 This updated fixes numerous problems with the CrewCapacity code and adds in the new Mk1 Crew Seat part (found in the 'Cargo' tab). As of right now it allows you to add seats to the existing default crew seating. Eventually all the crewed parts will be 'emptied' and you would then add in however many seats you need (and can fit!). It does not adjust the IVAs so there are a few glitches. The logs will show an error because of the mismatch between crew and the number of IVA seats and you won't see the full crew complement in the crew roster window in the Flight scene. You can still access them by clicking on the part's 'door'.

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.7m3. That's about the smallest you can squeeze someone into. Scaled to kerbal size that's about 0.425m3, 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.

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.

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?