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

[Shadowmage]

Much progress this week on bringing the StationCore parts back online.  So far, so good.  ST-DOS and ST-COS parts have had basic conversion done, and are loading properly.  ST-HAB has had model defs updated, with part configs WIP.  Current focus is on updating the ST-CFG parts, including some improved handling of the inflation sequence and rotation handling.

I know its not that impressive to show pics of parts that already worked in previous versions... but steps such as this are actually a pretty 'big deal'.  Specifically, how easy it is to get all of these different parts working using the new module.  Simply setup the model definitions correctly, plug in the proper values to the part config, and hit 'play' (it is quite a lot of config work, but its not hard work).  So easy to add new options and features, or customize the parts for specific setups.

After I get things a little bit further along and into the external testing phase (hopefully next week...), I intend on writing up a couple of sample parts to showcase some of the more.... complex... features of the new module, such as the model-layouts and integrated animation handling.  (these likely won't be parts intended for actual use, merely for showing off some of the features that are not yet used in any 'live' parts)

 

Regarding RO/RF use -- during or shortly after the initial testing period for these releases, it would be nice to take a look at cleaning up the RF integration for the modular-parts (MEC, MFT, MUS, ST, etc...), to allow for at least some level of integration.  I believe the problematic point will be, as it has always been, supporting the use of ModuleEngineConfigs without breaking the engine clustering code.  If others are serious about being able to use SSTU with RF/RO, it might well take some codeside changes to the RF modules to allow for some different interfaces.  If/when I get to this point, I'll probably reach out for help from someone who is actually familiar with RO configs/setup.

(note, I still do not intend on supporting RO/RF use or providing any configs, but I will do everything that I can to make it compatible from a plugin perspective)

[Iso-Polaris]

9 hours ago, Jimbodiah said:

If you don't want to use RO (and I don't either), just use my patch. No need messing with weights and rescaling of parts. Not sure why you want RF if you are not using RO though, as SSTU does not support either.

Where is that "your patch" you are talking about?

I don't use RO cuz it's messing up with KSPI-E but RF works fine with it. Since im playing with RSS-size planet pack its essential to have the weights messed with.

5 hours ago, Shadowmage said:

Regarding RO/RF use -- during or shortly after the initial testing period for these releases, it would be nice to take a look at cleaning up the RF integration for the modular-parts (MEC, MFT, MUS, ST, etc...), to allow for at least some level of integration.  I believe the problematic point will be, as it has always been, supporting the use of ModuleEngineConfigs without breaking the engine clustering code.  If others are serious about being able to use SSTU with RF/RO, it might well take some codeside changes to the RF modules to allow for some different interfaces.  If/when I get to this point, I'll probably reach out for help from someone who is actually familiar with RO configs/setup.

 

From I can tell, lots of people do love to use SSTU with RF/RO.

[Jimbodiah]

Check my signature... if you're not using RSS then just change/remove the NEEDS[...] part.

[Starwaster]

13 hours ago, Shadowmage said:

For reference -- if RF is the problem, it is not with any of its actual fuel related functions.  The technical issue is (and always has been) with ModuleEngineConfigs;  two entirely separate part-modules, both trying to manipulate part-mass (and thrust, isp, cost...etc).  If you use RF for only the fuel tanks, and don't include or use any of the engine-manipulation modules, there shouldn't be any problems with the engine parts.

Set origMass to -1 (or even delete it outright since it defaults to that anyway) and it won't touch mass.

4 hours ago, Iso-Polaris said:

From I can tell, lots of people do love to use SSTU with RF/RO.

As do I; no problems here.

[Shadowmage]

General development news:

Still working away at part configs.  Only the ST-HAB and MSRB parts left to do initial conversions on.  HAB will likely be cleaned up today/have the first pass done, and I want to take a look at the MSRB stuff over the weekend.  Really seems like initial test releases might be Sunday at the earliest, or more likely sometime next week/week-end.

I have adjusted the RCSFuelSwitch module to be a bit more generic.  It can now interface with ModuleRCS, ModuleEngines, and SSTUVolumeContainer; for rcs/engine it sets the propellant and ISP, and for VC it sets the resources and ratios (all while in the editor; no flight-scene adjustments are possible).  While I likely won't be using much of these functions in the default SSTU releases right now, I have a feeling they could be put to good use in the future (methalox engine conversions?).

