Jump to content

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


Shadowmage

Recommended Posts

@Shadowmage I love this!!!

One feature request/suggestion. How hard would it be to give us the ability to save a color.

You said there will be a couple buttons for preset colors, would it be extremely difficult to give us the ability to adjust sliders to find a color we like and then hit "save" and it is added as another "preset"?

Link to comment
Share on other sites

22 minutes ago, Akira_R said:

@Shadowmage I love this!!!

One feature request/suggestion. How hard would it be to give us the ability to save a color.

You said there will be a couple buttons for preset colors, would it be extremely difficult to give us the ability to adjust sliders to find a color we like and then hit "save" and it is added as another "preset"?

Instead of a "save" to a given save game, perhaps it could update an sstu cfg file, so we keep ideal colors across saves.

Link to comment
Share on other sites

17 hours ago, Akira_R said:

@Shadowmage I love this!!!

One feature request/suggestion. How hard would it be to give us the ability to save a color.

You said there will be a couple buttons for preset colors, would it be extremely difficult to give us the ability to adjust sliders to find a color we like and then hit "save" and it is added as another "preset"?

That is outside the scope of what I'm currently trying to accomplish, but might be an option in the future.  Currently the 'preset' colors are loaded from a .cfg file, that can be edited or patched (and shared), so that will have to suffice for now as far as customization goes.

Link to comment
Share on other sites

35 minutes ago, Shadowmage said:

That is outside the scope of what I'm currently trying to accomplish, but might be an option in the future.  Currently the 'preset' colors are loaded from a .cfg file, that can be edited or patched (and shared), so that will have to suffice for now as far as customization goes.

I kind of assumed it would be a system like that and was hoping you had some magic way to load changes made to the .cfg lol

Will we be able to add new presets and your UI will make new buttons for them or will we be limited to changing the already existing presets?

Link to comment
Share on other sites

9 minutes ago, Akira_R said:

I kind of assumed it would be a system like that and was hoping you had some magic way to load changes made to the .cfg lol

Will we be able to add new presets and your UI will make new buttons for them or will we be limited to changing the already existing presets?

You can add/edit/remove whatever you would like.  The GUI loads whatever is in the file, and has a scrollable area in case someone adds a ton of new colors.  As long as you reload the database between edits, the GUI should pick up the new config data immediately.

Link to comment
Share on other sites

1 minute ago, Shadowmage said:

You can add/edit/remove whatever you would like.  The GUI loads whatever is in the file, and has a scrollable area in case someone adds a ton of new colors.  As long as you reload the database between edits, the GUI should pick up the new config data immediately.

I always forget about that lol, thank's I can't wait to use this in game!!

Link to comment
Share on other sites

Bit of a heads up:

The initial KSP 1.3 releases of SSTU might have some incompatibilities with older saves / craft files (probably not game-breaking).  I'm working through the specifics of it now.  Currently it looks like the engine cluster spacing and vertical offsets might end up being off a bit for multi-engine parts.  Hopefully shouldn't be any game-breaking changes, but it is a bit early to be able to say one way or the other.

Working through a major cleanup pass on all of the modular part modules (fuel tanks, engine clusters, upper stages, station-core, msrb), to update them for some of the fixes in KSP API, and for some of the new techniques I have learned over the years of dealing with C# and Unity.  Should result in a more standardized feature set across the parts, as they will all be using a lot of the same code on the back end.  Also lots easier to maintain in the long run; instead of mostly copy-pasted code in 5 different classes needing updating individually, I can update the shared modular code and fix them all at the same time.

Programming with delegates -- fun stuff.  Coming from a Java background, this wasn't really possible in a clean manner.  But with C#, the ability to pass around a method/function as if it were a variable is...great.  Now if only I could figure out how to dynamically reference a field of a class without using reflection.... (I need a reference to a field in such a way as I can pass in any instance of a given class and retrieve the value of a given field; but it needs to work with multiple unique class types that have different field names).

 

Probably still a week or two out from seeing any of this stuff in a release (and still pending the 1.3 KSP release, and ModuleManager being updated).  Tons of code-side work to do, and then I still need to create masks and redo the textures for a few hundred models.  This stuff is all up on the SSTULabs repository under the various dev-branches if anyone wanted to try out the WIP code.... but be aware that it is highly WIP, and might not even be usable at any given time (will be more stable/usable in about a week or so as I finish the code work and move onto the texture/masking work).

 

