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

[Jimbodiah]

Ooooh, SR71, I smell an SSTU plane-core

[Jimbodiah]

Here's a link to the craft topic in Craft Exchange

Contained so far:

Delta II
Delta IV Heavy (Orion)
Ares I
Ares V
Saturn V
SLS
Space Shuttle
Soyuz / R7

LC2 lander
LC3 lander
LC5 lander
 

Edited April 4, 2016 by Jimbodiah

[Shadowmage]

General development update:

Still awaiting a bug-fix for the fairing bug (that breaks nearly all parts due to drag-cube updating).  Issue had some updates to it today.. so hopefully will be sorted out this week.

Found new bug in gimbal module that breaks all multi-engine engine-cluster setups.  Bug report submitted (http://bugs.kerbalspaceprogram.com/issues/8345).  Awaiting fix; as with the drag-cubes, I cannot work around this one... it completely breaks the mod in functional use.

Worked around the IMassModifier bug by defaulting to a non-zero 'modified mass' in the module, caching the calculated mass, and returning either the default or cached calculation as appropriate (is the same field... just starts with default and is updated to cached value when it is calced/recalced).  Stock also 'improved' this functionality by polling for mass for all parts on-tick rather than only on-editor-changes; displayed mass for parts should now be much more consistent across various mods, screens, and scenes.

Got all but ModularFuelTanks converted over to use the new UI controls; went alot faster (and cleaner, eaiser) after they added in the UI callback setups.  In general the editor UI will be much more responsive while using SSTU parts, as I've eliminated all of the uneccessary OnEditorShipModified events being fired (now they only get fired when cost/mass/geometry are actually updated).  Also cleaned up drag cube recalculation code to only update a drag cube for a part at most once per tick, which eliminates 70% of the drag-cube recalculation (previously the engine cluster would cause recalculation, and so would the node-fairing; often also triggering a third or fourth recalc from the event cycles).

So... -if- the above bugs get fixed... SSTU should have even better performance in general

Aside from those two bugs most everything appears to be working properly.  Still quite a large list of things on my '1.1. update TODO' list, but many of those can be done in short order after the initial updating is finished.

 

Will start publishing 1.1 test releases as soon as those two stock bugs listed above are solved.  Both of those render the mod functionally unusable (can't use map mode with many parts as root; can't use engine clusters in actual clusters...), and would be pointless to post releases as long as they exist.

[Shadowmage]

If anyone could do some testing and confirm the bug report regarding the gimbal modules, it will greatly increase its chance of being fixed in a timely manner:

http://bugs.kerbalspaceprogram.com/issues/8345

Basically to confirm the bug you'll need to edit one of the stock engine part config files;  remove the mesh=XXX, replace that with a properly setup MODEL node (e.g model=URL to model), and add a rotation to that model node (rotation = 0, 90, 0) for that model; use the patched engine in a craft; launch it, examine gimbal response to various inputs (notably, check that it responds to roll input improperly, and/or does not respond to pitch/yaw inputs properly).

Here is an example of how to edit/update the stock mammoth engine to test the bug:
Comment out the mesh= line, and add the MODEL node to the config file.  Save the file and launch KSP.  Alternatively you can copy the part config and change the name=to a new name if you don't want to alter the stock configs.

	// mesh = Size3EngineCluster.mu
	MODEL
	{
		model = Squad/Parts/Engine/Size3EngineCluster/Size3EngineCluster
		rotation = 0, 90, 0
	}

Edit:  That might not be the best test-case due to its multi-nozzle setups;  will update with a better example as soon as I am home from work (likely using the other 3.75m engine)

 

Thanks

 

Edit: More info can be found at:

 

Edited April 4, 2016 by Shadowmage

[_Augustus_]

Does the new test version work in 1.1?

[Shadowmage]

1 minute ago, _Augustus_ said:

Does the new test version work in 1.1?

No; I have not released a 1.1 compatible version, and will not be until the stock bugs mentioned this morning are fixed (drag-cube updating on root parts, engine gimbals on rotated engine models).  Those two bugs break nearly every single part in the mod to one degree or another.

 

[RedParadize]

2 minutes ago, _Augustus_ said:

Does the new test version work in 1.1?

 

lol. I don't want to be rude but reading last few comment could have answer that!

[VenomousRequiem]

4 hours ago, _Augustus_ said:

Does the new test version work in 1.1?

If it was 1.1 compatible he would have said something. :^)

