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

[Shadowmage]

In general development news:

Continued conversion work on the ModularXXX PartModules is going well.  Actually have the code back to a state where it will compile, though I haven't tried doing so yet -- still quite a bit more back-end work to do before it will be ready for testing.

On that note -- I have decided to delay the release of the 'reworked Modular Parts' to an undecided point in the future.  While working through stuff, I have realized that there is a lot more that needs to be done, and quite a bit of it will be 'craft breaking'.  So, the current tentative release for this work will likely coincide with the KSP 1.4 update.  I'm going to continue working on and developing it it in a separate branch, and might issue some pre-release versions prior to 1.4 (depending on timing / where I'm at compared to 1.4, etc), but the current intent is to hold off on the craft/save breakage until the major KSP version bump.

So, this week I'll be shifting focus back to generic cleanup tasks a bit -- fixing outstanding texture, config, and balance related problems that will carry over to the future releases.  Candidate work includes ongoing bugfixes, landing-legs for the LV tanks/general use, and continued conversion of parts for recoloring and/or PBR texturing.

 

Part of the reason for the major changes is that I'm fairly certain I'm going to be unifying nearly all of the ModularPart functions into a single PartModule that can have sub-modules enabled/added/swapped through config.  Every one of the current modular part-modules duplicates a large majority of the code from the others, with only some 'minor' variations to handle the part-specific functionality (e.g. the RCS selection on the MUS, the thrust updating on the MSRB, solar panels on MSC), and I believe this could all be handled more consistently, and be easier to maintain, if it were all managed by a single set of code.  Some of the stuff I have learned since I first designed those systems would now allow for it to all be combined while still keeping the code maintainable and adaptable.

This won't apply to -everything-, but only 'nearly everything'.  Some specific 'ModularXXX' part-modules would still exist with specific functions that are intended to be used as stand-alone -- such as the ModularHeatShield, ModularRCS, and a few others.  What it will apply to would be the MFT tanks, ModularStationCore parts, MSRB parts, MUS, ModularCargoBay, and ModularServiceModule parts / modules.

The current intended design is an '8-slot' modular part.  Parts that did not use all of the slots would simply not have them enabled (no GUI/etc for unused slots).

• Nose Adapter
• Upper Tank
• Core/Intertank
• Lower Tank
• Mount Adapter
• Upper RCS (positioned on 'upper tank', 'core', or 'nose')
• Lower RCS (positioned on 'lower tank', 'core', or 'mount')
• Solar Panel (positioned on 'core tank', or other depending on config)

Feature set would include:

• All sections (except RCS) would have built-in animation handling, including 'deploy limit' if enabled by the currently selected model definition.
• RCS fuel type selection linked to optional 'support container' setup (e.g. MUS, but with fuel type selection for both main and secondary containers).
• Option to have 'integrated engines' in any of the nose/upper/core/lower/mount model selections.  With the caveat that if the ModuleEngines is present in the part config, then every model for the engine-equipped slot must have engine thrust transforms -- this is because the stock engine module cannot be disabled. 
  • This feature is mostly intended to maintain compatibilty with the ModularStationCore parts with integrated engines, but will also be used by the ModularSolidRocketBooster parts.  So, ideally, this feature will have two inputs -- which slot to derive 'thrust' values from, and which slot to adjust 'thrust transforms' in.  They can point to the same slot (MSC), or different slots (MSRB).
  • This feature, if used to its full extent, can allow for integrated and swappable engines in modular part setups.  With the caveat that the stats for the engine module are taken from the 'model definitions', and any potential adjustments to engine stats would have to be done there.
• Upper and lower RCS selections, including 'none'.  Both sets of RCS ports will use a single thrust-transform name, and a single ModuleRCS, but will have independent controls for positioning and model selection.
• Can define in the part-config which 'slots' contribute to volume/mass/cost for the part, with the volume/mass/cost being taken from the model-definitions (with optional overrides in the part-module-config itself).
• Upper/lower tank, and adapter models 'chain-scale' from the central tank model.
  • Adapters model definitions will start to contain data regarding their 'profile' -- core diameter, top diameter, bottom diameter.
  • Any adapter can have a different core/top/bottom diameter.  Further slots up/down the chain will respect that diameter and be auto-scaled to line up properly.
    • E.g. if 'Core' slot is 5m, and the upper tank slot is using a '5m to 3.75m' adapter model, then the 'nose adapter' slot would automatically have its diameter scaled to match up with the top of the 5>3.75 adapter.
