shadowmage45 / SSTULabs

Dev repository for testing/unfinished KSP parts/plugins/etc.
Other
62 stars 41 forks source link

Q: COS core switch in GUI? #672

Closed Jimbodiah closed 6 years ago

Jimbodiah commented 6 years ago

By chance I noticed some of my cloned COS parts show a slider for the Core and it allows me to switch between the 4 sizes of the COS modules. Is this intended functionality, as I don't see it in any of the SSTU COS parts.

This could save me multiple clones for different sizes, so I hope this is a nice side-effect of tinkering with your parts :)

Jimbodiah commented 6 years ago

screen shot 01-12-18 at 04 06 am

shadowmage45 commented 6 years ago

Yes, it should be fully functional in the code (but untested as it is unused). Simply disabled in the existing StationCore parts.

But -- it won't work on modules with integrated engines (e.g. DOS), or integrated soloar (e.g. MST). Nor can it update/adjust crew capacity. Nor any IVA swapping.

Lots of reasons why it is not in use on the current parts ^^

Jimbodiah commented 6 years ago

I have a COS module clone purely as resource storage, and it works there; I see the resource volumes being scaled up. Ghe, that slider has been there for a long time, and I just noticed when I accidentally used the wrong one and saw the length change. Now I can remove a bunch of configs for each different size :)))

shadowmage45 commented 6 years ago

I would have just used the MFT (fuel tank) module personally.

Unless there are some functions of the ModularStationCore module that are needed? (not sure what those could be, as at this point the modules are nearly identical except for the solar panel support)

Jimbodiah commented 6 years ago

I wanted station parts with the COS look for storage only, and at the time there was no COS texture for the MFT (and there is no longer any iirc).

Actually, I use an MFT-A clone as an "ATV" that has added probe core functionalities.

Everytime I am building a ship or station and think of something I would like, I tend to clone an SSTU part and alter it into something new.

Jimbodiah commented 6 years ago

Regarding the MFT, is there a way to set the default texture for the mount/nose?

For the stationcore module it would be i.e. "currentTopTexture = Adapter-Silver" but is there an equivalent parameter for the MFT? I tried currentNoseTexture but that doesn't work ;)

shadowmage45 commented 6 years ago

https://github.com/shadowmage45/SSTULabs/blob/master/Plugin/SSTUTools/SSTUTools/Module/SSTUModularFuelTank.cs#L89-L97

Jimbodiah commented 6 years ago

nevermind... operator error... I was using @currentMountTexture when I should have been using %currentMountTexture, as it's not used in the original config. Looking at one thing when it's another.

Jimbodiah commented 6 years ago

Thanks for helping out!!! DIdn;t know the variable for the tank texture :)

I now have a scalable COS in 2.5 and 3.75m for storage in two single parts instead of 4 each :) And an MFT-ATV that starts out with the proper mount/nose/texture.

Jimbodiah commented 6 years ago

I noticed that any modules like reaction wheels or power supplies also get scaled when changing the length of the COS unit. Is there currently any way to disable this for certain modules?

shadowmage45 commented 6 years ago

Umm... they really shouldn't. SSTU doesn't touch reaction wheel or any other power-supply related code.

What specifics are you seeing? (screenshots, numbers, module names)

Jimbodiah commented 6 years ago

I made a COS with the usual PPC modules, and also a WildBlue reactor module. It has a much lower Ec gen rate and overheats at every timewarp vs the same module in a fixed size COS.

Side note: When I define internal volume and mass, I need to keep the same values as the original 2.5m when I scale up or down, or the volumes will increase to double of what they should be.

I've defined this for the COS Storage module:

CORE { name = ST-COS-XSHORT volume = 5.5 mass = 0.95 cost = 2000 } CORE { name = ST-COS-SHORT volume = 10.0 mass = 1.8 cost = 4000 } CORE { name = ST-COS-MEDIUM volume = 16.5 mass = 2.4 cost = 6000 } CORE { name = ST-COS-LONG volume = 22.6 mass = 2.725 cost = 8000 }

And I need to keep those the same when I scale to 1.25m or 3.75 using:

@MODULE[SSTUModularStationCore] { @topDiameter = 3.75 @coreDiameter = 3.75 @bottomDiameter = 3.75 }

This part is probably working as intended, but I thought it may have had relation to the behavior in the reactor module I was seeing. But on second thought that has no bearing on the length changes using the CORE functionality. Brainfart.

shadowmage45 commented 6 years ago

You can't really expect support when using an unsupported feature.....

(using multiple core modules and scaling is not supported in the StationCore parts/modules... so whatever problems you may encounter you are on your own to solve)

If you can manage to expose or replicate the problem with the existing StationCore parts, please let me know.

And also -- I don't touch any stats on any external modules (e.g. reactor modules), so whatever you are encountering there is not something I can solve.

Jimbodiah commented 6 years ago

Not asking for a solution ;) just asking if modules are touched by the Core rescaling that you were aware of.