Jump to content

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

Shadowmage

By Shadowmage
in KSP1 Mod Development

 Share

Recommended Posts

VenomousRequiem

VenomousRequiem

Posted
Posted

An updated release? Welcome back then, Shadow!

Ah, the hype for an EUS has been on for a while! And I'm sorry my bugging got to the point where you just made one to shut me up. :P

Now ADVENTURE IS REALLY POSSIBLE!

Eod7FO5.png

Really though, adventure has it's ups and it's downs. Shortly after that picture was taken, the interstage containing the lander was jettisoned, and the two fuel tanks of the lander split apart. I'm not sure how, they just did. And upon time accelerating as they were split, the top half shot back to the bottom half, and then started to drift again. Maybe this is a big with KJR? I think I've seen something like this before.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

KJR can cause its share of problems; very odd ones when they do pop up. However I have found it is generally more helpful than not, at least on the scale that I build things (hundreds of tons). If it is a repeatable issue, please let me know and I'll do some further investigation w/KJR installed (currently do not have it in my dev setup).

Will also be reworking the balance on the ICPS and CM/SM a bit, mass/resources wise. Will be rebalancing the ICPS towards a LH2/LOX fuel distribution - so you should see overall less weight, higher ISP, and slightly higher overall delta-v. The new HUS is already using these stats for balancing. The CM will have its dry mass reduced to compensate for the now-included ablator/heat shield (previously it had an extra weight factor fudged in to simulate it... but this extra weight was never removed when the ablator module was added). Might be rebalancing the SM a bit as well (mass wise), to make it all come in line with the vision that I have for these parts.

On the plugin end of things - currently cleaning up the 'NodeFairing' plugin (responsible for engine fairings, side fairings on the SC-B-SM) to more cleanly support complex fairing setups such as those on the bottom of the SM, and more cleanly handle the jettison/detach functionality.

Will also be looking into what it would take to allow more granular control over the tweakables for the fairings (radius, height), but not sure if I'll be able to do those without too much GUI work (would rather wait on the GUI stuff until next KSP update with the unified Unity 5 gui system).

Current plans are for a final private testing release this weekend/later this week, and hopefully first public release sometime next week.

Link to comment
Share on other sites
V8jester

V8jester

Posted
Posted
What, 3.75m SLS's aren't enough!

My SLS I built with procedural parts is a 7m rocket :) and can lift 200+tons to orbit. I know its a bit much but its one of the most realistic flying rockets I built. It hovers on the pad for about 2-3 seconds before slowly ascending

Link to comment
Share on other sites
_Augustus_

_Augustus_

Posted
Posted
My SLS I built with procedural parts is a 7m rocket :) and can lift 200+tons to orbit. I know its a bit much but its one of the most realistic flying rockets I built. It hovers on the pad for about 2-3 seconds before slowly ascending
That's too large, a KSP Saturn V only scales to 6.4m, and a real-life SLS is 8.4m...
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
I like the EUS, but I do wish that you could make a 5m balanced SSME cluster to use in an SLS.

So far the SLS parts I have designed are intended to be used on top of KW Rocketry parts for the 5m SLS 'Core' and boosters. I -might- make a set of 5m 'core' parts at some point in the future - no guarantee though as the existing options from other mods are more than adequate. I did a quick mock-up of it (the core) last week when I was working on the HUS, but need to finish up all the rest of the WIP before I start anything new :)

However in my current career game I am using a 3.75m lifter setup for the ICPS/SM/CM stack. It both looks and performs about like I would expect, for local missions at least. The 5m parts are overkill for local Kerbin area operations (Mun, Minmus), but needed a bit more for further-reaching missions, especially if using any planet packs or system rescaling.

So... perhaps in the future :)

Link to comment
Share on other sites
V8jester

V8jester

Posted
Posted
That's too large, a KSP Saturn V only scales to 6.4m, and a real-life SLS is 8.4m...

I do agree with you completely. The only reason I built mine so ludicrously huge was to build it to scale with Chaka monkey's Orion pod (without just rescaling it in the cfg) and have it look proportionate. Chaka is way oversized in every way as it is. But the textures look really good.

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted

