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

[Shadowmage]

2 hours ago, Qwarkk said:

Having an issue with the parachutes on the SC-B-CM rentry crew pod. They wont deploy during my re-entry, saying it is unsafe (even at around 200m/s?). Doing simple tests (launching a ship straight up and activating parachutes) they work fine, so it must be the speed/unsafety that is causing them to not deploy. I have checked and I have deployment altitude set to maximum for both parachute types. Am i doing something wrong / does it matter when I activate staging for them to open?

It may be worth noting that I'm using the crew pod's parachutes to re-enter a 20 tonne lander. Could this be the issue?

Here is the output log in case it helps.

HI Qwarkk;

It should not matter when you activate the parachutes (though they don't by default workthrough staging/space bar; you must assign an action group or use the right click menu).  You can even activate them while in space and they will properly not deploy until it is safe for them to do so.

The mass that they are attached to also should not matter; the only things that determine if they should open or not are 1.) The user specified altitude settings, 2.) The current dynamic pressure (speed+altitude), and 3.) The calculated shockwave temperature (speed+altitude; only while >350m/s).  They -should- open around 220ms for mains, and... 325m/s or so for the drogues (depending on altitude slightly).

I'm not seeing anything in your log that would point towards mod-conflicts; there is a null-reference caused by PersistentRotation (so you might try removing that mod...), but it looks like that is happening after the parts have started lithobraking/exploding.  Although the output_log file is far less useful than the KSP.log file (located in your main KSP directory, at least on Windows), so it might not be showing everything / might be some errors I cannot see in it.

Do you have any screenshots of when this is occurring, and what exactly does the parachute status say? (Unsafe, or Armed-Unsafe?  Huge difference there)

I would say you have couple things to investigate:  1.)  Try it with fewer mods; SSTU+stock parts only and see if the problem persists.  2.)  Try altering the mass and see if that has any impact on them deploying or not (it shouldn't),  3.)  Try your simplified straight-up and descend test with your lander attached to verify that it is not directly craft design related.

[RedParadize]

@Shadowmage About progress update from last page, if you manage to implement blend shape it will be quite a achievement. I believe that many modder will be intrested, maybe Squad too in fact. If not, rigid and semi rigid centrifuge are still a option. About dynamic IVA change, I cross my finger for it!

Looks like SSTU Orbital might be even more revolutionary than what you already gave us!

[Shadowmage]

8 hours ago, ComatoseJedi said:

Unless you are really opting in for the inflatable habitat market, I would just start off with cylindrical habs, first. See how well you can make them and move onwards from there. Think of the Mars D.I.R.E.C.T project. The hab was, in fact, a landable can with a heatshield on it. Granted, it was supposed to be 2 stories tall, to accommodate 4 humans (I'd say you can put 6 Kerbals in one of those with room for piddly things, like air, food, water, pet goldfish). But, with one of those attached to your cargo truss system, I'd say you'd had the beginnings of a fairly strait forward IPV. I know the Copernicus IPV concept did have an inflatable hab, but all the same and as always, I leave that up to you. 

Well... yes.. it appears I just might be doing at least a few inflatables.  Especially if I can get the BlendShapes to work; would allow for some truly unique deployment animations, of a quality and capability not seen in any other mods (well, dependent on my modeling and animation quality of course). 

There is also the fact that no other appropriately modeled inflatables exist for my purposes;  PJ's Hab pack is modeled well, but is done with stock-alike textures, and has those silly 1.25m hatch/node/things stuck on them (and the v2 pack is nowhere to be seen/no recent updates on it).  RoverDude's USI stuff is much the same; stock-looking textures, and improper sizes for most of the models, as well as having specific functions that are useless outside of UKS.

So its not that I really -want- to make them; its that I have no suitable alternatives available and my only recourse is to make them myself (or go without).

[Qwarkk]

1 hour ago, Shadowmage said:

HI Qwarkk;

It should not matter when you activate the parachutes (though they don't by default workthrough staging/space bar; you must assign an action group or use the right click menu).  You can even activate them while in space and they will properly not deploy until it is safe for them to do so.

The mass that they are attached to also should not matter; the only things that determine if they should open or not are 1.) The user specified altitude settings, 2.) The current dynamic pressure (speed+altitude), and 3.) The calculated shockwave temperature (speed+altitude; only while >350m/s).  They -should- open around 220ms for mains, and... 325m/s or so for the drogues (depending on altitude slightly).

