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

[RedParadize]

@PappysteinAnd thats why I don't use CKAN. 

For your testing. If you use HyperEdit, quicksave and reload after editing. It fix most of the bugs (as far as I know). If you still incounter the bugs, do the same test in a regular lunch or on the ground with as few part as possible. And if you still have the same issues, make sure to provide your output_log!

[Pappystein]

Just now, RedParadize said:

@PappysteinAnd thats why I don't use CKAN.

 

I had never tried it before and was giving it a go.    It is now GONE

I don't know/Don't think Hyperedit was the cause of most of my problems as I was not using it (it was installed but no functionality was used to launch the station parts.)   I DID use MechJeb for circulation and plotting maneuvers to build the station.    Quick saving Did NOTHING in my case (leading me to believe it is a different mod interaction.)  

 

Lastly for all my years playing this game (3 now I think?)   I have never looked for the logs.   I found it with a ton of NREs for FAR.... almost 87mb of NREs for FAR.  Awaiting on KSP launch with new version and slimmed down mod list.

 

[Shadowmage]

23 hours ago, RedParadize said:

[...]

Do you think it will eventualy possible to have integrated docking port on the sides of the adapter 3?

Certainly in the realm of doable from a technical standpoint, and I've considered doing as much for at least the stand-alone hub parts (ST-HUB-XXX).  Would be nice to extend that to the station-core parts, as most/all of them will have one hub or another as an adapter choice.

There is one big usability problem though that I haven't quite worked out yet -- the UI.  For the DOS/COS/HAB station parts with top and bottom hubs, it would require adding an additional 8 in-editor port selection sliders + 16 stock in-editor toggles on the ports (staging and crossfeed).  In flight you could have up to an additional 24 UI lines from the stock port options (crossfeed, staging, control-from-here, x8 additional ports).  Those are on top of already quite busy parts, UI-wise.   For the HUB parts it wouldn't be too terrible as they are only 5-6 ports and the part has no other functions.  On the HUB parts it would only add a total of 5-6 UI lines, and only in the editor; all other UI options already exist on the parts in their current state.

So, from a usability standpoint, I would say it is a bad idea to integrate them into the DOS/COS/HAB end-cap-hubs.  The stand alone ST-HUB-DOS already exists for this purpose; it is one additional part per hub, but makes for a nice clean separation of function and easier to use UI's.  Whether I add the port swapping function to the HUB parts... still thinking on it... it would require a new module specifically for the purpose, but could be quite a bit simpler (would only switch port models, transform locations, and a few module settings, with no support for any 'no port' options, so no module-switch functionality would be needed).

 

1 hour ago, Pappystein said:

 

Sorry for the work then.  I had hoped that someone else was having problems, hence posting.   I am downloading the latest update and have cleaned out MOST of the mods I have in my build.

I WAS using CKAN for the first time ever with this iteration of the game.   I found a bunch of crap that was never deleted by CKAN out of my GameData folder.   It is all gone.  I went down from 57 mods to 9 not counting SSTU.  I will post after further testing.   If it is any of these mods it should show up quickly in sandbox.

 

 

No worries, I was already doing general docking testing on parts over the weekend so wasn't too hard to add some surface mounted ports into the testing.

If you can narrow it down, please let me know what you come up with for craft/steps/mods.  There very likely are bugs with the docking ports that I simply haven't encountered yet in my testing and craft designs.  Even if you do find that it was another mod conflicting I would be interested in knowing that; most of the time I can find the cause and implement some sort of solution once I know which mod it is. 

Thanks for you help in tracking the problem down, hopefully your testing will have more informative results that can allow for some fixing to be done

[tater]

When selecting an integrated docking port as a target, I literally flip a coin because I can never for the life of me remember top vs bottom. Guess I should make sure I have a flag on them.

[Pappystein]

41 minutes ago, Shadowmage said:

No worries, I was already doing general docking testing on parts over the weekend so wasn't too hard to add some surface mounted ports into the testing.

If you can narrow it down, please let me know what you come up with for craft/steps/mods.  There very likely are bugs with the docking ports that I simply haven't encountered yet in my testing and craft designs.  Even if you do find that it was another mod conflicting I would be interested in knowing that; most of the time I can find the cause and implement some sort of solution once I know which mod it is. 

