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

[Domfluff]

Landing a Bigelow module on the Moon:

(The tubes are fuel tanks).


Covering with Regolith (1963):




Obviously both modelling radiation and digging up the actual surface of a body are well beyond scope here.

Most base concepts do involve heavy equipment, usually stripped down and folded up for space-use.

[tater]

Here's a hub with 3 crossed SSTU tanks. Obviously the docking ports could be welded types or standard size in any of the 6 directions. I don't know if they could be switchable, i.e.: 2 x welded, plus 2x standard, plus 2 x 2.5m, or something. Perhaps they could be slightly longer so that the hub is less tight, with room for some RCS (more of an obvious + shape). Docking lights are in SSTU, I wonder if on a hub such lights might be off the ports slightly, and not quite on-axis so that once docked they illuminate the docked segments.

[Shadowmage]

More work on the DOS/FGB/TKS based module prototypes.  Have settled on a 3-module part setup; simplifies the IVA creation and setup for a standardized 'core' size, and anything more than 3 modules starts running into compatibility problems between the modules (due to adapters sizing, solar panel placement, etc).  Three-module parts still allow for quite a bit of variation in the parts while keeping them simple enough to actually use and makes the modeling/designing end of things much easier.

So, color-coded prototype geometry:
Green = Core - Responsible for IVA size/shape, crew capacity, and most functions (solar, RCS, SAS, reaction wheels, transmitters)
Brown/orange = Bottom Adapter.  Far left is the Almaz based end-cap (with solar panels); will likely be a 1.25m dock version of it as well.
Purple = Top Adapter / Hub (more variants to be made / not all shown).  Special short 'cup' adapter included for use with the VA capsule.
Blue = Parts of the VA spacecraft (CM/SM/LAS)
Red = Solar panel locations (otherwise hard to see in that image).

 

 

2 hours ago, tater said:

 

Here's a hub with 3 crossed SSTU tanks. Obviously the docking ports could be welded types or standard size in any of the 6 directions. I don't know if they could be switchable, i.e.: 2 x welded, plus 2x standard, plus 2 x 2.5m, or something. Perhaps they could be slightly longer so that the hub is less tight, with room for some RCS (more of an obvious + shape). Docking lights are in SSTU, I wonder if on a hub such lights might be off the ports slightly, and not quite on-axis so that once docked they illuminate the docked segments.

Yes, larger 'hubs' will be coming; however they will be based on the Near-Future Octo-Truss format.  They will likely have both truss and 'pressurized' variants (see the other NF-pressurized truss models).  And they will likely include docking ports, probably with various combinations of sizes (but not welding ones; those -have- to be separate parts due to the nature of them deleting themselves).  There will also be the USOS styled multi-node parts (e.g. Unity/Node1).  So you'll have several options available for multi-connection hub setups.

Lights - perhaps.  The multi-docking hubs will at least have status lights and numbers on them (emissives), but unsure on a usable implementation of directional docking lights on them (mostly though with the part-count reduction, it should now be possible to add your own lights; I also believe that lights are 'physics-less' parts, so their impact for being a separate part is minimal with the biggest performance hit coming from the actual lights/shading).

[JoseEduardo]

will the hub include nodes for ~0.9375m (Soyuz) and 0.625m (Apollo) docking ports aswell?

[Shadowmage]

4 minutes ago, JoseEduardo said:

will the hub include nodes for ~0.9375m (Soyuz) and 0.625m (Apollo) docking ports aswell?

I will -not- be introducing another docking size; the options will be 0.625m and 1.25m (the stock docking port sizes).

 

 

[Domfluff]

In terms of integrating with USI-LS - giving the parts hab time bonuses and/or multipliers, and probably recyclers is one thing (and could be done entirely within a MM patch - I'd probably write one for myself anyway, so I'd be happy to knock one together if I can work out some approximate numbers to aim for, probably based on Salyut/ISS mission durations), but the main part-saving function you could provide would be to allow amounts of supplies and fertilizer to be configured as part of your tank config code.