Few questions:

With regards to decouplers - should I maintain them as integrated into the pods and/or fuel tanks, or separate them into distinct parts?

Integrated - Pros:

1.) Lower Part Count

2.) Less floppy rockets/landers - single-part decouplers seem to have a lot of joint flex and compression for some reason (might be solvable through config or plugin)

3.) Solves some strange node-connection issues with the LanderParts, where non-aligned nodes in the same position would prevent properly aligned nodes from connecting (e.g. the top and bottom nodes on a fuel tank would prevent the middle node from snapping into position).

Integrated - Cons:

1.) Can cause issues with MJ / KER delta-v calculations and auto-staging - they do not handle decouplers with fuel/engines very gracefully - have not been able to find any solution in the MJ code, but I'm admittedly unfamiliar with the code setup.

2.) Staging icon issues with other modules activated through staging - e.g. ModuleEngines. Can partially be alleviated by removing the decoupler from spacebar staging and mandating manual staging through right-click/action groups.

Some of the MJ/KER problems may be solved by swapping where the decouplers are located; e.g. put them on the top of the fuel tanks rather than the bottom of the pods. Have not yet fully investigated this yet; will likely be experimenting soon. Some of this would run afoul of staging problems -- a part may only have a single staging icon. So, not sure how to solve this for stuff with integrated engines (SC-B-SM, ICPS, HUS) other than to force manual right-click/action group staging.

Second question - I am thinking about creating a 'Welding Docking Port' part. This would be intended for space-station construction. It would function as a standard docking port, but have an additional right-click option on it to 'weld' the connected parts. What this would do is to remove two connected (matching/welding) docking ports from a vessel and move the remainder of the parts into position where the docking ports were removed - Essentially welding the two station sections together. This could save part-count on large multi-segment (constructed in-orbit) stations while still allowing for in-orbit construction (and all the fun/difficulty that comes with it). Any thoughts on this functionality? Should I investigate it a bit to see if it could be done?

Third question - Again, in regard to stations, I am contemplating making a multi-docking-node part. This would be a single part with multiple docking ports on it. Possibly with docking lights as well. This is all in the aims to reduce station part count. My current stations are ~40 parts, with ~10 of those being docking ports that could be combined into 2 discrete parts (so 40->32 parts, and with the above welded nodes 32->26 parts). Thoughts on the usefulness of this part?

If you can't tell, I'm trying to solve some current problems popping up in my career game - mostly running into part-count limits when trying to dock vessels at stations - starts lagging at ~150 parts or so; which is both headache and rage inducing for me. For the welded dock and multi-dock, these parts would probably be developed after the initial public release (so.. v1.1 or so) - they would form the initial pieces of the as-yet-unstarted 'Station Core' part series.

Anyhow, got quite a few plugin things cleaned up in the past couple of days. Just need to clean up the decoupler stuff mentioned above (e.g. figure out how to best handle it...), do a couple good passes over config stuff, and I think things will be ready for public release.

Link to comment
Share on other sites
riocrokite

riocrokite

Posted
Posted (edited)

From my side both those plugins are much needed for the community. Part count associated with multiple docking ports is a big performance hit on many planetary or orbital bases. Plus as you mentioned docking port low weight = wobbliness which brings another undesired effects.

So for example a long truss with multiple docking ports where you can attach stuff (living quarters, fuel, panels etc) would be a huge performance optimization.

Now I'm no coder myself, but from what information I gathered creating multiple docking port part might create quite a few problems. I was thinking that the easier route might be to create a part with switchable docking node. You could then select the one you want to use at the time. Problem with this might be that player wouldn't know which docking port is active at a given time (well you could name active docking port a number and use texturing with numbers so player could know). However using Firespitter FSmeshswitch could be alleviate this problem. (as it switches meshes thus indirectly textures in flight at the moment).

I don't understand completely how the welding stuff would work, however this sounds very promising and needed as well.

