[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[chrisl]

I'm pretty sure I already know the answer to this, but does SSTU have any way to add/remove available modules on a part?

[tater]

4 minutes ago, chrisl said:

I'm pretty sure I already know the answer to this, but does SSTU have any way to add/remove available modules on a part?

What do you mean?

You could edit the cfg files, and eliminate any adapters/etc you never use, for example. Is that what you mean?

[Jimbodiah]

I don't think KSP allows the adding/removing of modules in-game, only disabling them if there is an option to in the module itself (like reaction wheels and rcs). If you want to add a command module or reaction wheels to something for example, you will need to manually change the cfg files (see my patches ) .

[chrisl]

2 hours ago, Jimbodiah said:

I don't think KSP allows the adding/removing of modules in-game, only disabling them if there is an option to in the module itself (like reaction wheels and rcs). If you want to add a command module or reaction wheels to something for example, you will need to manually change the cfg files (see my patches ) .

That's what I figured but wanted to ask since SSTU has lots of features. 

[Starwaster]

3 hours ago, Jimbodiah said:

I don't think KSP allows the adding/removing of modules in-game, only disabling them if there is an option to in the module itself (like reaction wheels and rcs). If you want to add a command module or reaction wheels to something for example, you will need to manually change the cfg files (see my patches ) .

Yes it does. Deadly Reentry does that to ensure that every part has its module installed (except for flags and certain others). FAR does the same thing.

[Jimbodiah]

Yeah, by adding a patch at startup of the game to add modules into the existing CFG, but not when the game is already running. Not the same thing though

[Shadowmage]

6 minutes ago, Starwaster said:

Yes it does. Deadly Reentry does that to ensure that every part has its module installed (except for flags and certain others). FAR does the same thing.

 

1 minute ago, Jimbodiah said:

Yeah, by adding a patch at startup of the game to add modules into the existing CFG, but not when the game is already running. Not the same thing though

 

More precisely -- you can add modules to a part at runtime.  You can even remove modules.  It is just ugly and dirty, and can cause tons of compatibility problems with stock and other mods' code.

What you can't do (at least not that I've been able to figure out) is get proper and robust persistence support for modules added at runtime (any module not in the prefab will not get its persistent data reloaded properly).  You also can't patch/module-manager-edit any modules added at runtime (as there is nothing in the config file to patch).  Nor is there any generic method to add/remove arbitrary modules -- most modules have very specific setup/initialization/ordering that needs to be done to not break things.

 

[Starwaster]

 

@Jimbodiah  I'm not talking about using Module Manager patches. You can add modules at runtime. Deadly Reentry does so when the game gets to the main menu. FAR does so when a vessel is loaded.

@Shadowmage The only mods I've seen compatibility problems with were mods with invasive coding practices (which also caused the compatibility issues with multiple other mods)... or mods with just bad code

[chrisl]

Basically what I was hoping to do was put a couple different TACLS modules onto the generic station parts, then have a selection options in the VAB that let you specify which set you launch the part with.  That way I could use the same generic station part for Mir and ISS modules.  But it doesn't sound like I can do that.

So here's a different question.  Since I need to make parts that are more or less specific to Mir modules, and different parts that are specific to ISS modules, I've decided to just make parts without the SSTUModularStationCore Module.  I know that means I have to specify all the model's (and place/size those models properly) myself.  That's not actually all that hard.  But is there any way to tell those models to use other textures?  I know that with SSTUModularStationCore you can change from the default beige texture, to green, grey and a couple others.  I've tried using "texture = ST-DOS-GREEN-DIFF,SSTU/Assets/ST-DOS-GREEN-DIFF" in the MODEL section to make the core green, but that just doesn't seem to do the trick.

[T-10a]

Quick question: I'm trying to add the SSTU Heatshield module to an existing part (to reduce part count on my spacecraft), and when I right click the part ingame, my game freezes. Is there a fix to this I can do, or will I have to use the stock heatshield module and add a pull request on github?

[Shadowmage]

14 hours ago, chrisl said:

I've tried using "texture = ST-DOS-GREEN-DIFF,SSTU/Assets/ST-DOS-GREEN-DIFF" in the MODEL section to make the core green, but that just doesn't seem to do the trick.

The SSTUModularStationCore, and all of the models it use, use the TextureSet system.  Look in the SSTU/Data/TextureSets folder for the texture sets.  Basically create a new texture set, and reference that in the SSTU_MODEL.  Remove any existing sets if you want to force a specific texture.

8 hours ago, T-10a said:

Quick question: I'm trying to add the SSTU Heatshield module to an existing part (to reduce part count on my spacecraft) [...snip...]

Should be possible.  That is the entire reason for the module.