• Integrated fairing support at the plugin level.  Might not be enabled in all part-configs, but should be functional when it is enabled.
  • Will include the option to specify 'top', 'bottom' and 'body' fairings.  Still doing concept development on this a bit, will know more in the future.
• Nearly any combination of features can be used for any part.  Want a modular SRB type part that also includes solar panels, and an integrated service/cargo bay in the nose?  Sure thing.  One-part probe core with integrated RCS, solar, engines?  Sure.  Single part cargo bay that includes a built-in service module?  Yep, should be doable as well.

 

Edited December 11, 2017 by Shadowmage

[tater]

Made this thing last night:

It uses a petal adapter as a service bay: stock panels, since i wanted them really small, and a load of science experiments. I don't like the capsule floating, so I attached a tank to the adapter).

[Scorpiodude]

I don't mean to be rude but is the what state of development is the rover core in. Is it canceled not started barely started. I just want to know because it sounds awesome to have a single part rove like the description says.

[Shadowmage]

Just now, Scorpiodude said:

I don't mean to be rude but is the what state of development is the rover core in. Is it canceled not started barely started. I just want to know because it sounds awesome to have a single part rove like the description says.

Not even started, and I do not anticipate starting on it anytime soon.  It will likely be the last set of parts done for SSTU before the mod moves into 'finished' state (until/unless I decide to do Aero stuff, in which case those would be the last parts worked on).  At the current rate of work, I would guess it might be 6 months to a year before work is even started on it.  Complete guess though.

[Scorpiodude]

Okay thank you for the response

[Jimbodiah]

Mage has taken over the Kerbal Foundries mod, which includes a lot of cool wheels and tracks for rovers. You may want to check those out if you have not already. See his signature for the link.

[Shadowmage]

Life... as a docking port....

Spoiler

Entire docking operation done without any UI, from the view of the docking port.  Stock SAS was set to 'target' mode, targeting the port on the station.  Station was completely uncontrolled/passive.

And here is the external view after docking:

 

Just having a bit of fun with the station in my career testing game...  (gotta actually play KSP once in awhile).

[tater]

^^^That's cool.

I was actually playing the last couple nights with that Duna mission, etc. It was really fun.

[Jimbodiah]

General question:  Can clipping parts into each other be responisble for ships flinging apart, i.e. Kraken strikes? How do the colliders respond to being clipped?

[Shadowmage]

17 minutes ago, Jimbodiah said:

General question:  Can clipping parts into each other be responisble for ships flinging apart, i.e. Kraken strikes? How do the colliders respond to being clipped?

KSP models craft/vessels as a collection of parts, with each part having its own RigidBody, and all being joined together/held together by Unity Joint components.  Colliders that belong to a single rigidbody (part) will never collide with other colliders on that rigidbody (part). 

KSP also has code in place on vessel creation that loops through every collider on a vessel and sets an 'ignore other colliders on vessel' flag.  So colliders on a vessel should never collide with other colliders on the same vessel, even if they are from different rigidbodies(parts).

Now -- this all breaks down a bit when mods come into play.  Mods are capable of bypassing these collider checks, or simply creating new colliders after the checks have been run.  Either of those can create situations where colliders within the same vessel can 'collide' -- these instances manifest as RUD in major cases or in minor clipping cases, phantom forces.   KSPWheel also enables its wheel-colliders to exert forces on colliders in the same vessel (intentionally), so craft with wheels/legs need to take extra care in design to no clip the functional suspension part of wheels.

But I'm sure you've all seen what happens if you happen to decouple parts that were clipping, where some of the clipping parts become a new craft -- instant explosions.  This is because when you decouple something/undock, KSP splits the vessel into two separate vessels.  Each with their own colliders, which only ignore colliders on that same vessel (but are happy to collide with the colliders from the other new vessel).

So generally speaking, from the games perspective, when everything is setup/working, clipping is fine.  Clip away.