Further on from that, some kind of integrated processor part (the USI-LS greenhouses) is pretty much required for any long duration mission, but this is not necessarily required for transit - having a decent recycler level is sufficient for most long term LKO space stations, and most bases can grow food in-situ.

[JoseEduardo]

1 hour ago, Shadowmage said:

I will -not- be introducing another docking size; the options will be 0.625m and 1.25m (the stock docking port sizes).

will that be a thing that can be changed in the cfg files by a third party?

btw, I thought that your Soyuz docking port was something around 0.9375, hence why I mentioned, but checking the .cfg I noticed I was very wrong

[blowfish]

2 minutes ago, JoseEduardo said:

will that be a thing that can be changed in the cfg files by a third party?

btw, I thought that your Soyuz docking port was something around 0.9375, hence why I mentioned, but checking the .cfg I noticed I was very wrong

The docking ports are separate models that are added in with MODEL {} nodes.  In another context (i.e. RO) it's definitely possible to replace and rescale them.

[JoseEduardo]

1 minute ago, blowfish said:

The docking ports are separate models that are added in with MODEL {} nodes.  In another context (i.e. RO) it's definitely possible to replace and rescale them.

yep, I've changed the Orion's DP many times through patches for personal use, but I was wondering if that would still be a thing for the stations

[Shadowmage]

1 hour ago, JoseEduardo said:

will that be a thing that can be changed in the cfg files by a third party?

btw, I thought that your Soyuz docking port was something around 0.9375, hence why I mentioned, but checking the .cfg I noticed I was very wrong

 

1 hour ago, blowfish said:

The docking ports are separate models that are added in with MODEL {} nodes.  In another context (i.e. RO) it's definitely possible to replace and rescale them.

 

1 hour ago, JoseEduardo said:

yep, I've changed the Orion's DP many times through patches for personal use, but I was wondering if that would still be a thing for the stations

 

On the note of the Soyuz; if I ever retouch the model I'm going to clean up the nose so that other docking ports will be easier to swap in/out and to rescale the base models; that ring around the port is kind of hard to work around.  But yes, it is 0.625m currently, the same as the Apollo/SC-B. 

Mostly I'm aiming to keep compatible with stock sizing (and the majority of mods) for the major parts.  1.875m being a bit of an exception for the Soyuz stuff as I thought that it was really needed at that size, and the fuel tanks/engine code already easily adapts to whatever odd sizes I want to throw at it.

 

As to the station hubs, I'm still undecided on how best to integrate the docking ports.

From a plugin standpoint they all need to have individual transform names (e.g. Dock1, Dock2[...]); there is no way around that, it is a requirement of the stock ModuleDockingNode and is the only way for the modules' to tell what port they are each responsible for.  There are basically two ways make this work as far as model setup goes:

1.) Integrate the docking ports and transforms into the model.  Complicates the modeling and texture-sharing setup, greatly simplifies the config setup, but results in not being able to swap docking port models.

2.) Have the hub models be blank hubs with flat spots for the ports, and use standard stand-alone docking port models.  Have -separate- additional models that are nothing but a set of docking-port transforms (a control transform and a node transform, they have to be oriented differently), one for each docking port number (e.g. DockTransform1 in one model, DockTransform2 in another model).  Use the new SUBMODEL capability in the SSTU_MODEL setup to add the docking ports, docking-transforms, and station module part into a single welded model.  This makes the modeling end of things easier and allows for compatibility with swapping in new docking port models, but greatly increases the complexity of the config/model-definition setup.

 

For #1 there is no port swapping. 

To swap models for #2 you would edit the SUBMODEL nodes to swap in your docking port of choice and reposition the docking transform models according to the new docking ports setup.  The only limitation to the ports used would be that of the flat spots on the hub; so for your 0.9375 you would still have to use the flat for 1.25m (or create and add an adapter through another SUBMODEL).  This option also makes it easier to integrate into the module-switch setup as you could re-use many of the same docking port module definitions for the different hubs.

 