@JoseEduardo and/or @stratochief66 Are you still maintaining/helping with the SSTU-RO configs?  If there were any code-side changes needed in SSTU to fix any incompatibilities, now would be the time for them to be made.  Is there anything horribly broken?  (aside from some FAR issues)

Link to comment
Share on other sites

No, I'm not maintaining it anymore

btw, since you are working on the code, can I ask you if it is possible to add a slidebar or something to change the rotation of the engine clusters in-game? some engines look right with the clusters, but others might look off :)

Link to comment
Share on other sites

29 minutes ago, JoseEduardo said:

No, I'm not maintaining it anymore

btw, since you are working on the code, can I ask you if it is possible to add a slidebar or something to change the rotation of the engine clusters in-game? some engines look right with the clusters, but others might look off :)

Second this. The new RD-180 is a great example. Awesome engine, but clusters of two just look... odd. 

Link to comment
Share on other sites

33 minutes ago, JoseEduardo said:

No, I'm not maintaining it anymore

btw, since you are working on the code, can I ask you if it is possible to add a slidebar or something to change the rotation of the engine clusters in-game? some engines look right with the clusters, but others might look off :)

Good to know :)

Slider -- not really.  You can't dynamically add KSPFields/UI controls to a PartModule, and each engine in the layout would need its own rotation field/UI control so it can be controlled individually (so I would need from 1 to 9 fields depending on the layout, possibly more if using layouts with >9 engines).  Unless you are proposing a global rotation offset for all engines in a layout?  Would be doable, but wouldn't work on all of the layout/engine/mount combinations correctly (e.g. might work for the Four-X layout, but would not work properly on the Three-Inline layout).

6 minutes ago, CatastrophicFailure said:

Second this. The new RD-180 is a great example. Awesome engine, but clusters of two just look... odd. 

Heh, blame the Russians :)

Link to comment
Share on other sites

23 minutes ago, JoseEduardo said:

I was thinking on one global for the all engines in the layout, yes, keeps it simple and possibly compatible with new clusters (like those on that madman pack somewhere in the forum)

I'll see what I can come up with.  Seems like it would need to be coupled with a 'rotation direction' that is set per-engine-position in each layout, as i many cases you would want engines to rotate opposite of eachother and not in the same direction; but it would be different per-layout, and per-position (could even set some of the engines in a layout to not rotate, if desired).

Link to comment
Share on other sites

49 minutes ago, JoseEduardo said:

I was thinking on one global for the all engines in the layout, yes, keeps it simple and possibly compatible with new clusters (like those on that madman pack somewhere in the forum)

Added.  Engine layouts configs now support an optional 'direction' parameter in their position node specifications.  A single UI slider has been added to the engine-cluster module to allow for rotating all engines from -180 to +180 degrees, in the direction specified for the position for that layout.  Default direction is 1, which should be counterclockwise (but might be clockwise... silly different coordinate systems in use everywhere); specifying 0 for the 'direction' in the position node will disable slider-based rotation for that position.  This does not rotate the mount, nor the location of the positions in the layout, merely the local rotation of each engine in its existing location as defined in the layout.

