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

[Jimbodiah]

I have just been playing with CoM on boosters to get the to seperate nicely without them flailing around like a [insert metaphor]. Perhaps this is something to implement with the Modular Boosters?

CoMoffset at default (0,0,0)
https://www.youtube.com/watch?v=XKXbX-5t6Xk

CoMoffset at 0,15,0
https://www.youtube.com/watch?v=a4xBdL0A1WQ

This might stop smaller boosters from flipping into the back of the main core without needing to endlessly finetune the thrust of the seperatrons.

[blowfish]

6 minutes ago, Jimbodiah said:

I have just been playing with CoM on boosters to get the to seperate nicely without them flailing around like a [insert metaphor]. Perhaps this is something to implement with the Modular Boosters?

CoMoffset at default (0,0,0)
https://www.youtube.com/watch?v=XKXbX-5t6Xk

CoMoffset at 0,15,0
https://www.youtube.com/watch?v=a4xBdL0A1WQ

This might stop smaller boosters from flipping into the back of the main core without needing to endlessly finetune the thrust of the seperatrons.

What could you actually adjust about the booster that would move the dry CoM?

I think a better solution (and this might be how it is already, haven't checked) would be to just make sure that the dry CoM is lined up with the attachment point.  That gives you an easy point of reference from which to align the separation motors.

And I recall Shadowmage saying that the modular boosters will have built in separation motors, which kinda makes worrying about the CoM pointless.

[Jimbodiah]

Offsetting in the RBDC will not work as you can not pick up the part from a position not in it's center (if you do the part will just snap to center anyway. And if you offset with the tool, then chances are high the booster will wobble in the decoupler as an extra offset will be created by the tool in how far the booster is from the center of the ring.

We'll have to see what Mage comes up with. Anyway, it's a solution that works right now with SRBs and LRBs.

[blowfish]

@Jimbodiah The point I was trying to make was that if you know where the dry CoM is, then placing separation motors evenly is easy.  Where it's actually attached doesn't matter.

This doesn't work for LFBs, true, but there's no physical way you could change the CoM of a booster, so it would really bother me for such a thing to exist in KSP.

[Shadowmage]

57 minutes ago, Jimbodiah said:

I have just been playing with CoM on boosters to get the to seperate nicely without them flailing around like a [insert metaphor]. Perhaps this is something to implement with the Modular Boosters?

CoMoffset at default (0,0,0)
https://www.youtube.com/watch?v=XKXbX-5t6Xk

CoMoffset at 0,15,0
https://www.youtube.com/watch?v=a4xBdL0A1WQ

This might stop smaller boosters from flipping into the back of the main core without needing to endlessly finetune the thrust of the seperatrons.

 

48 minutes ago, blowfish said:

What could you actually adjust about the booster that would move the dry CoM?

I think a better solution (and this might be how it is already, haven't checked) would be to just make sure that the dry CoM is lined up with the attachment point.  That gives you an easy point of reference from which to align the separation motors.

And I recall Shadowmage saying that the modular boosters will have built in separation motors, which kinda makes worrying about the CoM pointless.

 

38 minutes ago, Jimbodiah said:

Offsetting in the RBDC will not work as you can not pick up the part from a position not in it's center (if you do the part will just snap to center anyway. And if you offset with the tool, then chances are high the booster will wobble in the decoupler as an extra offset will be created by the tool in how far the booster is from the center of the ring.

We'll have to see what Mage comes up with. Anyway, it's a solution that works right now with SRBs and LRBs.

 

6 minutes ago, blowfish said:

@Jimbodiah The point I was trying to make was that if you know where the dry CoM is, then placing separation motors evenly is easy.  Where it's actually attached doesn't matter.

This doesn't work for LFBs, true, but there's no physical way you could change the CoM of a booster, so it would really bother me for such a thing to exist in KSP.

 

Auto-Jettison -- the idea is about halfway scrapped at this point.  While I would -love- to implement it, I would need to know that RO could handle it appropriately; and as this requires creating a dummy/duplicate-fuel type, and RO is....particular... about fuel types, my current methods would not work due to stock limitations (unless someone can tell me how to make an SRB engine -not- consume all of its fuel; I need a fuel reserve for the jettison engine) (for example, RO breaks the BPC auto-jettison feature due to these issues).

I'm not completely done working on it / thinking on it yet though, so I may still find a way to cheat and let it work properly.  Or just let RO use standard decouplers/etc if they don't want to deal with dummy/duplicate fuel types.

Either way, it will -not- be part of tomorrows release;  I've got my hands full with just exporting all the models and doing up the configs (and the data-model changes... see the warning below).

 

COM Offset -- as blowfish points out is it mostly unrealistic to adjust the COM of the part -- the COM is set by the distribution of mass, which for an SRB/LRB (and indeed most parts) is mostly physically unalterable.  The one place where this -might- be realistic is in some command pods where the crew can re-arrange gear and/or use a sliding-balast setup.

Either way, the new MSRB's will be 'perfectly' balanced as far as COM goes.  I have built them, and the module/plugin, in such a way that the center/attach/grab point of the SRB -will- be its COM, and thus you should get nearly-perfectly-straight separation when using the RBDC with a non-offset attachment setup (e.g. just slap the booster onto the RBDC, and it -should- be good).

Alternatively, if/when I add the thrust differential control to the RBDC this will be much easier to setup (though may require some trial/effort/testing or an external tool such as RCSBA to get precise setups).

 

 

WARNING - IMPORTANT :

Tomorrows release will likely break -everything-. 

I'm in the process of reworking how I store information about various models (height/volume/diameter/nodes/etc) and texture-sets in favor of a more generic, efficient, and capable system.  I had wanted to wait until the 1.1 update to do this (as I would be breaking everything anyway), but I need some of the new features to even get the Modular SRB's working effectively (mostly texture-set related stuff). 

Texture set data will now be stored on per-model basis, so that modular parts where only some of the models have texture sets will work properly, and will allow for different texture sets to be used for each model variant (without duplicate/empty entries).  This change will likely break any existing texture-swap enabled parts (or at least their texture sets will revert to whatever the new default is).  This change is necessary for modular parts where only some of the models have texture-swapping (e.g. engine-mounts where only the delta-iv and shroud types have texture-sets, and nosecones/adapters where the new SRB nosecones will have different texture sets from the existing nosecones even though they will all be usable on the same part).

Model names will now be a more descriptive, as they are all being stored in the same in-memory list, by name, which needs to be unique.  For example, the generic mount has changed from being named 'Generic' to 'Mount-Generic'; adapters have been renamed similarly (and multicouplers have had the ':' removed to fix some module-manager incompatibilities).  This change will break MFTs, Engine-Clusters, and Modular Upper stages that happen to be using any of the effected parts (which is going to be nearly all of them).

Model data is now stored in a set of .cfg of dedicated to this purpose.  Parts that have information such as volume/height/mass/cost/tech/nodes etc stored in their part .cfg file will have this data moved out to the ModelData file (e.g. the MFT tanks, ModularUpperStage parts).  By only storing this information in a single place it cleans up and simplifies setting up new models for use in various parts -- merely setup the model definition once, and simply link to it in the parts .cfg file.

DO NOT EXPECT YOUR CRAFT TO SURVIVE THIS UPDATE.  That is why I'm warning you all about it -now-, rather than with the release tomorrow.  This should give you time (or at least fair warning..) to backup your game, remove any craft using SSTU parts, and be prepared to rebuild them with the new release.

[Jimbodiah]

Regarding realism in changing the CoM... You do realize that little green men are flying these ships in a physically impossible solar system, right?  Not to mention the countless other aspects, features and bugs just in the stock game. 

The CoM adjustment just compensates shortcomings elsewhere to help the gameplay a bit by not destroying the main core upon seperation in certain situation (and just look better in the others).

[stratochief66]

2 hours ago, Shadowmage said:

Auto-Jettison -- the idea is about halfway scrapped at this point.  While I would -love- to implement it, I would need to know that RO could handle it appropriately; and as this requires creating a dummy/duplicate-fuel type, and RO is....particular... about fuel types, my current methods would not work due to stock limitations (unless someone can tell me how to make an SRB engine -not- consume all of its fuel; I need a fuel reserve for the jettison engine) (for example, RO breaks the BPC auto-jettison feature due to these issues).

 

Really? We definitely don't intent to break the BPC behaviour within RO, that is likely more the result of JoseEduardo and my ham-handedness. I can think of a number of ways to probably get around any problem, such as reconfiguring the BPC to use two separate solid realfuels (such as PSPC and HTPB) to achieve the same effect as you do in stock. Thankfully, RO now includes multiple types of solid fuels that have basically the same density, so hopefully that is useful as a firewall between the two separate engines/effects. I will take a look at how RO handles the BPC sometime in the next week and see if I can shed any more light on the issue. RO configs definitely have a bit of flex to achieve function that can not otherwise be implemented.

Edited February 6, 2016 by stratochief66

[Shadowmage]

1 minute ago, stratochief66 said:

 

Really? We definitely don't intent to break the BPC behaviour within RO, that is likely more the result of JoseEduardo and my ham-handedness. I can think of a number of ways to probably get around any problem, such as reconfiguring the BPC to use two separate solid realfuels (such as PSPC and HTPB) to achieve the same effect as you do in stock. Thankfully, RO now includes multiple types of solid fuels that have basically the same density, so hopefully that is useful as a firewall between the two separate engines/effects. I will take a look at how RO handles the BPC sometime in the next week and see if I can shed any more light on the issue. RO configs definitely have a bit of flex to achieve function that can not otherwise be implemented.

Ahh, it likely is a simple oversight due to lack of familiarity with what the part/module was doing/meant to do.  And I'm not familiar enough with the RO/RF fuel stuff myself to know where to even begin setting up the fuel types/densities/etc properly.  No offense was intended, you and Jose seem to be doing an outstanding job on the configs, even with my crazy developments and changes.

If there are multiple similar-density solid-fuels (or really any fuel; volume doesn't matter too much for those parts, as long as the fuel-mass is proper...i.e. can fake it if needs be) it shouldn't be too much of a problem to set it up that way.  That is pretty much the entirety of it -- one 'main' engine module with a main fuel type, and a secondary 'jettison' engine module with its own fuel type.  This ensures that the jettison engines always have a fuel reserve, regardless of if the main engine has been activated or not.

Let me know if you need any help/insight/pointers on getting it set up/fixed up/whatnot; if nothing else I will work on it myself next time I'm working through RO configs.

[stratochief66]

I should be able to figure out the boost covers myself, i was looking at the code just now.

 

All the new part breaking changes in the next release, I would definitely appreciate if you could make a pull request on the RO repo to help us adapt to that.

[Shadowmage]

27 minutes ago, stratochief66 said:

I should be able to figure out the boost covers myself, i was looking at the code just now.

 

All the new part breaking changes in the next release, I would definitely appreciate if you could make a pull request on the RO repo to help us adapt to that.

Absolutely; although I expect the changes to RO patches to be minimal -- its more that it will break existing (in-flight or saved) craft due to plugin-side variables changing and possibly not initializing properly and/or reverting to the new default values.

Will know more tomorrow sometime; I'm just now getting into working on making the changes... work -- testing things in-game and getting all existing stuff back to working state.

[davidy12]

20 hours ago, Shadowmage said:

WARNING - IMPORTANT :

Tomorrows release will likely break -everything-. 

DO NOT EXPECT YOUR CRAFT TO SURVIVE THIS UPDATE.

Oh great! Gonna a be a long day rebuilding all my KLS variants and Kares variants. 

 

Still, nice SRBs. Though I'm curious on something @Shadowmage will the SRBs have a high gimbal range so we can build Ares I models?

[Jimbodiah]

Ares I works with the current SRBs.

[davidy12]

27 minutes ago, Jimbodiah said:

Ares I works with the current SRBs.

Yeah, but I had to go in and manually edit the gimbal range.

[Jimbodiah]

How come? I launched plenty of them with standard boosters. Ascent is less than optimal, but it works.

[StickyScissors]

23 hours ago, Shadowmage said:

WARNING - IMPORTANT :

Tomorrows release will likely break -everything-. 

DO NOT EXPECT YOUR CRAFT TO SURVIVE THIS UPDATE.  That is why I'm warning you all about it -now-, rather than with the release tomorrow.  This should give you time (or at least fair warning..) to backup your game, remove any craft using SSTU parts, and be prepared to rebuild them with the new release.

I hope game-breaking updates like this don't happen too often after this? having to re-build everything with SSTU parts on it takes a long while, especially since i built a lot of stuff yesterday :I. And maybe if things don't change drastically after this update, i can finally remove KW and depend on this more, because the KW community "fixes" are starting to test my patience.

[blowfish]

29 minutes ago, StickyScissors said:

I hope game-breaking updates like this don't happen too often after this? having to re-build everything with SSTU parts on it takes a long while, especially since i built a lot of stuff yesterday :I. And maybe if things don't change drastically after this update, i can finally remove KW and depend on this more, because the KW community "fixes" are starting to test my patience.

Shadowmage will of course be the only one with a definitive answer on this, but I don't imagine breaking updates will be very common.  That being said, this is a prerelease mod so anything can break at any time, with or without warning.

[Guest]

I've never been squeamish about having to rebuild vehicles, as long as the changes are a step forward in quality and function. I've found it forces me to go back and refine some of my more  wackadoodle kludge-fests  unusually improvisational designs.

And ditto on KW. I've given up.

[Shadowmage]

55 minutes ago, StickyScissors said:

I hope game-breaking updates like this don't happen too often after this? having to re-build everything with SSTU parts on it takes a long while, especially since i built a lot of stuff yesterday :I. And maybe if things don't change drastically after this update, i can finally remove KW and depend on this more, because the KW community "fixes" are starting to test my patience.

Generally not often, but that is also why this is in the 'under development' section.  If I need to break things to enable new features... I'm going to do it. 

With that said, I do not anticipate any more breaking changes before the KSP 1.1 update.  At that time there will be another round of breaking things as I will be renaming parts, and cleaning up the overall organization of the mod in preparation for moving some of it out of beta stage.

So, expect the first long-term stable versions to be sometime after the 1.1 update and the bugs have been ironed out.

 

3 hours ago, davidy12 said:

Oh great! Gonna a be a long day rebuilding all my KLS variants and Kares variants. 

 

Still, nice SRBs. Though I'm curious on something @Shadowmage will the SRBs have a high gimbal range so we can build Ares I models?

 

3 hours ago, Jimbodiah said:

Ares I works with the current SRBs.

Aye, I had no problem with Ares-I designs.  If all else fails, put fins/control surfaces on it.

The new nozzle variants each have their own gimbal ranges (some greater than others), but none of them are going to be more than a few degrees (5 deg or so max).  I think the old one was only like 0.5' or so, so you might expect up to a 10x increase depending upon which nozzle is used.

[Jimbodiah]

Verniers on the 2nd stage also work nicely. I copied the LFO one into an LH2/O version.

[Shadowmage]

Updated testing release is available:

WARNING - this release contains craft-breaking changes.  Backup your gameData and saves folders prior to installing this release if you want a chance to go back and fix things.

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.28-pre1

Mostly adds the MSRB parts (fully a WIP, mostly untested, -maybe- usable), in addition to an overhaul of the model referencing system.

• Known Issues:

• MSRB's are available in a wide range of lengths, with diameters from 0.625m -> 10m.  Length increments are determined by the segment-length for that model (2.5m, 3.2m, 5m).
• Auto-decouple/jettison motors are NOT yet working
• Texture-sets/swapping is NOT yet enabled (for any of their models/mounts/noses)
• Mass stats do not yet take into account the fixed-motor mass for a diameter
• Nosecones and nozzles are fully WIP, not even the geometry is done, and certainly not any textures. They are included for initial prototype testing/fitting only, and will likely all undergo substantial changes.
• THE MSRB PARTS ARE WIP AND MIGHT HAVE BREAKING CHANGES BEFORE THEY ARE DONE.

 

 

[davidy12]

AWESOMENESS!!! *Goes to build new SLS rockets*. 

 

@Jimbodiah: SSTU J-2X clusters are broken.

[Jimbodiah]

I think a lot of things are broken with the new update     I'll make some new ones tomorrow.

[davidy12]

25 minutes ago, Jimbodiah said:

I think a lot of things are broken with the new update     I'll make some new ones tomorrow.

Cool.

@Shadowmage: Will the old SRBs eventually be deprecated? 

[Jimbodiah]

Mage, these things look awesome!!!! Playing around with them now, really amazing looking! And so far they all seem to stay staight upon jetissoning

 

@davidy12 The old SRBs will indeed be removed. The new J2-X clusters

 

[davidy12]

5 minutes ago, Jimbodiah said:

Mage, these things look awesome!!!! Playing around with them now, really amazing looking! And so far they all seem to stay staight upon jetissoning

 

@davidy12 The old SRBs will indeed be removed. The new J2-X clusters

 

NOICE!!!!!!! Testing now.