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

[Shadowmage]

@RedParadize  Did a bit of investigation on the KIS-part volume issues (reading through source, asking questions on the KIS thread).  Apparently this is a limitation of KIS -- it does not allow for parts to have dynamic stored volume; it can only use a single value derived from the prefab parts geometry or prefab-parts override value; there is no way to override it on a per-part-instance basis (even with hacks/reflection).

So sadly, nothing that I can do about that problem; any solution will require changes to how KIS calculates the volume for parts.  In the mean-time I'm going to investigate ways to remove the capability to store modular parts in KIS containers, as without dynamic stored-volume calculation, the entire system is fairly broken.

You'll still be able to use the MFT tanks -as- KIS containers... you just won't be able to store them (or other modular parts) -in- other containers.

[rasta013]

3 hours ago, Shadowmage said:

In the mean-time I'm going to investigate ways to remove the capability to store modular parts in KIS containers, as without dynamic stored-volume calculation, the entire system is fairly broken.

You'll still be able to use the MFT tanks -as- KIS containers... you just won't be able to store them (or other modular parts) -in- other containers.

I think this is a very, very good idea.  Without doing so it leaves so many broken ways to exploit your beautiful system.

EDIT:

On a different note, a request if I may.  Would it be possible to setup the pods/landers to have the ability to disable the antenna?  I ask this because of a quirk of how KSP appears to handle antennas.  If a command pod or probe has an integrated antenna, no matter what you do, KSP always seems to favor this antenna over anything else you have installed.  This is problematic for those of us who use Antenna Range and run varieties of antennas to suit a craft's need.  As an example...

The last lander I built was destined for Minmus as a reusable craft to land, harvest and bring data back to the orbiting science lab.  The science lab has a high speed antenna that requires monster amount of EC to use but transmits at extremely high data rates under Antenna Range.  However, when the lander is docked to the station and a transmission is initiated of the researched science it bypasses the high gain antenna on the station and goes directly to the pod.  Now I've written AR configs for all the command pods for AR (still testing/balancing hence why I haven't sent them to you yet) but I've got them all setup as fairly short range, low-mid data rate antennas designed to link to either an orbiter, station or relay sat.  This works just fine so long as I'm not docked but once docked (see above). 

So, would it be possible to have the option, even if only in the editor to shut it off entirely for that craft, to have the antenna be disabled?

Edited June 2, 2016 by rasta013
Request added

[Sudragon]

7 hours ago, Shadowmage said:

 

 

Those images are a bit old, but are mostly still applicable.  A few new config options that they don't explain...

The most important things to get set properly are 'engineHeight', 'engineYOffset', 'engineScale', 'engineMountDiameter', 'engineSpacing', and the two toggles for the upper/lower mount options.  Okay,...so pretty much every line in the configs is important to get them properly setup.

Good examples of using others' engines can be seen in the SSTU-SC-ENG-NRV engines, as these use the stock LV-N model (at three different scaling factors, so you can see how easy it is to scale stuff (hint.. just change the scale value ).  Other examples exist from the rest of the SSTU engines, but some stuff is not applicable to them as they use specially setup/located models (e.g. the SSTU stuff doesn't need any vertical offset as the model is built intentionally for the plugin).  If you need explanations on any of those specific fields please let me know.

 

Truth be told, I'm trying to either build a patch or fiddle the .cfg of Cryo Rockets Volcano model engine. It meshes really well with SSTU and I wanted to cut a lot of fiddling around in the VAB to fit it properly. 

Are all the details necessary available in the .cfg?

[Shadowmage]

25 minutes ago, Sudragon said:

Truth be told, I'm trying to either build a patch or fiddle the .cfg of Cryo Rockets Volcano model engine. It meshes really well with SSTU and I wanted to cut a lot of fiddling around in the VAB to fit it properly. 

Are all the details necessary available in the .cfg?

Yes, all of the details are available in the existing configs in one form or another.