I'm not seeing anything in your log that would point towards mod-conflicts; there is a null-reference caused by PersistentRotation (so you might try removing that mod...), but it looks like that is happening after the parts have started lithobraking/exploding.  Although the output_log file is far less useful than the KSP.log file (located in your main KSP directory, at least on Windows), so it might not be showing everything / might be some errors I cannot see in it.

Do you have any screenshots of when this is occurring, and what exactly does the parachute status say? (Unsafe, or Armed-Unsafe?  Huge difference there)

I would say you have couple things to investigate:  1.)  Try it with fewer mods; SSTU+stock parts only and see if the problem persists.  2.)  Try altering the mass and see if that has any impact on them deploying or not (it shouldn't),  3.)  Try your simplified straight-up and descend test with your lander attached to verify that it is not directly craft design related.

I experimented a little further and as you suggested the problem isn't mass related, and it is also not craft related. The parachutes deploy as expected with my straight-up test. Here are the settings i have for the part:

I tried removing persistent rotation due to the null-ref, and then gave it a sub-orbital test. The parachute status read Armed-Unsafe all the way down. As the craft passed below 300m/s the parachute cover popped off, but no parachutes deployed (this is the first time this happened, all other times nothing happened).

On a side note, you mention that the parachutes don't by default deploy with staging, yet mine do (when they're working). Is this a problem or just another mod interacting with SSTU parts?

Finally, here is the KSP.log file.

Appreciate the help.

[Shadowmage]

7 minutes ago, Qwarkk said:

I experimented a little further and as you suggested the problem isn't mass related, and it is also not craft related. The parachutes deploy as expected with my straight-up test. Here are the settings i have for the part:

 

I tried removing persistent rotation due to the null-ref, and then gave it a sub-orbital test. The parachute status read Armed-Unsafe all the way down. As the craft passed below 300m/s the parachute cover popped off, but no parachutes deployed (this is the first time this happened, all other times nothing happened).

 

On a side note, you mention that the parachutes don't by default deploy with staging, yet mine do (when they're working). Is this a problem or just another mod interacting with SSTU parts?

Finally, here is the KSP.log file.

Appreciate the help.

 

Well, the parachutes worked fine during my gaming session last night (direct-from-minmus to 30k peri re-entry) without any issues, multiple times in a row; so I know that they are working for their intended use in a mostly stock / low mod environment (NF/USI/MJ/HE/RP/EVE/KIS/KAS/KJR/Scatterer).  You also have them working for your suborbital test cases.  The fact that the parachute cap deployed in your last test also tells me that the plugin is working, but something is causing it to cut the parachutes early.

That mostly leaves mod conflicts as the likely suspect.  About the only thing I can suggest there is to recreate the craft on a mostly clean (Stock+SSTU+dependencies) install and see if you can duplicate the problem there.  IF you can, please not the steps neccessary to recreate the problem and reply with those details / a craft file that always experiences the problem.  If the problem doesn't manifest on a clean setup, then you have a mod that is acting badly or interfering, and will need to identify which mod it is (by installing your mods one at a time and re-testing after each one).  I will gladly fix problems that I can duplicate in a stock install, but do not have time to find, download, and install a bunch of mods to test for a -possible- mod conflict (that most than often is a problem with the other mods that I can't fix anyway).  BUT if you can narrow it down to a specific mod / very small set of mods it makes it much more likely that I will investigate the interaction problems.

 

Staging: I noticed from your screenshot that you enabled the parachute staging in the right-click menu, in which case, yes it will respond to space-bar staging (but it is not setup like that in the default config; if that is your default setup then something is messing with the config for those parts, and is probably the first thing you should find out (what is messing with the parts configs)).

 

I'm not seeing anything too worrying in that log (though it appears that log got cut off early, as it ends partway during the initial loading sequence.. before the parts are even loaded), but thanks for including it anyway; never know when it'll have all the answers.

[Shadowmage]

