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

[jstnj]

Having an issue with the Modular Fuel Tanks. the UI is throwing a bunch of NaN's when trying to configure the tanks in the VAB...and eventually it gets stuck, not allowing you to remove the part or exit the game.

 

 

Log: https://pastebin.com/j5VeUmMV

Screenshot: https://i.imgur.com/ZEPJxao.jpg

 

I have already cleaned out the SSTU installation and reinstalled, including all dependencies listed in the readme. Also, the Textures Unlimited configs by @Jimbodiah seem not to be working either, the list after pressing "Open Recoloring GUI" yields no options, and then won't close.

 

Any help is appreciated!

[Shadowmage]

2 minutes ago, jstnj said:

Having an issue with the Modular Fuel Tanks. the UI is throwing a bunch of NaN's when trying to configure the tanks in the VAB...and eventually it gets stuck, not allowing you to remove the part or exit the game.

 

 

Log: https://pastebin.com/j5VeUmMV

Screenshot: https://i.imgur.com/ZEPJxao.jpg

 

I have already cleaned out the SSTU installation and reinstalled, including all dependencies listed in the readme. Also, the Textures Unlimited configs by @Jimbodiah seem not to be working either, the list after pressing "Open Recoloring GUI" yields no options, and then won't close.

 

Any help is appreciated!

Looks like you are using RO/RSS, so I can't really offer any support. (RF + FAR = not touching it....)  (Please see the SSTU main post -- it explicitly states that I do not offer support for any RO/RSS installs)

However, from your posted log, you are missing some model definitions.  So, this is certainly not a 'clean' install.  You have some mods or other patches that are messing with things.