Currently a bit 'stuck' on trying to figure out the best way to handle the container setup for the StationCore parts.  I want them to have the adapter selection contribute to the available volume for the parts... but I also want to keep a pre-set balance for the part in its default configuration (ISP, life-support, etc).  Seems like I'll be accomplishing this by manually specifying the volume for the CORE model, and letting the adapters contribute their volume to a container that is set to be 'empty' be default.

I'm also working on making the 'support container' setup used by the MUS into a generic system usable by the ModularPart system.  When enabled, this will allow for a user-controlled percentage of config defined containers to be diverted to a secondary config-defined container.  So you'll be able to change the ratio of main propellant vs. RCS propellant without too much difficulty.  When combined with the FuelSelection module from above, this will allow for direct GUI control of the main fuel types (e.g. fuel for engines) as well as the auxiliary fuel types (e.g. fuel for RCS), all without opening up the 'edit container GUI', and while also setting the RCS (or engine) to the proper fuel type.

 

9 hours ago, Starwaster said:

Set origMass to -1 (or even delete it outright since it defaults to that anyway) and it won't touch mass.

I'll have to give that a try when I'm trying out the RF integration stuff.  Is that a setting in the ModuleEngineConfigs  .cfg, or something I'll need to set through code (reflection)?

[Jimbodiah]

1 hour ago, Shadowmage said:

for rcs/engine it sets the propellant and ISP

[DragonRoco]

1 hour ago, Shadowmage said:

While I likely won't be using much of these functions in the default SSTU releases right now, I have a feeling they could be put to good use in the future (methalox engine conversions?).

That might make it neater than cloning the part. Once it comes out I might release my methalox configs along with some other small stuff. 

Is there any large config changes to the engine clusters? I'm thinking about doing the configs for the near future line soon. 

[Starwaster]

2 hours ago, Shadowmage said:

I'll have to give that a try when I'm trying out the RF integration stuff.  Is that a setting in the ModuleEngineConfigs  .cfg, or something I'll need to set through code (reflection)?

Set it in the MEC config

On another note, can you/would you expose the number of engines in a cluster, preferably as a persistent field in its config in order to allow other mods to pick up on the fact that it represents multiple engines? Stage Recovery can't really see it as anything other than a single engine. It would help with a pull I'd like to make to SR to fix the issue (SR can't really see the engine properly since it only sees it when it's off rails and off screen so it's either look at it's prefab or look at the config for the module)

[Shadowmage]

8 minutes ago, Starwaster said:

On another note, can you/would you expose the number of engines in a cluster, preferably as a persistent field in its config in order to allow other mods to pick up on the fact that it represents multiple engines?

I'll look into it.  Going to be not very straightforward though, as the number of engines isn't tracked like that -- it is dependent upon the currently selected 'layout', and how many POSITION nodes are defined in it.  I only store the current layout name, and a reference to the data-construct for the actual layout.  I could certainly write a method to return the # of positions as an integer, but it would be difficult (and entirely useless to SSTU) to expose it as a field.

So, in theory, that information is already available.  Grab the 'currentEngineLayoutName' name (public field, marked with KSPField) from the engine-cluster module, look up that layout via name from the KSP GameDatabase, and then count the number of 'POSITION' nodes in the config of layout.

Example code that should return the # of positions in the currently selected layout for an engine cluster.  Simply feed in the ModularEngineCluster part-module, and it should return the # of positions.  Structured in such a way as to not require reflection or compile-time dependencies (should be able to copy/paste that code into your mod, and it should 'just work').

        public static int getEngineClusterPosCount(PartModule module)
        {
            string layoutName = string.Empty;
            BaseField field = module.Fields["currentEngineLayoutName"];
            if (field != null) { layoutName = (string)field.GetValue(module); }
            if (!string.IsNullOrEmpty(layoutName)) { return findLayoutClusterPosCount(layoutName); }
            return 0;
        }

        public static int findLayoutClusterPosCount(string layoutName)
        {
            ConfigNode[] layoutNodes = GameDatabase.Instance.GetConfigNodes("SSTU_ENGINELAYOUT");
            int len = layoutNodes.Length;
            for (int i = 0; i < len; i++)
            {
                if (layoutNodes[i].GetValue("name") == layoutName) { return layoutNodes[i].GetNodes("POSITION").Length; }
            }
            return 0;
        }

 