Thanks for you help in tracking the problem down, hopefully your testing will have more informative results that can allow for some fixing to be done

I have sent you a link with photos from the previous release as well as current release as well as log files from both.    Yesterdays log files were spammed with 87mb of FAR NREs but I don't think that was the cause as I have removed FAR and am still having issues.

 

One possibility...   just RE RE validated game cache after I uninstalled the 45 mods I removed.   5 files failed their validation.

Sending link and then re-testing game

 

[StickyScissors]

@Shadowmage Am i correct in assuming that with the latest update note "FIX - Node specifications for many hub adapters" will fix this issue. I'm on the last update, not the latest (data cap ).

[Shadowmage]

1 minute ago, StickyScissors said:

@Shadowmage Am i correct in assuming that with the latest update note "FIX - Node specifications for many hub adapters" will fix this issue. I'm on the last update, not the latest (data cap ).

 

Yes, exactly that.

If you want you can replace just the model-data file for those adapters with the updated/fixed one from the release repository ( https://github.com/shadowmage45/SSTULabs/raw/master/GameData/SSTU/Parts/StationCore/ST-ADPT/ModelData-ST-ADPT.cfg )  (or otherwise manually fix the nodes).  That single text file should be almost unnoticeable from a data-use perspective.

[tater]

After some docking testing, I did my first munar landing of this 6.4X career. The 2-stage lander I built was a little OP---I staged it after munar liftoff---, but it turned out useful as my KOR/MOR mission profile with a hydrolox munar injection stage was little under designed for contingencies, so I used the remaining hypergolics on the munar ascent stage for the trans-kerbin burn, then the CSM for setting up my EDL. Had 200 m/s left over.

(yeah, I guess I didn't really need the fuel lines, I could have enabled crossfeed, but old habits die hard). It uses and lr-81 attached to the ascent stage, but at 6.4X, it's a little underpowered. Landing from a low munar orbit was a little scary. 

 

OTW home.

[Fobok]

Ok, that screenshot (plus my own disastrous mun mission today which cost me the lives of Bill and Bob and /tons/ of science and cash) changed my mind. I'm trying this mod, WIP though it may be. This whole thing looks so amazing.

[tater]

The entire mission had 4 non-SSTU part types in it (6 total parts), all visible in the 2 images above (and I didn't need the fuel lines I guess, dropping it to 4 total parts).

[falken]

I was having real trouble translating with the Apollo + CSM, until I realised that I should turn off the RCS on the command module and let the CSM RCS handle that.

 

[tater]

If you hit the fine mode control for RCS, it balances RCS for translation. That's my understanding, anyway.

It would be cool to have some simple color choices for the LC parts. All white for the crew section, and perhaps white or gold foil for the tanks as an option.

[falken]

I put together a quick resupply module using SSTU parts for the propulsion system, which now serves as my current space station command module.

I'd quite like to see a stubby CSM for the Apollo, like this: 

[VenomousRequiem]

10 minutes ago, falken said:

I'd quite like to see a stubby CSM for the Apollo, like this: 

We'll have one of those in BDB pretty soon.

[RedParadize]

37 minutes ago, tater said:

It would be cool to have some simple color choices for the LC parts. All white for the crew section, and perhaps white or gold foil for the tanks as an option.

I think that the same mechanics tanks currently use is preferable. You can still chose to give fuel section a different color, or go for everyones the same if you wish. Its less restrictive that way.

Regarding service module.  As they are right now it is much better to use a SSTU tanks + engine, they are lighter, contain more resource for similar volume and you can put a better engine behind them.  In my custom SSTU build I buffed them quite allot. I think its something that should be done as well in stock SSTU.

Edited August 30, 2016 by RedParadize

[tater]

1 hour ago, RedParadize said:

I think that the same mechanics tanks currently use is preferable. You can still chose to give fuel section a different color, or go for everyones the same if you wish. Its less restrictive that way.

? The LC tanks are always orange, no? The LC pods are always gray, with orange tanks. I was merely discussing the texture map. The other tanks have white, striped, orange, green, etc, all available. The crew parts, OTOH, currently have no texture options (and that might not be possible, or it might be more complex because of details on their surfaces, I don't know). I could see the Soyuz parts as having some color options as well. I've seen them painted a few colors, or with various thermal blankets (green, gray, silver, black).

Quote

Regarding service module.  As they are right now it is much better to use a SSTU tanks + engine, they are lighter, contain more resource for similar volume and you can put a better engine behind them.  In my custom SSTU build I buffed them quite allot. I think its something that should be done as well in stock SSTU.

I used a regular SSTU upper stage tank (with RCS). The engine in my image above is actually a vacuum Merlin.

 

BTW, @Shadowmage, the Progress (SMX?) craft also shows up as "Debris" instead of as a probe or craft.

 

For 6.4X people: I was experimenting with 6.4X some more, and I made a Soyuz replica to test what worked in the upscale (with FAR). I have SMURFF on, but I'm not sure if it does much with SSTU, frankly. Suffice it to say that with SMURFF on default, a Soyuz replica (I'm a little unsure on the upper stage just below Progress) I just got it into a 100-something km orbit (I wanna say it was like 180x147). I have propellant in the SM to clean up the orbit, and to reenter (300 something m/s). If SMURFF on default is indeed doing nothing with SSTU, SSTU must be perfectly scaled to 6.4x out of the box, as it were.

 

Probe core:

Obviously the probe core ring part is copied from the decoupler. It could use the same texture options  .

Other observations on that part:

1. the attachment node doesn't seem to scale with size---does that affect joint strength?

2. Could it get a minimal flywheel as a toggle? That would be useful for small probes, particularly given how flakey RCS can be.

3. Can core parts change shape? Ie: could you borrow the octogon shape you just added as an option for the probe core?

Edited August 30, 2016 by tater

[RedParadize]

45 minutes ago, tater said:

? The LC tanks are always orange, no? The LC pods are always gray, with orange tanks. I was merely discussing the texture map. The other tanks have white, striped, orange, green, etc, all available. The crew parts, OTOH, currently have no texture options (and that might not be possible, or it might be more complex because of details on their surfaces, I don't know). I could see the Soyuz parts as having some color options as well. I've seen them painted a few colors, or with various thermal blankets (green, gray, silver, black).

Thats not what I said.

From what I understood, you wanted a texture switch that follow content type. My answer is it should be selectable just as regular SSTU tank. Sorry if I was not clear.

 

45 minutes ago, tater said:

For 6.4X people: I was experimenting with 6.4X some more, and I made a Soyuz replica to test what worked in the upscale (with FAR). I have SMURFF on, but I'm not sure if it does much with SSTU, frankly. Suffice it to say that with SMURFF on default, a Soyuz replica (I'm a little unsure on the upper stage just below Progress) I just got it into a 100-something km orbit (I wanna say it was like 180x147). I have propellant in the SM to clean up the orbit, and to reenter (300 something m/s). If SMURFF on default is indeed doing nothing with SSTU, SSTU must be perfectly scaled to 6.4x out of the box, as it were.

If you want I have MM for 6.4x that adjust every engine separately. I must warn you that it is balanced to my personal taste. For example the RL-10 have more trust than it should. I am not that patient when manoeuvring. I have been thinking about doing a more simple MM that multiply trust and ISP, divide mass by using a single formula applied to all. The thing is It won't work correctly for every part (and also won't adjust it to my taste). @falken  Is also looking for something like that, so I might end up doing it anyway. It will end up looking like the global MM patch near future propulsion have.

I also have few custom tank setup like shielded, carbon, and carbon shielded. They are more expensive than original and sadly they are available at start in campaign... I also added some engines variant , pods that are just KIS cargo, buffed SM... extra tank resource type for Kerbalism, NFP NFF and probably other thing that I forgot about.

Edited August 30, 2016 by RedParadize

[tater]

2 hours ago, tater said:

If you hit the fine mode control for RCS, it balances RCS for translation. That's my understanding, anyway.

It would be cool to have some simple color choices for the LC parts. All white for the crew section, and perhaps white or gold foil for the tanks as an option.

 

19 minutes ago, RedParadize said:

Thats not what I said.

From what I understood, you wanted a texture switch that follow content type. My answer is it should be selectable just as regular SSTU tank. Sorry if I was not clear.

What I said is written above. I said nothing at all about tank content.

 

19 minutes ago, RedParadize said:

If you want I have MM for 6.4x that adjust every engine separately. I must warn you that it is balanced to my personal taste. For example the RL-10 have more trust than it should. I am not that patient when manoeuvring. I have been thinking about doing a more simple MM that multiply trust and ISP, divide mass by using a single formula applied to all. The thing is It won't work correctly for every part (and also won't adjust it to my taste). @falken  Is also looking for something like that, so I might end up doing it anyway. It will end up looking like the global MM patch near future propulsion have.

I also have few custom tank setup like shielded, carbon, and carbon shielded. They are more expensive than original and sadly they are available at start in campaign... I also added some engines variant , pods that are just KIS cargo, buffed SM... extra tank resource type for Kerbalism, NFP NFF and probably other thing that I forgot about.

I'd like to see carbon fiber tanks at some point... the dry mass savings for composites is probably pretty decent, and it all adds up, particularly at the top of the stack. 

I used to use KIDS for upscales. When I get sick of 6.4X and start messing with RSS/RO I'll likely have to dive in and figure out what to do with SSTU for that myself, as I honestly don't use other parts at this point, they are too limiting/painful compared to SSTU. 

Since @Shadowmage has added a number of SpaceX engines, perhaps we'll see a Raptor once the crazy BFR/MCT concept is announced on Sept. 27. Looks like my retro-future dreams of 1963 VTVL monster rockets have someone actually working on them now... interesting times.

 

[RedParadize]

@Shadowmage Just a trough, I know its realy early but do you think the future mechanic to make a ring in orbit would also work on the ground?

I always wanted to have a very simple ground base setup. Like a single part that do it all.  With your future deployable centrifuge mechanic, I think it could be possible. Something like a relatively light core module would be drop on a planet, then it would require like 200 tons of non extractable material to make it fonctional. Once fonctional it would hold +20 kerbal and have EPL lunchpad capacity. I am obviously not asking you to create that part. But it would be cool if your code would allow that eventuality.

[StickyScissors]

Not sure if this is a problem that shadow can solve, but holy god does the game drop to 5 seconds per frame when i try to use KVV with a craft that has station parts involved.

Upon activating KVV, the log is annihilated with:

[Log]: [Warning] KRSVesselShotNo replacement for Standard (UnityEngine.Shader) in SSTU-ST-GEN-DSP-DOS-M (Part)/*/ST-GEN-DSP-2.000 (UnityEngine.MeshRenderer)

or some very similar variation of it for each station part on the vessel.

[Shadowmage]

On Monday, August 29, 2016 at 6:20 PM, Pappystein said:

I have sent you a link with photos from the previous release as well as current release as well as log files from both.    Yesterdays log files were spammed with 87mb of FAR NREs but I don't think that was the cause as I have removed FAR and am still having issues.

 

One possibility...   just RE RE validated game cache after I uninstalled the 45 mods I removed.   5 files failed their validation.

Sending link and then re-testing game

 

Thanks for the info;  I took a look at the logs and did not see any null-refs that would have caused any problems, or anything else worrisome.

I'll take some time a bit later this week to do more testing on the docking ports.

One thing that would help would be craft files that are known to have the problem.  Do you have any stock+SSTU craft that exhibit the issue?  (mostly asking as my previous attempts to duplicate this issue with self-built craft did not exhibit any problems.)

 

21 hours ago, falken said:

I'd quite like to see a stubby CSM for the Apollo, like this: 

You and quite a few other people

I have no problem with the part in concept -- my problem is with the texturing.  Do you guys really want another 1024x texture for a single-use part?  (it won't fit on anything smaller at the same texture scale as the existing parts, nor can it re-use the existing texture).

Aside from the texturing, the rest of the part presents no problem aside from time constraints (I actually put together test geometry for it in a about 5 minutes yesterday, to see if it could re-use the existing textures).

 

20 hours ago, tater said:

? The LC tanks are always orange, no? The LC pods are always gray, with orange tanks. I was merely discussing the texture map. The other tanks have white, striped, orange, green, etc, all available. The crew parts, OTOH, currently have no texture options (and that might not be possible, or it might be more complex because of details on their surfaces, I don't know). I could see the Soyuz parts as having some color options as well. I've seen them painted a few colors, or with various thermal blankets (green, gray, silver, black).

[...]

BTW, @Shadowmage, the Progress (SMX?) craft also shows up as "Debris" instead of as a probe or craft.

[...]

Probe core:

Obviously the probe core ring part is copied from the decoupler. It could use the same texture options  .

Other observations on that part:

1. the attachment node doesn't seem to scale with size---does that affect joint strength?

2. Could it get a minimal flywheel as a toggle? That would be useful for small probes, particularly given how flakey RCS can be.

3. Can core parts change shape? Ie: could you borrow the octogon shape you just added as an option for the probe core?

SMX -- noted.  Will get that fixed up for the next release

Probe core textures -- noted.  They merely need the patch set added that will add the texture sets (the switching functionality is already in-place, but hidden unless multiple texture sets are enabled for the part).

Attach Node -- as far as I know node strength has nothing to do with node size, at least not through any of the testing I've done.  I could be wrong, but there is no way to know for certain without source-access to the stock code (or direct dev response to the question).

Reaction wheel -- I prefer it didn't have one.  Easy enough to patch in though if you really need it.

Different shapes -- negative, at least with the current setup.  Certainly possible from a technical standpoint (though would require a new module to manage it).  I had considered making a simple model-switch-and-rescale plugin for the decouplers, and if/when I do I will likely do the same for probe cores.  For now though they use the procedural mesh-generation code which is incapable of any form of model switching or different shapes.

19 hours ago, tater said:

 

[...]

Since @Shadowmage has added a number of SpaceX engines, perhaps we'll see a Raptor once the crazy BFR/MCT concept is announced on Sept. 27. Looks like my retro-future dreams of 1963 VTVL monster rockets have someone actually working on them now... interesting times.

 

Maybe... if/when they release some diagrams/schematics of the engine.  So far there is pretty much nothing usable available as far as modeling resources go (I don't even think the designs are finalized yet?)

 

15 hours ago, RedParadize said:

@Shadowmage Just a trough, I know its realy early but do you think the future mechanic to make a ring in orbit would also work on the ground?

I always wanted to have a very simple ground base setup. Like a single part that do it all.  With your future deployable centrifuge mechanic, I think it could be possible. Something like a relatively light core module would be drop on a planet, then it would require like 200 tons of non extractable material to make it fonctional. Once fonctional it would hold +20 kerbal and have EPL lunchpad capacity. I am obviously not asking you to create that part. But it would be cool if your code would allow that eventuality.

Yes, that plugin will work just fine for ground bases.  While it is called SSTUInflatable (for lack of a better name), all it really does is block of the playing of an animation until a certain number of resources are consumed.  As such it can work for... whatever

However it -cannot- disable a part entirely; your example part with the EPL launchpad would -still- have the launchpad capability while deflated/before construction.  Though it would have zero crew capacity.  In short -- that module controls an animation, and does not do any form of module-switching.

The only (stock compatible) way to do that would be to replace the part wholesale; rather than play an animation it would destroy the current part and create/insert the replacement part (where the replacement part has all the functional modules, the base pre-inflated part only has the inflatable module).  Would be hacky as hell, result in tons of extra parts in the editor and research tree...  not really anything I'm interested in implementing.

 

14 hours ago, StickyScissors said:

Not sure if this is a problem that shadow can solve, but holy god does the game drop to 5 seconds per frame when i try to use KVV with a craft that has station parts involved.

Upon activating KVV, the log is annihilated with:

[Log]: [Warning] KRSVesselShotNo replacement for Standard (UnityEngine.Shader) in SSTU-ST-GEN-DSP-DOS-M (Part)/*/ST-GEN-DSP-2.000 (UnityEngine.MeshRenderer)

or some very similar variation of it for each station part on the vessel.

That is due to KVV not supporting the Unity Standard Shader.  Nothing I can do about that.

Your option there is - don't use KVV with the unfinished/prototype parts.  Those are the only parts that use the standard shader, as they are placeholder parts.  They will receive proper shaders/material setups as the parts are finished.

 

20 hours ago, tater said:

? The LC tanks are always orange, no? The LC pods are always gray, with orange tanks. I was merely discussing the texture map. The other tanks have white, striped, orange, green, etc, all available. The crew parts, OTOH, currently have no texture options (and that might not be possible, or it might be more complex because of details on their surfaces, I don't know). I could see the Soyuz parts as having some color options as well. I've seen them painted a few colors, or with various thermal blankets (green, gray, silver, black).

LC stuff -- once again, I'm not touching any of those parts for a few months at least.  At which point it will be a complete re-do/reworking on all of those parts (pods, tanks, legs, accessories).

 

Texture swapping on other parts (CM/SM/Etc) -- possible, but would quickly result in a 500mb download.  Each extra texture set for those parts adds 3-5mb per part (they are not small textures); multiply that out by 3-4 parts per series, 4 series of parts, = 4*4*5 = 80mb per additional set of textures for the ShipCore parts.  If I added 3 texture options for each ShipCore part, you would have an additional ~250mb of textures.

I don't really have a problem with the download size... bandwidth is not as much of a problem as it was a decade ago.  Rather I'm worried about overall GPU memory use... it is a finite resource that must be shared with stock resources and all other mods.  I'm pretty sure KSP loads -all- textures into the GPU, and there is only limited GPU memory available.

If someone can provide verifiable proof that Unity is smart enough to dynamically upload textures to the GPU on a per-scene/as-needed basis (and thus the memory limit is per-scene, and not global), I would be much more willing to support further-reaching texture-swapping capabilities for other parts (still don't have time to make the textures... but at least I would be willing to if/when the time is found).

[JoseEduardo]

35 minutes ago, Shadowmage said:

You and quite a few other people

I have no problem with the part in concept -- my problem is with the texturing.  Do you guys really want another 1024x texture for a single-use part?  (it won't fit on anything smaller at the same texture scale as the existing parts, nor can it re-use the existing texture).

Aside from the texturing, the rest of the part presents no problem aside from time constraints (I actually put together test geometry for it in a about 5 minutes yesterday, to see if it could re-use the existing textures).

I was going to ask if that is possible

btw, apparently that engine is a LMDE, but if I could ask, could you leave the SM without engines?

[Shadowmage]

Made fairly significant progress on the UV unwrap and layout on the DOS parts over the last couple of days.

Have a -tiny- bit more texture space available that I can use for additional detail geometry, on the order of some ladder rungs/hand-holds, or other small geometry-based details.  Quite a bit of 'greeble' type details are going to be added through the textures (paneling lines, perhaps some wires or hoses and such); these are done at a reasonable-enough texture scale that I can get decent details in the normal and diffuse textures.

So -- last call on opinions/requests/desires for geometry based details on the DOS modules.  By Friday I expect that I'll have the models to a state where any additions will be prohibitive and will be very hesitant to make any geometry changes after that -- so if you have any requests, please put them forward now   (also please be specific/include examples, I'm really not very good at coming up with random greeble on my own... my mind merely doesn't work that way).

Current geometry with initial first-pass texturing (flat diffuse+AO only, very basic/unfinished normals on the radiators, no spec mask, no noise, and nothing finalized yet):

 

 

[CobaltWolf]

42 minutes ago, JoseEduardo said:

I was going to ask if that is possible

btw, apparently that engine is a LMDE, but if I could ask, could you leave the SM without engines?

can you provide a source for that? I thought it was supposed to be an LMAE.

[falken]

Those look good Shadowmage, and they look like they'd fit in with CXAerospace & Habtech quite nicely.

On the subject of the stubby eyes turned skywards Apollo CSM, if you're reluctant to make a single use part that uses a texture like that, how about as a compromise another semi-procedural tank that doesn't have the piping on the side?

All in all, I can live with the true to life CSM, it is very nice.