All in all I'm all for testing and help if you go ahead with this stuff :)

edit: as for staging I went with the integrated approach for my stork lander systems parts for update and yah KER doesn't count everything. I can live with that and one can always calculate dV separately. Maybe some solution would be to have switchable staging module (just to get all dV in editor) but still it won't be accurate since we need dV with all stages and separations ;)

Edited by riocrokite
Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted
From my side both those plugins are much needed for the community. Part count associated with multiple docking ports is a big performance hit on many planetary or orbital bases. Plus as you mentioned docking port low weight = wobbliness which brings another undesired effects.

So for example a long truss with multiple docking ports where you can attach stuff (living quarters, fuel, panels etc) would be a huge performance optimization.

Now I'm no coder myself, but from what information I gathered creating multiple docking port part might create quite a few problems. I was thinking that the easier route might be to create a part with switchable docking node. You could then select the one you want to use at the time. Problem with this might be that player wouldn't know which docking port is active at a given time (well you could name active docking port a number and use texturing with numbers so player could know). However using Firespitter FSmeshswitch could be alleviate this problem. (as it switches meshes thus indirectly textures in flight at the moment).

I don't understand completely how the welding stuff would work, however this sounds very promising and needed as well.

All in all I'm all for testing and help if you go ahead with this stuff :)

edit: as for staging I went with the integrated approach for my stork lander systems parts for update and yah KER doesn't count everything. I can live with that and one can always calculate dV separately. Maybe some solution would be to have switchable staging module (just to get all dV in editor) but still it won't be accurate since we need dV with all stages and separations ;)

I have a couple of ideas regarding the decouplers, to still allow MJ/KER to calculate dV properly; will be playing around with them tonight. Mostly it involves moving the decouplers into the lower part; so the pod-included decouplers would instead be included on the fuel tank below. Still thinking through how this would effect the rest of the parts, and it is likely that I'll still run into issues with this setup. I suppose I'll find out tonight :)

I'm about half-okay with letting them go with MJ/KER not doing the dV calc. Would really like it to work, but not sure I want to add extra part-count just to get it working. I'm also investigating what I could submit as a patch/PR to MJ/KER to fix things on their end, but quite lost on their code.

Still in very early concept phase on the other stuff, just working through ideas. I -think- I know how the multi-docking port stuff should work; already have a module written out for testing, but have not yet created any models. Yes, the docking ports would have specific names in the right-click menu which would correspond to textured labels on the ports/part itself to denote which options and ports correspond.

On the welding stuff - was just an idea I came up. No clue how it would work yet either. I'm 90% certain it is possible (moving/reparenting parts), and 80% certain that the code to do it would be a mess and take a bit to figure out :) Fun stuff to look forward to.

I have ideas for a few other part-count-reducing station/base parts, but will save the discussion on those for later when I am closer to starting development on them.

^

"You must spread some reputation around before giving it to Shadowmage again"

Thanks :)

Link to comment
Share on other sites
Shadowmage

Shadowmage

Posted
  • Author
Posted (edited)

Well, decoupler experiments last night showed that changing the node the decoupler is triggered on does nothing for fixing the dV display for KER/MJ. It actually made the parts harder to use as decoupling had to happen through manual right-click instead of spacebar staging. Having the decoupler on the bottom node doesn't work properly either; still no dV calculations.

Ohwell, back to brainstorming on those.

An alternative that I might be able to implement is a 'physicsless' decoupler part. It appears that they do not use standard joint mechanics and are 'skipped' for joints, rather they are parented directly to the parent part. Unsure how this would play out for decouplers with multiple attach nodes as compared to small radially attached parts. Going to create a couple crazy experiments tonight to figure out the performance difference between physics-less and physics-enabled parts. As the joints and collision handling are a huge part of the performance hit associated with part count this may or may not turn out to be a workable/acceptable compromise solution.

Mostly finished with the plugin cleanup end of things, at least what I can solve currently (lots of stuff waiting on Unity5 gui update). So.. as soon as I get this decoupler stuff figured out I should have an updated (and hopefully final) private test release in the next couple of days. Will try and update later with more info if I have it.

