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

[Shadowmage]

1.) The legs don't work due to Unity's terrible wheel-collider implementation.  No, I'm not going to make legs without suspension.
2.) The entire system was a giant hack.  The code was a nightmare to manage; any minor change and the whole thing broke.  Additionally it was built on top of a very poor system of module interaction; the only modules that would work with it were those that were specially coded to be able to be disabled; meaning I could not use stock modules for anything (no engines, no rcs, etc...).

Add those two together, and it results in a system that I was no longer willing to support.  The main reason for the system was gone (the landing legs), and the rest of the code limited the usefulness of the fuel tanks by restricting fuel type selection to LFO only; and with the code being so fragile/convoluted, there was no way I could update it to support fuel swapping.

Its like if you end up with a car that is just a complete POS, where you end up spending more time (and money) fixing it every week than you do driving it.  At some point its better to just send it off to the junkyard and look for something else.  When the wheels fall off, its a pretty good indication that its time has come.

[ComatoseJedi]

8 hours ago, Shadowmage said:

When the wheels fall off, its a pretty good indication that its time has come.

At least it was awesome while it lasted. 

 

 

[123nick]

15 hours ago, Shadowmage said:

1.) The legs don't work due to Unity's terrible wheel-collider implementation.  No, I'm not going to make legs without suspension.
2.) The entire system was a giant hack.  The code was a nightmare to manage; any minor change and the whole thing broke.  Additionally it was built on top of a very poor system of module interaction; the only modules that would work with it were those that were specially coded to be able to be disabled; meaning I could not use stock modules for anything (no engines, no rcs, etc...).

Add those two together, and it results in a system that I was no longer willing to support.  The main reason for the system was gone (the landing legs), and the rest of the code limited the usefulness of the fuel tanks by restricting fuel type selection to LFO only; and with the code being so fragile/convoluted, there was no way I could update it to support fuel swapping.

Its like if you end up with a car that is just a complete POS, where you end up spending more time (and money) fixing it every week than you do driving it.  At some point its better to just send it off to the junkyard and look for something else.  When the wheels fall off, its a pretty good indication that its time has come.

ahh ok. damn, it must suck too have such a neat system go too waste. 

[Jimbodiah]

Has anyone else tried the Lander tanks with an opening for the Ascent stage where the engine always gets stuck in the tanks (collider issue)? Any engine I put in there gets stuck and either explodes or doesn't separate.

Edited May 22, 2016 by Jimbodiah

[Shadowmage]

On Sunday, May 22, 2016 at 6:43 AM, Jimbodiah said:

Has anyone else tried the Lander tanks with an opening for the Ascent stage where the engine always gets stuck in the tanks (collider issue)? Any engine I put in there gets stuck and either explodes or doesn't separate.

Last I checked those parts still had hollow colliders.  So, shouldn't be a problem with the tanks themselves.

Although, thinking on it, this could be caused by my use of simple box colliders for the engines;  if the engine looks like it will -just barely- fit... then you would have collider issues like you are describing.

Could you post some pics and/or a simple stock/sstu craft file that exhibits the problem?

I may have to make cylinder/cone colliders for the engines; less optimal performance-wise, but would eliminate a few of the oddities that they experience.

[Shadowmage]

General development update:

As things seem to be settling down a bit (few new bug reports), I'm going to keep working towards the transition into the 'stable' branch.  If no new bugs pop up this week, or other changes needed, I will likely promote the current release to the 'stable' version.  I'm not entirely happy with some of the tech-tree locations for a few parts (e.g. the F1 engine seems to be a node or two earlier than it should be), but those kind of changes won't be game/craft breaking.  I -am- pretty happy with the mass/fuel fraction/isp/general rocket-equation performance of the parts;  might be some minor nerfs coming to some things to bring them more in line with stock or other mods' configurations (e.g. zero-boil-off tank capacity and masses as compared to Near-Future/Kerbal Atomics/Cryo-Engines setups).