Quick-and-dirty modular part setup for the 'Station Core' main modular part (which will probably be aptly called 'Station Core').  This potential layout makes full use of ModuleSwitch, ModelSwitch, dynamic crew-capacity, and IVA-swapping; some of which are 'tentative' or unknown if they will even be workable.  The crew-containing module would be the red colored sections due to limitations on only a single IVA being allowed per-part; all other modules are parts would be structural/functional parts only and would not expand the crew capacity.  The top and bottom module selections don't necessarily have to be the same, I was just running out of ideas.

With the current setup of the 'ModelSwitch' module, you could even omit the Top Module and Top Cap modules (same with bottom) if you only wanted the core piece, or any combination thereof (so can have top module + top cap, bottom module, but no bottom cap; or core module, no top module, but a top cap adapter).  The only non-optional bit would be the core segment.

Not shown are potential 'Core Module' accessories, which could range from solar panels, lighting rigs, transmitters, or ??, really anything small that would go on the outside of the  module is a potential 'accessory' option.  Other modules could potentially have 'accessories' as well, such as the reactor having optional radiators, or the logistics module having multiple transmitter options.  In theory the hubs could even have optional integrated docking ports as an 'accessory', or even just available as another discrete 'cap' option.

 

The same, or similar, setup could be used for some of the 'structural' parts;  the ModelSwitch module supports a pre-configured tree-type model hierarchy without any limit to length/depth of the branching.  So you may have a 'structural' part with multiple main body segments, various top and bottom adapters, and various cap options / hubs / docking port setups.

The only real limitations to this type of modular-part setup would be the complexity of the finished part (how many things do you really want on the right-click menu?), and the time needed to add all of the various options / tree branches for the ModelSwitch setup.  BUT -- I don't want to go overboard with the model-switching / modular parts setup.  Would still rather keep each 'modular part' to have a specific function and be usable in the 'lego-rocket/station' fashion.  As such would likely limit each modular part to 3-5 modules in length, with 2-6 options for each module.  That way a complete station would be constructed by docking together 2-4 of these 'modular parts', with perhaps a few random structural or custom bits on it (custom positioned lights or whatever... stuff that can't be done through the modular part setup).

Will try and whip up some prototype models to use for testing and better examples (I know, my graphical examples are kind of poor).  Have a -ton- of thinking to do on this stuff before I commit too much time on the implementation of it.  Far to often I come up with a concept that sounds great at first but soon starts sounding silly/over-the-top/too complex once I start working on implementing it.  Will almost certainly be creating some dummy/placeholder models to use for some test parts for feedback before I start actually modeling anything for them.

 

Also, if the new ModuleSwitch functionality works out this may mean that the 'Modular Service Module' may actually become reality at some point.  Would use many of the concepts discussed above for the station core part, but on a bit smaller scale (body option + engine option + EC generation option + CM adapter option + payload/science option?; okay so not really much simpler, just different )

[JoseEduardo]

I'm probably arriving at the party too late, and sorry if this was discussed previously, but what will be the style for the parts? USOS-alike, DOS and TKS-based, both or none/custom? not talking about replicas, as that would obviously limit them a lot, but the style of the parts

both styles go well with the modular idea, DOS and OPS cores could have sections of it changeable, like the bottom part having different capabilities/functions/storage (if possible) (but wouldn't change IVA or crew capacity for example), and other sections offering other things, like the central section having no solar panels, or Salyut 4/6 panels, or Salyut 7 panels with more output, then Mir with two panels and one radiator and Zvezda with only the panels, then the top part, which could be a single docking node with some features or simply a hub





some exaples of the modular capabilities (in theory, of course)
DOS-1 core

DOS-3 core

DOS-5 Core

DOS-6 with TKS spacecraft (was used to test if modular stations would work IIRC):

OPS core

DOS-7/Mir Core without the radiator


again, not talking about replicas, but style, you could end up with a DOS based station that doesn't look like anything that was launched, like MrMeeb's "Cooperation" station core: )

or even end up with something like this (TMK/Mavr):


as for USOS and TKS parts, they speak for themselves, a common endcap for them, and a cylindrical structure in between with a specific function to it and handrails attached, and a structure that can go from storage and docking extension to a material lab with a tapered part in one end with a docking port  (even USOS modules could become TKS-based modules, but if they are 2.5m wide that would mean a even bigger tapered structure, same goes for MFT tanks if you add the tapered or USOS structures to their endcap list, you could use them for fuel storage in a station)

[RedParadize]