[Starwaster]

3 hours ago, Shadowmage said:

I'll look into it.  Going to be not very straightforward though, as the number of engines isn't tracked like that -- it is dependent upon the currently selected 'layout', and how many POSITION nodes are defined in it.  I only store the current layout name, and a reference to the data-construct for the actual layout.  I could certainly write a method to return the # of positions as an integer, but it would be difficult (and entirely useless to SSTU) to expose it as a field.

So, in theory, that information is already available.  Grab the 'currentEngineLayoutName' name (public field, marked with KSPField) from the engine-cluster module, look up that layout via name from the KSP GameDatabase, and then count the number of 'POSITION' nodes in the config of layout.

Example code that should return the # of positions in the currently selected layout for an engine cluster.  Simply feed in the ModularEngineCluster part-module, and it should return the # of positions.  Structured in such a way as to not require reflection or compile-time dependencies (should be able to copy/paste that code into your mod, and it should 'just work').

        public static int getEngineClusterPosCount(PartModule module)
        {
            string layoutName = string.Empty;
            BaseField field = module.Fields["currentEngineLayoutName"];
            if (field != null) { layoutName = (string)field.GetValue(module); }
            if (!string.IsNullOrEmpty(layoutName)) { return findLayoutClusterPosCount(layoutName); }
            return 0;
        }

        public static int findLayoutClusterPosCount(string layoutName)
        {
            ConfigNode[] layoutNodes = GameDatabase.Instance.GetConfigNodes("SSTU_ENGINELAYOUT");
            int len = layoutNodes.Length;
            for (int i = 0; i < len; i++)
            {
                if (layoutNodes[i].GetValue("name") == layoutName) { return layoutNodes[i].GetNodes("POSITION").Length; }
            }
            return 0;
        }

 

Not sure why it wouldn't be straightforward as it's three lines of code but as you say it's of no use to SSTU so I understand your position.

As to the suggested code, the second one could work as the module's saved ConfigNode could be retrieved easily enough... that's basically the only reliable information that's available at the time the code would have to be run since the vessel in question wouldn't have properly loaded PartModules.

[Shadowmage]

5 minutes ago, Starwaster said:

Not sure why it wouldn't be straightforward as it's three lines of code but as you say it's of no use to SSTU so I understand your position.

Because it is not a field that is already in use.  I would have to create a new public field in the class to store the information (not hard at all), and then I would have to make sure to manually update it and keep it in sync with the actual data from the layout (potentially not that hard, but is needless complexity).

But if the live and fully initialized PartModule (and its fields) are not accessible as you say... a 'position count' field wouldn't help either.  The layout name is already a persistent public field of the module, and would have the exact same accessibility as any 'position count' field I could potentially add.

[Shadowmage]

SSTUFuelSelection module + SSTUVolumeContainer...

In this example I've defined a separate CONTAINER in the config that is responsible for the RCS fuel.  By default it is set to AZ50/NTO mix which is shared by the engines (top screenshot), but can be changed to MP with the 'RCS Fuel' selection widget (lower screenshot)

[Shadowmage]

Much work over the weekend on finishing up the rest of the plugin features and updating configs.  I think at this point it is about as ready for initial testing as it will ever be.  Undoubtedly there are still a few things that got missed, are unfinished, or are actual bugs.

So, for anyone interested in helping to do testing on the 1.4 versions, you may find it all here:  https://github.com/shadowmage45/SSTULabs/archive/dev.zip

The above link should be a zipped up copy of the entire dev repository.  You should install only the contents of the GameData/ folder,  minus the Optional Patches and Texture Sets folders.  I will not be packing up actual releases until this initial testing period is done and most of the bugs/issues have been resolved.  I anticipate that at least a couple of weeks worth of testing and cleanup will be needed.

