Jump to content

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


Shadowmage

Recommended Posts

your mod is insanely cool! One day, I will probably delete my whole Squad folder and replace it by SSTU :)

Just two suggestion:

  • The current mount system is really cool, but...
    • Mounting multiple engines in a single part means you cannot control them separately (example: central engine shutdown on the Saturn V). Plus if one explode, all of them explode (if you fail a falcon 9 landing with stock parts, you may save one or two engines which haven't exploded, but with SSTU...)
    • This mount system is great but only support your parts :P...so maybe adding a mounting part with nodes instead of engines?....
  • Pleaaaaase do a CKAN release! :D (you don't have to, but it will be much simpler for testing...)

A big thanks from the whole KSP community...you are creating the future of KSP!

Link to comment
Share on other sites

 

3 hours ago, Zarbizaure said:

your mod is insanely cool! One day, I will probably delete my whole Squad folder and replace it by SSTU :)

Just two suggestion:

  • The current mount system is really cool, but...
    • Mounting multiple engines in a single part means you cannot control them separately (example: central engine shutdown on the Saturn V). Plus if one explode, all of them explode (if you fail a falcon 9 landing with stock parts, you may save one or two engines which haven't exploded, but with SSTU...)
    • This mount system is great but only support your parts :P...so maybe adding a mounting part with nodes instead of engines?....
  • Pleaaaaase do a CKAN release! :D (you don't have to, but it will be much simpler for testing...)

A big thanks from the whole KSP community...you are creating the future of KSP!

 

3 hours ago, Acvila said:

you can mount single engines on multiple nodes, it's possible, they can be surface attached.

And one of the stated goals is to keep part count lower while providing maximum quality.  Running 190+ mods atm and I'm grateful for this even with my beast of a PC and x64 KSP.  Additionally, the system itself only supports multiple SSTU engines but if you run the mount list further down the chain on any SSTU tank the adapter 2,3 and 4 mounts all provide various form factors for mounting multiple engines from other mods or from stock.

Link to comment
Share on other sites

1 hour ago, Zarbizaure said:

@rasta013 you're right, it's possible like that! thanks for the tip :) 

As Master Yogurt would say...Yur Velcome!  Anyway, poke around with all the different little things in this mod and I think you'll find like most of us that it is one of, if not the most, flexible mod around.  Honestly, I used to rely on PP for all my custom tanks and I almost never use them anymore except for the occasional really oddly sized adapter I just can't quite get right.

Link to comment
Share on other sites

@rasta013 I'm probably going to switch to SSTU tanks too...as soon as these tanks will be supported by RP-0 :P there is still a lot of work to do with the RO/RP0 integration...

However placing engines is simple and I'll configure some of them :) the merlin are not done yet, I'll see how I could do it!

Link to comment
Share on other sites

59 minutes ago, Zarbizaure said:

@rasta013 I'm probably going to switch to SSTU tanks too...as soon as these tanks will be supported by RP-0 :P there is still a lot of work to do with the RO/RP0 integration...

However placing engines is simple and I'll configure some of them :) the merlin are not done yet, I'll see how I could do it!

they are, I submitted a patch to make the diameters scale just like PP in RP-0, you can get it from the dev repo or wait until they make a new release

(ignore if they are flagged as Non RP-0, they are supported)

also in the dev repo, someone already added the engines and pods to their respective place in the tech tree, but you'll need to turn the tree.yml file to a MM patch

Link to comment
Share on other sites

yes I turned it into a MM patch it (Temeter did a good job!) but some engines are still not placed. Any idea on what to do with the RD107X? It has no real counterpart :P I suggest setting it as the RD-107, withouth the gimbal, and costing it a bit less than the RD-107.

Edited by Zarbizaure
Link to comment
Share on other sites

@Shadowmage About KIS and SSTU. KIS only see the default size of the object, regardless of the number of engines or size of the tanks. Thats a problem in itself. On my part, I would like if we could store empty tanks as a IKEA style kit, packed into its empty volume only.

Link to comment
Share on other sites

hey Shadowmage, trying to understand your Module SSTUModularFuelTank

- how does it get the right position of top and bottom node of TANK nodes (I couldn't find their bottom/top nodes in cfg and .mu files)

- how does SSTUModularFuelTank/SSTUVolumeContainer get the volume information for TANK and CAP nodes? (mesh/collider geometry?)

- is it possible to run SSTUModularFuelTank module without SSTUVolumeContainer? (tried to run modularfueltank alone and specify volume in TANK nodes without success)

- is it possible to specify different tankageVolume / tankageMass (don't know what is the difference between them as well :P) for different TANK nodes?

cheers,Rio

Link to comment
Share on other sites

14 hours ago, RedParadize said:

@Shadowmage About KIS and SSTU. KIS only see the default size of the object, regardless of the number of engines or size of the tanks. Thats a problem in itself. On my part, I would like if we could store empty tanks as a IKEA style kit, packed into its empty volume only.

Extra-planetary Launchpads -- lets you compact your parts into RocketParts; which are fairly dense, easy to store, and generic - can be made into any part you desire.  This would be the closest analogue to your 'build a booster on site'... as that is exactly what it is intended for :)

As to the other; probably not much that I can do about it -- it seems that KIS only calculates the part volume once rather than dynamically prior to adding it to a container.  I'll look into it a bit... but the likely 'fix' will need to come from KIS in the form of dynamically calculating volume based on -current- geometry rather than prefab geometry (I bet it has similar problems with procedural parts...).

 

12 hours ago, martinezfg11 said:

@Shadowmage

Here's some progress for the LC3 IVA textures.

Still a WIP, and there's some placeholder stuff there that will be replaced soon. I'm making some props for it which I'll show in detail later.

 

Awesome, looking very good so far; far better than I would have done.  Keep up the good work, I'm sure there are at least a few people looking forward to functional (and nice looking!) IVA's for those parts :)

 

8 hours ago, riocrokite said:

hey Shadowmage, trying to understand your Module SSTUModularFuelTank

- how does it get the right position of top and bottom node of TANK nodes (I couldn't find their bottom/top nodes in cfg and .mu files)

- how does SSTUModularFuelTank/SSTUVolumeContainer get the volume information for TANK and CAP nodes? (mesh/collider geometry?)

- is it possible to run SSTUModularFuelTank module without SSTUVolumeContainer? (tried to run modularfueltank alone and specify volume in TANK nodes without success)

- is it possible to specify different tankageVolume / tankageMass (don't know what is the difference between them as well :P) for different TANK nodes?

cheers,Rio

1. Defined in SSTU_MODEL blocks, in GameData/SSTU/Data/ModelData/XXX.cfg.  The 'central tank' doesn't actually have any attach nodes associated with it; they are added through the mounts.  Specifically the 'mount-none' types add a node at a zero-height offset from the top of the tank (top of tank is defined in the tanks model config file, through the 'height' and 'verticalOffset' fields).  Other mounts use their height/offset/node specifications to determine node locations (e.g. look into the multi-adapter model definitions for info on how to do multiple attach nodes for a cap/nose/mount).

2.) Again, that info is in the SSTU_MODEL config files (GameData/SSTU/Data/ModelData/XXX.cfg).  All main tank segments, mounts, adapters, etc, should have their volume listed in their model definition file.

3.) If you want the volume-based resource handling your choices are A.)SSTUVolumeContainer, B.) RealFuels-ModuleFuelTanks, C.) ModularFuelTanks-ModuleFuelTanks.  The SSTUModularFuelTank does not touch resources, period.  You need to use one of its supported resource-manipulation-modules, (A, B, or C).