One of the most important points to note though, is that this -cannot- be done (easily) through just patches; the SSTUModularEngineCluster MUST be the first module in the part, BEFORE the engine module; there is no (easy/clean) way to do this with patches (you can delete -all- modules with the patch and re-add them in the order you need; but might as well make a separate part config at that point).

However, the SSTUModularEngineCluster config for that part should be setup such as:  (may not be completely correct, derived all of these stats from the part.cfg file rather than the actual model)

MODULE
{
	name = SSTUModularEngineCluster
	engineModelName = CryoEngines/Parts/Engine/cryoengine-125/cryoengine-125-1
	currentEngineLayoutName = Single
	engineSpacing = 1.25
	engineHeight = 1.5039796
	engineYOffset = -0.9656104
	engineScale = 1
	partTopY = 0.5
	smokeTransformName = SmokeTransform
	smokeTransformOffset = -1
	diameterIncrement = 0.625
	engineMountDiameter = 1.25
	upperStageMounts = true
	lowerStageMounts = true
}

 

2 hours ago, rasta013 said:

I think this is a very, very good idea.  Without doing so it leaves so many broken ways to exploit your beautiful system.

EDIT:

On a different note, a request if I may.  Would it be possible to setup the pods/landers to have the ability to disable the antenna?  I ask this because of a quirk of how KSP appears to handle antennas.  If a command pod or probe has an integrated antenna, no matter what you do, KSP always seems to favor this antenna over anything else you have installed.  This is problematic for those of us who use Antenna Range and run varieties of antennas to suit a craft's need.  As an example...

The last lander I built was destined for Minmus as a reusable craft to land, harvest and bring data back to the orbiting science lab.  The science lab has a high speed antenna that requires monster amount of EC to use but transmits at extremely high data rates under Antenna Range.  However, when the lander is docked to the station and a transmission is initiated of the researched science it bypasses the high gain antenna on the station and goes directly to the pod.  Now I've written AR configs for all the command pods for AR (still testing/balancing hence why I haven't sent them to you yet) but I've got them all setup as fairly short range, low-mid data rate antennas designed to link to either an orbiter, station or relay sat.  This works just fine so long as I'm not docked but once docked (see above). 

So, would it be possible to have the option, even if only in the editor to shut it off entirely for that craft, to have the antenna be disabled?

Sadly, no, this is not doable.  The antennas require a PartModule, and stock does not allow for run-time modification of the PartModules on a part;  the only option to disable them is to remove the MODULE entirely from the config file (through manual editing or patching).

[ComatoseJedi]

@Shadowmage That would be pure genius if we could use Nertea's Nuclear Engines on your engine plugin code. Probably would save you from making your own, but we all know you'll make your own one day  

 

[Sudragon]

I didn't think a patch would do it, the clustertech is fairly deep tricky stuff.I think there's scope here for a full set of reworked replacement config files, for both cryo and atomic engines, and I'm thinking of taking a swing at it, if it doesn't make my head explode in the process.

Edited June 3, 2016 by Sudragon

[Shadowmage]

1 hour ago, ComatoseJedi said:

@Shadowmage That would be pure genius if we could use Nertea's Nuclear Engines on your engine plugin code. Probably would save you from making your own, but we all know you'll make your own one day  

 