ERROR: Could not locate model data for name: MUS-Upper-Dome
[ERR 12:59:50.478] Module SSTUModularFuelTank threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at SSTUTools.ModelData..ctor (.ConfigNode node) [0x00000] in <filename unknown>:0
  at SSTUTools.SingleModelData..ctor (.ConfigNode node) [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUModularFuelTank.loadConfigData () [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUModularFuelTank.initialize () [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUModularFuelTank.OnStart (StartState state) [0x00000] in <filename unknown>:0
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

(BTW, also include the -full- log file when posting, as 90% of the stuff I need to know is what happens during part-loading, which is missing from your posted log).

That single error there will cause complete failure of the part.

 

Does the problem happen on an actual -clean- installation?  Only SSTU and its core dependencies?  (TU, KSPWheel, CRP, MM).  Please try in that environment, and if the problem persists, post full log files.

 

[Jimbodiah]

My color presets file replaces the existing one, it works fine as I have several other people using it besides myself. Maybe if you have it as duplicate it could cause issues; havne't tried that tbh? Anyway, just use a clean install like Mage said, no other mods that affect SSTU like my JPL patches just to be sure. But I think it's RO that has an SSTU patch that is out of date. RO supports up to KSP 1.2.x  iirc.

BTW, if you are using my recoloring presets, you will need KSP1.3.1 and the corresponding SSTU version. Not sure what version you have as you are running RO.

Edited February 14, 2018 by Jimbodiah

[jstnj]

So @Jimbodiah/ @Shadowmage:

 

This is almost definitely an RO issue.

 

Although not required of you (because I know you dont support RO yourselves)...if you have time to take a peek at the full logfile here (https://pixeldra.in/u/I1W8-1), I would appreciate it.

The tanks worked on a real clean install (only SSTU dependencies on a new KSP install), but as soon as RO was installed, the same exact issue came back, that log ^  represents this latest RO / SSTU install and the resulting issue.

 

Anyway, if not, I appreciate your help anyway. Thanks!

Edited February 14, 2018 by jstnj
typo

[Theysen]

2 hours ago, jstnj said:

So @Jimbodiah/ @Shadowmage:

 

This is almost definitely an RO issue.

 

Although not required of you (because I know you dont support RO yourselves)...if you have time to take a peek at the full logfile here (https://pixeldra.in/u/I1W8-1), I would appreciate it.

The tanks worked on a real clean install (only SSTU dependencies on a new KSP install), but as soon as RO was installed, the same exact issue came back, that log ^  represents this latest RO / SSTU install and the resulting issue.

 

Anyway, if not, I appreciate your help anyway. Thanks!

You're using a SSTU version in 1.3.1 RealismOverhaul it looks like which is still under development, the latest working SSTU configs are for the officially released 1.2.2 SSTU with the corresponding SSTU version marked in the RO OP.

There is no issue with SSTU itself, it's just that the Fuel Tank for example had some severe changes since RO configured it, it will be fixed soon.

 

[anan4art]

My ST-DOS and COS can not show their docking ports on their respective nodes. I did delete most of solar panels in ST-GEN but the Welding Port since those solar panels wont be tracked in my Kerbalism gameplay (and why a Welding Port be stranded in the ST-GEN folder?) Though ST-DOS still able to load these solar panels to the MAX-L, their docking ports just refuse show up.

My current guess is the SSTUModularStationCore has connection to ModelData-DockingPorts.cfg somehow but I cant fathom why the DOS/COS docking ports wont show up in the VAB and their right-click menu. My tinkering are futile.

Also, where can I find the config file to unlock SSTU-ST-DockUpgradeMedium / Small / Large? I can't find it in the Upgrades folder.

PS: If you're not already correct it, The IVA for E-FSX is off in the z axis by -13 units.

Love your mods

[Shadowmage]

5 hours ago, anan4art said:

My ST-DOS and COS can not show their docking ports on their respective nodes.

The integrated docking port functionality has been entirely removed in recent versions due to conflicts with the core KSP code.  (KSP code does not fully support runtime dynamic module switching).

So it doesn't matter how much you try, it is not going to work.

(Is there still information posted somewhere that states they have integrated docking ports?  I thought I had removed all such references, but apparently I've missed some...)

[Jimbodiah]

The cfg options for ports were removed from everything but the two hubs, so there should not even be a GUI option for them anymore?

[T-10a]

Any progress to report so far @Shadowmage?

In my progress, I've added the RD-275, RD-0210 (Proton family engines), LR-87, LR-91 (Titan family), 1 & 2kN thrusters, Vikas-2 and some others via patching existing parts (ala Jimbodiah's patches), and I'm working on the RD-58, to be followed by the RD-270 & RD-264 (you can tell I have a thing for hypergolics ). I've also made use of the VSR SSTU patches from a while back for the basis of the Proton & Titan engines.

Edited February 18, 2018 by T-10a

[Shadowmage]

On 2/18/2018 at 3:23 PM, T-10a said:

Any progress to report so far @Shadowmage?

Progress on what?

Still working on the tank model+texture update and still making some small progress on the plugin/coding side of things.  Still going to be at least a few weeks until it is all usable, and likely a few more after that until it is 'finished'. 

I'll probably post up some renders of the new tank models (and textures) when they are a bit further along.  Right now I'm working on figuring out the best use of the texture space for the non-cylinder tank models (sphere, soyuz); hope to get the re-UV'ing done this week, as well as some good progress on the textures.

[truckstoppers]

Can you put this on CKAN please?

[tater]

56 minutes ago, truckstoppers said:

Can you put this on CKAN please?

No.

On 7/28/2015 at 12:13 PM, Shadowmage said:

Please keep in mind that these are all testing releases. Things may break between releases. There will be bugs. Many things are unfinished and/or unoptimized.

 

[Shadowmage]

Some idea of the level of simplification that this update is allowing me to do....

Here are all of the current cylinder fuel tank models.  Every time I change textures, or really do anything model related, I have to update and re-export every single one of these.  Something like ~100 models to update, export to .fbx, and then run through part-tools.  Hours worth of 'busy' work.  (discard the cargo bay models, as those aren't part of the tank texture/model set... just included in the render for reasons...; but also not shown are the spherical tank bits, which is actually a larger number of models than the cargo bays)

 

And then here is the new lineup of fuel tank models (WIP, missing perhaps 1-2 more segments for conical tanks) (textures very WIP, only used to line up UVs):

From 48 basic 'cylinder' fuel tank models, down to 6.  Should cut many hours out of every update.  Will also allow for more user-configurability in the tank models (e.g. adding new model definitions) as these new 'modular models' can simply be strung together to form whatever kind of tank that is desired (at the config file level).

[Starwaster]

So, how about an SSTU - Lite so people don't get upset if I don't update Procedural Parts...?

[RedParadize]

@Shadowmage Now I understand better some of the comment you made! I trough your approach was more similar to the now defunct Kosmos URM. I now wonder how you will apply various textures to this. UDIM maybe?

Regardless, it look much simpler like that. Might incite modder to use your stuff. You comment suggest "advanced" user could potentially combine various section themselves. I am interested by that part.
 

[Shadowmage]

7 minutes ago, RedParadize said:

I now wonder how you will apply various textures to this. UDIM maybe?

Very simply

I recently added some plugin code to merge the models within a model definition.  So you just apply a material to the single (merged) mesh, and away you go (merging requires that all meshes will use the same material, as KSP does not support multiple materials on a mesh).

 

8 minutes ago, RedParadize said:

You comment suggest "advanced" user could potentially combine various section themselves. I am interested by that part.

Yep.  If the tank segments are labeled A,B,C,D,E, etc, you'll be able to create a config for a new model definition, and specify that you want segments A,D,B,D,D,A,E, or any other combination.  When the model definition is parsed/loaded, it will locate those meshes, clone them, merge them all into a single model/game-object, and will then use that merged model whenever that model-definition is specified in a modular part.  The only caveat with the merged meshes/models is that they all must use the same materials/textures -- if they require separate textures/materials (e.g. for different AO sheets), you need to use non-merged SUBMODELs (but a single model-definition can specify both merged and non-merged sections...and the texture set system can already properly handle multiple material assignments within a single texture-set).

All of that functionality already exists in the current releases, minus the model/mesh merging bits.  You can already use the SUBMODEL setup within model-definitions to create new compound model types; I don't use it very much, but it certainly exists and works well.

 

Hopefully I'll be wrapping up the modeling bits in the next few days.  Need to find a good replacement for the Soyuz booster tanks (or just re-UV them for the new textures....) -- really want to replace these with some simple multi-segment conical tanks that can be used for more than just side boosters (e.g. N-1 lower stage tanks).

[RedParadize]

@Shadowmage I see. I already used SUBMODEL when I did my single part lander quite a while ago. I have some Idea I would really like to do... will see.

About your comment on the soyuz booster, I agree. I often have wished for longer nose cone and sloped tanks. There is so many ways these could be used. Now that you are down to repeated sub segments it might open up many possibilities, like curved segments. Depending on how your new in-game editing works obviously. If I ad to  do that in maya I would simply use a lattice...

[tater]

Nice stuff. There is a mod about to drop a beta with "munar village" where the inflatables have a mun texture that gets added (like my ideas posted here to simulate regolith on top).

Another is doing landers, woot!

My interest is starting to increase again, along with my continued FH excitement.

[RedParadize]

6 minutes ago, tater said:

My interest is starting to increase again, along with my continued FH excitement.

FH?

[Shadowmage]

31 minutes ago, RedParadize said:

Depending on how your new in-game editing works obviously.

The same way that it currently does.  E.G. there is no in game 'editing' of the models.  For each slot (module) in the part, you select from a list of pre-built models via the slider/buttons.  Only there are now 2 more 'slots' for models; so instead of a 3-slot part, you get 5 slots (+2 rcs, +1 solar).  Also the built in scale-chaining is a bit of a change, allowing for a single model definition to be used at different scales depending on what slot/module it is below it in the hierarchy (with the middle/core slot being the root).  It is this scale-chaining that will allow for conical models to be usable, and potentially other setups that I haven't quite narrowed down yet.

With the two additional model slots + good use of the SUBMODEL and merged-model setups, it should be quite a bit easier to design new tank types and entirely new part concepts.  At least from a modeling perspective -- there will be additional config work needed, but being able to re-use the existing models should result in a net gain in productivity.

The other new feature of the modular parts is 'adapter validation' code -- ensures that only adapters that can actually fit onto the parent slot can be selected.  So, for example, you can't select an 'empty' adapter for a tank end-cap, as the tank itself lacks any end-cap mesh (it will only allow for selecting adapters with meshes that will properly close the end of the tank).  This feature basically just allows for lots of different adapter/model types to all be used in the same part without requiring tons of additional setup code in the part config (rather, the validation data is specified in the model definitions).  No longer will there be a need for a new part just for spherical tanks -- the validation code will enforce proper use of the body/adapter combos (same goes for other 'special' fuel tank setups); of course, it is still an option and does make sense for specific part configurations (e.g. lander fuel tanks).

[tater]

32 minutes ago, RedParadize said:

FH?

Falcon Heavy.

[RedParadize]

1 minute ago, tater said:

Falcon Heavy.

Ah yeah obviously.  There is a guy that is currently developing a mods/script that use Kos and Trajectories to get the booster to land on their own. Looks cool.

[Jimbodiah]

4 hours ago, Starwaster said:

So, how about an SSTU - Lite so people don't get upset if I don't update Procedural Parts...?

SSTU-Tanks ftw!

[Jimbodiah]

1 hour ago, RedParadize said:

FH?

 

Speaking of the FH... Would there be room for their style of nosecone somewhere down the line? Plus I've been wondering if integral legs on tanks are possible similar the the eventual LV setup? I mean, single part Falcon booster, just sayin' :))))) drooooool

Edited February 21, 2018 by Jimbodiah

[Starwaster]

20 minutes ago, Jimbodiah said:

 

Speaking of the FH... Would there be room for their style of nosecone somewhere down the line? Plus I've been wondering if integral legs on tanks are possible similar the the eventual LV setup? I mean, single part Falcon booster, just sayin' :))))) drooooool

 

I'm using the Kerbal Reusability mod which has some decent looking Falcon legs. Of course, I seldom actually LAND the stages myself, electing instead to let Stage Recovery deal with it, making the legs are superfluous, though sometimes I do manage to intercept it before it's destroyed and try to land it myself.

Though there's an unfortunate problem in that Stage Recovery can't really deal with SSTU's cluster engines and treats them as having the thrust of a single engine since it operates at a time when the part and its part module don't exist. I've actually tried hacking SR's code to deal with the problem but snapshot parts and partmodules are apparently highly resistant to reflection. Very frustrating and a solution may not be possible