In regards to submitting bug reports -- keep them all on the Github issues tracker, preferably in one of the existing issues.  Please take a look at the existing issue tickets before posting about a problem and make sure it hasn't already been reported.  For most part-related problems, you will also need to include at least the last few hundred lines of your KSP.log file.

Any 'bug reports' for 1.4+ versions posted here on the forums will result in me adding you to my forum ignore list, without further warning or response.  This is your warning, single and only...be responsible and respectful, or there will be no further releases (dev or otherwise).

[tater]

I’m out of town, but will grab it tomorrow.

[Shadowmage]

16 minutes ago, tater said:

I’m out of town, but will grab it tomorrow.

Thanks.  No rush, whenever you have time.

Should also mention that I'll be updating the dev branch regularly (likely several times per day), so it would be best to keep an eye on the commit log to be apprised of changes and fixes ( https://github.com/shadowmage45/SSTULabs/commits/dev ).  Just use the same link as posted above to grab the updated version (it always points to the most recent .zip of the dev branch).

[drtedastro]

ok, time to start playing with the dev stuff.

thanks.

hey, any new craft files?  or which should we use for initial testing ??

Cheers.

[Jimbodiah]

This is to test at part level,; craft files will come after the official non-dev release is stable. I'll add the craft files to the repository.

[drtedastro]

roger that.  just thought initial tests using a blueprint would come first.

my bad.

lets see what we can concoct.

cheers.

[Jimbodiah]

This is to see if the parts actually still work as the underlying code was changed considerably and needs to be tested. So it is best to wait a bit before making complete craft files that might be broken by a new release. It doesn't take much time to make an apollo replica, so by the time the 1.4 release is stable you will see the updated craft files appear. I'll try to make a few career crafts as well like last time.


 

Meanwhile in KSP 1.3.1: J.J. is a sissy.

Edited May 21, 2018 by Jimbodiah

[drtedastro]

Many thanks for info and reply.

I am starting from scratch with a complete clean install.  currently i can not get ksp to load with the new sstu dir's installed.  just bare load is causing ksp to hang.

I will find it.

 

cheers.

[Jimbodiah]

I see you got it to work over on github?    Try the new dev version, Mage fixed some things.

Edited May 22, 2018 by Jimbodiah

[Shadowmage]

14 hours ago, drtedastro said:

Many thanks for info and reply.

I am starting from scratch with a complete clean install.  currently i can not get ksp to load with the new sstu dir's installed.  just bare load is causing ksp to hang.

I will find it.

 

cheers.

 

14 hours ago, Jimbodiah said:

I see you got it to work over on github?    Try the new dev version, Mage fixed some things.

^^ This.  There were some out of date dependencies in the dev branch.  Also, as previously posted, keep all discussion of problems and issues regarding the 1.4 testing versions on Github.  No further warnings will be issued, I'll just start ignoring people.  I have enabled and use the github issue tracker for a reason, and it is not so that I can sort through pages of forum posts....

 

On a more positive note:

The new plugin code has made it possible to add separation motors to the MFT-D (radial booster fuel tank).  The only limitation would be that if it were added to the part, it would always be present on the part -- it could not be disabled in the editor, and would have to be patched/edited out of the part to be removed.  What kind of interest is there in having this feature added?

[Jimbodiah]

Can't you the user just set the solid fuel or the thrust to zero in the gui? The same goes for the radial booster decouplers.

Edited May 22, 2018 by Jimbodiah

[Shadowmage]

Just now, Jimbodiah said:

Can't you just set the solid fuel or the thrust to zero in the gui? The same goes for the radial booster decouplers.

Yes, you could still do that.  I was more referring to the fact that the 'ModuleEngines' can't be removed from the part once added.  But yes, you could set the thrust + resources to zero, which would effectively disable it.

[Inside-Squirrel]

On 5/21/2018 at 6:30 PM, Shadowmage said:

So, for anyone interested in helping to do testing on the 1.4 versions, you may find it all here:  https://github.com/shadowmage45/SSTULabs/archive/dev.zip

In the perspective of the next 3 months, which minor version of the game will concentrate the developer's efforts? (1.4.1, 1.4.2 or 1.4.3)
I can take part in testing dev version with the game version 1.4.3
or do I need to downgrade to 1.4.2?

P.S.

Thanks for the excellent mod!