-A friendly PSA for everyone on this website.

[Shadowmage]

General status update:

More things working and/or fixed up last night.  The functionality of most parts appears to be working at the moment (minus the aforementioned stock issues).  Still left to do is re-export all of the ShipCore engine-containing parts (service modules, shuttle fuselage) to fix up their gimbal orientations.  Still more on the 1.1. TODO list, but finally the list is growing shorter rather than longer.

Got the A+B tank type swapped around yesterday, and re-exported all their models minus the top and bottom cap;  this is so that I can introduce an inset mount type (or two/three) for use as inset-engine mounts for landers/etc (those will be coming later...).

Started working last night on enabling -optional- colliders for node-fairings, petal adapters, isdc, and pdc parts.  This will end up with a toggle in the editor that determines if colliders are enabled or disabled;  for isdc this will enable surface attach, for the rest though I will be disabling surface attach for those colliders (as they either move, or get attached to other parts.... anything surfaced attached would look strange after activation or jettison as it would be floating in its previous position and/or destroyed by collision upon detach/jettison).  So far I have these setup to create 1 collider-per-face, but will have an option to adjust the # of faces per collider when it is all done (not sure if it will be config or UI based).

On the stock issues front; NathanKell has kindly begun looking into the gimbal problems, so hopefully a resolution will be found and available soon.  Haven't seen any updates on the drag-cube related issue, but as it effects several stock parts I expect it will be looked into and fixed before pre-release is over.

[StickyScissors]

Is anybody else having issues with engines ignoring the gimbal limit? Testing out a launcher, and noticed it was over correcting roll, so i went back to the VAB and dropped the gimbal down to 1* from the original 5*, but it doesn't seem to actually be limiting, because they still visually gimbal the original 5*, and they still roll the vehicle as if it were set to 5* (rapidly). The only way i have found to get around this is just locking the gimbal, something that isn't exactly a great idea during ascent.

[Shadowmage]

10 hours ago, StickyScissors said:

Is anybody else having issues with engines ignoring the gimbal limit? Testing out a launcher, and noticed it was over correcting roll, so i went back to the VAB and dropped the gimbal down to 1* from the original 5*, but it doesn't seem to actually be limiting, because they still visually gimbal the original 5*, and they still roll the vehicle as if it were set to 5* (rapidly). The only way i have found to get around this is just locking the gimbal, something that isn't exactly a great idea during ascent.

Could be related to how I force-reload the gimbal module; its likely overwriting any custom limitation settings.  Will have to pull the current limitation out, re-load the module, and re-seat the user-set limitation.

Will investigate this for a fix in 1.1 versions.

[acolangelo]

I’ve searched this thread and the GitHub issues list, but haven’t found any mention of the bug I’ve been seeing. The nozzle extensions of the RL10 variants are collapsed up into the engine itself. This is seen even on an entirely stock KSP install (OS X). As you can see in the attached screenshots, the nozzle extensions are displayed appropriately in the parts list, just not in the editor or in flight.

Screenshots and craft file attached—let me know if you need anything else, or want me to try anything specifically!

PS: Absolutely fantastic work. This mod quickly became an absolute essential to me.

 

Craft file: https://www.dropbox.com/s/elkg2vc1wwe5w3o/RL10-Test.craft?dl=0

EDIT: GitHub issue opened here: https://github.com/shadowmage45/SSTULabs/issues/278

Edited April 6, 2016 by acolangelo

[Jimbodiah]

They normally extend when you activate them (not in the VAB).

[blowfish]

36 minutes ago, acolangelo said:

I’ve searched this thread and the GitHub issues list, but haven’t found any mention of the bug I’ve been seeing. The nozzle extensions of the RL10 variants are collapsed up into the engine itself. This is seen even on an entirely stock KSP install (OS X). As you can see in the attached screenshots, the nozzle extensions are displayed appropriately in the parts list, just not in the editor or in flight.

As Jimbodiah mentioned, that's just how the RL10 works (IRL picture).  It extends when you activate it.

[acolangelo]

17 minutes ago, Jimbodiah said:

They normally extend when you activate them (not in the VAB).

 

5 minutes ago, blowfish said:

As Jimbodiah mentioned, that's just how the RL10 works (IRL picture).  It extends when you activate it.

Filed under: TIL

Useful to know—issue closed!

[Jimbodiah]

  Also nice to know if you stick them on very light rockets as a second stage, that it takes around 3 seconds for the engine to fire up after activating. These engines are also on the HUS/ICPS

Edited April 7, 2016 by Jimbodiah

[Shadowmage]

General update:

Been a bit slow the past few days as I've not been feeling the best, making it hard to concentrate on things.  But...things have still been getting done/checked off , just a bit slower, and nothing too complex.

NodeFairings, Petal Adapter, and Interstage Decoupler have all had a 'transparency' toggle added to their in-editor GUI, allowing for manually turning on and off their transparency.  This lets you see the texture-swap options better, and gives a better idea of what the finished rocket will look like (ideally this will allow the fairings to show up in the thumbnails...).  Most will also have a toggle to enable/disable colliders while in the editor.

Tracked down the source of the gimbal bug I was seeing last night, and it sounds like it will be fixed in the next pre-release.  Also added in a hacky work-around for the root-part-drag-cube-updating problems.  So the two major bugs that were keeping me from doing a release have been (or will shortly be) squashed.

I'll likely spend tonight and tomorrow doing extended testing and a bit more cleanup, and would like to have a 1.1 testing version available on Saturday.  Will still be a week or 3 before I'll have 'stable' versions ready.  Notably, I haven't even begun to work on wheels or legs, which are likely to take a few weeks to get sorted out.  So for now the SC-E parts do not work (or at least will not have integrated landing gear=\).

 

And on a more far-reaching note:
In general performance on 1.1 is way up; I have not noticed any lag from part count yet, even when I launched a ~200 part testing rig I was still sitting at >60fps on the pad (until aero effects kick in... but thats another discussion).  So I might not be as... stingy... with part count in the future.  I will still be designing modular parts with switchable geometry/etc, but this gives a bit more breathing room for designs and allows me to not pack -everything- into a single part.  So, might see a few more stand alone or limited use parts; mostly stuff that I run across and find a need for in my own game

[Shadowmage]

And on a general discussion point:

What are the thoughts about adding two more rocketry / engine related nodes to the Tech-Tree?

The first would fill the gap between XXX and VeryHeavyRocketry.  This would be a ~300 science node, and would give an excellent place for some of the more advanced but not-quite state-of-the-art engines (RS-25, ??).

Am also considering adding a 1000 science node -after- veryheavyrocketry for the most advanced / future-tech engines; F1B, J-2X, higher-end Merlins; all the stuff that never was or almost is.  'Experimental Rocketry' would likely be its name, or similar (most others have a 'hidden' 1000 science node that mods can use... rocketry does not for some reason).

 

(Just going through my 1.1 TODO list and this is one of the bigger changes that is on there to investigate)

[Jimbodiah]

Take it easy Mage, take care of your health.

[ComatoseJedi]

