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

[bazz]

Awesome mod digging it so very much.

One tiny bit of constructive chritisim would be the ship core pod impact tolerance speed is a bit weak 14m/s for such a beefy looking pod.

[Shadowmage]

Awesome mod digging it so very much.

One tiny bit of constructive chritisim would be the ship core pod impact tolerance speed is a bit weak 14m/s for such a beefy looking pod.

Thanks for the support

The low impact tolerance is intentional; notice how light the pod is compared to other available options based on the number of occupants it carries and the included features. 6 occupants, RCS, and heat-shield. Something had to give somewhere.

I've also always thought that the 45/60 m/s impact tolerance of some of the manned parts is.... silly. 45m/s is ~90mph. I've personally never slammed into the ground at 90mph... but let me tell you... I don't want to... it sounds very painful.

Example: The Apollo command capsule was validated for a touchdown speed of 7m/s. During testing anything above ~12ms could cause potentially harmful/fatal damage to the craft (e.g. crushing the heat shield, rupturing propellant tanks) and the astronauts (massive g-force spike, potential for concussion or compression injuries). (Source: http://www.dtic.mil/dtic/tr/fulltext/u2/a455658.pdf).

So... I might consider raising it to 20m/s, but even that is quite a bit higher than it probably should be.

Anyhow, I think I will likely be working on IVAs this week. Gotta get started on them or they will never get finished. Will continue to slowly poke at some of the other stuff I'm working on, but the IVAs will be the main focus this week. Will hopefully at least have internal geometry finished for one of them (yes, will probably take me all week.... have I ever mentioned how slow and painful they are to work on?).

Edit:

Edited September 14, 2015 by Shadowmage

[davidy12]

LES EFFECTS!!! Thanks so much!!!

[Shadowmage]

LES EFFECTS!!! Thanks so much!!!

Aye

I was playing around with the SRB effects for another (new) part that I'm working on... and figured what the heck, lets try copying them into the BPC to see what they look like. And...well... it looks acceptable. Will play around with it a bit when I have time to see if I can get the smoke effects to lineup with the (angled) thrust effects...it seems they currently spawn from effect origin without the same angled velocity component that the flame effects have. Might not be much I can do about it, but will see what I can do about cleaning it up.

[Shadowmage]

For those wondering why IVAs are so slow to create:

It is because you run into (potentially unsolvable) problems such as these:

Note the terrible shading on the left. Note the proper shading on the right.

Because I am working on 'internal' geometry, the normal tools available to fix such problems don't work. As such I had to spend the entire last two days (something like 20 hours of modding time) to re-learn basic Python (because for some obtuse reason Blender.org decided to use Python as their plugin language), and write a custom blender script to fix the normals for a cylinder with extrusions.

What should have been a simple 'push the button' operation has turned into such a major affair... I'm not even sure I want to continue working on the IVAs after this. Seriously, in the time I lost fixing an issue that should never occur, I could have modeled several parts (at least one!), or gotten a texture mostly done. And I haven't even started on the actual geometry for the IVAs; all this was just to fix the @#$% shading problems for the main cylinder walls.

So... for now IVAs are on hold until I can find/create the tools to work on them without massive frustration (or until someone else offers to create them(IVAs or tools)). Because if I have to spend another two days dealing with python/blender scripting and fixing &^$#@*( shading and normals, I will be done modding and never look back; I enjoy creating things, but it is not worth the level of headache and frustration (and lost time!) that I have dealt with over the last couple of days.

[Shadowmage]

On a more positive note;

Mutli-docking port parts are a go.

Did some quick testing with a mockup geometry part with the requisite docking node transforms. With the stock ModuleDockingNode you can successfully dock and undock multiple craft to it the same part, it all comes down to having the transforms in the right place, with the right names. There is still a problem in telling which part to decouple/undock with the stock module, but I -think- I have a little bit of custom code that should clean it up quite a bit by labeling the undock/decouple node options in the context menu.

So, expect to see a couple multi-docking node parts in the semi-near future; will probably be 2-4 different parts, each with 5 docking nodes on them (and one non-docking attach node). The different parts will have different combinations of docking port sizes on them -- standard x5, standard x3 + large x2, large x5...(others..?) Will also be using these types of multi-docking ports on some of the upcoming Station Core parts -- such as a large storage torus with integrated docking ports, lights, and solar arrays.

Will investigate using mesh-switch on them to limit the editor part list additions, but not sure if I'll be able to pull it off cleanly on these (due to needing different settings for node positions and docking port sizes). Will also be investigating a 'docking port toggle' that would activate/deactivate the magnetics, etc; would basically function as the shielded docking port (without an animation) to hopefully reduce the CPU overhead caused by docking ports in general.

Still doing some thinking on the 'welding docking port'; I believe I should be able to pull it off, just need the time to sit down and tinker with it.

[wasml]

So... for now IVAs are on hold

Your doing this for yourself - do what you enjoy and leave the rest for someone that wants to do it. I appreciate your sharing this with us.

My 2 cents.

[riocrokite]

hey Shadowmage, I wonder how is work concerning multidockingport module?

I've accidentaly stumbled upon Habitat Pack by porkjet and his just using stock deployable docking port modules in his multidocking part. And it works However with all fps drop I mentioned earlier for deployable (shielded) docking port that activates with animation. Did additional tests and it seems that there is no slowdown when ports are manually opened or closed. However upon scene load there is a slowdown so one has to manually open/close docking ports (on both vehicles).

That's a good news since opened docking ports seem to not create performance issue as implied from previous tests (when they can be manually opened/closed). However issue remains for static multiple docking ports since they cannot be 'activated/deactivated' upon scene load.

test rig: 2 vehicles with 12 inflatable modules each. 1 inflatable module cointains 3 shielded docking ports:

FPS is the same (good) with all open and closed and 2 vehicles present. However on scene load FPS goes south (until I manually open / close them on each vehicle):

Edited September 16, 2015 by riocrokite

[Shadowmage]

hey Shadowmage, I wonder how is work concerning multidockingport module?

[...]

Have just re-started working on them. Will likely bash out a model for an initial concept part today along with doing a bit more work on the plugin that will drive it.

The main points that I'm curious about currently are the 'Control from Here' and 'Target Here' options; I'm wondering how nicely these will play with MJ/etc for autopilot control, and wether they work properly for targeting and control orientation -- did not get a chance to test them last night, so will be looking into that a bit today as well.

If all goes well, I might be able to get at least an untextured multi-docking port part for this weekends' release.

Excellent work on the research, has provided some interesting insight, and certainly saved me some time on that end of things. I'll be trying to incorporate a 'shielded'/unactivated mode into the multi-port parts, to hopefully cut down/eliminate the CPU hit for the docking node code.

Will post some preview/renders as things develop

[riocrokite]

Have just re-started working on them. Will likely bash out a model for an initial concept part today along with doing a bit more work on the plugin that will drive it.

The main points that I'm curious about currently are the 'Control from Here' and 'Target Here' options; I'm wondering how nicely these will play with MJ/etc for autopilot control, and wether they work properly for targeting and control orientation -- did not get a chance to test them last night, so will be looking into that a bit today as well.

If all goes well, I might be able to get at least an untextured multi-docking port part for this weekends' release.

Excellent work on the research, has provided some interesting insight, and certainly saved me some time on that end of things. I'll be trying to incorporate a 'shielded'/unactivated mode into the multi-port parts, to hopefully cut down/eliminate the CPU hit for the docking node code.

Will post some preview/renders as things develop

cool,

glad to hear that you made progress with multidocks and sorry for confusing question - haven't read your last post before posting mine:P

Concerning the code about activation / deactivation of docking ports - it would be cool if it could be implemented to all docking ports (later on) since all stock static docking ports have this 'illness' thus affecting performance :/

I've also tested 'adaptive docking node' mod by Cpt. Kipkard which uses plugin written by toadicus.Unfortunately this plugin works 'along' normal ModuleDockingNode and the slowdown problem persists. (although there was some weird improvement when I used docking ports from the mod without the needed plugin?!?)

[Shadowmage]

cool,

glad to hear that you made progress with multidocks and sorry for confusing question - haven't read your last post before posting mine:P

Concerning the code about activation / deactivation of docking ports - it would be cool if it could be implemented to all docking ports (later on) since all stock static docking ports have this 'illness' thus affecting performance :/

I've also tested 'adaptive docking node' mod by Cpt. Kipkard which uses plugin written by toadicus.Unfortunately this plugin works 'along' normal ModuleDockingNode and the slowdown problem persists. (although there was some weird improvement when I used docking ports from the mod without the needed plugin?!?)

Took a quick look at the exposed stock docking port code; I don't think there is anything I can do regarding toggling of 'searching' or 'enabled' state. All of the necessary variables/members are private (animation control, enabled/disabled state). All of the methods I would need to override are private (e.g. Unity FixedUpdate). I can't even hack my way around this one; there is no room for adaptation or alteration in that code.

About the closest I would be able to do is implement a dummy empty animation -- but you would still run afoul of the stock bug of needing to activate/deactivate whenever you reloaded the vessel. The next best thing I could do would be to completely re-implement it as a custom class.... I really don't want to (going to be days/weeks of coding), but at this point it is looking like I might just have to if I want to clean up the stock/vanilla problems. From what I can see it shouldn't be hard to do better than the stock code; it is a complete mess, and no wonder it performs as poorly as it does.

For now though, I will be using a slightly adapted stock docking port module that will include special handing for the naming on the right-click functions on a per-docking-node basis - e.g. it will list 'Decouple Front' or 'Decouple Port 1' instead of 'Decouple Node'. Will investigate the custom/re-implemented docking port code when I have time.

Todays previews:

- Concept development of the Lander Core Skycrane module(s)

More previews - Multi-Docking Port parts, concept development

Close up view of the 'standard' MDP

From left to right:

1. 2x 0.625m & 3x 1.25m

2. 5x 1.25m

3. 3x 1.25m & 2x 2.5m

4. 2x 1.25m & 3x 2.5m

5. 5x 2.5m

Might be a sixth that would be all 0.625m, but not really sure that it is needed; I would certainly never dock that many small craft to the same station

Edited September 16, 2015 by Shadowmage

[Shadowmage]

Preferences as to station structural truss type?

Left - Nertea / Near-Future style Octo-Truss

Right - Full Octagonal Truss

Other - Not Shown - Hexagonal Truss - ISS style

Any preferences? Should I aim to be compatible with the existing station trusses (e.g. NF Construction Octo-Truss), or go for something new?

And... any interest in the multi-docking ports that I posted a few days ago? If yes, I will see about getting some test pieces ready for this weekends release; if not then I will continue to refine them until they are ready for my games (I'm making them either way, its just a question of if others want to try them out now, or later).

Regarding the IVAs -- I have not yet completely given up on them; I'm currently trying to find the best seat positioning for the kerbals to allow a more downward view / better view for landing, but it is not very easy -- If I move the seat forward/up enough to view the ground acceptably, you lose all view of the instruments and lose the ability to look out/up from the window. Will see about posting some position-comparison screenshots this evening for some input on what looks best to others.

Edit --

And one more preview:

Semi-finalized geometry for LC2 and LC3 skycrane modules (they slide out on rails, and there is a door that rotates up and then slides inward); yes they are using a simple octagonal tank -- was going to be a mess trying to create actual small tanks to fill the space, and the tri-count is already high enough with just the engines. So... will be doing a ton of details in the normal map and texture. The space not occupied by the engine bays will be used as fuel capacity. They will also contain an ASAS module for direct torque/control. Strongly thinking about adding some static/non-deployable solar panels to the diagonal exterior sides (the ones not occupied by engines).

Thoughts? Should I have some small outward angle on the engines at full deployment (15-35 degree), or leave pointing straight downard?

Edited September 18, 2015 by Shadowmage

[riocrokite]

stuff new pieces

tbh all those new pieces looks awesome! IMHO it's good to have compatibility with other mods (octo-truss /NF). multidocking ports also look awesome to me:)

iva's positioning, what about one position for better view and second with instrumentation on the left right (so you have good up / down view and then can glimps on the instrumentation on the side). This is how I'm planning to implement it for my pod IVA's (distant future though).

multidocking bug - what about trying easiest route first? for example something like a custom function that is looking for parts with animated docking modules in all vessels on the scene upon scene load and then toggles on/off animation on those parts?

edit: don't worry about no responses, september is a busy time for most of us

edit3: octagonal deployable engines I love them all! I would rather point them straight down (to save dV). They shouldn't occlude landing legs, should they? If anything they could extend a bit further but for right now is also great! If anything I would make struts holding them a little bigger to account for forces between engines and body;)

edit2: multidocking bug, what about looking for all parts in all vessels that have both moduleDockingNode with deployAnimationController = 1 and then toggling their animation (toggle their ModuleAnimateGeneric) twice ? I think given the performance benefits players would have no trouble ditching stock docking ports (not shielded) and using new ones (yours and in other mods) that replace them with a dummy animation.

suggestions from KSP IRC:

1)

(dp.part.Modules.GetModule(dp.deployAnimationController) as ModuleAnimateGeneric).Toggle() maybe? (dp is the ModuleDockingNode)

2)

