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

[Shadowmage]

To be fair / honest -- investigating a replacement / proper setup for module-switching is literally the first thing on my to-do list after the 1.1 update is completed.  Will be needing it for the station/base parts extensively, and many existing parts could have cool alternate (optional) functionality added (want some Falcon style landing legs on your main tanks?... or solar panels on upper stages?  or optional solar/rtg/legs/rcs on...whatever?).

None of the existing parts (aside from LC) need it, so my initial plan is to not let those parts hold back the rest of the mod.  I'll have to find some interim solution for the LC-POD ascent fuel tanks (or allow those as separate parts temporarily).

If I do make an MFT out of the LC-FUEL tanks, it would come with the full range of fuel/resource switching options... so you could use them for LH2 or monoprop if you wanted.

[blowfish]

@Shadowmage Any idea how you're going to implement the module switching yet?  There are two options I see:

1. Hold the ConfigNodes in memory (as strings because they serialize) and actually create/destroy modules as needed.  Might cause a bit of overhead when switching.  Not sure if action groups would survive.
2. Set enabled and isEnabled on each module, which prevents updates, and disable/enable the part action UI elements.  Might lead to unexpected weirdness in some situations.

Edited March 31, 2016 by blowfish

[Shadowmage]

1 minute ago, blowfish said:

@Shadowmage Any idea how you're going to implement the module-switching yet?  There are two options I see:

1. Hold the ConfigNodes in memory (as strings because they serialize) and actually create/destroy modules as needed.  Might cause a bit of overhead when switching.  Not sure if action groups would survive.
2. Set enabled and isEnabled on each module, which prevents updates, and disable/enable the part action UI elements.  Might lead to unexpected weirdness in some situations.

 

#1 -- if I can pull it off.  Not too worried about the overhead, as it should be about the same as if stock were adding those modules.

#2 is basically what I was doing; however I had only used modules that I wrote so that I could enforce the disabled status; was not aware that there was a .enabled property for modules/components (that actually worked/did anything).  Hacky, ugly, resulted in tons of unused data in the persistence file, and the 'disabled' modules still recieved tick/frame updates (but just ignored them).  The .enabled flag would probably clean up some of that (e.g. unity would not fire the FixedUpdate events), but I'm unsure if KSP respects those flags while doing its own updates (e.g. OnFixedUpdate).  Also caused hell with modules that needed a specific model setup before they were enabled; it was -very- config order-dependent and code-order dependent.

 

I intend on specifying the MODULE config nodes as sub-nodes inside of the ModuleSwitch module config:

MODULE
{
    name = ModuleSwitch...or whatever
    MANAGEDMODULE
    {
        name = managedModuleName
        .....xxxx....module config fields....
    }
}

And from there I would manually managed the save-data for each module (I think).  Although... it might 'just work' as long as I (re)inserted the modules early in the loading sequence.

None of the modules would be inserted or activated on the prefab; so it would not have any 'dangling' module save-data.  Still have not been able to find a way to prevent the 'cannot locate module...blahblah...' error messages from extraneous modules... but if I can pull it off properly... that shouldn't be a problem.

 

From there I would have some ... interlinking... code between the MFT / whatever other modules that would tell the ModuleSwitch to enable/disable things as needed.

 

Still going to be a fairly complex setup, I just want it to be less of a hack than it was.  Also still a lot of stuff to think through / test / work out.

 

[blowfish]

@Shadowmage Makes sense.  Just for reference, enabled affects whether Unity events fire, and isEnabled affects whether KSP events fire (OnUpdate, OnFixedUpdate, etc.  Note that OnStart happens regardless).

[Shadowmage]

Well, took some reworking.. but the texture name replacement program is working well   It was mangling the bytes in the bytes->string->bytes conversion for some of the bytes of model data, so I had to resort to even more low-level byte-by-byte handling.

Now to work on updating... ~400 file names

 

Think anyone else would be interested in the functionality?  Is a simple .jar file with a .cfg file to determine what model/texture to update (of course ui/startup can always be improved).

 

Hopefully I'll have a good portion of the parts 'working' tonight, I don't really see to many problems that could pop up with most of it.. just a matter of time

[Shadowmage]

Well... things mostly work.  Definitely things that will need to be fixed... but nothing is throwing null-refs, crashing, or behaving too (unexpectedly) strange (so far...).  Engine gimbals are definitely out of whack and will need re-export of most engine-enabled parts (most engines gimbal in incorrect directions at the moment due to their gimbal transforms not being oriented the same as the thrust transform).

Really not a fan of the graphics/shading though...

Its a bit better in flight, but still something seems off;

 

-Might- have some initial versions sometime over the weekend, barring finding anything too broken.