Though this reminded me that there are per-engine-per-layout (and per-mount) overrides available for the rotations which can be specified in the part-configs (e.g.  https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Parts/ShipCore/Engines/SC-ENG-RS-68.cfg#L152-L206 ).  So the proper solution, for the RD-180, would be for someone to figure out what those custom rotations would be and to submit a PR for them (or wait until I can get to it, which should happen before the 1.3 initial releases).  This would give them the proper initial rotations, which the user could then customize further with the 'rotation' slider.

Link to comment
Share on other sites

15 hours ago, linuxgurugamer said:

@Shadowmage

I'm working on adding support for SSTU into Fusebox.

Specifically the solar panels.

I need to know two numbers: 

  1. Max EC generation possible for use in the Editor
  2. Current EC generation

I see a field:  resourceAmount, but no explanation as to what it is.  Can  you help?

Thanks

resourceAmount is indeed the field you are looking for as far as max EC generation is concerned.  It is multiplied at runtime by the number of suncatcher transforms found in the model (which are unfortunately private...).

'energyFlow' is the current EC/s value, but it is a private field as well.

Edit:  I'll look into cleaning up the max EC calculation to use the config value as a 'total', and dividing by transform# to get the per-transform value.  Will also see about adding a publicly accessible 'current' EC generation to simplify the integration support.

Will probably be a few weeks out for these changes though (will first be avaialble for KSP 1.3+ more than likely), as I'm in the middle of a fairly substantial rework on some models/shaders/textures that is going to keep me busy for a bit.  So the best bet on these would be to hold tight for a few more weeks; if anyone questions the status/etc, feel free to link them to this post.

 

3 hours ago, Iso-Polaris said:

Cuold you add RealFuel compatibility for SSTU?

Should be supported as far as plugin-level compatibility goes.  Patches are community provided/maintained, and nothing that I have any involvement in.  So if something isn't working, feel free to submit some patches to fix the problem/parts.

(The existing RF support was intended for RO compatibility along with the rest of the RO patches, so might not work with stand-alone RF installs)

Edited by Shadowmage
Link to comment
Share on other sites

5 hours ago, Shadowmage said:

resourceAmount is indeed the field you are looking for as far as max EC generation is concerned.  It is multiplied at runtime by the number of suncatcher transforms found in the model (which are unfortunately private...).

'energyFlow' is the current EC/s value, but it is a private field as well.

Edit:  I'll look into cleaning up the max EC calculation to use the config value as a 'total', and dividing by transform# to get the per-transform value.  Will also see about adding a publicly accessible 'current' EC generation to simplify the integration support.

Will probably be a few weeks out for these changes though (will first be avaialble for KSP 1.3+ more than likely), as I'm in the middle of a fairly substantial rework on some models/shaders/textures that is going to keep me busy for a bit.  So the best bet on these would be to hold tight for a few more weeks; if anyone questions the status/etc, feel free to link them to this post.

ok, thanks

Link to comment
Share on other sites

Spent my dev time over the weekend working on the recoloring update.  So much work to do... (didn't realize I had so many models...)

The MFT and MEC modulues have both been adapted to use the new modular-part code setup.  Will be working through the MSRB, MUS, and MSC modules this week now that I've got the system worked out and working.  The change greatly reduces duplicate code across the modules and is giving them all a very similar internal layout to make them easier to maintain and work with in the long run.  Few hundred lines of code reduction per class so far, and potential for a bit more if I can find how to unify a few more functions.

All of the adapters, MFT-nosecones, and SRB-nosecones have all been combined onto a single texture sheet.  Results in much better use of the UV space, reduces the number of textures needed, and will give a consistent set of textures and colors across the parts.  Will be working through the rest of the nosecone/adapter stuff this evening, and then moving onto the engine mounts.

I also intend to add recolor support to the Procedural Decoupler, Probe Core, Interstage Decoupler, Interstage Petal Adapter, and am going to attempt to add it to the stock-based payload fairings as well (no clue how that will go, they already use a customized shader setup; but I'm going to give it a try...).

Lastly, I'm going to try to work the recoloring system into the generic SSTUTextureSwitch setup so that it might easily be applied to parts for other mods.  Should be as simple as adding a patch to add the module to the part, and supplying the color masks if needed (optional, but highly recommended).  Might even be able to apply this to the SC-A/B/C/E part series... we'll see how motivated I am once the rest of the parts are finished up.

 

WARNING - There -will- be some craft/vessel/save breakage with the update to 1.3.  So much is changing with the texture sets that I cannot guarantee any compatibility across KSP versions.  Most craft should survive the update physically (part names or stats aren't changing), but none of them will have the proper texture set / coloring information in place, and as such will revert to the defaults for the parts/models in use.

ADDITIONAL WARNING - The texture set definition system is changing as well (the config file layout).  Any external packs using the SSTU plugin will need to also be adapted to the new texture set system, or their texture sets may be non-functional (I've tried to keep a bit of extra code to allow for loading the old definitions, but they will be lacking some features).  This is mostly a warning for @JoseEduardo and @Jimbodiah for their custom expansion packs, though I'm not sure how much you guys are using the texture-set stuff.  Feel free to contact me via PM and I can give you details on what is changing / etc.

Link to comment
Share on other sites

4 minutes ago, Calvin_Maclure said:

@Shadowmage, I think you already stated this in the past, just cant remember what you said. But everything you just talked about in the above post, is that just for the 1.3 version or is it also for the 1.2.2 version?

All of this work will be for the initial KSP-1.3+ releases of SSTU.

What you have now is the final 1.2.2 release.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...