Will also be doing another pass over the texture sets; the setup I did on Saturday was a bit of a hatchet-job, and I would like to clean it up a bit more/trim it down even further;  e.g. SRB's will only have one stock texture set, all others will be added through the optional texture pack, MFTs will only have 3-5 variants, and most mounts will have perhaps 2-3 variants.  Even debating whether or not to split those off into a separate 'basic' texture set pack (so would be core-mod, basic texture pack, and full texture pack);  still thinking it all over....

Will be spending quite a bit more time over the next few weeks on getting the KSPWheel stuff all sorted out and working ( https://github.com/shadowmage45/KSPWheel ).  Gotta have wheels and legs...things gotta roll and be able to land.  So far, so good; initial in-game tests of using the code to replace the stock system gave some very promising results (see second image and more info below).

 

After all of the fun with wheels has been had, I'll be moving onto station parts (finally!)  Or perhaps finishing off the tanks, structural elements, and cargo bays?  Spherical tanks, cryo tanks, trusses, and various cargo bays would be nice to have in the short-term.  Trusses might wait until I start on the station parts in earnest;  will likely be contacting Nertea to see if I can borrow the form-factor from his trusses (hexa and octo), as I would like to remain visually compatible with his NF-Construction/Structural parts.  The models will have some differences to them, but should be visually compatible enough to not stick out too much if they are used on the same craft.  Will also be fewer parts that I need to make (e.g. adapters), as the NF parts will work fine (may still make a few adapters, to be used on the modular-structural-segments).

Quick mock-up of a saddle-truss style 'cargo bay' that I had done a few months back (actually two short ones in that image).  These will be modular parts similar to the MFT tanks with multiple lengths available, and optional built-in end-caps.  Some of the structural/skeletal cargo bay variants will include NodeFairing modules so that the contents may be easily protected during ascent.  Other cargo-bays will use standard bay-door opening styles; some hinge style, some folding, some rotating (might even be a modular option?).  May or may-not have an end-cap variant with a deploy animation (you know... for driving rovers into and such)(or several deployable variants if I can pull it off).

 

Wheels:

In the image below I have replaced the stock wheel modules with a custom module, removed the U5 wheel collider component and replace it with a custom solution as well.  Suspension forces work, mesh animation works; input handling, throttle, steering, brakes not yet implemented (at the time of the image, but are partially/tentatively implemented now).  No twitching, jumping, bouncing... or any of the other weirdness that occurs with the U5 wheel colliders.  No exploding, or launching of craft/kerbals into the air.

Still quite a bit left to be done; the friction model is overly simplistic (though -seems- good from a gameplay standpoint), and the sticky friction setup is only partially implemented (works, but with caveats); animation handling is implemented but un-tested (for landing legs or deployable landing gear).  Have not done anything yet regarding impact-tolerance or wheel/legs breaking, though as this is intended as a stock-replacement-solution I'll have to get those working eventually.  Have not yet done any dynamic-setup of the wheel parameters either.  Will likely implement some sort of a dynamic configuration 'range' for each wheel; obviously light wheels shouldn't be able to support multi-ton vehicles, but they do need to be usable across a wider range than a single set of spring/damper/friction values would allow (more the spring/damper... friction is already mass adjusted).

Will likely go with a similar setup for SSTU wheels, though they will likely use a custom module that enables multiple wheels in the same part (baking that into the stock replacement module might be doable... still thinking on it a bit).

 

 

[superm18]

1 hour ago, Shadowmage said:

Wheels:

In the image below I have replaced the stock wheel modules with a custom module, removed the U5 wheel collider component and replace it with a custom solution as well.  Suspension forces work, mesh animation works; input handling, throttle, steering, brakes not yet implemented (at the time of the image, but are partially/tentatively implemented now).  No twitching, jumping, bouncing... or any of the other weirdness that occurs with the U5 wheel colliders.  No exploding, or launching of craft/kerbals into the air.

Still quite a bit left to be done; the friction model is overly simplistic (though -seems- good from a gameplay standpoint), and the sticky friction setup is only partially implemented (works, but with caveats); animation handling is implemented but un-tested (for landing legs or deployable landing gear).  Have not done anything yet regarding impact-tolerance or wheel/legs breaking, though as this is intended as a stock-replacement-solution I'll have to get those working eventually.  Have not yet done any dynamic-setup of the wheel parameters either.  Will likely implement some sort of a dynamic configuration 'range' for each wheel; obviously light wheels shouldn't be able to support multi-ton vehicles, but they do need to be usable across a wider range than a single set of spring/damper/friction values would allow (more the spring/damper... friction is already mass adjusted).

Will likely go with a similar setup for SSTU wheels, though they will likely use a custom module that enables multiple wheels in the same part (baking that into the stock replacement module might be doable... still thinking on it a bit).

 

Maybe Squad should hire you to do the wheels 

[ComatoseJedi]

I think Squad couldn't afford Shadowmage. I consider the work he's done is priceless. I would think, however, that the wheel solution would be a major sought after plugin. I'm not sure if he could make a profit off it (kinda doubt it). But, I think if he had a donation link, I think a bunch of people could show appreciation (either monetarily or with major kudos). 

[rasta013]

1 hour ago, Shadowmage said:

General development update:

*snip*

While checking balance I'd recommend looking at EC totals available early in the tech tree.  I have no idea how this might be done but it's possible to use the smallest tank possible with the lowest vertical adjustment and have a battery that gives 1500+ EC available at a time in the tech tree when the biggest battery is 100 EC.  This is the main issue with balance that I've seen other than tiny tweaks in masses/fuel fractions which you've already mentioned.

[Shadowmage]

1 hour ago, superm18 said:

Maybe Squad should hire you to do the wheels 

If/when they are working, and -if- Squad is interested, I would gladly re-license the code to enable them to include it (at least the portions that I have written).  Lo-fi would likely say the same about what he has written (though I have not talked to him about it, and cannot speak for him on this).  I'm sure everyone would love to see some working wheels in stock

 

1 hour ago, ComatoseJedi said:

I think Squad couldn't afford Shadowmage. I consider the work he's done is priceless. I would think, however, that the wheel solution would be a major sought after plugin. I'm not sure if he could make a profit off it (kinda doubt it). But, I think if he had a donation link, I think a bunch of people could show appreciation (either monetarily or with major kudos). 

I might be willing to add a donation link as there have been a few requests for it.  I'm certainly not doing this for the money; but donations can aid with my sanity in the long run... they usually end up going towards picking up new games when I need to take a break, or various server/hosting costs (Github is ~$7 a month to enable private repositories, which I use for development), or just keeping me supplied with caffeine

 

1 hour ago, rasta013 said:

While checking balance I'd recommend looking at EC totals available early in the tech tree.  I have no idea how this might be done but it's possible to use the smallest tank possible with the lowest vertical adjustment and have a battery that gives 1500+ EC available at a time in the tech tree when the biggest battery is 100 EC.  This is the main issue with balance that I've seen other than tiny tweaks in masses/fuel fractions which you've already mentioned.

Noted.  However, the stats that it uses for EC are based on the stock batteries as far as cost/weight go.  I've always found it... dumb... that you had to wait until halfway through the tech-tree to unlock decent capacity batteries (or longer fuel tanks, in a similar vein).

Sadly I'm not sure there is much that I can do about it without removing intended functionality.  I could remove EC entirely from the configs.... but what if you actually want some on your tanks (e.g. for part-count reduction)?  I guess there is not too much difference though between one large battery, and spamming a ton of the smaller ones, other than part count.

 

I -am- planning on making a dedicated MFT tank that is a dedicated 'battery', which would have different sets of models to use (to allow for smaller batteries), as well as allowing a smaller diameter (0.3125 min?).

[rasta013]

6 hours ago, Shadowmage said:

Noted.  However, the stats that it uses for EC are based on the stock batteries as far as cost/weight go.  I've always found it... dumb... that you had to wait until halfway through the tech-tree to unlock decent capacity batteries (or longer fuel tanks, in a similar vein).

Sadly I'm not sure there is much that I can do about it without removing intended functionality.  I could remove EC entirely from the configs.... but what if you actually want some on your tanks (e.g. for part-count reduction)?  I guess there is not too much difference though between one large battery, and spamming a ton of the smaller ones, other than part count.

Well to be perfectly honest I bring it up only because it really violates the tech tree but I'm of the same opinion that you are.  Battery level limits have always seemed overly restrictive only to ramp up so fast as to make you wonder what happened.  This is the same vein as not being able to have a ground vehicle LONG before being able to launch probes to other planets...especially when I can see vehicles driving around the KSC from the first time I enter a building.  Personally, I favor the part count reduction line of thought and prefer that as a solution than going out of your way to handicap the EC.  Perhaps if you later choose to add an independent battery tank then you might revisit this but until then I certainly wouldn't break my back trying to "fix" it.

[riocrokite]

hey @Shadowmage

It's cool that you're working on wheels; a few ideas which you might find useful:

- in flight adjustable ride height - similar to what KF wheels had, this is useful to dock rovers together
- in flight adjustable spring strength
- deployment animation support - with one-off modifier and optional resource cost, i.e. you might need some resource to deploy wheels
- wheels do not work and use any resources when stowed
- possibly disabling / enabling wheel collider in animation for inflatable wheels option, personally I've tried with changing wheel collider diameter for animation (inflatable) without much success; it might be an unity limitation.
 

[Acvila]

leave the battery as they are, even stock batteries can be scaled up with tweak scale, but they're so unreal... never saw planes or rockets with external batteries. who want small capacity batteries has the possibility to not use more then they think it's "real", u can't cheat in a single player game...

instead making a battery tank, better a storage tank for mining or storage purpose, i'm tired of adding 10 tanks with different resources instead of one with all o them!

i like your mod, it's one of the best modes for ksp even if it's not finished! good work!

Edited May 24, 2016 by Acvila

[JoseEduardo]

you do realize you can put batteries and all the stuff that aren't supposed to be on the outside inside a cargo/service bay like RL, right?

In my career game I find myself using procedural batteries a lot, so having one good looking like SSTU would be great (and a lot of people doesn't use tweakscale, I stopped using myself when I started using Procedural Parts)

[Shadowmage]

9 hours ago, riocrokite said:

hey @Shadowmage

It's cool that you're working on wheels; a few ideas which you might find useful:

- in flight adjustable ride height - similar to what KF wheels had, this is useful to dock rovers together
- in flight adjustable spring strength
- deployment animation support - with one-off modifier and optional resource cost, i.e. you might need some resource to deploy wheels
- wheels do not work and use any resources when stowed
- possibly disabling / enabling wheel collider in animation for inflatable wheels option, personally I've tried with changing wheel collider diameter for animation (inflatable) without much success; it might be an unity limitation.
 

Thanks for the suggestions

Right now I'm concentrating on making the low-level WheelCollider component that manages the physics forces (suspension and friction).  This will be the majority of the KSPWheel project, and is aimed at custom use by other mods own' PartModules (they'll need to write whatever advanced features they want for themselves).  Kerbal-Foundries will have their own custom PartModule for the features they want, SSTU will have its own custom PartModule for the wheel features that I want.

The other part of the KSPWheel project will be a stock-replacement PartModule.  This will be a very basic replacement for the stock PartModules that drive the stock wheels; its features will be those that are present on the wheels currently and/or were present on the wheels in KSP 1.05;  so pretty much you'll get a brake-torque slider, motor and steering invert toggles, and motor and steering enable/disable toggles, and not much else.  Legs -might- get a 'lock suspension' feature (if I can figure out how to do it with physics alone/in a non-hacky manner for the stock legs).

I'm intentionally -not- designing the 'ultimate wheel part-module', for the simple reason of different people wanting different features and having different expectations for the model hierarchy and setup.  So stuff like traction control, adjustable spring/damper/ride height, multi-wheel-collider support (for tracks), repulsor type setups, dynamic steering adjustment, more advanced animation integration, etc... will all be features that individual mods' implement on their own.  There is nothing stopping someone from implementing your suggestions, but most will not be part of the stock replacement PartModule that I'll be writing for the project.  Some may be part of the SSTUWheel module that I'll be writing, but it'll be a completely different beast than the stock-replacement-module.

As long as I can get the low-level component working, I'll consider the project a success.  Getting a stock-replacement PartModule out of it will just be a bonus   I'm going into this knowing that I'll still need to write my -own- wheel-controlling PartModule regardless, as the stock one will likely only work for the stock wheels (and wheels setup specifically for the stock modules).

 

[Theysen]

Does your wheel module mean the Shuttle-like parts are coming back once the wheels work again? Really looking forward to this!

 

Really hope your module fixes the issues, sounds promising! 

[ComatoseJedi]

That's the plan, but first the stock wheel system needs to be fixed in order for the shuttle wheels to progress. Without that basic function, it's pointless to even consider doing shuttle wheels. I would think after that's fixed, then Shadowmage will do the code for his shuttle wheels, because they will require custom coding to handle suspension and the goodies that come with landing gear. With the progress he's made, the wheels perform better than stock and that's only 20% done. I'm sure he's close to a bare bones release of the wheel code he's been working on, but there are no guarantees on when it'll get done. And, yes, his shuttle parts are pretty awesome. I was finding myself doing more shuttle missions. 

[superm18]

Small bug here:

Log can be found here:

https://drive.google.com/folderview?id=0B9nI5bkIqoAEMnBmTnd1WnF6N0E&usp=sharing

[Shadowmage]

Bug reports belong here: https://github.com/shadowmage45/SSTULabs/issues

The bug appears to be an error in the config file for the part; specifically in the default resource definitions for the container; it was missed during the update when I changed how the default resources are defined (now uses ; instead of , inbetween each resource set).

I have opened a bug-ticket for you with the relevant information, and already fixed the problem in dev version.  https://github.com/shadowmage45/SSTULabs/issues/321

Fix will be available with this weekends' release.

[Shadowmage]

While I'm contemplating the 'cleanup' and 'polish' of the mod...

What are the thoughts on adding patches to convert the stock tanks to use the SSTUVolumeContainer system?

Similarly/alternatively, I could potentially combine all of the standard stock tank models into a single stock-model-based MFT fuel tank (including adapters).  Any want, or need, for this?  (Could do a separate MFT each for the Mk2 and Mk3 shaped tanks).  This would give diameter scaling (and possibly limited vertical height scaling) to the stock tanks through the MFT module and allow variable resources through the VolumeContainer module.

Either of these would be fully config / patch based, and would not require any additional models or plugin-code-changes.  If done through patches they could even be setup to patch only if certain mods were present/not present (e.g. default to using RF if it is installed, otherwise use VolumeContainer).

[superm18]

On 26/5/2016 at 9:01 PM, Shadowmage said:

Bug reports belong here: https://github.com/shadowmage45/SSTULabs/issues

The bug appears to be an error in the config file for the part; specifically in the default resource definitions for the container; it was missed during the update when I changed how the default resources are defined (now uses ; instead of , inbetween each resource set).

I have opened a bug-ticket for you with the relevant information, and already fixed the problem in dev version.  https://github.com/shadowmage45/SSTULabs/issues/321

Fix will be available with this weekends' release.

Ahh of course...should have known, thanks for the pass on that one.

Good to see it was an easy fix.

2 minutes ago, Shadowmage said:

While I'm contemplating the 'cleanup' and 'polish' of the mod...

What are the thoughts on adding patches to convert the stock tanks to use the SSTUVolumeContainer system?

Similarly/alternatively, I could potentially combine all of the standard stock tank models into a single stock-model-based MFT fuel tank (including adapters).  Any want, or need, for this?  (Could do a separate MFT each for the Mk2 and Mk3 shaped tanks).  This would give diameter scaling (and possibly limited vertical height scaling) to the stock tanks through the MFT module and allow variable resources through the VolumeContainer module.

Either of these would be fully config / patch based, and would not require any additional models or plugin-code-changes.  If done through patches they could even be setup to patch only if certain mods were present/not present (e.g. default to using RF if it is installed, otherwise use VolumeContainer).

I'm all for it. I use your parts whenever I can since the level of customization is unparalleled.

The only downside I can think of is that its going to take more time to build a rocket/plane (at least for me) with all the variants to go through, instead of the Lego building style. but then again I quickly learn where everything is and that together with very good balanced part stats is a win. (Hope that made any sense)

[rasta013]

1 hour ago, Shadowmage said:

What are the thoughts on adding patches to convert the stock tanks to use the SSTUVolumeContainer system?

I love your container system.  IMHO it's the best I've seen and I've used pretty much every type of fuel container there is in this game.  If you want to expand that I would have no hesitation in taking advantage of it everywhere that it's present.  So with that in mind...

What will it's effects be when running multiple fuel switches as required by some mods?  If you implement this across all tanks inevitably people will fail to read the OP/ReadMes/changelogs etc and will come asking/bug reporting that either a) they don't have their switched tanks they were expecting or b) if you ignore tanks modified by those switchers, people will come asking/bug reporting that they don't have the SSTU switched tanks.  I would volunteer now to help field those question in thread to be able to have the SSTU container model more widely available. 

As to the second part - limited expansion to MK2/3 form factor?  This may be the best solution as it will still result in people asking (and I'll help field LOL) but there would be less of it to some degree.  Personally I want your container setup available to me everywhere.  I frequently find myself pulling off a B9 switched tank in favor of one of yours because they are so much better.  Perhaps you could include this as an optional patch similar to the way the Nertea handles some things for CryoEngines/Tanks.

[RedParadize]

1 hour ago, Shadowmage said:

What are the thoughts on adding patches to convert the stock tanks to use the SSTUVolumeContainer system?

On my side, SSTU fuel tanks made stock rocket tanks else obsolete. And this is true for most of modded rocket tanks as well. There is a notable exeption to this: Near Future Propultion tanks. I already made a patch that add NFP fuel to your tanks. But I could see myself using a SSTU style version of NFP and NFC, mostly for esthetical reason. Don't get me wrong, your tanks look awesome. But for a Space Tug, NFC trust/tanks are looking great.

For the Mk2 MK3,  I barely use them when building planes. (OPT and MkIV when it will be updated) But I am sure others would find a use for SSTU style Mk2 and Mk3.

 

On 23/5/2016 at 3:04 PM, Shadowmage said:

After all of the fun with wheels has been had, I'll be moving onto station parts (finally!)  Or perhaps finishing off the tanks, structural elements, and cargo bays?  Spherical tanks, cryo tanks, trusses, and various cargo bays would be nice to have in the short-term.  Trusses might wait until I start on the station parts in earnest;  will likely be contacting Nertea to see if I can borrow the form-factor from his trusses (hexa and octo), as I would like to remain visually compatible with his NF-Construction/Structural parts.  The models will have some differences to them, but should be visually compatible enough to not stick out too much if they are used on the same craft.  Will also be fewer parts that I need to make (e.g. adapters), as the NF parts will work fine (may still make a few adapters, to be used on the modular-structural-segments).

That sound awesome. Cargo bays and reusable fairing would be great. Same with NF style trust and tanks. I am curious to know how you imagine your crewpod/habitat, will they be customizable? And also, will you do centrifuge?

 

On another topic, I have a suggestion, see it as a wish list from a always-wanting-more-customer. 

The Rocket-in-a-Box:

Do we realy have to carry a empty tank to Duna or a fully assembled trust to space? I am thinking about a IKEA kit. Basicly, If SSTU part could be either converted into "box" or stored in KIS with only thier tankageVolume concidered. I always wanted to carry assemblable booster to Eve and strap them on the spot. It could also be realy usefull for station building.

Thanks again for your great mod!

[tater]

I imagine that spaceplane people would only be helped by SSTU-ing this parts. I honestly don;t bother with he stock tanks---or crew parts, actually---at all any more.

Regarding station parts, what's your target functionality/aesthetic? Obviously I could imagine a bare-bones truss/tank system as one element, but what would the crew part variants be? Or would they be only variant in what they have aside from crew (built in functionalities like the current capsules)? Would variant length parts be possible, with crew number changing with length? Are IVAs possible (I know they're not your favorite thing  ) in that case?

Looking good, as always.

[tajampi]

Wow, this mod is amazing, really like the engine customization