[komodo]

Depending how systemic the filename changes need to be, that could be a sed problem, as much as I dislike its syntax; it does do good work in the right situations...

But I feel you for sure on the bytes>string>bytes thing... It's always something silly like the whole "bytes" part not working, right? (Mine are usually of the style "well you worked perfectly, only you did something entirely different than I intended...)

[trooperMNG]

8 hours ago, Shadowmage said:

Well... things mostly work.  Definitely things that will need to be fixed... but nothing is throwing null-refs, crashing, or behaving too (unexpectedly) strange (so far...).  Engine gimbals are definitely out of whack and will need re-export of most engine-enabled parts (most engines gimbal in incorrect directions at the moment due to their gimbal transforms not being oriented the same as the thrust transform).

Really not a fan of the graphics/shading though...

Its a bit better in flight, but still something seems off;

 

-Might- have some initial versions sometime over the weekend, barring finding anything too broken.

also stock models and textures are pretty awful. C'mon Squad, let Porkjet do some renovation!

[Jimbodiah]

I don't think it has anything to do with Porkjet, all parts look "off", I think they have everything under control yet.

[Shadowmage]

1 hour ago, Jimbodiah said:

I don't think it has anything to do with Porkjet, all parts look "off", I think they have everything under control yet.

Indeed, its 'just' the lighting and/or shading.

But I don't think they are going to 'fix' it; what you see now is likely what we will be stuck with.  Sad... all my parts look terrible in-game now, even though they still look fine in blender.  I guess I won't be spending much time on texturing anymore... if its all going to look like @#%^^ anyway, I'll likely just be slapping some plain diffuse on stuff and calling it good.  Certainly won't be spending hours making nice looking spec masks if they are just ignored/unused.  ....and I was previously greatly looking forward to the shader updates....  that'll teach me...

 

Got most of the _engines_ re-exported last night to fix their gimbal orientations; seem to work properly now even when used in clusters (aside from part.mass...).  Have not yet updated the more complex / verier equipped engines as I will need to do some experimentation to figure out the unity end of things and will need to update some code for them as well.

So.. still need to re-export the RS-68, RD-107/8, RD-0110 engines.  Will also need to re-rig and re-export the SC-A/B/C/E engine equipped parts; those are the painful ones....parts are so complex and it is so very easy to miss something during re-rigging.

SC-E / landing gear will need to be rebuilt/re-rigged as well.  Can only hope I can adapt things to the new stock hierarchy; which I'll need to figure out before I can even start working on them.

 

