Jump to content

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


Shadowmage

Recommended Posts

10 minutes ago, captinjoehenry said:

I love this mod a ton.  The only odd thing is that once you fully upgrade the SSTU tanks they hold an insane amount even at small sizes.  Is this normal or is this caused by a bug in my install?  If it is a bug I would guess it's from module fuel tanks and the volume system being confused?

Which parts are you talking about? I've been spending a lot of time digging through the configs lately and I know that the MFT-A tanks are pretty reasonable compared to stock.

Volume scaling for stock and stock-alike parts is pretty arbitrary, and only roughly corresponds to in game dimensions. I do recall being surprised at capacity of radial tanks at some point but I don't think I checked it out in detail.

 

Link to comment
Share on other sites

Just now, Nightside said:

Which parts are you talking about? I've been spending a lot of time digging through the configs lately and I know that the MFT-A tanks are pretty reasonable compared to stock.

Volume scaling for stock and stock-alike parts is pretty arbitrary, and only roughly corresponds to in game dimensions. I do recall being surprised at capacity of radial tanks at some point but I don't think I checked it out in detail.

 

I only tried the SSTU fuel tank and SSTU lander tank and both of them hold an insane amount of fuel even on the smallest size.  I can provide some screenshots when I am back at my PC in about 30 minutes.

Link to comment
Share on other sites

36 minutes ago, RedParadize said:

@Shadowmage
Regarding the quick render you did:

1-The "Boxy" variant on the left seem a bit plain. Will you add details only in texture?

2- Does it mean we wont be able to have less tank around the frame? like 2 or 4?

3- This beg for a stretchable hexagonal frame!  

1.)  Those are the 'paneled' variants, that can be seen on many of the 'Altair' or LSAM concept renders.  As such they won't really have much detail, being a simple paneled box.  Also intended for use for storage of resources that wouldn't make sense in a standard liquid/gas fuel tank (e.g. minerals, snacks, etc.).

260px-Altair-Lander_(latest).jpg

2.) Was never planned to have that functionality.  I don't have the kind of time necessary to make that many model variants (already I'm at >40 hours of modeling work on these parts; triple or quadruple that to add more variants, as well as needing a ton more textures/RAM usage).

3.)  See NearFuture mods -- with the SSTU-OptionalPatches setup installed, there is a modular hex truss part :)

 

14 minutes ago, captinjoehenry said:

I love this mod a ton.  The only odd thing is that once you fully upgrade the SSTU tanks they hold an insane amount even at small sizes.  Is this normal or is this caused by a bug in my install?  If it is a bug I would guess it's from module fuel tanks and the volume system being confused?

Are you using the ModularFuelTanks mod?  If so -- that is the problem.  It incorrectly sets the volume of resources and assumes all resources are specified in 5-liter units, and as such the SSTU parts end up with 5x more fuel than they should.

This is an error in the MFT mod -- even though I tell it to update the volume in LITERS (the method actually has an input variable called 'liters'), it uses that value as 5-liter UNITS.  Literally, there is nothing I can do about it.  The 'fix' needs to come from MFT -- they need to respect the volume specified in the resource definitions, and actually respect the input of 'liters' rather than assuming 'units'.

 

Link to comment
Share on other sites

1 minute ago, Shadowmage said:

1.)  Those are the 'paneled' variants, that can be seen on many of the 'Altair' or LSAM concept renders.  As such they won't really have much detail, being a simple paneled box.  Also intended for use for storage of resources that wouldn't make sense in a standard liquid/gas fuel tank (e.g. minerals, snacks, etc.).

260px-Altair-Lander_(latest).jpg

2.) Was never planned to have that functionality.  I don't have the kind of time necessary to make that many model variants (already I'm at >40 hours of modeling work on these parts; triple or quadruple that to add more variants, as well as needing a ton more textures/RAM usage).

3.)  See NearFuture mods -- with the SSTU-OptionalPatches setup installed, there is a modular hex truss part :)

 

Are you using the ModularFuelTanks mod?  If so -- that is the problem.  It incorrectly sets the volume of resources and assumes all resources are specified in 5-liter units, and as such the SSTU parts end up with 5x more fuel than they should.

This is an error in the MFT mod -- even though I tell it to update the volume in LITERS (the method actually has an input variable called 'liters'), it uses that value as 5-liter UNITS.  Literally, there is nothing I can do about it.  The 'fix' needs to come from MFT -- they need to respect the volume specified in the resource definitions, and actually respect the input of 'liters' rather than assuming 'units'.

 

Ah good to know as I have that mod installed.  Can I just remove the MM patch for MFT from SSTU and restore reasonable fuel amounts?

Link to comment
Share on other sites

Just now, captinjoehenry said:

Can I just remove the MM patch for MFT from SSTU and restore reasonable fuel amounts?

Yes.  The parts will then use the built-in SSTU method for resource configuration, which has a different GUI and options compared to MFT.

Link to comment
Share on other sites

