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

[Shadowmage]

Texture on these is about 1/2 to 3/4 done, but looking pretty good so far:

RL10A-3

RL10A-4

RL10B-2

[blowfish]

You never cease to amaze

[Autochton]

Gotta ask. Does the RL10B-2 stow its outer nozzle enlarger?

[Shadowmage]

Gotta ask. Does the RL10B-2 stow its outer nozzle enlarger?

Both the A-4 and B-2 will feature extendible nozzles (in fact, you won't be able to activate the engine until the nozzle is deployed). Uses/will use a custom animation-aware engine module specifically built for these engines.

[Shadowmage]

'Final' textures for RL10 (a-3, a-4, b-2):

Will likely start working on finishing of the J-2 geometry today, and hopefully get it finished up for this weekends' release as well. Overall a much simpler engine than the RL10 (was a convoluted mess to UV/unwrap/layout), so should be able to get it finished as well. That will leave J-2X and RS-68 (and the custom RS-69 upper-stage derivative) for next week.

I have not heard of any terrible game-breaking problems with the SSTU plugin / custom modules, so I will be doing the official 1.05 update patch for it with this weekends' release as well.

[VenomousRequiem]

Hooray! Can't wait for all of these engines to be released.

[JoseEduardo]

had to make this up

quick question, will you swap the engines in the EUS and ICPS in a future release for this new one?

[VenomousRequiem]

http://i.imgur.com/rGTvmff.jpg

had to make this up

quick question, will you swap the engines in the EUS and ICPS in a future release for this new one?

Nice picture!

I asked him about swapping engines yesterday and he said maybe.

[JoseEduardo]

Nice picture!

I asked him about swapping engines yesterday and he said maybe.

with a engine swap config like the lower stages? if so, sweet

[VenomousRequiem]

with a engine swap config like the lower stages? if so, sweet

I haven't a clue.

[Shadowmage]

with a engine swap config like the lower stages? if so, sweet

-If- I update them it would be set geometry built into to the model exactly as the current engines are.

Chances are though that they will be staying exactly as is; as it would likely require completely redoing their geometry (and as a result, the textures as well) just to make the new engines fit. And I would much rather spend that week worth of time doing the proper customizable upper stage stuff.

So... I'm just going to go ahead and say 'No' at this point. Would be a near-complete waste of time considering the future plans for the mod.

For future reference, I will not change geometry on finished models. As even a minor geometry change requires redoing most of the texturing (at least it requires re-exploding the model, redoing the AO bake, re-combining the model, re-exporting it to Unity, recompiling in Unity for KSP, AND still updating any changed texture stuff; hours worth of work at least). A good deal of the 'optimization' done to models during the last phases of design renders them... mostly unalterable without having to redo a great deal of the initial geometry work. For example, just to change a hose a tiny bit for a 'finished' model, I need to redo the entire bezier path for it from scratch, re-layout control points, re-convert it to a mesh, re-UV the mesh, re-atlas those UVs into the main model (If they fit properly, and it doesn't require re-doing the entire UV layout and texture), re-bake the AO for the entire model, AND still redo the texture for the changed geometry (or whole texture in some cases, if the overall UV layout changed).

Basically it takes longer to -change- an existing finished model than it would to create an entirely new model. As soon as you start seeing preview images with actual color/texure (beyond the raw AO bake), it is already too late for geometry changes. Generally the AO bake stage is the last point at which geometry changes can be made without major impact to the rest of the work-flow/time-to-completion.

Edit:

Rough geometry for J-2 engine. This is prior to doing any of the fittings and/or merging the hoses into the turbos/manifolds in one fashion or another. Still likely another day worth of geometry work before I can start unwrapping. Looking not too bad though. Let me know if you spot anything that looks 'off', as now is about the last opportunity to change anything major.

Edited November 10, 2015 by Shadowmage

[JoseEduardo]

how is the J-2 going? also, are you planning on adding engine mounts for them in this release?

[01010101lzy]

Will there be a somewhat RSS or RO compatible release eventually?(something like 8.4m or 10m tanks and massive engines or so)

[JoseEduardo]

Will there be a somewhat RSS or RO compatible release eventually?(something like 8.4m or 10m tanks and massive engines or so)

Most is included in the latest RO release, you can get WIP versions in the RO repository that adds RO support to the F-1 and F-1B though

and in the RO release there is 5.5, 6.6, 8.4 and 10m tanks plus the ones available in the original pack

[Shadowmage]

how is the J-2 going? also, are you planning on adding engine mounts for them in this release?

Good. Still working on geometry; apparently there was more to do than I had thought, looking quite nice though, will post an updated render a bit later today. Still likely will be available with this weekends update (even if I have to delay the update til Sunday...).

Will there be a somewhat RSS or RO compatible release eventually?(something like 8.4m or 10m tanks and massive engines or so)

As Jose points out, a few nice folks (StratoChief, JoseEduardo, others...) have been nice enough to put together some RO configs, available directly from the RO repository/releases.

Most is included in the latest RO release, you can get WIP versions in the RO repository that adds RO support to the F-1 and F-1B though

and in the RO release there is 5.5, 6.6, 8.4 and 10m tanks plus the ones available in the original pack

And thanks again btw RO/RSS support seems to be the biggest non-mod related request by a large margin.

Been doing some thinking towards the custom upper stage stuff (which will be the next new feature, after another few engines are done), and how to best set it up to be most configurable.

It seems that there are two main varieties of upper stage -- common bulkhead, and split tank, with the split-tank having skeletal and covered varieties. Common bulkhead is most commonly seen with the Centaur series of upper stages (and the ACES concept), while the split tank is what is used for the Delta-IV upper stages (and ICPS/HUS/EUS/etc).

It seems like it should be fairly easy to apply a SSTUCustomFuelTank type module to handle doing mesh-switching w/volume-based resource switching. Might be an even more customized module to handle the upper stages though, as they will have some vastly different requirements compared to the fuel tanks. My biggest quandry at this point is actually deciding if I should try and include both styles in a single part, or have two parts-per-stack-size (one part for common-bulkhead, another for split tanks). In theory, I could put it -all- into a single part (all stack sizes, both varieties), though the GUI/interface might become a bit confusing and cluttered. So, will likely be going with one part per stack size (or two parts per-stack-size, for the different varieties). I also intend for the upper stages to include some form of RCS and/or ullage engines, and may have options for solar panels.

The current idea is that you will be able to select your upper stage part, add it to your vessel, and then customize it to the shape/stats that you want. This will likely be accomplished by using mesh/model switching similar to the fuel tanks, switching in longer or shorter tank models and adjusting attach-node/attached part locations. Additional controls would be available to add/remove/enable/disable the solar panel and rcs options. Will likely come texture-switch enabled, with similar texture sets to the fuel tanks.

Edit:

Updated J-2 Geoemtry -- still have 6 more pipes to join/make fittings for, the gimbal to finish up, and the gimbal actuators(pistons)/mounting brackets.

Further Edit:

Near-final geometry -- all that is left is adding some mounting brackets to things (electronics controls, turbos). Piping and fittings are done, gimbal and pistons are done. Should move on to unwrapping/layout tomorrow, and textures perhaps tomorrow/Saturday/Sunday.

Edited November 12, 2015 by Shadowmage

[Shadowmage]

So... have been reviewing some of the recent changes to other mods that I use heavily, namely MKS and Near-Future. It seems that they have both gone the route of 'forced-extra-part-count' by mandating external radiators to manage the heat on their reactors (Near-Future has always been that way, and as such I've never actually used its reactors).

As I believe forced-extra-part-count is EVIL (at least as long as game performance is part-count limited), I guess it is pretty much mandatory at this point that I create some reactors with integrated radiators. Not sure where I will be able to fit those into my schedule/plans, but will likely come around the time that I am working on the Station Core parts (0.4.x update is when the first set of station parts is intended to be included; 0.3.x will be 'live' once the upper stage stuff has been developed).

May even have some integrated reactor/radiators in some of the other large station parts, to even further reduce part count for stations (a full station with only ~8 parts? unpossible!).

Anyhow, just throwing that out there for now, still have -lots- of time to develop the concept (and to figure out all the other station parts).

[JoseEduardo]

speaking of stations, any station in special in mind? Mir? Mir-2? Salyut? Skylab? ISS? Almaz? Freedom? Tiangong? Skylab II? Exploration Gateway? Eyes Turned Skywars ones? custom design?

I would vote for Mir as Bobcat's one is aging and needs user-made maintenance to keep working

[Shadowmage]

speaking of stations, any station in special in mind? Mir? Mir-2? Salyut? Skylab? ISS? Almaz? Freedom? Tiangong? Skylab II? Exploration Gateway? Eyes Turned Skywars ones? custom design?

I would vote for Mir as Bobcat's one is aging and needs user-made maintenance to keep working

Custom design - modular parts. Some will be inspired by ISS parts, other by Mir, others by the upcoming Boeing/Bigelow inflatables, though I'm hoping to be able to set them all up in such a way as to be usable in whatever station you want to design and be compatible with stock parts. Will likely be a mix of 2.5 and 3.75m parts (with some inflatables going much bigger once expanded).

Current part concepts include:

Multi-Docking-Port Hub - multiple docking ports in the same part. Will likely take advantage of the new stock multi-docking-size functionality for maximum compatibility.

Multi-Axis-Tracking Solar Truss - Will include -large- solar panels with standard sun-tracking, with the entire 'wing' rotating around its Y-axis for a second degree of tracking - may also include radiator parts.

Reactors w/Integrated Radiators - For your extra large/power hungry stations (and bases? might be a separate line of parts for bases).

Science Module - includes basic MPL/MSL functionality, as well as perhaps many/most/all of the science experiments.

Hab Module - includes living space AND life support modules.

Storage Module - An SSTUCustomFuelTank with specialized station-centric models, and a much-expanded resource-switch list. May include some regular tank/container parts, as well as some torus-shaped parts.

Service Module - Propulsion / attitude control, probe core. Might roll this functionality into one of the other modules/all other modules (RCS ports all over the station?).

That is just off the top of my head.

Ideally I'm aiming to bring station part counts down from ~30-40 to more like 10-15 for a 'full' station (including MKS and EPL capabilities). So sick of going to dock to my stations and having the game slow to a crawl because of the crazy part count needed to build any kind of usable station (now if I could just solve the ~60 parts needed to make a basic SSTO problem; though engine clusters might help with that a bit, I'm afraid the symmetry needed will likely still win the battle).

[JoseEduardo]

so, if I understood this correctly, even though it will be custom part it technically would allow to make a Mir for example?

also, one question, Skylab's parasol solar panels are quite unique, would you add something similar to that in the pack?

[riocrokite]

Custom design - modular parts. Some will be inspired by ISS parts, other by Mir, others by the upcoming Boeing/Bigelow inflatables, though I'm hoping to be able to set them all up in such a way as to be usable in whatever station you want to design and be compatible with stock parts. Will likely be a mix of 2.5 and 3.75m parts (with some inflatables going much bigger once expanded).

Current part concepts include:

Multi-Docking-Port Hub - multiple docking ports in the same part. Will likely take advantage of the new stock multi-docking-size functionality for maximum compatibility.

Multi-Axis-Tracking Solar Truss - Will include -large- solar panels with standard sun-tracking, with the entire 'wing' rotating around its Y-axis for a second degree of tracking - may also include radiator parts.

Reactors w/Integrated Radiators - For your extra large/power hungry stations (and bases? might be a separate line of parts for bases).

Science Module - includes basic MPL/MSL functionality, as well as perhaps many/most/all of the science experiments.

Hab Module - includes living space AND life support modules.

Storage Module - An SSTUCustomFuelTank with specialized station-centric models, and a much-expanded resource-switch list. May include some regular tank/container parts, as well as some torus-shaped parts.

Service Module - Propulsion / attitude control, probe core. Might roll this functionality into one of the other modules/all other modules (RCS ports all over the station?).

That is just off the top of my head.

Ideally I'm aiming to bring station part counts down from ~30-40 to more like 10-15 for a 'full' station (including MKS and EPL capabilities). So sick of going to dock to my stations and having the game slow to a crawl because of the crazy part count needed to build any kind of usable station (now if I could just solve the ~60 parts needed to make a basic SSTO problem; though engine clusters might help with that a bit, I'm afraid the symmetry needed will likely still win the battle).

I love your concepts Shadow, also agree on unnecessary part count increase with extra radiators. Below are couple of my thoughts after a quick brainstorming, feel free to ignore if you don't like them:

Multi-Axis-tracking - I would love to implement that for planetary purposes, if there was possibility to implement some kind of limitation (so for example rotate Y axis +50 to -50 degrees, X axis +20 to -30 degrees) it would be cool. Also you might consider having multitracking module version with configurable output resources and configurable body tracking - for example solar tracking focusing mirrors for thermal energy / heat generation (isru purposes) or Kerbal tacking large dishes .

Another thing considering tracking, however might be difficult to implement - would be the ability to specify multiple objects within a part that track stuff, for example multiple solar panels within one part.

Multidocking module - I would love to use some optimized docking port code for my needs, but we already had discussion about it and I understand it's complex matter (KSP hehe) so I won't bother you more

RCS ports - yah it could be cool idea to have them embedded in larger station parts. Personally I think that 4 multidirectional ports placed on a circle around part's CoM should be enough for docking them themselves. Maybe integrated probe core in every large module could also help (so a part alone could be detached and positioned - docked using rcs ports). Also from fuel perspective you might consider either including a monoprop tanks for every part that has embedded rcs thrusters (so no need for more parts with monoprop), or having rcs thrusters use LFO so no need to worry about monoprop at all. I guess the first option would be more consistent with stock

From the looks perspective when we have finished station with multiple docking ports on it, it might look a little bit overloaded, so maybe it would be good idea to make them more embedded in the parts geometry (i.e. similar to shuttle nose).

And the last little thing; you might consider including KIS storage in your resources switch (I think Angel-125 - the dev of Pathfinder and Buffalo - has this already implemented in his mod), so for example one config would be 1000 l for KIS, another config = 500 l for KIS and 500 monoprop, 3rd config = just 1000 monoprop etc.

-------------------------

Just letting you know;

For my mod I'm testing small 'boxy' reactor for vehicles with throttled down output compared to mass (so less radiation area needed) however with integrated radiators on the walls. I plan to make my future reactors much less capable than current ones for NF / MKS (for planetary needs: heavier, safer, fully automatic, require no maintenance, longer periods of operation however no refuelling ability). I'll probably follow RAPID-L derived design, however even more minimized and with less output so around 100 kW for 2t mass.

Edited November 13, 2015 by riocrokite

[JoseEduardo]

expanding the idea of using KIS: Landers could have a module for KIS storage and bring a Lunar Rover with them

[davidy12]

Are there going to be engine mounts for the J-2? Also, are we going to be able to make our own ICPSs?

[Shadowmage]

expanding the idea of using KIS: Landers could have a module for KIS storage and bring a Lunar Rover with them

Already on the todo list, see the OP; planned for the 0.4.x release (LC skycrane and service modules).

Are there going to be engine mounts for the J-2? Also, are we going to be able to make our own ICPSs?

Yes, and yes. But not in this release. Mounts will likely come next week, upper stage stuff whenever it is ready.

so, if I understood this correctly, even though it will be custom part it technically would allow to make a Mir for example?

also, one question, Skylab's parasol solar panels are quite unique, would you add something similar to that in the pack?

Recreating real-world stations is not the intention of the parts, so no guarantees. I'm merely using existing real-world designs to as a basis for the parts (as ksp is a physic simulator, you generally want things with at least some minimum level of physical accuracy / plausibility).

Solar panel designs -- maybe, if I find a need for them. However, as stated, I'm not trying to enable recreations of real world/historic stations, I'm trying to reduce station part count and make them usable in game with ships docked at them.

So... don't get your hopes up that I'm making a bunch of ISS or Mir or whatever parts. I'm not. I'm making general station parts that will draw some design inspiration from modules from those stations. I really have no interest in enabling recreations of real world designs on anything (far too use-limited, impossible to balance in stock KSP, lack of compatibility). However, I will use real-world designs as the basis / inspiration / reality check for many of the parts that I make. If in doing so I happen to enable some historic recreations... it is merely an unintended bonus.

- - - Updated - - -

I love your concepts Shadow, also agree on unnecessary part count increase with extra radiators. Below are couple of my thoughts after a quick brainstorming, feel free to ignore if you don't like them:

Multi-Axis-tracking - I would love to implement that for planetary purposes, if there was possibility to implement some kind of limitation (so for example rotate Y axis +50 to -50 degrees, X axis +20 to -30 degrees) it would be cool. Also you might consider having multitracking module version with configurable output resources and configurable body tracking - for example solar tracking focusing mirrors for thermal energy / heat generation (isru purposes) or Kerbal tacking large dishes .

Another thing considering tracking, however might be difficult to implement - would be the ability to specify multiple objects within a part that track stuff, for example multiple solar panels within one part.

Multidocking module - I would love to use some optimized docking port code for my needs, but we already had discussion about it and I understand it's complex matter (KSP hehe) so I won't bother you more

RCS ports - yah it could be cool idea to have them embedded in larger station parts. Personally I think that 4 multidirectional ports placed on a circle around part's CoM should be enough for docking them themselves. Maybe integrated probe core in every large module could also help (so a part alone could be detached and positioned - docked using rcs ports). Also from fuel perspective you might consider either including a monoprop tanks for every part that has embedded rcs thrusters (so no need for more parts with monoprop), or having rcs thrusters use LFO so no need to worry about monoprop at all. I guess the first option would be more consistent with stock

From the looks perspective when we have finished station with multiple docking ports on it, it might look a little bit overloaded, so maybe it would be good idea to make them more embedded in the parts geometry (i.e. similar to shuttle nose).

And the last little thing; you might consider including KIS storage in your resources switch (I think Angel-125 - the dev of Pathfinder and Buffalo - has this already implemented in his mod), so for example one config would be 1000 l for KIS, another config = 500 l for KIS and 500 monoprop, 3rd config = just 1000 monoprop etc.

-------------------------

Just letting you know;

For my mod I'm testing small 'boxy' reactor for vehicles with throttled down output compared to mass (so less radiation area needed) however with integrated radiators on the walls. I plan to make my future reactors much less capable than current ones for NF / MKS (for planetary needs: heavier, safer, fully automatic, require no maintenance, longer periods of operation however no refuelling ability). I'll probably follow RAPID-L derived design, however even more minimized and with less output so around 100 kW for 2t mass.

Multi-Axis Tracking -- hmm.. some interesting ideas. Will give them some thought when I'm working through the station parts. Really though, the solar-panel module is designed specifically for solar panels, so much of that stuff is already out of consideration. Would be simple enough to write plugins for those other functions if I ever found a need for them.

Multi-tracking within a part -- already implemented; see the SC-B-SM (has four solar panels in it), and the LC-DSP (deployable solar panel module in the fuel sections; has four panels in it as well). The lander-core pods also have multi-panel-aware modules; and actually use multiple raycasts/transforms to determine output from their 'curved' panel sections.

Multi-docking module -- I already have the stock-derived multi-docking-port module written and working (as far as I know), I just haven't had time to make the actual parts for it yet. So, if you need a multi-docking-port part/module, let me know and I can go through the instructions / make sure it actually is working.

KIS -- As 'KIS storage' is not a resource, it won't really work in that manner. Would require a ton of effort just to add support for -just that mod- (lots of special casing/extra stuff that would be useless/wasted when KIS was not installed). Even less important as there are already dedicated KIS containers in multiple sizes, from many other mods. When stock includes KIS functionality / it is an always present capability, at that point I will consider adding a resource-switch option for it.

Edit:

'Final' geometry for J-2 engine. It is by a good margin the most detailed geometry that I have done to date. Actually had to spend a bit of time the past few days to cut out some polys to keep it in the 'sane' range.

Will be moving on to UV unwrap/layout/AO bake today, and texturing perhaps tomorrow and Sunday mornings.

Edited November 13, 2015 by Shadowmage

[riocrokite]

hey Shadow, thx for replying,

as always awesome modelling with J-2:)

If you had time to provide me with the code of multidocking module I could create a part and test it myself

[Shadowmage]

hey Shadow, thx for replying,

as always awesome modelling with J-2:)

If you had time to provide me with the code of multidocking module I could create a part and test it myself

The module is quite simple; its an extension of the stock module with an additional field to name the port with a unique name. It is already included in the SSTUTools.dll plugin that is distributed with SSTU.

Basically, take the stock docking port module config, change the 'name' field to SSTUMultiDockingPort, and add the 'portName' field with whatever you want that port to be called. Requires one module per-docking port. So, if your part has 5 ports, it will need 5 modules. Each module needs a unique docking transform, and adding a unique 'control' transform is also possible (so the 'control from here' option works properly).

The -very- short source for the module can be found at:

https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUMultiDockingPort.cs