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

[Shadowmage]

3 hours ago, Pappystein said:

In the short term I am worried about stand alone but longer term the whole shebang.   So basic +PART for stand alone and the copy paste the module for the complex parts is what you are saying?

 

 

Yes, for cloning the stand-alone parts at custom diameters -- take a look at the differences between the DP-1 and the DP-0.  They both use the same MODEL, but use different scalings/positions.  Notably the parachute has a bunch of stuff that will need adjusted for the scale.

For cloning/making new models for the station-core part use, it would be much as I explained in the earlier post -- clone the SSTU_MODEL, and update the various fields for the new scale.

[Shadowmage]

On 5/15/2017 at 3:50 PM, RedParadize said:

@Shadowmage Hi, I would have love to test your new stuff, but I have been quite busy lately... Anyway I do not consider myself as reliable enough to do this. About updating prior to 1.3, you do not have to, the current release is more than ok for anyone that would wish to stick with 1.2.2. Unless you think a release prior to 1.3 does not represent extra work, I would advocate against it. I am sure you could use that time on something more useful (or just relax really).

I have been playing around and trying to make a ship that enter the atmosphere like a space shuttle but landing vertically, like the SpaceX ITS but much smaller. It got me thinking about your plan on doing the aeroshell thingy as it could probably do something similar. What I previously posted about it was way to ambitious to be made, there is definitively something to be done with much more simple mechanics while remaining customizable.

No worries on the testing; I fully understand having a busy schedule

Releasing for 1.2.2 would be zero extra work -- my dev setup is still using the KSP-1.2.2. libraries.  My main point of hesitation on doing it for 1.2.2. it is that it -will- be craft/save breaking.  Perhaps if it gets to a more stable point, and we are still waiting for KSP-1.3, I'll look into packing up official/public 'testing' releases of the new version for use with KSP 1.2.2. -- if nothing else it would help make sure there are no more breaking changes when things are updated for 1.3.

 

Atmospheric horizontal landers -- yeah, I'm still giving them a bit of thought.  Still not sure how to handle the aeroshell setup and/or if it will even work in KSP (might end up being a visual-only thing, KSP's drag system really can't accommodate partial shielding). 

Ideally I would like to make a new stand-alone 'aero-shell' part, that could be resized and customized for use with any payload/lander setup; alternatively it might be procedurally-generated fairing, using the existing procedural generation code.  The big problem either way still comes back to how to handle holes for engines/etc -- such a setup almost needs to be part-specific, with no support for scaling or customization.

 

 

General Development Updates:

Still more recoloring system work.  The last few days saw the MSRBs converted to allow for recoloring (plugin/textures/configs).  Possibly a few config-level things to adjust on them, but they are working and finished from a functionality perspective.

Yesterday's work went into converting the NodeFairing system to allow for recoloring -- updating the plugin, texture set configs, and remaking the actual textures.  Seems likely that I'll be upping the texture resolution on them, at least doubling it in the X-axis, which should reduce the 'blur' between different colored sections, and bring the texture density-per-meter closer to what is used by the rest of the parts (it is currently about 1/4 to 1/2 density compared to tanks/etc).

Today's work is going into code-side changes to allow for recoloring on the rest of the procedurally generated parts (ISDC, IPA, PDC, PPC).  Progressing well so far, hoping to get them finished up this afternoon/evening.

Once those parts are finished the last parts needing reworking will be the StationCore series of parts.  Will likely be doing a fairly simple initial set of textures for these, probably consisting of only a single mask / set of textures (except those where multiple sets already existed -- COS/DOS).  Can always add more masks/sets at a later time now that all the rest of the support is in place.

 

In regards to RO / RSS / RealFuels / FAR compatibility (as I keep seeing this stuff pop up) -- is there anyone who regularly uses the RO suite and wouldn't mind getting their hands dirty with a bit of compatibility testing, and who is also familiar with the RO patch setup?  I would like to do a pass over the SSTU plugin code to make sure there are no low-level incompatibilities, but the amount of setup time needed to do even simple testing on it has been prohibitive, and my lack of familiarity with the use/setup of RealFuels has not been helpful either.