Log file?  (nothing I can do without logs but... guess...... I guess there is a problem somewhere?)

 

15 hours ago, Starwaster said:

The only mods I've seen compatibility problems with were mods with invasive coding practices (which also caused the compatibility issues with multiple other mods)... or mods with just bad code

Have you figured out how to get persistent data to work for those modules (added at runtime)?  And how do you deal with the ModuleManager patching issues?  (no config to patch = can't patch it?)

Runtime module switching is something I've wanted... forever.  Every attempt at that I've done it runs into issues with stock code in one place or another.

(note, I'm not talking about just adding one specific simple module; that I can already do.... I need full in-editor switching of arbitrary modules, with persistent data support; e.g. remove engine module, add RCS module; or swtich out a 'probe core' module for a 'science experiment' module)

 

[RaiderMan]

the ISS style hab modules, I've never looked despite using them often, but are they resizable like the fuel tanks and whatnot are?

[Shadowmage]

3 minutes ago, RaiderMan said:

the ISS style hab modules, I've never looked despite using them often, but are they resizable like the fuel tanks and whatnot are?

No.  Crewed parts are not resizable; only the raw resource containers can have their size/diameter adjusted.

[chrisl]

1 hour ago, Shadowmage said:

The SSTUModularStationCore, and all of the models it use, use the TextureSet system.  Look in the SSTU/Data/TextureSets folder for the texture sets.  Basically create a new texture set, and reference that in the SSTU_MODEL.  Remove any existing sets if you want to force a specific texture.

Like I said, I ended up creating parts without SSTUModularStationCore.  Since I am making specific parts to be specific components of Mir and ISS, it didn't seem like the best option to use SSTUModularStationCore.  After all, if you're using just one specific Top adapter, one Bottom Adapter, one solar panel and no docking ports, it didn't seem worth it to use SSTUModularStationCore.  Especially since SSTUModularStationCore doesn't allow for statically declared mass and volume values.  So rather than using SSTUModularStationCore, the parts I setup have 11 MODEL definitions in the cfg file.  I had to work out the scale, position and rotation for each of those MODEL definitions, but that wasn't overly complicated with the hints already available in the SSTU_MODEL I was mixing and matching.  The parts I setup all look good and seem to work properly.  But they are all using the default textures which isn't horrible but if I could figure out how to get the texture command to work in the MODEL definitions, I'd be able to use (for instance) the green textures you have available for the DOS station parts.

[Shadowmage]

54 minutes ago, chrisl said:

But they are all using the default textures which isn't horrible but if I could figure out how to get the texture command to work in the MODEL definitions, I'd be able to use (for instance) the green textures you have available for the DOS station parts.

The stock MODEL node setup does not support the proper shaders and other features needed for SSTU textures.  So basically, its never going to work properly/fully using the stock texture changing methods. 

You can either accept whatever the default texture/color is, or you can setup the SSTUModularStationCore module (it works fine with only a single adapter option; it'll even disable the adapter-selection-GUI controls if only a single option is specified), or you can work out how to use the SSTUTextureSwitch module (which is fully capable of using custom shaders/textures).

58 minutes ago, chrisl said:

Especially since SSTUModularStationCore doesn't allow for statically declared mass and volume values.

It does, very much so.  You just have to specify them properly in the SSTU_MODEL nodes and/or in the PartModule itself.

Look in the existing station-core parts.  See the CORE node, with the mass/volume specified?  Yep, that bit right there lets you change the mass/volume of the part.  You can even adjust the VolumeContainer config so that it does no further mass adjustments for tankage, using the mass of the CORE + resources only.

[Starwaster]

2 hours ago, Shadowmage said:

Have you figured out how to get persistent data to work for those modules (added at runtime)?  And how do you deal with the ModuleManager patching issues?  (no config to patch = can't patch it?)

Runtime module switching is something I've wanted... forever.  Every attempt at that I've done it runs into issues with stock code in one place or another.

(note, I'm not talking about just adding one specific simple module; that I can already do.... I need full in-editor switching of arbitrary modules, with persistent data support; e.g. remove engine module, add RCS module; or swtich out a 'probe core' module for a 'science experiment' module)

Ah, sorry, I guess we misunderstood each other. DRE does add modules but only at the main menu. So what you're wanting isn't just runtime addition but to do so on the fly. Persistence shouldn't be a problem because as long as the relevant fields are marked persistent then they'll be deserialized when  a craft with that module is loaded. 

MM patching would clearly be a problem though if there's an actual need to patch something, maybe you could get by with template parts that exist but aren't usable by the player (no techRequired assigned or a dummy tech so they don't appear) and patch that and then refer to the template when needing to add the module.

Unfortunately I can't speak to other problems you may have had since I haven't done that kind of module manipulation before. Adding them and then having them disabled when not present (as @Jimbodiah alluded to) seems easier

[chrisl]

17 minutes ago, Shadowmage said:

The stock MODEL node setup does not support the proper shaders and other features needed for SSTU textures.  So basically, its never going to work properly/fully using the stock texture changing methods. 

You can either accept whatever the default texture/color is, or you can setup the SSTUModularStationCore module (it works fine with only a single adapter option; it'll even disable the adapter-selection-GUI controls if only a single option is specified), or you can work out how to use the SSTUTextureSwitch module (which is fully capable of using custom shaders/textures).

It does, very much so.  You just have to specify them properly in the SSTU_MODEL nodes and/or in the PartModule itself.

Look in the existing station-core parts.  See the CORE node, with the mass/volume specified?  Yep, that bit right there lets you change the mass/volume of the part.  You can even adjust the VolumeContainer config so that it does no further mass adjustments for tankage, using the mass of the CORE + resources only.

I hadn't considered creating/using a separate SSTU_MODEL for each part.  Can't use the same for each since the mass/volume of Kvant-2, Spektr, Zarya and Nauka are all wildly different (examples) from each other which was were I was running into problems.  I may have to consider trying that.

As for SSTUTextureSwitch, is that part of SSTU 0.5.34.134?  I haven't looked through every part, but I'm not seeing that module on the parts I've looked at so far.

[Shadowmage]

10 minutes ago, Starwaster said:

Ah, sorry, I guess we misunderstood each other. DRE does add modules but only at the main menu. So what you're wanting isn't just runtime addition but to do so on the fly. Persistence shouldn't be a problem because as long as the relevant fields are marked persistent then they'll be deserialized when  a craft with that module is loaded. 

Ahh, yeah, adding them at the main menu (into the prefab part) should present no problems with persistence.  As long as the module is in the prefab part, it should 'just work'.

My problem is that modules added in the editor to an instance of a part are not present in the prefab.  They'll save their data out during the OnSave() call, and properly write it to the persistence file/craft file, but as the module is not present in the prefab, the module will never be reloaded properly.  It'll just log some error about 'ModuleXXX was present in the save file but not in the part prefab' or somesuch; the stock code doesn't even attempt to re-add the module if it isn't in the prefab.

 

12 minutes ago, Starwaster said:

Adding them and then having them disabled when not present (as @Jimbodiah alluded to) seems easier

Indeed -- but this only works with modules that support the stock 'moduleIsEnabled' flag, which is sadly, a very small number of them.  Works fine for RCS (which as moduleIsEnabled support), but not for engines (which do not have any support for moduleIsEnabled).

 

14 minutes ago, Starwaster said:

MM patching would clearly be a problem though if there's an actual need to patch something, maybe you could get by with template parts that exist but aren't usable by the player (no techRequired assigned or a dummy tech so they don't appear) and patch that and then refer to the template when needing to add the module.

My previous attempts had this setup such that the module-to-be-added was defined in a sub-node in the ModuleSwitch part-module.  It allowed for patching of the dynamically-added modules' config values, but was incompatible with existing patches (they would need to be re-targeted at the sub-node of the ModuleSwitch).

 

Really the largest problem that I was unable to solve regarding dynamic-module switching was the persistence handling.

Just now, chrisl said:

I haven't looked through every part, but I'm not seeing that module on the parts I've looked at so far.

It is mostly used on the command-pods, namely the SC-B (Apollo) pod.

 

1 minute ago, chrisl said:

I hadn't considered creating/using a separate SSTU_MODEL for each part.

You shouldn't need to.  You can override the mass/volume of the SSTU_MODEL directly in the CORE subnode of the SSTUModularPart config.

E.G.: The mass and volume specified here --  https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Data/ModelData/ModelData-ST-DOS.cfg#L1-L61

are overriden here for that specific part -- https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/StationCore/ST-DOS/ST-DOS-COM.cfg#L136-L142

 

And it looks like the VolumeContainer on those parts is already setup properly to not adjust things further (so it should use the values specified in the CORE block directly) -- https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/StationCore/ST-DOS/ST-DOS-COM.cfg#L591-L592

[RaiderMan]

bugger. 

what part(s) would you recommend then, as something that could be taken up on an ares flight, far as throwaway hab/mission modules are concerned?

[Jimbodiah]

40 minutes ago, Starwaster said:

Unfortunately I can't speak to other problems you may have had since I haven't done that kind of module manipulation before. Adding them and then having them disabled when not present (as @Jimbodiah alluded to) seems easier

This is why I have my own pack of patched parts, as they tend to be very specific to my personal game play. I just make a copy of the part in question and configure it to hold whatever modules and/or resources I want. Specific game-play features will always be hard to include in mod packs, especially ones as flexible as SSTU. I'm amazed what Mage pulls off with all the modelling options and still have it work properly   If he ever finds out how to add modules in-game, I'll be stuck in the VAB even longer 

Edited January 26, 2018 by Jimbodiah

[chrisl]

22 minutes ago, Shadowmage said:

It is mostly used on the command-pods, namely the SC-B (Apollo) pod.

I don't see it on any of the SC-B parts that come with v0.5.34.134 but I do see it on parts that come with v0.7.39.148.  Unfortunately, I think I'm limited to v0.5.34.134 since I'm still using KSP1.2.2.  But I will definitely keep it in mind for what RO is finally updated to support KSP1.3.1.

[Shadowmage]

13 minutes ago, RaiderMan said:

bugger. 

what part(s) would you recommend then, as something that could be taken up on an ares flight, far as throwaway hab/mission modules are concerned?

The COS parts work fine as temp habs.  A bit heavy perhaps, but functional.  You realize you don't need larger diameter parts, right?  2.5m is just fine, esp. when enclosed in a fairing on a larger diameter rocket.

The alternative to the COS parts that I've used is the HAB parts, notably the HAB-B series.  It requires an additional container of resources to inflate it once in orbit, but they are some of the better mass-per-kerbal habitation parts included in SSTU, and is what I was using as a transit-hab for my Kerbin<->Minmus missions  (life support + hab requirements = can't cram 6 kerbals in an SC-C for the entire trip).

6 minutes ago, chrisl said:

Unfortunately, I think I'm limited to v0.5.34.134 since I'm still using KSP1.2.2.

Erm.. yeah... can't really offer any help then.  I don't even remember what the feature-set was that far back...  (I don't think the texture-switch module was developed yet at that point).

The rest of the SSTUModularStationCore stuff should still work; I believe the features I was talking about were part of its original development, so they should be present even in the older releases.

[Jimbodiah]

3 minutes ago, Shadowmage said:

can't cram 6 kerbals in an SC-C for the entire trip).

Whut?! You mean I didn't send tourists to gather science by accident after all?

[Starwaster]

13 minutes ago, Jimbodiah said:

This is why I have my own pack of patched parts, as they tend to be very specific to my personal game play. I just make a copy of the part in question and configure it to hold whatever modules and/or resources I want. Specific game-play features will always be hard to include in mod packs, especially ones as flexible as SSTU. I'm amazed what Mage pulls off with all the modelling options and still have it work properly   If he ever finds out how to add modules in-game, I'll be stuck in the VAB even longer 

I do that to a limited extent, stuff like cloning KWR 5m parts and making them 10m so that I can make Saturn V type launchers for Kerbol 10x. So when I first installed SSTU I tried to cherry pick parts  which was a veritable nightmare (you understand why no doubt), but having tried them, next major KSP install I'll just do a full SSTU install and ditch a lot of the other stuff. Especially now that he's got PBR in there

[Starwaster]

56 minutes ago, Shadowmage said:

My problem is that modules added in the editor to an instance of a part are not present in the prefab.  They'll save their data out during the OnSave() call, and properly write it to the persistence file/craft file, but as the module is not present in the prefab, the module will never be reloaded properly.  It'll just log some error about 'ModuleXXX was present in the save file but not in the part prefab' or somesuch; the stock code doesn't even attempt to re-add the module if it isn't in the prefab.

 

Indeed -- but this only works with modules that support the stock 'moduleIsEnabled' flag, which is sadly, a very small number of them.  Works fine for RCS (which as moduleIsEnabled support), but not for engines (which do not have any support for moduleIsEnabled).

 

My previous attempts had this setup such that the module-to-be-added was defined in a sub-node in the ModuleSwitch part-module.  It allowed for patching of the dynamically-added modules' config values, but was incompatible with existing patches (they would need to be re-targeted at the sub-node of the ModuleSwitch).

 

Really the largest problem that I was unable to solve regarding dynamic-module switching was the persistence handling.

 

Ok here's an idea...  assuming a central module that's keeping track of these configurations. All possible PartModules that could be added to the part are added in the config so that they're present in the prefab. When the part is loaded in the editor or in flight mode, the controlling module will remove everything that's not designated as being installed by default. Loading into the editor (whether from the part inventory list or loaded craft) all such modules are removed. Loading into flight scene, same thing. 

Adding them back in later then should get around the issue of the KSP not finding the modules in the prefab during loading.

(ugh, that was supposed to get appended to the last message but I guess I took too long)

Edited January 26, 2018 by Starwaster