@JoseEduardo Well, It might be possible to have a Salyout alike using Shadowmage setup. Say the "core module" is the largest diameter section of the Salyout, the smaller diameter could be science experiment etc. The question would then be if a adapter (same as on the current Tanks) from one diameter to a smaller could be placed between core module and top/bottom. At that point, might be better to have 2 or 3 parts.

[JoseEduardo]

yep, that's what I had in mind when I saw his example image above, the IVA would cover only the largest section and that specific section wouldn't change, while the other parts would change while retaining a DOS appearance

EDIT: now that I've read the last part of your post more carefully I understood the problem... indeed, in a MFT setup where you only can change the tank and the ends, a DOS setup wound't be viable if you would try to change the ends (bottom part to match Salyut 1, Almaz or Salyut 6/7/Mir/Zvezda), the top (Salyut, Almaz or Mir/Zvezda hub) and the middle-section (where solar panels are attached) wouldn't change much, the IVA could be extended to there and match the RW versions, and the outside could change for solar panels perhaps?

however, if I understood Mage's drawing that wouldn't be the case, as there seems to be 5 sections to be changed, and then a fully customizable DOS would be possible, you could pick the top end, the middle-section (which could have different functions), a core which wouldn't change crew capacity, size or IVA, these would be static, an optional part under it, and a bottom end that could be a Salyut 1/4, Almaz, Salyut 6/7, Mir/Zvezda (the difference is the antenna) or even something new like a TMK-alike end or a hub like MrMeeb's

Edited July 14, 2016 by JoseEduardo

[Shadowmage]

Still way to early to even think about what style / aesthetics the parts will have; need to make sure the concept will even work first.  Probably be a week or two before I'll be ready to think on the geometry of them.  First will come the concept-validation prototypes (basically just cylinders); and if that all works out, then I can start working on figuring out what I want them to actually look like.

Generally though most of those examples should be workable in one form or another, though I would prefer to keep a constant/consistent diameter for all of the main modules (top/core/bottom) (e.g. if the crew compartment is 2.5m the lab/etc would be as well).  Not a necessity, but it makes things much easier to develop a uniform style for and greatly eases the 'modularity' of it (else I would need so many adapters for the various sizes...ughh..).  I might be willing to make a special exception (read: a second 'Core' part) with the stylings of a 'russian' station/module that has the different sized modules... really won't know until I can dig into it a bit more and figure out the practical limitations of the system.

 

[Nertea]

21 hours ago, Shadowmage said:

Indeed, that is unfortunate.

Even through custom plugin, the data simply doesn't exist; the loaded mesh in-game contains no BlendShape keys, so cannot be even manually animated with them.  Seems like it would require an update to PartTools just to export the data, and further updates to the KSP model loading code to import that data (and I'm not even sure it can be done, it almost seems that there is no manual access to blendshape data through the Mesh class, so no way for them to recreate the data from file).

I have one more avenue of exploration - AssetBundles.  I'm moderately familiar with them from working on the KSPedia stuff, but have no clue how they relate to loading model and texture assets.  When they were initial 'advertised' as being supported it was stated that they would load any component that Unity recognized, but I'm really unsure on how to access them from in-game to load the models, etc.  Will let you know if I find out more...

 

Progress update:

Have figured out how to access/load AssetBundle data from in-game, but it is a bit weird.  It appears to load asynchronously, so I'm going to need to somehow ensure that I can get the models loaded prior to them being needed on prefabs (or else have placeholder models for prefab icon display).  And have just verified that the BlendShape keys do import properly this way.  Have not yet managed to get the model to display or animate in-game, but that shouldn't be too difficult of a thing to accomplish now that I can get the models to load.

So... I've got a few things to think over/investigate regarding how best to handle the model-loading for asset-bundle based models.  I -might- be able to start them loading at the point where ModuleManager finishes its database loading; hopefully this would give them time to load so that I could inject them into the GameDatabase loaded models list so that they can be used as any other model.  But as my head is pounding from digging through obscure KSP API stuff, that investigation will have to wait for another time / tomorrow.

Sounds like that's two major features needed for the station parts that I've got sorted out now.  The next to investigate will be dynamic IVA swapping;  a brief look indicated that most of the fields/methods that look like they would be needed are all public and accessible, so there may yet be some hope for that as well.