Basically what I'm asking is -- is there anyone out there who would like to undertake the role of being the SSTU-RO compatibility master?  (possibly I should ask in the RO thread?)    Duties/tasks would include setting up configs, fixing configs, submitting PRs to RO to merge configs, keeping track of/responding to any SSTU-RO issue tickets (on either repository), and working closely with me during development and testing to iron out any plugin-side changes or fixes that need to be made. 

If there is anyone interested in contributing to the SSTU-RO compatibility setup, please send me a PM and we can discuss it further / work out the rest of the details.  This would hopefully allow me to move RO/RSS/RF/FAR support from the 'unsupported - bugger off' state that its currently in, into a more friendly, organized, and officially supported state.

[ThePhoenixSol]

SSTU doesnt like G-Effects It lowers my fps majorly

[RedParadize]

12 hours ago, ThePhoenixSol said:

SSTU doesnt like G-Effects It lowers my fps majorly

That does not sound like a SSTU problem, at least I never had that issues, on my side everything always have been faster because I have much less part that what I would have without SSTU. (still have some vessel that dash in the 100 part)

Did you check your log? 

 

[ThePhoenixSol]

15 minutes ago, RedParadize said:

That does not sound like a SSTU problem, at least I never had that issues, on my side everything always have been faster because I have much less part that what I would have without SSTU. (still have some vessel that dash in the 100 part)

Did you check your log? 

 

yes i checked the log, nothing was giving off errors. and its likely a SSTU issue, because the game runs fine with G-Effects in, its just when G-effects and SSTU are both in at the same time. And I have no issue with SSTU without G effects, the low part count helps a lot.... i was saying that the issue was when they were both installed.

Things i checked:

Logs - no errors at all

parts - 1, stock mk1 command pod

the issue only appears when G effects is added

was testing with a brand new save, and 100% fresh ksp install.

(thought i had posted this stuff, guess i forgot to, my bad.)

 

[RedParadize]

@ThePhoenixSol The thing is, we can't help you unless we have some stuff to work with, usually log reveal the source of the problem. Normally, G lag happen when you have too much part to simulate, SSTU or not. Your problem could be elsewhere, I suggest testing stock ships that have a similar amount of part and mass and see if it lag too. I am pretty sure it will. If it doesn't, we will still need your log, Shadowmage can't just look at its code and magically find the source of the problem, if there is.

[ThePhoenixSol]

1 minute ago, RedParadize said:

@ThePhoenixSol The thing is, we can't help you unless we have some stuff to work with, usually log reveal the source of the problem. Normally, G lag happen when you have too much part to simulate, SSTU or not. Your problem could be elsewhere, I suggest testing stock ships that have a similar amount of part and mass and see if it lag too. I am pretty sure it will. If it doesn't, we will still need your log, Shadowmage can't just look at its code and magically find the source of the problem, if there is.

i repeat. log would be useless.... i read through it all, with no errors, ksp doesnt even know its having an issue..... and again, i tested with the stock mk1 command pod... i already tested stock things with similar amount of parts... 1 part... the issue is not related to part count. its the weirdest issue i have seen in any game/mod, wont be easy to find the issue, but i figured shadow should know it existed. And as a programmer i know you cant magically find the issue, but sometimes you dont have enough feedback to find out how to fix it.... its part of the hobby/job.... best he can do is run both mods at the same time himself, and try to make ksp output a more detailed log(like crash logs) and that MAY show him something, but the in game logs show nothing wrong. If he doesnt get the issue. then im lost for words, worst issue to ever happen.... XD

[RedParadize]

@ThePhoenixSol I would suggest to enter a ticket at on Shadowmage github . It will help to keep track of it, provide your ticket anyway, Shadowmage might see something in it that you didn't. 

Edited May 18, 2017 by RedParadize

[Temeter]

Btw, the recoloring system is awesome! It's actually much easier and more comfortable than before to make neat and diverse looking crafts. GUI is super useful.