Indeed it is possible; most of my part-modules can use models (.mu files) from any source, be it stock, SSTU, or other mods.  Some take a bit more work to setup than others, and may not be compatible with -all- models from other mods, but should work in the majority of cases.  For example the MFT I posted a few days back that used the Near-Future/Cryo Tanks models (or the one using stock models).  Wasn't too hard to set up/didn't take too long (granted I'm very familiar with the code and setup), and they will be functionally equivalent to the SSTU modeled parts.

Making custom config sets for many Near-Future and USI parts (mostly containers) has been on my personal to-do list for quite awhile as I would/will be using them next time I start up a career game.  Sadly as I still cannot actually play due to bugs/issues in stock (orbit instabilities/phantom forces, lack of reliable wheels and landing legs) it has not been too high of a priority.

 

42 minutes ago, Sudragon said:

I didn't think a patch would do it, the clustertech is fairly deep tricky stuff.I think there's scope here for a full set of reworked replacement config files, for both cryo and atomic engines, and I'm thinking of taking a swing at it, if it doesn't make my head explode in the process.

It can still be done through patch, but its not the simplest of affairs.  The engine-cluster module doesn't actually need to be first in the config file, it just needs to come before any engine, gimbal, emissive, or animation modules... which happens to be all of the modules in most engine parts.  So you can delete those modules, insert the engine-cluster module, and then re-add the deleted modules (by re-defining them as new modules).  This lets you keep the mass, cost, description, etc, and you don't need to delete the original part, but the patch file is a bit ugly, and its hard to say if it would be stable when other patches come into play.

Writing it as a separate config file is probably going to be the cleanest and most compatible way though.  This ensures that regardless of what patches are run, in whatever order, that the engine-cluster module will always be first in the part.  You can then use ModuleManager to delete/remove/not-load the original part config to avoid duplicate parts.  The one bit I haven't figured out is how to make defining a new part dependent on a mods presence (e.g. a NEEDS[XXX] block on a base part config file, using module-manager).  It is supposed to work, but didn't last I tried.  I'll toy around with this a bit if I can figure it out.

If you do come up with some sets of patches that you don't mind sharing, I have no problem including them in the mod in one form or another.  If you run across any specific problems you can't figure out, feel free to poke me for some answers.

 

[ComatoseJedi]

1 hour ago, Shadowmage said:

Sadly as I still cannot actually play due to bugs/issues in stock (orbit instabilities/phantom forces, lack of reliable wheels and landing legs) it has not been too high of a priority.

Yeah, i totally understand that. I've been playing and I guess I haven't seen much of that insofar as orbit instabilities, but I've seen some phantom forces (ghosties be plaguing the gaming engine, me thinks). As with everything that changes, it will -hopefully- iron out. Wheels, be as they may work, if they set up properly, but are still buggy. As far as landing legs, i've been using stock for that and they seem to be better, even though the footpads still sink into the ground. With the supposed 1.1.3 looming around the corner, I hope they squash the majority of these things, including the orbit instability. I know the wheel issue is being sorted out by "third parties"  

[Jimbodiah]

The Kraken is acting up again as well, can't build anything large or it will just shake apart.

[_waynepainter_]

Amazing mod!! Ok so i know the mod author does not have any craft files but does anyone in the community have some?

[ComatoseJedi]

2 hours ago, _waynepainter_ said:

Amazing mod!! Ok so i know the mod author does not have any craft files but does anyone in the community have some?

There are no craft files for the 1.1+ version of the game, but there's craft files for 1.0.5. The reasoning behind this is the fact that this is still a mod under development and the last -stable- version is the one with no more development. I would imagine when there's a more stable version of the 1.1+ development to an official release, then craft files will probably be made. There's still more parts to be made, bugs to be squashed and the re-introduction of the shuttle series, when the wheel issues get ironed out. If you need help in making craft with the current build, I'm sure there's someone with craft files that could help you with that. 

[SpaceBadger007]

I found a wee bug, in career mode whenever i have an sstu part, the terrior engine shroud dissapears, when the sstu parts are gone the shroud stays, ill do some more research tomorrow to find out if its just one part. Plus im a noob so i have no idea how to get screenshots from steam to here (if someone could point me in the right deriction i'd really appreciate that!) And same thing with the loooooooogs!

Edited June 5, 2016 by SpaceBadger007

[Jimbodiah]

Re zero boil-off tanks: Once in orbit and out of focus, the tanks drain all the Ec and all the LH2 boils off despite there being enough panels and batteries that it does not go empty when in focus.

[JoseEduardo]

5 hours ago, SpaceBadger007 said:

I found a wee bug, in career mode whenever i have an sstu part, the terrior engine shroud dissapears, when the sstu parts are gone the shroud stays, ill do some more research tomorrow to find out if its just one part. Plus im a noob so i have no idea how to get screenshots from steam to here (if someone could point me in the right deriction i'd really appreciate that!) And same thing with the loooooooogs!

on the steam screenshot window there should be an button to open the screenshots in disk

alternatively you could press F1 and get them from the KSP/Screenshots folder (far easier to find than the steam ones)

[Shadowmage]

7 hours ago, Jimbodiah said:

Re zero boil-off tanks: Once in orbit and out of focus, the tanks drain all the Ec and all the LH2 boils off despite there being enough panels and batteries that it does not go empty when in focus.

Hmmm...  thanks for letting me know

This is a bit of a difficult issue to solve appropriately for all situations, due to the nature of out-of-focus vessel updates (or lack of).  Most stock modules ignore them, at least the stock solar-panel module (not sure on fuel-cell or rtg).  The boiloff module plays 'catch-up' as soon as the vessel is re-focused by simulating the un-focused time; resulting in (ideally) the proper amount of boiloff/remaining resource after re-focusing the craft.  However what is happening is the boiloff module is doing its catch-up routine, but no additional power is being generated by the panels... it quickly runs out of power after the initial battery capacity is used up, and full-boiloff is processed for the remaining time-delta.  Unless/until stock has a system in place for out-of-focus vessel updates (or re-focus simulation probably), there cannot be any 'proper' solution.  The basic options are to either:

# 1 - Process it as it currently is.  Will always have the problem you are encountering.  This results in only effectively 1 vessel being able to use ZBO tanks, and it must remain focused at all times.  Probably not the best solution given the stock limitations.

# 2 - Ignore it out-of focus vessels. Can be abused by un-focusing for most of its journey. No-focus = no-boiloff; probably the least intrusive, but least correct method.

# 3 - Boiloff module keeps track of if it had 'enough' power generation while in focus (total EC was stable or increasing between ticks when last focused), and uses that value during the catch-up simulation.  Will notably be inaccurate for craft who's power output decreases over time (decaying rtgs, lower solar panel output from time/distance), and would mostly be ignoring solar-panel orientation/occlusion.

I'll give it a bit more thought and see if I can come up with any more optimal solutions; #3 will probably be the best compromise, and what I'll likely change the code to.  Not perfectly accurate, but better than all your fuel vanishing when at least most of it should be left.

 

 

[Jimbodiah]

Realism doesn't really factor in here as the system (KSP's out-of-focus handling) is broken to start with. I will disable boiloff for now, as LH2 is only usable for lifting at the moment.

[GoldForest]

I found a possible bug, but I need someone to duplicate it for me so I can confirm it.
The bug is that the plumes appear on The SSTUL engines when you have contares installed.
The RCS on the orion also starts firing by itself.

[Shadowmage]

18 hours ago, Jimbodiah said:

Realism doesn't really factor in here as the system (KSP's out-of-focus handling) is broken to start with. I will disable boiloff for now, as LH2 is only usable for lifting at the moment.

Yah, probably the best course for now;  I should have this cleaned up in one form or another for the next release/update (sometime this week/end).  Sadly I was not thinking about stocks improper out-of-focus handling when designing the system =\

[Jimbodiah]

NP mage, a lot has changed with 1.x, I just mentioned it so you'd know.

[Shadowmage]

Had to take a bit of break from wheel physics; have a few problems that I'm 'stuck' on, so letting my mind do the subconscious-processing thing.  In the mean-time...

Thought of a way to allow the Modular Cargo Bay (MCB) parts use the existing MFT (fuel tanks) module (well, a derived/child class with slight modifications); so with minimal effort in the coding department, I'm hopeful I'll have a working MCP prototype part for the next update/release.  This means the MCB's will be able to come with the existing set of mounts/adapters, as well as a few new/custom cargo-bay oriented adapters.  Some of the MCB parts will even have included fuel capacity (saddle truss/skeletal variants could have fuel in the end-caps if they are used).

Shown is the 'saddle-truss' variant (all 8 main models, ranging from ~2.9h x 5.0diam, to ~20.4h x 5.0diam, height increment of 1/2 diameter, same as MFT tanks), which will be the first one available as far as prototype parts.  These will come with an optional fairing surrounding them for use during ascent (can be toggled in the editor; all the usual fairing options apply for textures, diameter set through MCB module).  Will have internal front, back, and dorsal attach nodes (as well as the standard external top/bottom nodes); the proper way to attach drop-tanks for these saddle-trusses would be using surface attach against the internal dorsal node with a decoupler (may come with integrated decoupler for dorsal node... undecided).

More MCB parts will be available in the future with different models, including fully enclosed cargo bays (circular), with various options for door mechanics (folding, rotating, hinged).  Also planning on having a couple of extensible/deploy-able cargo ramp setups that can be used for end-caps/adapters.  Haven't quite worked out how the dynamic-animation stuff is going to work out....but I'm sure I'll figure it out (my current animation handling module is pretty generic, robust, and configurable; will require minor modifications at most).

 

 

Edit: Basic reference image for saddle trusses; you've probably all seen this one before...  (just realized I'm missing the secondary cross-braces...but no problem to add those in...)