Since you asked a question, whenever I think of "Experimental Rocketry", I think of theoretical/concept engines. Electric engines (using Argon and Xenon), Nuclear rockets (which you've already started on). Pretty much the things that have already been done by Nertea and the KPSI-E branch by FreeThinker. Even the original Orion nuclear pulse engine comes to mind. Even going through CTT to Colossal Rocketry (the proposed Nova that never got built), but if you want to stick to stock, that's fine. Whatever you do is okay with me, because I don't plan on doing anything 1.1 until this mod is compatible with an official release of 1.1. So, you have time to sort all of that out. In the meantime, take care of yourself. Take a nap (or 12). Drink some fine, top shelf whiskey and relax. 

No one is going to bug you about "when is this thing going to be updated" since they changed the forum rules to prohibit such activity. And if they do, you can bet someone will notify the Mods about it. We got your back brother. 

But, switching gears to other aspects of this mod. I'd like to see the beginnings of station parts. Which are way easier to come up with than engines. And you don't have to worry about IVA's because the stock ones work just fine for these. While the ISS has been probably the most duplicated station part mod out there, you have plenty of material to work with. I'm rambling... let me go back to my corner and talk to the plants

Edited April 7, 2016 by ComatoseJedi

[Jimbodiah]

11 minutes ago, ComatoseJedi said:

"when is this thing going to be updated" since they changed the forum rules to prohibit such activity.

You're kidding, right?

[ComatoseJedi]

10 minutes ago, Jimbodiah said:

You're kidding, right?

Nope. not kidding. 

 

Quote

2.3 Forbidden messages
 f.  Messages that repeat inquiries about updates or content from modders.

This is a more explicit expansion on our rule against harassment, 2.2d. Requests in an add-on thread for updates when there has already been such a request will be moderated. The onus is on the poster to check the thread to see if an update has already been requested."

Not exactly "prohibit", but stop from constantly asking about updating a mod that's already been addressed to be updated by the OP. They will be moderated.

Edited April 7, 2016 by ComatoseJedi
a DOH moment

[JoseEduardo]

IIRC Experimental Rocketry is there, hidden and unused by stock but it is there, I don't remember exactly which mods use that node though... I guess USI warp drive does?

btw, I like Jedi's (you rebel scum) idea of using a Colossal Rocketry node, M-1 engine could be used there... and if engine layouts could be locked to tech tree nodes (please don't, I beg ya, leave all until 9 unlocked from start if you ever go with this idea), 14 and 18 Nova MM-1B and 1C engine layouts could be unlocked there and maybe other monstrosities in between based around the Nova MM-1B/C

[Shadowmage]

Thanks for the support guys

Its nothing life-threatening, or even that serious; just enough to keep me distracted for a few days.  Thankfully I had the amazing foresight last week to request some vacation time for tomorrow and Monday, so I've got a nice long weekend to finish recovering.  Originally I had taken the time off just for some time off (and to finish the updating...); but spending it for recovery is also a good cause.  Doc says all should be well in another 2-3 days... so.. yah... will be taking it easy for a few more days.

 

And before I forget, and surprise everyone by it;  I will (most likely) be changing most of the engines and parts that currently use 'MonoPropellant' to use a true hypergolic bi-propellant from CRP.  Have not decided which one, or at what ratio... but will likely get that all sorted out in the next day or two.  This is so that there is a separate pool of fuel for RCS and engines, and so that the fuel obeys stack-flow rules.  The few exceptions to this might be those specialty parts that are intended to burn the same fuel in their RCS and service engines... where I will likely just make the RCS use the bi-propellant fuel as well.  Still a bit to figure out on it... but as my mod is mostly a 'realism-light' type setup, I think this fits a bit better than just slapping MonoProp on everything.

[ComatoseJedi]

2 minutes ago, Shadowmage said:

Thanks for the support guys

Its nothing life-threatening, or even that serious; just enough to keep me distracted for a few days.  Thankfully I had the amazing foresight last week to request some vacation time for tomorrow and Monday, so I've got a nice long weekend to finish recovering.  Originally I had taken the time off just for some time off (and to finish the updating...); but spending it for recovery is also a good cause.  Doc says all should be well in another 2-3 days... so.. yah... will be taking it easy for a few more days.

 

I'm telling you, top shelf whiskey works wonders for just about anything that ails you. Trust me. I been drinking whiskey for medicinal purposes since I was a little boy and was common practice when your parents come from a generation when there was no such thing as a doctor visit. I'm not an alcoholic by a long shot, I haven't touched alcohol in years, but I will when I get sick/down and out and it fixes me right up. Not to mention, you see donkeys for a little while, which is a nice side effect.