[Shadowmage]

@ThePhoenixSol  I'm guessing that 'G-Effects' is a mod, and that you are not referring to the stock G-effects?

As was stated by others, the best thing you can do is to file an issue on the Github repo, including the details of what is going on, and any log files.  (Logs are useful for more than just exceptions and errors; they tell quite a bit about the environment (hardware), and other mods that are installed).  At the very least having it on the repo makes sure that others can see that it is a 'known issue', and gives a centralized place to collect information regarding the problem.

Please include as much information as possible.  Craft files if they are stock+SSTU only are greatly helpful.  Otherwise a description of the craft, part-count, and what you were doing at the time the problem manifested.  Basically I need the exact steps to replicate the problem on a stock+SSTU (+g-effects) only install.  If I cannot replicate the problem, I will not be able to fix it.
 

Without knowing what 'G-Effects' is or does, I would guess that they are doing something with either quite a bit of CPU or GPU overhead.  Custom shader effects and rendering routines would be the primary candidate.  Its quite easy to implement rendering routines in Unity that will break down under specific situations or hardware combinations.

 

Edit: As I was curious what could be going on here, I downloaded G-effects and installed it in my dev install, and did a bit of poking about in their source code.

I did not notice any slowdowns, regardless of the craft being used.  I tried the 'mk1 pod' as listed above, and also tried a couple SSTU-only craft designs.  The only difference was a very minor drop in FPS with G-effects installed, about equivalent to their use of a full-screen post-processing filter/shader setup (unavoidable, it is the cost of doing a full-screen post-processing).

With G-effects - ~202 FPS with Mk1 pod only,

Without G-effects - ~210 FPS with Mk1 pod only

With that information, I can tell you that it is not SSTU alone that is causing the slowdown you are seeing.  Could be a multi-mod interaction problem (what other mods are you using?), or could be hardware limitations for your setup.

A bit confusing is the fact that you say you experience the problem with only a mk1 pod?  SSTU does not touch the MK1 pod, and should have zero active code running if the scene does not contain any SSTU parts.  If you remove just the SSTUTools plugin (but keep the parts/textures/etc), does the problem go away?

Edited May 18, 2017 by Shadowmage

[ThePhoenixSol]

9 hours ago, Shadowmage said:

@ThePhoenixSol  I'm guessing that 'G-Effects' is a mod, and that you are not referring to the stock G-effects?

As was stated by others, the best thing you can do is to file an issue on the Github repo, including the details of what is going on, and any log files.  (Logs are useful for more than just exceptions and errors; they tell quite a bit about the environment (hardware), and other mods that are installed).  At the very least having it on the repo makes sure that others can see that it is a 'known issue', and gives a centralized place to collect information regarding the problem.

Please include as much information as possible.  Craft files if they are stock+SSTU only are greatly helpful.  Otherwise a description of the craft, part-count, and what you were doing at the time the problem manifested.  Basically I need the exact steps to replicate the problem on a stock+SSTU (+g-effects) only install.  If I cannot replicate the problem, I will not be able to fix it.
 

Without knowing what 'G-Effects' is or does, I would guess that they are doing something with either quite a bit of CPU or GPU overhead.  Custom shader effects and rendering routines would be the primary candidate.  Its quite easy to implement rendering routines in Unity that will break down under specific situations or hardware combinations.

 

Edit: As I was curious what could be going on here, I downloaded G-effects and installed it in my dev install, and did a bit of poking about in their source code.

I did not notice any slowdowns, regardless of the craft being used.  I tried the 'mk1 pod' as listed above, and also tried a couple SSTU-only craft designs.  The only difference was a very minor drop in FPS with G-effects installed, about equivalent to their use of a full-screen post-processing filter/shader setup (unavoidable, it is the cost of doing a full-screen post-processing).

With G-effects - ~202 FPS with Mk1 pod only,

Without G-effects - ~210 FPS with Mk1 pod only

With that information, I can tell you that it is not SSTU alone that is causing the slowdown you are seeing.  Could be a multi-mod interaction problem (what other mods are you using?), or could be hardware limitations for your setup.