(if you are having problems with some clipping-related Kraken-strikes while using SSTU parts, please file a bug-report with as much info as possible; it is entirely possible that I've missed one of these collider updates somewhere in one of the modular parts; other mods might have that problem as well if they deal at all with model/collider manipulation)

[Jimbodiah]

The reason I ask is that when I start getting a lot of ships docked, stuff goes seriously wrong sometimes when getting near other ships or after docking. Not just SSTU parts. hence I was wondering if any kind of clipping might be the cause of this.

[RW-1]

On 12/11/2017 at 10:23 AM, Shadowmage said:

Not really.  Due to lots of texture and model sharing between parts, there is no clean way to split the mod up.

It can be done, but only with considerable effort.  Basically you have to pick what parts you want to keep, and then go through every config file associated with those parts to note the models and texture names that need to be kept (part.cfg, model-data.cfg, texture-set.cfg).  This is sometimes non-obvious, as a simple thing like an engine also requires all of the models and textures for the mounts and adapters.

On the bright side of that -- I currently have it in my TODO notes to reduce the texture resolution for the diff/spec/met/ao textures for the recolorable parts.  Should result in a massive decrease in RAM use when just the default install is used.  Might see this implemented in one of the next few releases (if it doesn't muddy up the textures too much).

 

Likely the RPM camera position/config is configured incorrectly.  Could be either in the models, or in the config.  Generally the SSTU parts with built-in docking ports -should- have viable docking camera transforms.  But I don't use RPM, so they have never been tested. (nor do I have any way to know if they were 'fixed' if I were to adjust them).

Sadly, not sure what to tell you on this one.  Short of someone taking a look at the models who also knows about RPM, it is not something that I'll be working on.  If someone can tell me exactly what needs to be done (e.g. move 'transform XXXX up 0.15m on X axis), I can likely get it fixed up, but I do not have the time or patience to find/download/setup RPM just to test a feature that I will never use and have no interest in.

 

Its not intended to be made of gold.  It is simply gold colored.  And as the precise material in use is different and varied between parts using the color, 'gold foil' was the most appropriately generic and descriptive name.  Perhaps 'golden colored foil' would be a bit more apt, but is a far more cumbersome description.

You can, of course, patch the name in your personal game if it bugs you that badly.  Find the TexturesUnlimited/PresetColors.cfg, and patch the 'title=' line for the gold foil entry to say whatever you want in the GUI (don't patch the name=XXX entry, or you'll break all the configs using that color).

 

SI;

 

This is wehat I ghot concerning the "Docking: camera from MOARdV, wor what it's worth:

 

"

The docking camera in RPM is a special-case camera. 

In a conventional RPM camera, you provide a transform, and (optionally) rotation and translation components to configure it how you need.

For the docking camera, RPM searches the part for a transform named 'dockingNode'.  If it finds that transform, it uses it for the camera location.  If there isn't a transform with that name, RPM simply grabs the root transform (I believe) of the part.  There aren't any knobs you can adjust to move the docking camera around, either, so it'd require model changes to support RPM docking cameras.

You *could* add a conventional RPM camera to the part and adjust it to where you need it, but it would not work for a docking camera without also editing the MFD config.

FWIW, this will not be a problem in MAS, since every camera has to be specified.  I'm hoping to have a major update for MAS in the next week or two, although there's only one IVA currently available for it (and it's not an SSTU capsule)."

 

So again, if it isn't something that I can edit and p[lay around with myself, it's no biggie to me, there are always workarounds

 

Have a great holiday!

[Shadowmage]

Just in time for X-mas (and/or other Holidays)...

And also...

[Jimbodiah]

   

 

 

I pressed the like button 20 times, but they don't show up for some reason  

Edited December 13, 2017 by Jimbodiah

[Pappystein]

12 hours ago, Jimbodiah said:

The reason I ask is that when I start getting a lot of ships docked, stuff goes seriously wrong sometimes when getting near other ships or after docking. Not just SSTU parts. hence I was wondering if any kind of clipping might be the cause of this.

That sounds like an issue that was common in 0.21  The station just starts to tremble and then KA-BLAM-O  Pieces everywhere.

Go through and turn off all SASes you have on the station then try docking with it again.  If the issue goes away then you are somehow replicating a REALLY old bug.   I had a 26 part (20 of them being from SSTU so there are actually a lot more parts but...) station (not counting the escape pods (Mk 1 pods with a small SRB for de-orbit burns)    And no issues.  I am NOT using any of the inflatable HABS in this (it is all strictly DOS/COS based with a couple hitchhikers for extra crew spaces with small size.)

Before I upgraded to 32GB of ram I WAS having a lag issue if too many things were flying NEAR each other.....  That would sometimes cause colisions that did not appear on screen.

 

Hope that helps! (I know it probably wont but...  I still hope it does!)

 

[Shadowmage]

Hehe...

Quick -- someone find me a 'public domain' x-mas tree model that I can import in game + add recoloring support to.  And a couple x-mas ornament type things (or maybe just use the MFT-S?).

   (only half kidding.... if someone does post/link to a decent public domain tree model, I likely will add it in for the holidays, at least as a separate release)

[Jimbodiah]

you mean like my torus tree video?

 

 

 

[Shadowmage]

As I've made excellent progress on the outstanding issues and cleanup tasks this week, I decided it was a good idea to spend some time on figuring out at least the basic geometry for some of the upcoming new parts.

This is the 'light' version of the LV landing leg (there will be a more robust 'heavy' version as well) (and this one might be made to look even lighter; mostly working on rigging at the moment).  This version is specifically intended to fit well onto the spherical '0 length' tank setups, but can also be used on longer tanks.  Will also work on standard cylindrical parts (and the paneled LV tank variants), but some of the pistons will clip into the tank (will be making a third set of landing gear specifically for paneled / standard round tanks as well).

As stated, still very early in the development on these, lots of geometry to cleanup, UVs to setup, textures to make.  Likely will be a few weeks before they are usable (going to be at least another couple days just figuring out the rigging).

[Jimbodiah]

I smell small surveyor type lander possibilites.

[tater]

44 minutes ago, Shadowmage said:

 

Since this looks like it has structure above and below the tank, will it have that spacing (tank height) as something that adjusts in standard height increments, or are there simply multiple versions?

Regardless, that looks so cool.

[Shadowmage]

5 minutes ago, tater said:

Since this looks like it has structure above and below the tank, will it have that spacing (tank height) as something that adjusts in standard height increments, or are there simply multiple versions?

Regardless, that looks so cool.

It is intended to be a single part that has four integrated legs.  The attach node on it should be attached to the bottom attach node on the fuel tank.  The 'scale' control on the leg will be used to line up the size of the part to the fuel tank's diameter.  When sized properly (this is up to the user to do), the struts on the leg will line up precisely with the struts/framing for the fuel tank.  The 'leg quad' will have another attach node, in the same position as the first and facing downward, so that an engine may then be attached to that attach node (or alternatively, use the 'interstage' node on the fuel tank to attach the engine).

The leg shown above is the 'light' version -- it is intended specifically for the '0' length tanks (as shown in the render).  For longer tank lengths, the 'light' version will still work (the struts will still line up with the struts on the tank), but there might be a couple of struts that clip into the fuel tanks.  The 'medium' (and/or heavy) leg variants will have their struts setup specifically to line up with the longer LV fuel tanks (these will not have structure 'above' the tank, only beside and below).

Both / all variants will -also- be usable on standard fuel tanks, though on some of the models the upper support struts (non-animated) will clip into the tank (it will look like only the main leg and lower bracing exists).

(so no, there will not be adjustable height; there will be multiple different legs (light/med/heavy); use whatever you think looks best for your craft)

[tater]

Awesome. Looks very reasonable from a function standpoint (RL) as well. Nicely done.

[RedParadize]

That's great! it will fit nicely on TSTO first stage. I do not know if it fit with your plan but, will we be able to adjust the number of leg?

[Shadowmage]

7 minutes ago, RedParadize said:

That's great! it will fit nicely on TSTO first stage. I do not know if it fit with your plan but, will we be able to adjust the number of leg?

Not directly.  But there will be a 'single leg' version in addition to the quads.  So, yes, but with increased part count as you'll have to use multiples of the single leg (KSPWheel isn't setup to support dynamic part manipulation like that).  The single leg version will not feature the 'bottom' attach node setup either, so it will require some manual offset positioning to line it up appropriately (but you'll also be able to use arbitrary scales for the legs).

So if you want a 'perfect fit' of 4 legs on the LV tanks -- choose the leg quad(s).  If you want 'something else', use the stand alone leg and set it up however you want (position, scale, rotation, symmetry count).

[tater]

Was horsing around with the "make everything metal" patch @Electrocutor posted in the TU thread...