i feel like it could be as simple as GameObject.Find<dockingportname>.getcomponent<dockingportthing>.enable, wait for seconds, disable

Edited September 18, 2015 by riocrokite

[anxcon]

for that engine, toss on bahamuto animated engine module support

[Shadowmage]

tbh all those new pieces looks awesome! IMHO it's good to have compatibility with other mods (octo-truss /NF). multidocking ports also look awesome to me:)

iva's positioning, what about one position for better view and second with instrumentation on the left right (so you have good up / down view and then can glimps on the instrumentation on the side). This is how I'm planning to implement it for my pod IVA's (distant future though).

multidocking bug - what about trying easiest route first? for example something like a custom function that is looking for parts with animated docking modules in all vessels on the scene upon scene load and then toggles on/off animation on those parts?

edit: don't worry about no responses, september is a busy time for most of us

edit3: octagonal deployable engines I love them all! I would rather point them straight down (to save dV). They shouldn't occlude landing legs, should they? If anything they could extend a bit further but for right now is also great! If anything I would make struts holding them a little bigger to account for forces between engines and body:wink:

edit2: multidocking bug, what about looking for all parts in all vessels that have both moduleDockingNode with deployAnimationController = 1 and then toggling their animation (toggle their ModuleAnimateGeneric) twice ? I think given the performance benefits players would have no trouble ditching stock docking ports (not shielded) and using new ones (yours and in other mods) that replace them with a dummy animation.