A bit confusing is the fact that you say you experience the problem with only a mk1 pod?  SSTU does not touch the MK1 pod, and should have zero active code running if the scene does not contain any SSTU parts.  If you remove just the SSTUTools plugin (but keep the parts/textures/etc), does the problem go away?

yes Geffects is a mod, as you found out. and yes, it was with only a mk1 pod. i knew sstu did nothing to the pod, but neither does g effects as far as i know... all it should do it make g's more realistic, and give the black out and redout effect when g's are effecting the kerbal. and its a difference of 60+ fps to a struggle for 20 for me. So maybe the issue has multiple parts to it. hardware, maybe other mods(will try and test further tomorrow[stock install with SSTU and Geffects, then slowly adding. also that plugin idea]) and ill try and post something to the GIT sometime tomorrow when i got time.

[Byolock]

Is it possible that the new in dev recoloring feature is incompatible with the "-force-opengl" parameter? Whatever I do, SSTU Parts are remaining pure Black. 
//Edit : Finally got KSP to launch using DirectX again. And bug is gone, works fine now.

Edited May 19, 2017 by Byolock

[pap1723]

@Shadowmage I am looking to make a MM config for RO that has ModuleToggleCrossfeed as active and having to click to change it to off. Is that something that is possible?

[RedParadize]

1 hour ago, Byolock said:

Is it possible that the new in dev recoloring feature is incompatible with the "-force-opengl" parameter? Whatever I do, SSTU Parts are remaining pure Black. 
//Edit : Finally got KSP to launch using DirectX again. And bug is gone, works fine now.

I stoped using -force-opengl since ksp64, its not as usefull as it was and you lose allot of quality.

[Shadowmage]

2 hours ago, pap1723 said:

@Shadowmage I am looking to make a MM config for RO that has ModuleToggleCrossfeed as active and having to click to change it to off. Is that something that is possible?

I'm not sure on that -- ModuleToggleCrossfeed is a stock module, and I have no idea what most of its controls/etc do (no source access).

Should be doable, yes, but I'm not sure on what fields you would need to setup for it.

 

14 hours ago, ThePhoenixSol said:

yes Geffects is a mod, as you found out. and yes, it was with only a mk1 pod. i knew sstu did nothing to the pod, but neither does g effects as far as i know... all it should do it make g's more realistic, and give the black out and redout effect when g's are effecting the kerbal. and its a difference of 60+ fps to a struggle for 20 for me. So maybe the issue has multiple parts to it. hardware, maybe other mods(will try and test further tomorrow[stock install with SSTU and Geffects, then slowly adding. also that plugin idea]) and ill try and post something to the GIT sometime tomorrow when i got time.

Please let me know if you can narrow down the cause or problem.  Nothing in my brief tests would point towards actual mod compatibility problems between the two, but it is certainly possible that having them both installed might manifest problems on others' hardware (memory, gfx capabilities), which might also depend on what other mod(s) are installed.

 

On 5/18/2017 at 8:44 AM, Temeter said:

Btw, the recoloring system is awesome! It's actually much easier and more comfortable than before to make neat and diverse looking crafts. GUI is super useful.

Glad it is working out well for you so far    Don't think the functionality will change much from what you see currently, but more parts and masks/layouts for some parts will be added over time.

 

4 hours ago, Byolock said:

Is it possible that the new in dev recoloring feature is incompatible with the "-force-opengl" parameter? Whatever I do, SSTU Parts are remaining pure Black. 
//Edit : Finally got KSP to launch using DirectX again. And bug is gone, works fine now.

No clue on the -force-opengl parameter, but I do know that it works with OpenGL at least on OSX (which does not use/support DirectX).

It could be that I'm not intentionally compiling OpenGL shaders on the Win64x shader bundles, as I believe they default to building directx only.  Will see about taking a look at it for one of the upcoming dev versions.

[pap1723]

Thanks @Shadowmage!

Can I get the new coloring system directly from the Github?

[Shadowmage]

