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

[Sudragon]

Re: iniflatabes

Will there be a selection of skin colours/textures like the fuel tanks? (I'm holding out for pink with purple polka dots).

[Domfluff]

More habitat pictures. MPLM and "ISS lab" are intended to be USOS-derived hab parts, MMSEV is the pressurised rover/lander/exploration vehicle multipurpose concept - I'm not sure how this is supposed to be docked here. Radiators, solar panels and a cryogenic transit stage.

[Shadowmage]

19 hours ago, Sudragon said:

Re: iniflatabes

Will there be a selection of skin colours/textures like the fuel tanks? (I'm holding out for pink with purple polka dots).

Yes; at least two textures for most/all of the parts.  DOS parts will have gray/white/brown/green, COS will have a few textures for the differences between USOS module styles, inflatables... not really sure on those yet.  Though I'm partial to phychedelic tye-die myself

 

14 hours ago, Domfluff said:

More habitat pictures. MPLM and "ISS lab" are intended to be USOS-derived hab parts, MMSEV is the pressurised rover/lander/exploration vehicle multipurpose concept - I'm not sure how this is supposed to be docked here. Radiators, solar panels and a cryogenic transit stage.

Interesting...  that design should be fairly doable with the current planned layout of parts; the only thing missing is the MMSEV (which would be part of LanderCore if I made it).

Edited July 30, 2016 by Shadowmage

[ComatoseJedi]

Since you asked about the functionality of the inflatables, a nice suggestion is to put the fuel switching plugin you made to put on some of these. The torus ones, are strictly habitat. I'd say the smaller ones (especially that cute, little one) could be used to store stuff for stations/craft. I wouldn't go as far as putting ore in them, but fuel would suffice. Maybe have them store life support? I'm not sure how you could switch out from a habitat to a storage tank, but these are just ideas. I've seen where the Nautilus X has several of these inflatable types on there for either hab space, storage or even laboratory work. 

Not going to go into texturing a lot, since that step isn't prevalent at this point and time. But, I'd say keep them white-ish. To make them separate from the rest to not make them look like they've been constructed in a kerbin sewing sweat shop, I'd say add segmented seams, especially on the torus ones. Because, I'm sure they will not be one piece of material, if you applied it to a real life material construction concept. Not really sure on how hard that'll be to accomplish on a model, but it's a thought. But, definitely for the fuel switching, a mylar/gold texture would be a nice touch. 

Like I said, these are just things to ponder and I am not requesting anything. If you like any of these ideas, Scooby snacks will suffice  

[-MadMan-]

Spam in log...

[EXC 13:05:49.240] NullReferenceException: Object reference not set to an instance of an object
	SSTUTools.SSTUAnimateEngineHeat.updateHeat ()
	SSTUTools.SSTUAnimateEngineHeat.FixedUpdate ()

 

[Gerbwerz]

6 hours ago, -MadMan- said:

Spam in log...

[EXC 13:05:49.240] NullReferenceException: Object reference not set to an instance of an object
	SSTUTools.SSTUAnimateEngineHeat.updateHeat ()
	SSTUTools.SSTUAnimateEngineHeat.FixedUpdate ()

 

I am seeing tons of this span with Exception Detector mod installed (100s of throws per second for updateHeat) plus the SC-C SM keeps decoupling spontaneously when I switch scenes and return to it. I thought it was due to Throttle Controlled Avionics mod, but I tried it in a fresh KSP install and it seems to happen regardless of if TCA installed or not after some period of time. I then thought it was something to do with the SC-C CM setting of SM DC Staging setting, but even that doesn't seem to make a difference. I don't see anything in the logs expect SSTU spams about Animate Heat. In addition the SM engine will automatically activate on the pad before launch. That one does seem to be related to having TCA installed. Happy to help debug if needed.

btw, thank you for such a great and detailed mod! Awesome work.

Edited July 31, 2016 by Gerbwerz
added thanks.

[Shadowmage]

6 hours ago, -MadMan- said:

Spam in log...

[EXC 13:05:49.240] NullReferenceException: Object reference not set to an instance of an object
	SSTUTools.SSTUAnimateEngineHeat.updateHeat ()
	SSTUTools.SSTUAnimateEngineHeat.FixedUpdate ()

 

Thanks for the report;  what part(s) are causing this error, and what other mods are you using?   I have not seen it pop up during any of my testing, so chances are there is an external patch or another mod that is messing with one of the parts (or the part is just not setup properly to begin with).

 

Spent a good chunk of yesterdays development time re-re-examining the possibilities of adding some basic ModuleSwitching, thanks to some prodding and motivation from @blowfish.

I'm glad to report that in this specialized case it appears that it will work out.  So now most of the StationCore parts can have optional and swappable docking ports.  There were a few caveats that I had to work around a bit, as the stock code still really doesn't like some aspects of it, and I'm not fully confident that it will be without errors; but so far it has been working.  If this initial use works out I might be able to add other similar uses to other parts/modules in the future.

This means that the modular station parts will have 5 components/modules; top dock, top, core, bottom, bottom dock.  Sadly I was not able to add docking ports for the sides of the hub-top caps, so the integrated hubs have 1 port (optional) + 4 blank attach nodes... which is still better than no ports

DOS/COS/HAB modules will all have the optional docking ports, potentially the MST (modular solar truss) as well, though they are less needed for those as they would likely use the welding docking ports.  With this added functionality the COS/DOS modules are pretty much exactly as I had intended them from the beginning, and the DOS modules should even work well as single-part-spacecraft (as they have engines, rcs, solar, fuel, hab, and now docking ports).

 

Currently doing a bit more cleanup on the docking port module-switching (ensuring module order is maintained across scenes), and then will be doing a quick balance pass on the rest of the parts to make sure they are at least close to where they should be.  Few other things on the issues list that I'll be taking a look at, and then will be packing up the release shortly after that and hopefully have it available later this afternoon.

 

Also a quick heads-up that I'll be out of town for part of next week and week-end for another camping trip.  I'll try for an updated testing release on Wed. from the feedback between now and then, but if that doesn't happen for whatever reason it'll have to wait until I return (sun/mon).

2 minutes ago, Gerbwerz said:

I am seeing tons of this span with Exception Detector mod installed (100s of throws per second for updateHeat) plus the SC-C SM keeps decoupling spontaneously when I switch scenes and return to it. I thought it was due to Throttle Controlled Avionics mod, but I tried it in a fresh KSP install and it seems to happen regardless of if TCA installed or not after some period of time. I then thought it was something to do with the SC-C CM setting of SM DC Staging setting, but even that doesn't seem to make a difference. I don't see anything in the logs expect SSTU spams about Animate Heat. In addition the SM engine will automatically activate on the pad before launch. That one does seem to be related to having TCA installed. 

Well, I can tell you that the problem is -not- with the SC-C-SM, so the problem must lie in another mod / set of patches.  The auto-decoupling and auto-activating of the engine is -definitely- caused by another mod that has some improper code in it.

(screenshots of it working just fine, with log open with no errors)

 

If you do happen to track down what mod is causing the problem please let me know and I'll do a bit of investigation.  Nothing I can do at this point though without knowing precisely which mod(s) are at fault.

[-MadMan-]

36 minutes ago, Shadowmage said:

Thanks for the report;  what part(s) are causing this error, and what other mods are you using? 

 AJ10 Series(Early)...

RSS+RO+RP-0+SSTU+SSTU Nova+Soviet Engine 

 

 

[Shadowmage]

13 minutes ago, -MadMan- said:

 AJ10 Series(Early)...

RSS+RO+RP-0+SSTU+SSTU Nova+Soviet Engine 

 

 

Thanks for the quick reply

I don't personally use or offer support for RO installs, and have no way to do any testing with it.  But, I'll ask around a bit, probably bug @JoseEduardo to see if he has seen any similar problems?  I doubt the problem is with Jose's Nova pack, but he has more experience with the rest of the RO patches and setup than I do, so may have more information about it.

So... will do some investigation, but it does not appear that the problem is with SSTU, but rather with another mods patches (which will need to be fixed on their end after we figure out what mod/patch is causing it).  Might take a bit to get this one cleared up due to the external nature of the problem (if it was with the base SSTU code/parts I could have it fixed today). 

In the mean-time you can remove/patch out the SSTUAnimateEngineHeat module from those parts; it'll stop the null-ref spam, but you'll lose emissive animations (which probably aren't working anyway with the null-refs).

 

[Gerbwerz]

1 hour ago, Shadowmage said:

T

Well, I can tell you that the problem is -not- with the SC-C-SM, so the problem must lie in another mod / set of patches.  The auto-decoupling and auto-activating of the engine is -definitely- caused by another mod that has some improper code in it.

(screenshots of it working just fine, with log open with no errors)

 

If you do happen to track down what mod is causing the problem please let me know and I'll do a bit of investigation.  Nothing I can do at this point though without knowing precisely which mod(s) are at fault.

Yes its definitely a mod. TCA seems to be the culprit for the pad staging problem. For the SM spontaneous disconnect I'll try and narrow it down. 

What is SM DC staging for? It doesn't seem to make a difference in the stack.

[Shadowmage]

3 minutes ago, Gerbwerz said:

Yes its definitely a mod. TCA seems to be the culprit for the pad staging problem. For the SM spontaneous disconnect I'll try and narrow it down. 

What is SM DC staging for? It doesn't seem to make a difference in the stack.

 

SM DC Staging should be an option on the command-module; it toggles the space-bar staging for the command modules lower decoupler for its service module node.  Note though that there are two lower nodes on most of the command pods and the decoupler affects the upper of the two nodes (the lower node is intended to be used with other decouplers / other parts).  But, due to a stock bug with staging icon management, toggling that option does not change the staging GUI; so it'll never look like it is working, even though it is properly toggling the staging.

[JoseEduardo]

thanks for finding the culprit of the pad SM decoupling, I was experiencing it aswell and I also have TCA 

as for the AJ-10, possibly RO but IDK for sure because I'm not using RO right now... could you try testing it without RO?

[Gerbwerz]

2 hours ago, Shadowmage said:

 

SM DC Staging should be an option on the command-module; it toggles the space-bar staging for the command modules lower decoupler for its service module node.  Note though that there are two lower nodes on most of the command pods and the decoupler affects the upper of the two nodes (the lower node is intended to be used with other decouplers / other parts).  But, due to a stock bug with staging icon management, toggling that option does not change the staging GUI; so it'll never look like it is working, even though it is properly toggling the staging.

Ok so ran some tests on the SM engine activation on the pad with a fresh KSP install.

Here is my mod list:

http://imgur.com/VIUUl4x

 

As soon as I add TCA (and its 000_AT_Utils) to the game and put the rocket on the pad it activates the engine on the SM. Ill try to pull some parts off my rocket to get the mod list smaller as I am using one part each from SpaceY and Kerbalism on the lander in the stack. All the chutes on it are for Stage Recovery which I am not using in this test.

http://imgur.com/a/dDn1r

Also there are no exceptions being thrown by SSTU with this mod list. So there is another mod that must be causing those (updateHeat).

Edited July 31, 2016 by Gerbwerz
updated

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.32.120

This release consists mostly of prototype station parts, though there are a few other minor fixes/changes in place too.  Please see the link for the full change-log and downloads.  Also please note the 'known issues' section at the bottom of the change log.  Github, Curse, and AVC have all been updated for this version.

I'll work on putting up a list of things to test / what I'm looking for feedback on for this release, should hopefully have it up later today but might not be until tomorrow morning.

 

[JoseEduardo]

Quote

• NEW PART - SC-GEN-PPC - Procedural Probe Core - Uses model and textures from procedural decoupler, but instead of decoupling things, it is now intelligent and can now form the basis for Skynet.

LOL

[ComatoseJedi]

1 hour ago, JoseEduardo said:

Quote

• NEW PART - SC-GEN-PPC - Procedural Probe Core - Uses model and textures from procedural decoupler, but instead of decoupling things, it is now intelligent and can now form the basis for Skynet.

LOL

Yeah, we're going to have to initialize it

HELLO, DOCTOR, NAME, CONTINUE, YESTERDAY, TOMORROW (if you don't get it, there's nothing I can do for you  )

[Domfluff]

Brief thoughts on the DOS modules, and USI-LS. Obviously actual figures here are meaningless until the parts are finalised/balanced, but still worth thinking about.

ST-DOS-LAB (lab)
ST-DOS-STR (storage)
ST-DOS-TKS

These are probably fine without additional USI-LS configs, since the seating will do the trick.

ST-DOS-COM (station core), HAB and FEM would need some thought. COM and HAB will want some bonus to Kerbalmonths, and FEM will provide a multiplier. In Roverdude's notes, these should be derived from the mass. Since much of the point of SSTU is combining parts, it wouldn't be appropriate (or balanced) for the multiplier to be equal to the mass of the entire module - instead this should have a multiplier based on whatever the "payload" mass should be of the module. Probably not more than ton or two for the multiplier (exercise equipment, etc.), but the KM's can be the total mass of the module, more or less.

Aside from fiddling with the exact numbers, I think that all works in a fairly sensible fashion.

In terms of required space for supplies - a Kerbal eats 16.2 supplies a day, so a 90 day mission consumes 1458 supplies, which means that a two person crew noms through about 3000, or about 3 tons. Since that's more-or-less within Progress capabilities, that makes sense to me as a baseline.

I'd be tempted to not include any recyclers in the DOS parts at all (and certainly no processors), but that's also worth thinking about.

*

ST-HAB-A through D are relatively simple to sort, since they'll provide a bonus to Kerbalmonths relative to their mass (whatever their mass ends up being).

The ST-COS-xxx modules are a little harder to grok right now, since they are currently a lot more generic than the DOS modules, and don't easily split into multipliers/non-multipliers. You can make a really good argument that the rotating torus parts (ST-HAB-E through H) will grant multiplicative bonuses, but again deciding how much they should have is awkward here.

[Domfluff]

One option for the ST-COS modules might be to treat them as generic, multipurpose modules - they do a little of everything, and therefore supply a small amount of multiplier, additional kerbalmonths and recycling. This would mean that individually they wouldn't be anything special, but if you strapped enough of them together they would sum to something significant.

[Gerbwerz]

4 hours ago, Gerbwerz said:

Ok so ran some tests on the SM engine activation on the pad with a fresh KSP install.

Here is my mod list:

http://imgur.com/VIUUl4x

 

As soon as I add TCA (and its 000_AT_Utils) to the game and put the rocket on the pad it activates the engine on the SM. Ill try to pull some parts off my rocket to get the mod list smaller as I am using one part each from SpaceY and Kerbalism on the lander in the stack. All the chutes on it are for Stage Recovery which I am not using in this test.

http://imgur.com/a/dDn1r

Also there are no exceptions being thrown by SSTU with this mod list. So there is another mod that must be causing those (updateHeat).

Got rid of Space Y and Kerbalism. Same issue with Throttle Controlled Avionics mod installed. SM engine auto starts on pad if TCA is installed. Works fine if its not.

Here is the logs and craft file from the latest run:

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/SSTU CMSM.craft

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/output_log.txt

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/KSP.log

Mod List:

http://imgur.com/TXriLIc

The spontaneous SM decouple does not seem to happen even with TCA installed. Ill see if I can narrow that one down to another mod.

Edited August 1, 2016 by Gerbwerz

[blowfish]

Small suggestion on the centrifuges: add a counter-rotating flywheel.  It adds a second simple but visually interesting moving part and makes it plausible that the centrifuge could start spinning without spinning up the whole ship, or introduce weird torques when you try to rotate the ship while the centrifuge is running

[Gerbwerz]

2 hours ago, Gerbwerz said:

Got rid of Space Y and Kerbalism. Same issue with Throttle Controlled Avionics mod installed. SM engine auto starts on pad if TCA is installed. Works fine if its not.

Here is the logs and craft file from the latest run:

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/SSTU CMSM.craft

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/output_log.txt

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/KSP.log

Mod List:

http://imgur.com/TXriLIc

The spontaneous SM decouple does not seem to happen even with TCA installed. Ill see if I can narrow that one down to another mod.

The culprit for all the log spam appears to be a mod called Atmosphere Autopilot. If I add it to the above mods list SSTUTools starts throwing hundreds of exceptions per second on my ship about update heat. Still looking for what causes the automatic SM decouple.

SSTUTools.SSTUAnimateEngineHeat.updateHeat

[Jimbodiah]

Very cool stuff, Mage! 

[StickyScissors]

Really loving the station parts so far, even if they are textureless and lack some functionality as of now. VERY much potential these have. Frames: very good, NullRef's: nowhere to be seen. Both of those were -not- the case when building previous stations that crashed together 10+ separate mods.

Some quick 3AM testing has seen no errors, and has produced some sweet cinematic screenshots

Also, is it possible to remove the outer fuel line running down the side of fuel tanks? it seems particularly out of place on the side of structural-only tanks

Edited August 1, 2016 by StickyScissors
i is do words good when sleep not

[tater]

I did some quick testing with the large torus with a multi-port COS module (the larger one) on the end. Targeting was only possible on the white port (that one was on the axis of the station), the other colors would select, then immediately say "No Target." I was also unable to dock at all with any of the ports. The only mods I have on this test installation are KJR and hyperedit (so I can throw stuff into orbit fast for testing). 

Regarding life support, the torus parts should have a huge multiplier. I have always disagreed with roverdude using mass for that one multiplier, it should be volume related. Regardless, the large torus should have a habitability multiplier high enough that pretty much only supplies limit anything. Gravity is a huge LS multiplier from all current data we have.

[Shadowmage]

13 hours ago, Gerbwerz said:

Got rid of Space Y and Kerbalism. Same issue with Throttle Controlled Avionics mod installed. SM engine auto starts on pad if TCA is installed. Works fine if its not.

Here is the logs and craft file from the latest run:

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/SSTU CMSM.craft

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/output_log.txt

https://dl.dropboxusercontent.com/u/6187623/SSTU Issues/KSP.log

Mod List:

http://imgur.com/TXriLIc

The spontaneous SM decouple does not seem to happen even with TCA installed. Ill see if I can narrow that one down to another mod.

Thanks for the investigation on these problems.

I'm going to open up an issue ticket regarding the TCA incompatibility, just so it is on the known issues list and does not get forgotten about.  I likely won't have time to do much investigation on it this week (busy prepping for a trip and being gone for a few days), but I'll attempt to take some time after I return to look into it.     -- https://github.com/shadowmage45/SSTULabs/issues/341 --

Feel free to add info on the other problem to that ticket as well (or open up a new one, as they do appear to be separate problems).  Helps me keep things organized when I don't have to scroll back through forum pages looking for issue reports