7 minutes ago, Shadowmage said:

Yes.  The parts will then use the built-in SSTU method for resource configuration, which has a different GUI and options compared to MFT.

Great to hear!  Maybe think about not having the MM patch in the download till it is fixed so others don't have this issue?

Also the SSTU reentry capsule styled off the Orion is fantastic!  The only thing is that I wish I could use stock monoprop instead of the realistic fuels it uses now as basicly all the RCS systems I have run off of stock monoprop :P

Edited by captinjoehenry
Link to comment
Share on other sites

1 hour ago, captinjoehenry said:

Great to hear!  Maybe think about not having the MM patch in the download till it is fixed so others don't have this issue?

Also the SSTU reentry capsule styled off the Orion is fantastic!  The only thing is that I wish I could use stock monoprop instead of the realistic fuels it uses now as basicly all the RCS systems I have run off of stock monoprop :P

The new SSTU RCS parts will have a fuel switch so that you can use those with either propellant.

 

Link to comment
Share on other sites

I'm playing with sstu and non of the mks parts appear, neither is usi life support even though I installed. It just automatically deletes the mks parts and the usi life support folder. I'm sure it's caused by sstu cause it used to prevent stock parts from appearing in game 

Link to comment
Share on other sites

12 hours ago, captinjoehenry said:

Huh I can't seem to find the MFT patch for SSTU.  What file is it?

It is labeled as a RF (RealFuels) patch, as that is what it was intended for.  GameData/SSTU/ModIntegration/RealFuels/RF.cfg

 

1 hour ago, The-Doctor said:

I'm playing with sstu and non of the mks parts appear, neither is usi life support even though I installed. It just automatically deletes the mks parts and the usi life support folder. I'm sure it's caused by sstu cause it used to prevent stock parts from appearing in game 

I can guarantee that SSTU is not deleting any folders.  That statement is simply false.

(its statements like this that make me question why I continue modding / releasing things)

Link to comment
Share on other sites

I have long dreamed of having all the most common plane fuselages and major mod expansions to those fuselages reskinned in properly reflective bare metal. I don't care how unrealistic it is for spaceplanes to look shiny silver... it'll be seriously badass! And that vision might possibly become a reality if you make these pbr whatsits available to other modders. Please, please, pretty please.

Link to comment
Share on other sites

@White Owl  I want everything to look like it's either chrome or gold plated, or black chrome, or blue... ah heck, I don't care for the color, as long as it is SHINY  :sticktongue:

@Shadowmage  Easy son, you'll pop an artery!  Don't you know The Doctor is never wrong :wink:

 

20 hours ago, tater said:

he new SSTU RCS parts will have a fuel switch so that you can use those with either propellant.

Only the SM/CMs and DOS parts have their RCS running on Hypergolics, but all have local fuel supplies. The seperate RCS parts are all MonoPropellant.

And here I kept wishing they would be Hypergolic instead (which is why I patched some for myself).

Link to comment
Share on other sites

22 hours ago, RedParadize said:

I have dreamed of that for a long time.

I think that trying to adapt your work to other texture switch plugin might be more work and maintenance than explaining how your own system.  And from my point of view the  standard shader/PBR setup is a bit like the icing on the cake. The full SSTU system, with its the tank content and scaling system, engines, model switch, texture switch... I would like to see all of that used. 

Having messed quite allot with your system (prior to texture switch) once you get how it work its not that hard. Obviously converting existing model to your system might be quite challenging.

If you would provide a exemple model, reduced to its simplest expression, with annotated config and a brief wiki for the overall architecture. Don't you think modder could quickly learn how to use its various functionality? Could they use these functionality independently? 

While I could certainly port the SSTUTextureSwitch module into the PBR shader release (and might, its a decent stand-alone texture switch system), I don't think it would be wise to include much more than that.  If another mod author really wanted to use all of the SSTU features (model switching/fuel setup gui/etc) -- they can install the full SSTUTools.dll.  The rest of the 'modular part' modules and functions are so deeply integrated into the SSTU code that there really is no way to separate them -- the 'modular parts' -are- the SSTU code.

I would love to see others use the model setup/definition and modular parts system.  I really don't think that anyone would though (there has been ample opportunity for it over the past 2+ years).  It seems that most other modders' (and players?) embrace and enjoy the stock model setup and part setup (lego rockets with lots of parts).  I'm not going to try and change that.  I cannot decide how others will enjoy the game; all I can do is keep modding the things that help -me- to enjoy the game more.

Do I think that other mods/modders could learn and use the modules?  Absolutely -- both @JoseEduardo and @Jimbodiah have released 'mod-of-a-mod' expansion packs that do as much.  The modules themselves are compatible with a very wide range of modeling styles and workflows, and most entire mods could be converted to use the SSTU modules and part setup through nothing more than MM patches (lots and lots of patches... but still... just plain-old config/text editor work).

 

19 hours ago, captinjoehenry said:

Great to hear!  Maybe think about not having the MM patch in the download till it is fixed so others don't have this issue?

Also the SSTU reentry capsule styled off the Orion is fantastic!  The only thing is that I wish I could use stock monoprop instead of the realistic fuels it uses now as basicly all the RCS systems I have run off of stock monoprop :P

Please file a github issue regarding the ModularFuelTanks patch -- seems prudent to simply remove it for the time being.  I've tried asking MFT to fix their resource volume issues but was told it was being done intentionally (an attempt to 'simplify' resources in a stock install).  (really not sure how it copes with XenonGas having a different volume in stock than the rest of the resources... but not my problem)

RCS -- I have a solution to this problem in the pipeline, unfortunately it has gotten a bit buried under some of the other development work.  Will see about moving this closer to the top of the stack.  (SSTU's stand-alone RCS ports will have a module that allows for switching the RCS propellant while in the editor;  the module could be applied to other mods/stock parts through MM patches)

 

53 minutes ago, White Owl said:

I have long dreamed of having all the most common plane fuselages and major mod expansions to those fuselages reskinned in properly reflective bare metal. I don't care how unrealistic it is for spaceplanes to look shiny silver... it'll be seriously badass! And that vision might possibly become a reality if you make these pbr whatsits available to other modders. Please, please, pretty please.

:)

I'm certainly going to try and put together the shaders as a separate / stand-alone mod.  From there it is entirely upon other mod authors as to if they want to support the shaders -- as it will require new textures be created for each supported part, I imagine that adoption will be fairly low.  Add in that most mods seem to enjoy the 'stock-alike' textures, and the potential audience for adoption is probably like 1-2 mods total (with one of those being SSTU itself).  So far the responses I've seen have been mostly positive from players/end-users, but I haven't heard anything regarding it from other mod authors (i.e. seems nobody is interested yet).

Link to comment
Share on other sites

4 hours ago, Shadowmage said:

It is labeled as a RF (RealFuels) patch, as that is what it was intended for.  GameData/SSTU/ModIntegration/RealFuels/RF.cfg

 

I can guarantee that SSTU is not deleting any folders.  That statement is simply false.

(its statements like this that make me question why I continue modding / releasing things)

not my fault mate, just encountering a strange problem, sorry

Link to comment
Share on other sites

7 minutes ago, RedParadize said:

@Shadowmage Does integrated docking port on hab are permanently gone? It was massively reducing part count. 

Yep.  I don't see any potential of the optional/switchable docking ports making a return.  KSP code simply refuses to cooperate with modules that are added (or removed) at run-time.  Given enough time (and patience) I might have been able to get it working...(blah blah, work sucks, meh, etc...).   I'm not happy about having to remove them either, but it was better then continuing to have the buggy parts in the releases (for example in my recent testing, I was using a station-core part with the docking ports removed/disabled in the editor, but the 'decouple node' button from the docking port module was still showing up in flight, and actually decoupled parts of the craft when activated).  (WTB proper use of moduleIsEnabled flag in every stock part-module.... if that was implemented in the stock code none of this would have been a problem)

Now, the main problem isn't actually with the integrated docking ports themselves -- KSP deals with those decently -- it is with the adding/removing them while in the editor.  Nor is changing the ports' model or size problematic -- all of that can be dealt with in a fashion that works with the stock code.

One potential alternative might be to create a 2n'd copy of those parts that has full-time (non-optional) docking ports.  Would require some minor adjustments to the plugin code to handle the docking port model re-positioning with adapter changes, but nothing too complex or time consuming.  The problems with this are related to editor-part-list bloat (I really don't like duplicate parts for such minor functional differences), and it wouldn't be able to handle cases of only wanting a docking port on one end of the part (it would be either ports on both ends, or none at all).  Far from an ideal solution.  So far that I'm not even going to think any further about implementing it (until/unless the problems could be solved).

 

A couple potential... enhancements... I might be able to offer in regards to the part-count increase from stand-alone docking ports are:

  • Welding docking port -- if your station is permanent, use these to make it permanent.  No worries about docking ports increasing part count with these, as the docking ports remove and delete themselves when the parent parts are welded together.
  • Docking port toggle -- a mini-mod that I put together that adds a 'toggle docking port' control to stock docking ports.  When toggled to the 'disabled' state all nearly all docking port code is disabled -- the performance hit from using non-docked and non-shielded ports is removed.  The downside is that you have to remember to 'activate' the ports before you can use them for docking.  https://github.com/shadowmage45/DockingPortToggle (consists only of a single model file and an MM patch, no plugin code; patch can be extended to other mods' docking ports very easily).
Link to comment
Share on other sites

3 minutes ago, The-Doctor said:

Bro, I can confirm sstu labs was deletings the parts in mks, I just removed sstu and they appeard

So they are not "deleted" just hidden. Its most likely a patch that does that,      bro.

Look in /SSTU/ModIntegration/ and SSTU-OptionalPatches/ If you have it installed.

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...