I'll probably go with #2 as it will just be more configurable in the long run, and makes dealing with the modeling end of things easier (good for me, I would rather have complex configs and easier modeling).  Who knows, maybe I'll even redo my docking ports at some point and want to be able to swap them in without redoing the whole model

[Nightside]

Does anyone have a thrust curve to share for the SRBs? I'm playing around with that feature and am wondering what others like.

[tater]

#2 sounds better, frankly.

[JoseEduardo]

the only thing that bugs me about a hub with integrated multiple docking ports is that it makes hard to know which one is which to dock... Porkjet made this in his inflatable hub, and it was quite confusing to know which one is which unless you read the numbers on the texture and tried to figure out which one was the one you'd pick in the right menu, say you want to dock a Soyuz in a one part Mir, you have 6 docking targets and you want to dock in either the front or the rear of the core, unless you have labels telling which one is which it might be hard to figure out which one is the one you want to go

EDIT: with that said, I'd go with #2

btw, now that I realized that this will be hard only for the lazy-asses like myself who use mechjeb, those doing manually won't have an issue with it

Edited July 20, 2016 by JoseEduardo

[Dr.K Kerbal]

Great mod. Solve the SLS!

[tater]

Regarding docking, particularly welded docking: can those ports "snap to alignment?" 

It's really hard to build something where all the parts stay in alignment on orbit. I get usually get pretty close eyeballing it, but it can be a few degrees off, and once I notice I cannot unseen it.

Ideally this would be a function you could set in the right click, because it would be useful for any new docking port part. Perhaps the part needs to be rotated within 5° or something, and then rotates to alignment. This idea sort of goes hand in hand with my asking for a sort of linear docking truss part, as that would have to snap to alignment to be useful.

[JoseEduardo]

ModuleDockingNode supports snap to alignment, so if Mage uses the stock code he can set it to snap to a certain angle

or if he doesn't do that, but still uses the stock code, you could add it yourself, I found this out while checking the .cfg file from CxAerospace:

	MODULE
	{
		name = ModuleDockingNode
		referenceAttachNode = top
		nodeType = APAS_CXG
		gendered = true
		genderFemale = false
		acquireTorque = 0.5
		acquireForce = 0.5
		captureMinRollDot = 0.99999
		snapRotation = true
		snapOffset = 120
	}

I have added the gendered option to Bobcat's Soyuz and Mir, for personal use, but I haven't added the snap part mainly because I want some freedom to rotate with these ports, so if you want you can remove the gendered bit or set it to false, and use the snap

btw, idk which one does it, but you have to be very precise while docking for it to dock, if you don't you'll need to rotate the vessel until it find the right spot and docks

Edited July 20, 2016 by JoseEduardo

[Shadowmage]

9 hours ago, JoseEduardo said:

the only thing that bugs me about a hub with integrated multiple docking ports is that it makes hard to know which one is which to dock... Porkjet made this in his inflatable hub, and it was quite confusing to know which one is which unless you read the numbers on the texture and tried to figure out which one was the one you'd pick in the right menu, say you want to dock a Soyuz in a one part Mir, you have 6 docking targets and you want to dock in either the front or the rear of the core, unless you have labels telling which one is which it might be hard to figure out which one is the one you want to go

EDIT: with that said, I'd go with #2

btw, now that I realized that this will be hard only for the lazy-asses like myself who use mechjeb, those doing manually won't have an issue with it

The docking port hubs will have multiple right-click options for targeting each port, with numbers or other labels that correspond to textures or something on each port..  MJ docking will still be fully possible.  It will also have right-click options to 'control from port #1' or 'target port #3'.  So, the only difference from normal docking ports is you'll have to look at the vessel to find the # of the port that you are docking to / undocking from / targetting, and use that # to get the right option in the right-click menu.

 