Re: blendshape - what about exporting in an AssetBundle?

[Climberfx]

Cool man!

[Shadowmage]

1 minute ago, Nertea said:

Re: blendshape - what about exporting in an AssetBundle?

The models export fine into the AssetBundle; but there is no built-in ability to reference that model in a parts' config file (that I could find/see).  The assets within the bundles are not actually loaded, and no models are added to the GameDatabase.loadedModels list; only the bundle definitions are loaded during the KSP loading sequence.

There are methods to manually access the assets from within a bundle, which is what I'm currently investigating -- how to load those models and add them to the GameDatabase models list so that they may be used in a part like any other model.  You can follow the progress of that investigation here:

The good news is that during my initial investigation last night I was able to get the model to load (in a hacky/debug/prototype fashion), and the SkinnedMeshRenderer and all of its BlendShape keyframes were intact (which was not the case when I tried the model through the PartTools .mu format).  So, as soon as I figure out how to get those models to load into the GameDatabase models list and usable in part configs, then yes, blendshapes should be totally usable.

I'll hopefully have something figured out a bit later tonight; will be the primary focus of my investigations this evening.

[tater]

One thing that would be incredibly nice to be able to tweak is the mass, somehow, such that a lab and hab could be balanced to be identical in mass, even if the length was added via service modules, etc.

[JoseEduardo]

Then I arrived too early at the party 

if this helps anything regarding sizes on the russian parts, Tantares sizes seem to work best for stock, he's been using 2.5m for the bottom section of the DOS cores and the widest part of the bottom section of the TKS, 1.875m for TKS/VA core and DOS middle-section and 1.25m for the top section of DOS cores (however he included three options for docking ports, 1.25m-->1.25m, 1.25m-->0.9375m and 1.25m-->0.625m)

this way they would be in scale with the 2.5m parts if they are based on USOS modules and could be placed early in the tech tree

[RedParadize]

You think it would be possible to have hatch on cap and auxiliary module? Would be nice as a option. Make sense to have limited amount of Airlock.

[Shadowmage]

So, here is one more bit of... data... that I could use some help in putting together.

How beneficial are the current modular parts as far as frame-rate is concerned in 1.1?  I honestly haven't tried building anything... large.. since 0.90, where anything in the ~80 part range would start causing lag.  But, for example, compare a stock-built Apollo-ish rocket to an SSTU SC-B setup; is there any noticeable difference in FPS performance between them? (Might be too few parts to even notice a difference in those cases).

 

Mostly I'm asking this because the recent plan for the modular-station parts boils down to little more than a limited form of part-welding; the parts would actually be -more- usable for lego rockets/stations if they were made distinct parts.  Would also save me a few days/week worth of updating/fixing/writing new code to handle them.  Even if I made them distinct parts, quite of bit of the part-count savings would still be in place, as each module (part) would have its own integrated accessory bits (solar panels, transmitters), and could still make them modular in so far as including choices of adapters/docking ports (optional).

Basically the system I had envisioned would work, but the -only- gain out of it would have been part count reduction (2-4 parts saved per complete modular part, compared to the stand-alone versions), while actually reducing the potential combinations of use for the part(s) they were constructed of, and would require substantial amounts of work to get it setup (both as far as coding and the actual part config creation), and could be very prone to breaking for very minor updates to the parts/configs.  I suppose this boils down to I would rather save parts through integrating the 'accessory' bits into the modules (solar panels/etc) rather than pre-welded modules.

On that note, the Russian DOS station modules/parts would still make good candidates for single-part setups, and would still make a good single-part starter station / station-core.  Would need to decide if I wanted to make multiple discrete variants or to use modularity in the part itself for the different options; will have to do a bit more investigation on their various configurations and options.

 

I suppose I'll have to do some testing this weekend and see where the performance limits are at in 1.1 as far as part-count is concerned.  While I do want to reduce part-count as much as possible, I would rather not do it at the expense of design options, vessel configurability, and general stability.  The goal in the end is to have 'usable' stations/etc, not merely the lowest part count possible; as long as the station can be used with a few vessels docked to it, then that goal has been achieved (and with the super-low-part count ShipCore vessels in SSTU, that leaves quite a few parts available to be used for the station itself).

 

On a slightly different note:

Looking over the images of real-world station modules (mostly the ISS), it appears that there are two basic variants -- the US 'silver cylinder' style, and the Russian DOS variants (Salyut program, Zvezda, Zarya, etc)  (which is mostly what Jose had pointed out the other day).

So for those wondering on what the styling of the station parts will be, ^^^ there is your answer.  There are really only two real-world styles available, and as such I'll likely do a bit of each.

[cxg2827]

11 minutes ago, Shadowmage said:

How beneficial are the current modular parts as far as frame-rate is concerned in 1.1?

this is my findings from a while back:

Quote

With regards to the performance increase in 1.1 (running on an i5 4690K), my 147 part station in 1.0.5 was in the delta timer and basically took 2 seconds real-time for every second game time. With 1.1, no lag at all. Very promising for high part-count stations.

 

 

12 minutes ago, Shadowmage said:

Looking over the images of real-world station modules (mostly the ISS), it appears that there are two basic variants -- the US 'silver cylinder' style, and the Russian DOS variants

the "silver cylinder" style can actually be broken out into 3 distinct styles: USA, JAXA, ESA if you so choose.

[Nightside]

8 minutes ago, Shadowmage said:

...

How beneficial are the current modular parts as far as frame-rate is concerned in 1.1?  I honestly haven't tried building anything... large.. since 0.90, where anything in the ~80 part range would start causing lag.  But, for example, compare a stock-built Apollo-ish rocket to an SSTU SC-B setup; is there any noticeable difference in FPS performance between them? (Might be too few parts to even notice a difference in those cases).

...

I haven't done much comparison, but I can say that performance is massively improved overall on my laptop (8GB RAM, but with virtual graphics). Ships that would have had the clock running the timer on the low end of yellow are now mostly green in launch. In orbit, it mostly depends if I'm looking at the planet or not. If not its usually green.

For me the biggest benefit of your modular parts is saving time in attaching all the fussy little parts like RCS and making sure to have tanks for every resource, instead of one tank part that holds it all. Also having a unified look and texture across a vessel.

The "expensive" part of building stations isn't really in the station modules themselves but in the connectors and adapters, especially if you are actually constructing it in space. If you don't want your station to look like a 2.5m paper towel roll, then you need to put an adapter with 1.25m docking port between each 2.5m section. To me the most useful modular stuff might be hubs that can change number and size of connection and can switch textures. Built in docking ports would be useful, but I understand those have some special complications.

28 minutes ago, Shadowmage said:

  While I do want to reduce part-count as much as possible, I would rather not do it at the expense of design options, vessel configurability, and general stability.  The goal in the end is to have 'usable' stations/etc, not merely the lowest part count possible; as long as the station can be used with a few vessels docked to it, then that goal has been achieved (and with the super-low-part count ShipCore vessels in SSTU, that leaves quite a few parts available to be used for the station itself).

Yeah, if you have too many modules/functions in a single part you start run into the limits of the stock right click menu. For those of us on small screens/lower resolution, it doesn't take much the menu to be too big.

Anyway, thanks for all your work, looking forward to what you create!

[tater]

I have not done really good tests on framerate, but I can try tonight.

Regarding stations, I think that it's important to consider that station parts are also effectively interplanetary ship parts, particularly for those of us that use life support. To a large degree, that's actually what I use them for, to build a craft to comfortably hold ~4 kerbals for a multi-year journey in a space that I don't think would drive them insane (I use about 1 hitchhiker volume per kerbal as a minimum).

BTW, would it be possible to have a cupola as a cap module?

[Shadowmage]

20 minutes ago, Nightside said:

The "expensive" part of building stations isn't really in the station modules themselves but in the connectors and adapters, especially if you are actually constructing it in space. If you don't want your station to look like a 2.5m paper towel roll, then you need to put an adapter with 1.25m docking port between each 2.5m section. To me the most useful modular stuff might be hubs that can change number and size of connection and can switch textures. Built in docking ports would be useful, but I understand those have some special complications.

 

Indeed, that is mostly my conclusion from observations as well.  The 'core' parts of the station (habitation, lab, command, storage, shipyard?) are the most minor contributors to its part count; most of the part-count comes from adding solar panels(4-20 parts), adapters between different styles/sizes of parts (2-4 per 'module'), and, of course, all the docking ports (20-40 depending on the size of the station).