18 minutes ago, pap1723 said:

Thanks @Shadowmage!

Can I get the new coloring system directly from the Github?

Yep, is available directly from the 'dev' branch  (link:  https://github.com/shadowmage45/SSTULabs/archive/dev.zip  ).

Note/Warning -- these releases are craft/vessel/save breaking, and also several parts are simply not working/broken (notably the cargo bays/trusses, and the stock-based fairing parts).  So I would recommend against trying to use the dev releases for any actual playing, they are currently only intended for testing of the new features.

(Even when finished there will be quite a few potentially craft-breaking changes, which is why the initial release of the recoloring system is slated for KSP 1.3+)

[Temeter]

Wait, the stock-based fairing parts are broken? I've yesterday used one, and it seemed to work fine. (or are the aerodynamics bugged?)

[Shadowmage]

Just now, Temeter said:

Wait, the stock-based fairing parts are broken? I've yesterday used one, and it seemed to work fine. (or are the aerodynamics bugged?)

In the current testing versions (from dev branch), they null-ref in the editor and are generally unusable (can't build, can't resize, can't change textures, etc).  Just pushed an update (like <2 mins ago) that should fix them up + add recoloring support.

[Temeter]

2 hours ago, Shadowmage said:

In the current testing versions (from dev branch), they null-ref in the editor and are generally unusable (can't build, can't resize, can't change textures, etc).  Just pushed an update (like <2 mins ago) that should fix them up + add recoloring support.

I've noted the stuttering performance when I picked them up in the editor, that's explains that one. Was able to resize and change textures in my campaign save though. But well, lets not dwell on why outdated stuff isn't breaking as much as it should.^^

Btw, since I've noted the neat upgrade to the Soyuz rocket parts, I tried to make an R7. Worked quite well wit the paint tools. Painted Metal parts probably need a darker color, though. I know the Soyuz parts are unfinished wip thingies, but I noted the engine section seems to lack the option to drop side panels.

Spoiler

 

Edited May 19, 2017 by Temeter

[Gordon Dry]

17 hours ago, RedParadize said:

I stoped using -force-opengl since ksp64, its not as usefull as it was and you lose allot of quality.

Could you tell me more about it?

Sources?

Memory footprint?

[Shadowmage]

Just finished adding recoloring support to the StationCore parts.  Basic setup, but effective:

 

That just about wraps up the recoloring system work, at least the major planned portions of it.  From here the rest of the work is cleanup and bugfixing, possibly adjusting a few things based on feedback from testing.

[RedParadize]

@Shadowmage Damn, you have to release that mod. Think about the poor player that do not know that mod, stuck with single colored ship with hundreds of un-customizable part. You have to end their misery! And maybe some modder would use your code to create spaceplane, rover and other part too!

On a more serious note, ever trough about doing cargo bay? 

Scrap that, looks like your SSTUModularCargoBay already have that feature. Can we expect it to be implemented soon?

I asking because looking at what you already have, there is not much missing to do a horizontal lander using existing SSTU material. The missing stuff is: 

A cargo bay with jetisonable panel and/or a cargo bay.
A body texture that split tanks in two, (to get black the shielded side)
A funky nose cone that looks like nasa lander.
A funky engine mount that have one side shielded

Edited May 21, 2017 by RedParadize

[tater]

 

Edited June 30, 2017 by tater

[Akira_R]

On 5/20/2017 at 2:05 PM, Shadowmage said:

Just finished adding recoloring support to the StationCore parts.  Basic setup, but effective:

*snip*

That just about wraps up the recoloring system work, at least the major planned portions of it.  From here the rest of the work is cleanup and bugfixing, possibly adjusting a few things based on feedback from testing.

WOW..... 

These look absolutely amazing.... I'm going to have to come up with some head canon as to why all of our stations need to be scraped so I can install the update. Maybe something about faulty coatings on the modules not protecting the metal from degradation due to ionizing radiation resulting in potential structural weakness that could lead to catastrophic rapid decompression, that sounds good.

Edited May 22, 2017 by Akira_R