1 hour ago, tater said:

Regarding docking, particularly welded docking: can those ports "snap to alignment?" 

It's really hard to build something where all the parts stay in alignment on orbit. I get usually get pretty close eyeballing it, but it can be a few degrees off, and once I notice I cannot unseen it.

Ideally this would be a function you could set in the right click, because it would be useful for any new docking port part. Perhaps the part needs to be rotated within 5° or something, and then rotates to alignment. This idea sort of goes hand in hand with my asking for a sort of linear docking truss part, as that would have to snap to alignment to be useful.

Yes I could potentially add the snapping feature to the ports (or as Jose says, you can add it through a simple patch).  However, if I do add it I will be finding some way for an in-vab / in-flight toggle for it -- the stock module does not support this, so I likely won't have snapping initially; will have to wait until I can come up with a workable hack around the stock module limitations / write yet another module just to add the gui toggles / wait until stock adds such a feature.

[JoseEduardo]

1 minute ago, Shadowmage said:

The docking port hubs will have multiple right-click options for targeting each port, with numbers or other labels that correspond to textures or something on each port..  MJ docking will still be fully possible.  It will also have right-click options to 'control from port #1' or 'target port #3'.  So, the only difference from normal docking ports is you'll have to look at the vessel to find the # of the port that you are docking to / undocking from / targetting, and use that # to get the right option in the right-click menu.

like Porkjet's inflatable hub, gotcha!

multiple docking ports doesn't kill MJ, it just makes it confusing to know which one is which, but since you'll be adding labels that will help a lot

[tater]

I've managed a few MM patches myself, so that's not a problem

I used to have @Nertea's stuff in my install, and with 64 bit I guess I can put it back (woot!).

[Shadowmage]

Hit a bit of a snag in the ModuleSwitch setup last night regarding its use with my own modules.  Works fine for stock modules, but many of my modules rely on the config for the module being accessible from the part / database due to them needing sub-node data that is not always available in the node passed into the OnLoad method.

So, I can either 1.) Drop the module-switching altogether (which would force a redesign of all of the station parts' concepts), or 2.) Rework all of my other modules that use cached part-config nodes to use some other method; cannot even rely on the prefab part having the node, as the modules from ModuleSwitch do not get loaded on prefab parts; will require special hand-coding of the config node handling for each and every module that I want to be compatible with the ModuleSwitch (which at this point could be quite a few).

As the station parts pretty much need the module-switching functionality (or they would end up just like every other part-count-inflating station parts pack), my choices become to either 1.) Don't make station parts at all, or 2.) Same as #2 above; tons of work, and ugly fragile code to boot.  Neither is a good choice.  Going to have to do some thinking / consideration on it. 

 

 

On the part design front -- I'm highly considering making the DOS-based hub be a separate part;  yes I know it was integrated into the Mir core (and others), but this is one of those cases where splitting it off might be necessary to clean up some of the part functions;  the 'core' modules already have enough functions (and potentially also a front and rear docking port), so I think that having all of the other right-click docking port options on the part might just be too much.  Instead of the hub with ports on it the CORE modules would get a blank 1.25m end-cap suitable for attaching the hub or any other part (dock, hub, welding docking port, whatever).

This would leave the docking hub as a separate part, but that is not really a problem either -- I was already planning some stand-alone multi-docking-hub parts.  Splitting them off from the core actually allows for much more opportunity for configuration and options in (through yet another custom tailored plugin).  Options such as being able to swap around the docking port models for each port on the hub (0.625m, 1.25m, blank for welding port), switchable 'hub' models, and potential inclusion of other structural bits on the hub (e.g. hub has an option for a truss segment or adapters for one of its port/node model options).

[rasta013]

2 hours ago, Shadowmage said:

Works fine for stock modules, but many of my modules rely on the config for the module being accessible from the part / database due to them needing sub-node data that is not always available in the node passed into the OnLoad method.

 Ok maybe this is a silly question but it did occur too me.  Couldn't you setup the modules as part of the on-load and then MM patch everything in you want config wise as a :FINAL or :AFTER patch?  I know this may not be ideal and since I'm not a coder this could be an utterly idiotic idea, but whenever I think of moving/changing/adding modules around on custom parts I make I tend to do them as :FINAL patches and I've done it with mod added modules (like DMagicScienceAnimate) where I can't do anything with the module until after its OnLoad has passed.

[Domfluff]

Some bug reports (none of these are show-stopping):


"Enable parachute staging" works fine, but doesn't appear on the staging track. This may be by design, but something you said earlier makes me think it may not be intentional.

(As an aside, the SSTU parachutes are a little counter-intuitive with how KSP chutes work now, and especially the stand-alone docking ports/chutes, which don't have integrated drogues. They do work fine, but I've certainly lost capsules in testing to having overly aggressive atmospheric entries. Perhaps your docking ports should have the same inbuilt drogues as the ones built into capsules).

SSTU-SC-B-SM (Apollo-like Service Module) - "Jettison fairing" for the engine doesn't seem to appear in right click menus, nor functional when set as an action group.

SSTU-SC-A-OM (Soyuz-like Orbital Module) - Enable docking lights" doesn't turn these on.

All SSTU Fuel tanks and SRB's - will not radially attach at first attempt, instead these need to be attached via a node, and then can be attached radially.

SSTU-SC-GEN-MHS (modular heat shield) - the modular heat shield isn't resizing anymore (I'm sure I've seen this work in a previous build). The connection is re-sizing fine, but the heat shield itself stays at it's default size.

All size limits - these are now correctly applying in career mode (thank you!), but the same limits apply in Sandbox - i.e., if you have unlocked 2.5m parts, then sandbox will also be limited to 2.5m parts. If it was one or the other then this is probably the better option, so it's not too serious, I think.

[Shadowmage]

38 minutes ago, rasta013 said:

 Ok maybe this is a silly question but it did occur too me.  Couldn't you setup the modules as part of the on-load and then MM patch everything in you want config wise as a :FINAL or :AFTER patch?  I know this may not be ideal and since I'm not a coder this could be an utterly idiotic idea, but whenever I think of moving/changing/adding modules around on custom parts I make I tend to do them as :FINAL patches and I've done it with mod added modules (like DMagicScienceAnimate) where I can't do anything with the module until after its OnLoad has passed.

Sadly no;  ModuleManager does its patching of the configs long before the parts are ever loaded; there is no way to tell it to patch -after- the part has loaded, and would in fact defeat the entire purpose of patching the files.  Neither ModuleManager nor patches could conceivably be a solution to this problem.

What I need is for the stock OnLoad method to -always- pass the full config-node for the module, instead of only passing the full config node on the prefab part.  But this would mean that stock would need to persist that config node with the module (which is what my original hacky workaround consisted of) or look it up from the Parts base config node (which would not work in this case as they are not defined as a normal module, and is why my current code is failing; the modules are not defined in the part, but as sub-nodes in another modules config node).

 

At this point I cannot think of a clean solution to the problem.  I have a couple fairly terrible workarounds that I'm going to look into... but none of them are 'nice' and all will likely run afoul of issues later down the road, they all also require substantial amounts of additional code be added to pretty much all of my other modules, which is likely to break lots of things.  Not really the road I want to go down; its like building a house out of already rotten timber... just a bad idea and only going to cause more problems later when you have to rip it all out and rebuild it from the ground up.

 