suggestions from KSP IRC:

1)

(dp.part.Modules.GetModule(dp.deployAnimationController) as ModuleAnimateGeneric).Toggle() maybe? (dp is the ModuleDockingNode)

2)

i feel like it could be as simple as GameObject.Find<dockingportname>.getcomponent<dockingportthing>.enable, wait for seconds, disable

Trusses -- will do some further mockup of a NF-compatible Octo-Truss styled stuff. These trusses will form the exterior for -many- of my upcoming station parts (those that are not directly cylindrical, which will be mostly just the crewed parts).

IVAs -- I was kind of thinking that when looking at the IVAs -- the only place for instruments is on the left/right of the window, normal (e.g. widescreen) aspect-ratio screens do not have enough vertical view to normally see any instruments that were below. So.. will probably place the stuff necessary for landing on the vertical columns so you can still see them while looking out the window -- nav ball, altimeter, speed indicator

Deployable engine modules -- these are -intended- to be used for skycranes. As such, there will be no leg modules included. I will perhaps look into including other external options such as static solar panels and ladders (just in case someone wants to use them as the engine portion of a lander... which they are perfectly capable of doing). If used in conjunction with other lander fuel tanks, you could always use the leg-module from the other tanks.

Docking Port Performance -- interesting proposition. It -might- work; I'll have to poke at the code a bit to see where it polls for the animation status -- whether it is updated from an event or actively polled (event driven I might not be able to fix, polled I might be able to hack around a bit like you had suggested). If it works out I could probably even have my module add a dummy animation at runtime and would be able to MM patch my docking port module in place of the stock ones; Every docking port would end up with 'activate' and 'deactivate' right-click options. I should also be able to manually (through code) activate/deactivate the port whenever the scene is reloaded. Will really have to poke into the stock code a bit more to see if I can even figure out where the bug originates from.