4.) No, those are defined on the CONTAINER level (in SSTUVolumeContainer), further modified by container-type/modifier-type; the SSTUModularFuelTank doesn't touch those stats/cannot influence those stats.  A single part will use the same tankage ratio stats for all sub-models.  If the tank models are really so different that they would have different tankage stats, that is a good indication it belongs as a completely separate part.

Edit: 

TankageVolume = volume lost from the raw volume due to insulation, domed tank-ends, bulkheads, etc.  E.G.  1000l tank, with a 0.15 volume loss = 850l usable space.

TankageMass = a fraction of the (filled) resource mass for the tank that represents the structural mass of the tank.  This is based on the mass of the resources for the chosen fuel type and the post-tankage-volume-loss volume value.  E.g. 1000l tank, 0.15 volume loss = 850l usable volume.  Filled with LFO, this would give a resource mass of (850/5)*0.001 tons (0.85t, 850kg).  With a tankageMass of 0.15, this would result in a tank dry-mass of 0.85 * 0.15 = 0.1275t (127.5kg).  Lighter/less dense resources will thus naturally have a lower structural/dry mass for the tank.

 

Edited by Shadowmage
Link to comment
Share on other sites

On Saturday, May 28, 2016 at 11:02 AM, Gordon Dry said:

It seems it has something to do with

Logs are there...

Taking a look at those logs...

You've got -major- issues with a couple of mods, but not a single error related to SSTU plugin code.

The first worrying thing, corrupted orbit information for your vessel; this will cause major issues in the game; you'll need to find whatever is causing that and fix it:

[WRN 16:28:13.345] [OrbitDriver Warning!]: GD Saturn C8 01 + GD ION Engine probe 03e Debris had a NaN Orbit and was removed.
[LOG 16:28:13.346] ObT : NaN
M : NaN
E : NaN
V : NaN
Radius: NaN
vel: [NaN, NaN, NaN]
AN: [0.731871694933476, -0.681442456965517, 0]
period: NaN

Second:

[EXC 16:28:13.373] NullReferenceException
	DistantObject.VesselFlare.Update (Vector3d camPos, Single camFOV)
	DistantObject.FlareDraw.Update ()

Whatever is causing the corrupt orbit is likely causing this null-ref.  Fix the first one and this will likely go away as well.

 

Try A simple stock+sstu install.  If that works, start adding mods one-by-one until you find whatever mod is causing the problem; report the problem to that mods' author.

Link to comment
Share on other sites

10 minutes ago, Gordon Dry said:

I guess this was Stage Recovery, I removed that one yesterday.

Strange, SR has usually been one of the more stable mods I've played with.  Good to know though.

Does the problem manifest with just SSTU + SR, or is the problem between some other mod + SR?  (if it is just SSTU+SR causing issues there is a chance that I can fix things on this end...)

Link to comment
Share on other sites

6 hours ago, Sudragon said:

Is there a simple tutorial to applying the engine clustering technology to engines from other mods? 

 

 

Those images are a bit old, but are mostly still applicable.  A few new config options that they don't explain...

The most important things to get set properly are 'engineHeight', 'engineYOffset', 'engineScale', 'engineMountDiameter', 'engineSpacing', and the two toggles for the upper/lower mount options.  Okay,...so pretty much every line in the configs is important to get them properly setup.

Good examples of using others' engines can be seen in the SSTU-SC-ENG-NRV engines, as these use the stock LV-N model (at three different scaling factors, so you can see how easy it is to scale stuff (hint.. just change the scale value :) ).  Other examples exist from the rest of the SSTU engines, but some stuff is not applicable to them as they use specially setup/located models (e.g. the SSTU stuff doesn't need any vertical offset as the model is built intentionally for the plugin).  If you need explanations on any of those specific fields please let me know.

 

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