Its really looking like I'm going to have to ditch the ModuleSwitch functionality entirely.  It won't work with my current modules setup and will likely have other as-yet-unforeseen/untested compatibility issues with other mods' modules.  Sadly this leaves the modular station parts as being... well... not very modular.  Each 'core' variant would have to be its own distinct part (to enable the different core module functions; e.g. lab vs. hab; or at least two variants for the module setup while still allowing swapping of the 'CORE' model).  Also could not be any optional docking ports; it can either have ports on all variants or not at all, the only possibility would be to allow for switching the models around with custom transform repositioning.

Would also mean that docking hubs could not have optional ports on them; they would come with a preset number of ports and your only option would be to change the models (so no option of blank nodes and thus no ability to use welding docking ports with the hubs).

 

Ughh... perhaps I should just give up in my crusade to lower part-count.  I'm quite sick of fighting with the stock code (and lack of available source) and the stock mentality of 'just add more parts!'; at this point it is only making me bitter and resentful, which is not at all conductive to me being productive.  Its hard to get motivated about doing something when you know it will be a long, drawn out, painful battle the entire way with little to show for it in the end.  This isn't even touching on the fact that there still isn't a working wheel solution available even months after the 1.1 release, but if I'm not doing integrated/modular parts I suppose that is a bit of a moot point anyway (though it will still prevent me from doing any sort of wheel/landing legs; I refuse to touch the pile of @#$^ that is the current Unity wheel system).

Sadly that doesn't leave me much in the way of things to actually do for modding; most of the part concepts that I have, at a single-part-setup level, have already been done in other mods, and I don't really feel like doing a bunch of models and textures just to have them in 'my style'. 

Sorry if that sounded like a bit of a whine; merely trying to express a bit of my frustration before it forces me to just walk away.  Its not what I want to do, but obviously I have some re-evaluation to do concerning my goals for the mod and plans for future parts/modules if I'm going to continue working on it -- I cannot simply keep marching along and putting up with the stock incompatibilities and assumptions they make.

So I'm going to take the next few days to rethink the mod a bit, re-evaluate the goals and intent, and try to think of a better way to to handle things moving forward.  If I don't like what I come up with I'll likely just take a break until 1.2 is ready and see if the stock code situation has improved at all (they are finally taking optimization seriously, so there might be some hope for better performance in the future; though by the nature of the system the best they can hope for is O(n)... which is still far better than the O(n^2) to O(n^n) that it currently operates as).

17 minutes ago, Domfluff said:

Some bug reports (none of these are show-stopping):


"Enable parachute staging" works fine, but doesn't appear on the staging track. This may be by design, but something you said earlier makes me think it may not be intentional.

(As an aside, the SSTU parachutes are a little counter-intuitive with how KSP chutes work now, and especially the stand-alone docking ports/chutes, which don't have integrated drogues. They do work fine, but I've certainly lost capsules in testing to having overly aggressive atmospheric entries. Perhaps your docking ports should have the same inbuilt drogues as the ones built into capsules).

SSTU-SC-B-SM (Apollo-like Service Module) - "Jettison fairing" for the engine doesn't seem to appear in right click menus, nor functional when set as an action group.

SSTU-SC-A-OM (Soyuz-like Orbital Module) - Enable docking lights" doesn't turn these on.

All SSTU Fuel tanks and SRB's - will not radially attach at first attempt, instead these need to be attached via a node, and then can be attached radially.

SSTU-SC-GEN-MHS (modular heat shield) - the modular heat shield isn't resizing anymore (I'm sure I've seen this work in a previous build). The connection is re-sizing fine, but the heat shield itself stays at it's default size.

All size limits - these are now correctly applying in career mode (thank you!), but the same limits apply in Sandbox - i.e., if you have unlocked 2.5m parts, then sandbox will also be limited to 2.5m parts. If it was one or the other then this is probably the better option, so it's not too serious, I think.

Thanks for the reports;

#1 - known issue with stock code, nothing I can do about it:  https://github.com/shadowmage45/SSTULabs/issues/287

#2 - you need to increase the section/segment count, or else there is no ability to manually jettison (how can you manually jettison a fairing that is attached to the fuel tank below?  you jettison the fuel tank and the fairing goes with it).  The manual jettison buttons only apply if the section count for the fairing is > 1, this is the intended behavior.

#3 - will look into it

#4 - known issue with stock code https://github.com/shadowmage45/SSTULabs/issues/272; they don't like it when you switch models/colliders around during part initialization.  Nothing I can do about it as far as I'm aware (would need full source access to have any chance of tracking down and fixing the problem, which I do not have, nor is there any option for me to get access to it that I'm aware of).

#5 - hmm... I probably broke that with some recent code changes as it used a bit of a strange setup for the model, will investigate next time I feel up to digging into things.

#6 - will look into that as well - it should be clearing out the tech-limits (and not using them at all) when you switch over to the sandbox game; seems likely that it is an artifact of the caching system I had to put into place (because for some reason the tech-node data is not available when the editor/flight scenes are initializing; it only becomes available later after the scenes are all setup).

 

In the future, please look at the issue tracker to make sure you are not posting duplicate issues, and any new issues that you have should go directly there; it ensures that I see them and that they do not get forgotten about (as I'm likely going to forget about #3, 5, and 6 before I can fix them as they're not on the tracker).  The issue tracker can be found at:  https://github.com/shadowmage45/SSTULabs/issues

[rasta013]

2 hours ago, Shadowmage said:

Sadly no;  ModuleManager does its patching of the configs long before the parts are ever loaded; there is no way to tell it to patch -after- the part has loaded, and would in fact defeat the entire purpose of patching the files.  Neither ModuleManager nor patches could conceivably be a solution to this problem.

What I need is for the stock OnLoad method to -always- pass the full config-node for the module, instead of only passing the full config node on the prefab part.  But this would mean that stock would need to persist that config node with the module (which is what my original hacky workaround consisted of) or look it up from the Parts base config node (which would not work in this case as they are not defined as a normal module, and is why my current code is failing; the modules are not defined in the part, but as sub-nodes in another modules config node).

Ok gotcha.  Thanks for the explanation. I've probably learned more about the internal workings of the game, load sequence and part initialization by following this mod than I have everywhere else combined. LOL

As for the frustration thing - I get it.  I had to take a break entirely from KSP last year because the memory issues combined with stability problems finally broke my back and I left for about 6 months.  That's just me as a player dealing with the craziness that is the KSP code so I can only vaguely imagine how irksome it must be for someone trying to code around all the little quirks and issues.  You do what you need to do to get yourself where you feel good about things and if that means you don't add anything else, so be it.  What you have created is truly one of the all time best mods this game has ever seen and I think I can safely say those of us that use it thoroughly appreciate everything you have accomplished and do for us as players.

[Domfluff]

Thinking about usi-ls support some more, and doing a bit of research - the DOS modules had a mission duration of 90 days, which with a crew of two implies a total of six seats (30 days per seat, divided by two kerbals) - this would mean that the station itself would have two available seats, with no bonuses on hab time. I think this is fine, since these  are low-tech stations, more sophisticated hab modules would perform better. The other four seats come from the soyuz capsule itself.

In terms of supplies, 500 supplies is enough for one kerbal/month, therefore the station needs to hold 3000 supplies, with no need for recycling (low tech). The early Salyuts had no resupply, so this puts a fairly hard limit on the station lifespan. Salyut 6+ could dock a Progress vehicle for supply, and judging by the mission logs, it looks like one Progress could supply the full ninety day duration. This implies that the Progress can hold 3000 supplies, or three tons of cargo. Since that mostly matches the real world, that's pretty straightforward. I'll write a basic mm patch when I'm in front of a pc, and see if that causes any other problems.

Mir and ISS modules would require some more thought/research, as would inflatables or anything more sophisticated. Going the other direction, a MOL-like station would require minimal supplies and perhaps only one seat (for the lab) to match it's forty day mission duration.