Looking promising for a release tomorrow.  Have a few mandatory code-side changes to make regarding the part.mass stuff (and likely a bug report to submit if zero-mass parts still crash even though they have modules setting their mass), and the engine cluster changes (for the differing thrust on the same module.... though I'm tempted to just leave them as-is with multiple modules...).

[tater]

A quick look at the 1.1 forum shows no threads regarding the look of parts at all. Perhaps a 1.05/1.1 comparison of parts might be a useful post over there.

[Jimbodiah]

Just made one, although it has been pointed out in other topics in that sub-forum though. But not many people are really bothered it seems. I even have ships that flap around like rubber dildos when you launch them, and I am told that is how it is supposed to work, 'cause kerbals and all. As KJR is not working yet, I am stuck strutting everything like a mofo to get it off the ground.

[Shadowmage]

36 minutes ago, Jimbodiah said:

Just made one, although it has been pointed out in other topics in that sub-forum though. But not many people are really bothered it seems. I even have ships that flap around like rubber dildos when you launch them, and I am told that is how it is supposed to work, 'cause kerbals and all. As KJR is not working yet, I am stuck strutting everything like a mofo to get it off the ground.

 

LoL... like a rubber... duck... indeed.  Couldn't have made a better analogy... probably not the best language for the forums, but quite accurate of a description.

Not often can posts make me smile/laugh... that one did though

 

[benjee10]

Re things looking terrible at the moment, I'm pretty sure that what he have now is a hacked together fix to keep the old shaders working fine in Unity 5. Inclusion of PBR shaders has been pushed back to 1.2. I believe (though may be wrong) that PBR shaders do currently work in KSP, it's just that the stock parts haven't been converted to using them yet, so you may be able to use the fancy new shaders on your parts as-is. 

[Jimbodiah]

The ticket I made got an answer that the behavior is just like in real life, if it is very long and narrow it will bend and wobble. Yeah, sure. Can't wait for KJR to be updated so they can fix the game at least on that front, as Squad is not intending to do anything about it apparently.

[tater]

Yeah, the struts thing has always been absurd. If every craft you built was untextured, but you had to manually drag the same, white texture onto every part, they'd still be defending that, too, I guess "you have to paint stuff in RL, right?"

[Shadowmage]

16 minutes ago, benjee10 said:

Re things looking terrible at the moment, I'm pretty sure that what he have now is a hacked together fix to keep the old shaders working fine in Unity 5. Inclusion of PBR shaders has been pushed back to 1.2. I believe (though may be wrong) that PBR shaders do currently work in KSP, it's just that the stock parts haven't been converted to using them yet, so you may be able to use the fancy new shaders on your parts as-is. 

I'm going to give it a try, but I believe it is not fully supported/implemented.  If I remember reading their dev-notes correctly at least the reflection light-probes will not be setup properly; so you might be able to get -some- bits of the PBR shading, but I don't think it will work fully as it is supposed to.

[Theysen]

1 hour ago, tater said:

A quick look at the 1.1 forum shows no threads regarding the look of parts at all. Perhaps a 1.05/1.1 comparison of parts might be a useful post over there.

I don't get how people claim that the editor thumbnails don't look different at all? They're flat and washed out, not much contrast etc. Or am I blind? I really really hope it's not like @Shadowmage said they won't fix anything about it.

[tater]

I'm a 2d class citizen, so I have to rely on screenshots.

[Jimbodiah]

Not even mentioning the huge navball and IVA pics that block half the screen, and those new messed up orbit lines that are next to useless now (if you can even see them).

It's like no one played the new release before going beta with it: most bugs/issues that are being posted can be encountered within 5-10 minutes of game play. Not to mention none of the suggested items by players has been addressed. So now it will be a wait for 1.2, which will be available Soon™, 2017-ish.

Yes, I'm liquiding (omg, they actually censor the p word for urinating here) vinegar right now 

I would break out Elite Dangerous again if there was any point in playing that (next update maybe, also Soon™). So I'm back to WoT for now.

Edited April 1, 2016 by Jimbodiah

[Shadowmage]

 

-If- I can get the PBR working... you guys might expect some engines that look more like:

(Screenshot from unity editor; should generally reflect the in-game look under bright lighting)

That is using the existing textures;  I merely apply the spec mask to itself and use that composite texture as the metal map.  Quick, easy, works well (or looks better than the current stock shading); though still room for improvement with proper differentiated metal and smooth maps.

Though, as stated earlier, I really don't think they've got the reflection support working/fixed in-game.  Going to try it out though, especially as it only takes a few seconds to make the composite metal/smooth texture from the existing spec mask textures (you can thank blender for me having the spec masks laying around as full textures; blender doesn't support spec(A) setup).

^^ This is why I wanted the updated shaders to begin with....

[Jimbodiah]

If it were that simple I think someone would have run all the stock parts before releasing it.

[ComatoseJedi]

21 minutes ago, Jimbodiah said:

If it were that simple I think someone would have run all the stock parts before releasing it.

You know Ven is going to have a field day with the stock parts, soon-ish. 

 

[Pappystein]

1 hour ago, Shadowmage said:

 

-If- I can get the PBR working... you guys might expect some engines that look more like:

(Screenshot from unity editor; should generally reflect the in-game look under bright lighting)

 

That is an awesomely detailed engine.  

RE shaders in 1.1.   Everything I have seen (which is officially scant little admittedly) is that this is normal in the testing process.   During experimental they start with a low overhead build and build up to full release quality for graphics as progress in fixing non graphical bugs starts to wined down.   The less variables impacting things the better for testing purposes.

[JoseEduardo]

4 hours ago, Jimbodiah said:

I even have ships that flap around like rubber dildos when you launch them, and I am told that is how it is supposed to work, 'cause kerbals and all. As KJR is not working yet, I am stuck strutting everything like a mofo to get it off the ground.

I can't tell how much I laughed at this... but you know my standing against politically correct, so that shouldn't come as a surprise

also waiting for KJR, tried out Proton and Zenit and they behaved exactly like a rubber dildo, except they were flying way past mach 1, so it's needless to say they were quite explosive... I could try making some more politically incorrect jokes, but....
 

3 hours ago, Jimbodiah said:

Yes, I'm liquiding (omg, they actually censor the p word for urinating here) vinegar right now 

yeah... there's that preventing these jokes...

the politically correct censorship is up even on PMs
 

Quote

I would break out Elite Dangerous again if there was any point in playing that (next update maybe, also Soon™). So I'm back to WoT for now.

AFAIK the next update is going to be the engineer thing... but anyways, that should have some interesting stuff to do... once they release it, wanna fly in a wing? I still need to do some trading to buy the upgrades though...

Edited April 1, 2016 by JoseEduardo