Sounds like I might be downloading some other station-part mod packs this weekend and testing out various station designs to see what works, doesn't work, could use part-count reduction, etc.  I honestly gave up with stations with the part-count limitations of 0.90 / 1.0; they simply weren't feasable

It would be extremely simple to add optional docking port models/modules/adapters to the various core modules, so that they could be used stand-alone, or with the welding docking ports.  Just integrating the docking ports alone could be a massive part-count reduction process.

 

6 minutes ago, tater said:

I have not done really good tests on framerate, but I can try tonight.

Regarding stations, I think that it's important to consider that station parts are also effectively interplanetary ship parts, particularly for those of us that use life support. To a large degree, that's actually what I use them for, to build a craft to comfortably hold ~4 kerbals for a multi-year journey in a space that I don't think would drive them insane (I use about 1 hitchhiker volume per kerbal as a minimum).

BTW, would it be possible to have a cupola as a cap module?

Indeed, they do often make wonderful interplanetary parts.  I have about the same 'requirements' for my interplanetary craft; roughly 3-4x the crew capacity compared to actual crew... nobody wants to be stuck to a single chair for a 4-year voyage

Cuppola as a cap, sadly, no.  It has crew capacity + IVA, so it could not be used as anything but a 'core' module (of which there can only be one in each part, due to KSP limitations on only a single IVA in a part).  However, I could create a cuppola part with modular adapter setup.  It is precisely this/these problems that are causing me to re-think the 'super-modular-single-part' concept a bit (and why I'm glad it is only a concept at the moment and no real work has gone into it yet).

[tater]

For large ships (stations can be a little more arbitrary) mass balance really matters, and I tend to dislike really long vessels for a number of reasons (though I put any NTRs way, way back using trusses, etc for "safety.").

While not a "real" part on ISS, etc, what about a full-diameter hub part that contains a common area? Imagine a common-area hub (if it had a full IVA, perhaps eating and socialization area), and a hab in each of the 4 radial directions, and the thrust axis through the other 2 faces (perhaps a lab and "bridge" forward, and equipment/tanks to the rear).

[cxg2827]

1 hour ago, Shadowmage said:

It would be extremely simple to add optional docking port models/modules/adapters to the various core modules, so that they could be used stand-alone, or with the welding docking ports.  Just integrating the docking ports alone could be a massive part-count reduction process.

With regards to the docking ports, when you "set as target" to get the reticle on the nav ball it points at the CoM for the part.

With welding I'm not sure if there is a way to have the "set as target " able to point directly at the docking port rather than the overall welded station module.

[tater]

@cxg2827 's station parts are pretty fabulous, BTW.

[Shadowmage]

3 minutes ago, cxg2827 said:

With regards to the docking ports, when you "set as target" to get the reticle on the nav ball it points at the CoM for the part.

With welding I'm not sure if there is a way to have the "set as target " able to point directly at the docking port rather than the overall welded station module.

The 'welding' docking ports are standard stand-alone parts, just like the stock docking ports.  They merely have additional functionality to be able to remove themselves from the vessel when the 'welding' is done (thus permanently joining the other parts that were attached to the two ports).  They are intended for multi-launch construction of non-modular stations and serve mostly as a part-reduction measure, but also help with a lower number of joints between parts and will help with vessel rigidness..

As to other 'integrated' docking ports -- yes, you can specify a transform in the model that will be used as the target of a 'set as target' command; so each port on a multi-port part can have its own target transform.  It requires a special model setup (the stock parts do not have this transform in their models), and proper setup of the part config file to specify the transform name for each ModuleDockingPort.  They are all part of the same right-click menu, but my 'multi-docking port' module allows for renaming them, so you would see 'Set Port 1 as Target', 'Set Port 2 as Target', 'Set Port XXXX as Target', etc. (same for undocking; you would see 'Undock Port 1', 'Undock Port 2', etc).  You can also specify a custom 'control from here' transform for each docking port in the part/model (and set custom names through my multi-docking-port module).

 

3 minutes ago, tater said:

@cxg2827 's station parts are pretty fabulous, BTW.

Indeed; I will likely be using them in my station investigations over the weekend.  Very well done looking parts.  I may even use some of the models for the initial prototype part design (through patches/etc; would not be distributing the parts/models).