I have validated that the multiple 'control from here' options in the docking ports -do- work properly if given distinct control transforms. Sadly, these transforms have different orientations than the docking node transforms, so I am having to add a second transform to my parts for that purpose, but it -looks- like it will work out well so far. Have not been able to test the 'Target X Port' functionality yet to see if you get a different target point per-port, but will hopefully be looking at that over this weekend (and from my experience with welding parts, it -should- work, as my welded parts were able to properly be targeted at just the port). I'm also thinking of adding some lights/emissive stuff to my docking ports to tell you if they are active or not; think red/green lights on the hub around the docking port, hopefully visible on-approach to the port.

for that engine, toss on bahamuto animated engine module support

A: I already have my own custom deployable/animated engine module that will be used.

B: Due to licensing I cannot bundle any external plugins with my work (ARR = incompatible with nearly every open source license). As such I must code my own plugins for... well... everything. Sad. Blame the copyright system. (I will be releasing full public (non-test) versions of my mod under GPL, but sadly that also is incompatible with the vast majority of other open-source licenses)

C: Maintaining dependencies for external plugins is -not- something I want to undertake. From my previous experience it will cause nothing but headaches in both the short and long term; moreso in the long-term concerning KSP version updates -- I have to wait for all dependencies to update before I can even -start- working on updating my stuff; often delaying my updates by weeks/months while I wait for everyone else to do their bit.