Edited June 6, 2016 by Shadowmage

[Nightside]

6 hours ago, Shadowmage said:

Yah, probably the best course for now;  I should have this cleaned up in one form or another for the next release/update (sometime this week/end).  Sadly I was not thinking about stocks improper out-of-focus handling when designing the system =\

I don't claim to know much about the details, but people may have already figured some of this out in other threads, it seems like Kerbalism has got the out of focus electricity usage figured out, so it should be doable.

Looking forward to building with those trusses!

[Jimbodiah]

Re Ares tanks:  We needz gold foilz!

[Shadowmage]

17 hours ago, Nightside said:

I don't claim to know much about the details, but people may have already figured some of this out in other threads, it seems like Kerbalism has got the out of focus electricity usage figured out, so it should be doable.

Looking forward to building with those trusses!

I took a look over Kerbalism, and the author does some pretty dirty stuff in order to achieve those effects.  Basically the mod manually simulates the stock (and ONLY stock) solar panels in the background while the vessel is unfocused, and simulates the EC state changes due to life-support/recyclers/etc, manually updating the vessel/proto-vessel state; ignoring all other sources of EC input or consumption.

Which is -way- more effort than I'm willing to go through for this, not to mention less than optimal from a performance standpoint (especially if every mod is doing its own simulations), nor is it a 'complete' implementation as it ignores generators aside stock energy sources, and ignores consumers aside from Kerbalism.  This is where there needs to be a stock system in place for out-of-focus vessel updates; something a mod can subscribe to (or preferably at the part-module level) to process these out-of focus updates properly, with every module being able to do its generation/consumption updates properly.  The stock system need not run on every 'tick', but could process things in larger discrete chunks to cut down on the overhead of all of those updates (e.g. simulate minutes, hours, etc rather than physics-frame updates).

 

However, I have 'fixed' the boiloff code to no longer just drain the EC and then process full boiloff.  It will now track the effective percent (average over the last few ticks) from before the vessel is unfocused, and use that value upon vessel re-focus; simulating all elapsed out-of-focus time with that cached 'effective percent'.  What this means is that as long as you had EC when the vessel was un-focused, it'll process as if it had EC the entire time;  if the battery was empty and the EC generation was only supplying part of what was needed for boil-off prevention, that partial value will be used to simulate for the elapsed un-focused time.  Still a bit abusable, but at least it won't make all your fuel disappear when it shouldn't (though it may leave you with more than you should have had left... but that is a smaller problem from a gameplay/enjoyability/expectations perspective).

[Adrianstu98]

Hi, i am having a problem with the launch abort system of the Orión craft. It desapear at 8000 m of altitude.

Edited June 7, 2016 by Adrianstu98

[Shadowmage]

2 hours ago, Adrianstu98 said:

Hi, i am having a problem with the launch abort system of the Orión craft. It desapear at 8000 m of altitude.

Going to need logs to figure out what is going on:

95% chance that it is caused by another mod (my plugin doesn't do anything regarding altitude except for parachute enabled parts).