EDIT:

Physics-less decouplers may indeed be the answer. Initial testing has revealed little/no performance degradation from physics-less parts.

Test1 - physics enabled parts:

7x short 3.75m tank (base stand)

180x rockomax decoupler

total parts: 187

FPS: 25-42

Test2 - physics-less parts:

7x short 3.75m tank (base stand)

180x physics-less SSTU test decoupler

total parts: 187

FPS: 59 + (vsync capped)

Further testing, through rather crude methods, showed that the performance hit from the physics-enabled decouplers was present with or without the joint-attachments (by decoupling all of the decouplers so that they were single-part vessels). So, the performance problems may stem from the general rigid-body updating on Unity's end of things rather than the joints between them as I had previously thought. In essence, more rigidbodies = lower FPS, regardless if they are attached to each other via joints or not (though the joints probably do have some additional computation penalty, my crude testing methods were not able to tell the difference/delta).

So... I will likely be creating specific physics-less decoupler parts for use for both SC-B and LC part series in order to solve the decoupler/dV calc issues.

Will probably just create a procedural decoupler using my existing procedural mesh-generation for the round decoupler shapes, and utilize the existing meshes for the LC sleeve style decouplers. The LC decouplers will be removed from the fuel/cargo mesh-switch variants as I make this change (there were some really weird issues that popped up because of these). The pod-integrated decouplers will likely also be removed at this point in favor of discrete physicsl-less part-based decouplers.

Am also considering creating an 'auto decoupler' module that automatically inserts a (physics-less) decoupler part into the stack below certain pieces. Still thinking on the logistics of this one. It would be only be a separate part as far as the game-engine is concerned for staging and fuel-flow operations; it would not be directly clickable or interactive, would have no model, no physical dimensions, and would be activated through right-click on the parent part or through space-bar staging. Would probably also make it disable-able for instances where users did -not- want a decoupler (or want to use a specific decoupler). Will likely investigate this route -after- the initial public releases as this feature may take some time to implement properly, and the parts should work fine without it. Need to think on it a bit/investigate if this would be breaking change for existing saves (that will be the deciding factor of -when- it is implemented).

Edited by Shadowmage
Link to comment
Share on other sites
riocrokite

riocrokite

Posted
Posted
Well, decoupler experiments last night showed that changing the node the decoupler is triggered on does nothing for fixing the dV display for KER/MJ. It actually made the parts harder to use as decoupling had to happen through manual right-click instead of spacebar staging. Having the decoupler on the bottom node doesn't work properly either; still no dV calculations.

It's strange; I didn't encounter space-bar staging problems by making decoupling nodes top or bottom (last week I made 2 new parts for my mod that use top and bottom stack decoupling modules). I agree on dV calculations.

An alternative that I might be able to implement is a 'physicsless' decoupler part. It appears that they do not use standard joint mechanics and are 'skipped' for joints, rather they are parented directly to the parent part.

[stuff]

So, the performance problems may stem from the general rigid-body updating on Unity's end of things rather than the joints between them as I had previously thought. In essence, more rigidbodies = lower FPS, regardless if they are attached to each other via joints or not (though the joints probably do have some additional computation penalty, my crude testing methods were not able to tell the difference/delta)

It's very interesting observation also when it comes to docking ports. So for example one could create a standard part with rigidbody/colliders (i.e. habitation module') that have i.e. 2 'holes' for physicless docking ports that you can attach in editor. Then when launched those 3 parts would count as 1 part with 2 docking ports (performancewise). That could be partial solution to the performance problem. It would come with some ceveats though (player would not be able to click on docking port parts - no collider, so generally no option to undock a part?, probably those parts wouldn't work well with KIS system etc).

This however could be solved by hybrid system, so one part is normal and has integrated docking module (i.e. habitation module with one side docking port) and other side you would just pluck physicless docking port. Then when docking other parts with integrated 1 docking port you could always undock :P.

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.

×
 Share
Go to topic listing
×
×
  • Create New...