Anyhow, yes, they will have full animation support, and must be deployed before the engines can be activated (or rather any attempts to activate the engine while stowed will result in first deploying the engine before it is activated).

Will be working on cleaning up a few things tonight and tomorrow morning, and hopefully have an updated testing release sometime Saturday afternoon. Will have a couple of small bug fixes, adds engine effects to the LES/BPC, and several prototype new parts for testing (e.g. untextured, geometry might not be finished, but they should work well enough to validate the concept and begin balancing mass/thrust/fuel/etc)(SC-B-SRB, SC-B-CORE, ST-Multi-Docking-Port parts).

[anxcon]

you dont have to release other plugins with you, just support via a MM cfg

and why use ARR? i dont think ive seen a mod goto that extreme

[riocrokite]

stuff

Cool

Two more things: for that deployable engines: might be cool to add 4 deployable quite strong rcs boosters on side panels of octagon so you can move precisely in x-y directions while maintaining altitude with you main engines (you can have a look at space-y mod there are strong rcs thrusters blended with an engine)

Another idea - might be useful for your lander stuff; what about resources in tanks that can be switched on (off) upon staging? For example you have a fuel tank in the middle that you don't want to drain fuel from before you jettison an other tank. So player wouldn't need to manually switch off resources

So in other words:

From this state -> to this state: upon staging. Ideally EC would be excluded from staging or resources for staging could be selectable

Just an idea

[Shadowmage]

you dont have to release other plugins with you, just support via a MM cfg

and why use ARR? i dont think ive seen a mod goto that extreme

I use All Rights Reserved for my development and testing releases. Full public releases will be under a much more liberal license (L/GPL and/or CC, depending upon the specific asset and my final decision). As I have not yet reached the full public release stage (probably wont until KSP 1.1), it is all currently ARR. Public releases will be posted under a new thread, have a completely separate GitHub repository, and have their own licensing as noted above.

The reasoning behind this is to do as much as I can to stop people from trying to redistribute unfinished works. In the past I have had people lift my entire in-development project (I had not even posted anything regarding testing or releases yet), re-brand it as their own, and start overloading my issues tracker regarding stuff that was in active development and obviously not finished yet or even ready for distribution or testing. And there was not much I could do as I had licensed it under a CC license... which allows for such alteration and redistribution.

If it weren't for the few bad apples I would probably release my stuff under public domain; sadly, experience has taught me that if there is room for someone to abuse something, someone, somewhere, will abuse it.

[anxcon]

CC has multiple types, including no distro and no changing

[Gunslinger1]

Having a weird glitch with this mod where vehicles fly apart at the seams for no reason. haha

[Shadowmage]

Having a weird glitch with this mod where vehicles fly apart at the seams for no reason. haha

Have any more information regarding the problem? Anything in the KSP.log file? What specific parts/combinations of parts? Any other mods in use?

[anxcon]

playing with a few parts, such as this, and had a thought

SSTU - LC5-FL

when you switch mesh to be a hollow middle, what about add another toggle for the middle to be round vs octo

hile i like the octo for some parts matching, when using a round tank down the middle it seems weird

also perhaps depending on mesh used, only allow some nodes, move/disable others?

imo drop the middle node, and if hollow put top/bottom on same location, if not hollow, top/bottom

or accually, if you want to go fancy, if hollow use middle node, hide top/bottom, and apply a new blank node to the part it snaps to on placement

that would give the effect of attaching radial, and not weakening the stack, even though its technically added by stack

i was messing around with that for stock toroidal tank one day, kinda fun to mess with nodes

Edited September 19, 2015 by anxcon

[Gunslinger1]

Have any more information regarding the problem? Anything in the KSP.log file? What specific parts/combinations of parts? Any other mods in use?

Trying to track down what is causing it. Was going to run a flight with just the SSTU lander parts and see what happens.

- - - Updated - - -

Yeah for some reason every time I fly the lander above 6000 ft. every single part of the craft decides to lose structural integrity and fly apart as fast as possible.

[Shadowmage]

Trying to track down what is causing it. Was going to run a flight with just the SSTU lander parts and see what happens.

- - - Updated - - -

Yeah for some reason every time I fly the lander above 6000 ft. every single part of the craft decides to lose structural integrity and fly apart as fast as possible.

Anything out of ordinary in the log file? E.G. Exceptions or errors?

[Shadowmage]

Update beta/test release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.10-beta

Contains a few plugin fixes and several updates to textures and part configs.