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

[Shadowmage]

1 hour ago, tater said:

I forgot to report this last night, but on "main" fuel tanks (name escapes me right now) if you option-click to duplicate, they have z-fighting issues (I think) that mess up the textures (say to grab a 1st stage and build a craft that looks like Delta IV Heavy by option clicking the booster, then sticking it to the side in 2X symmetry.)

 

1 hour ago, blowfish said:

I've experienced issues with duplication as well - specifically with regards to rescaling the duplicated part.  My best guess is that both this and the z-fighting have the same cause - somehow, a duplicate mesh is created.

 

1 hour ago, tater said:

Yeah. It was rescaled. I'll test more, tonight.

 

Is that -still- happening?  Thought I had fixed it with yesterdays release... or was it sundays? .... either way... thought I had fixed it over the last couple of days (for like the 10th time... why KSP... oh why.. do you have to be so inconsistent with loading sequences?).

Edit: Confirmed, but only when you alt-click a part to duplicate it (before it was doing it for regular symmetry counterpart use).

Anyone know what code-path it is using for that setup?  As apparently the models don't exist when I'm doing the 'destroy existing models, recreate from scratch' setup (or else.. they would have been deleted and not duplicating...)

 

Further edit:
Very strange stuff going on with this bug; when you alt-click clone a tank, a tank model is being parented to the base part model transform (rather than the managed root transform), and so is not being deleted as it should be.  Going to try and squash this one tonight and will post an updated release when available.  I know its just a cosmetic / in-editor bug, but still annoying.

Ooh.. ooh... methinks I found the bug....

 

Even further edit:

Squashed without mercy.  Looking into the engine-cluster fairing-size reset now, will package and post an update as soon as it is figured out.

Edited March 29, 2016 by Shadowmage

[ComatoseJedi]

To all the bugs that deserve no mercy.

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.30-pre6

Few more fixes, enhancements, and updates.  Adds RD-0110 as a usable (but WIP) part, and cleans up the cost/tech-nodes/effects of the SSTU-NRV engine parts (both stock and real-plumes are fixed/set/improved).

 

.... (sneaks off to poke at pre-release (stock) for the night)

[tater]

2 hours ago, Shadowmage said:

Squashed without mercy.  Looking into the engine-cluster fairing-size reset now, will package and post an update as soon as it is figured out.

[Sudragon]

Oh look. 1.1 prerelease. 

[ComatoseJedi]

don't forget the 1.1 part tools @Shadowmage 

[ComatoseJedi]

Did some playing around tonight with the 64k mod tonight with these parts. I did some -tweaking- with the engine parts to make a full scale version of the SLS with the HUS and ICPS for a run around to the Mun and back. I really do have to say if you want to play with the 64k mod and these parts, the adjusted parameters for Isp and thrust came in handy. And I'm sure glad you adjusted the ablator value for the B CM. Due to the simple fact if you don't slow down enough to at least 5200 m/s before hitting atmosphere, you will cry. And not slowing down isn't an option here, you have to slow down, because I was getting velocities up to 7200 m/s and that really makes you bite the seat with your buttocks. Ended up hitting atmosphere around 5400 m/s, almost overheated to explosion and had 110 ablator left when I got done playing in the plasma. But this mod is PERFECT for the larger Kerbin. I actually had to use up all the fuel from all stages before the final burn for re-entry, which is something I rarely do. 

[Shadowmage]

Busy days at work recently (past 3 weeks)... so very slow progress.  Probably will stay busy throughout the summer... so development may be a bit more casual than it has been the past few months.  When I get off work tired, worn out, and mentally exhausted... not good for modding that day even if I still had the will.

The bad news -- I had previously intended on maintaining concurrent development branches for 1.05 and 1.1 for at least a few weeks.  It no longer looks like this will be reasonably possible (certainly doable, but so much extra work its not worth it; -hours- to swap between branches/setup as there is a ton of manual stuff that Git can't switch that I have to do manually; not to even get into the Unity project problems).  So, as soon as I begin development on 1.1, there will be no turning back.

So.. if you have any bug-reports for 1.05... post them now and I'll attempt to get them fixed today/tonight for one final update/release for 1.05.

 

1.1 Pre-Release -- First Impressions:

Performance = good, with some hitches/snags/pauses that will likely be sorted out. 150 part ship no longer results in poor frame rate.  Though a <30 part (all stock) SSTO still killed my FPS during ascent (aero graphics I think).
Graphics = bad.  It looks like most stock parts have lost their specular mask entirely; shiny-metal things are... not.  All of the parts in the editor are washed out and appear to lack depth due to the flat / ambient shading in use (combined with the loss of specular highlighting).  No Unity Standard Shader support as far as I know.
UI (in-game) = good and bad.  The widgets are too big, the text is too small.  So when you scale it to make.. for example the nav-ball.. be smaller, all the text becomes unreadable.  They'll likely get this fixed up for full-release (else I'll be hacking away at it to make it all free-scalable).
UI (code) = ummm... not sure what I think of it yet.  They added to stock all the UI controls that I was going to make, so that is good... but I'm unsure if they added them in such a way as to allow for input event driven setups; haven't been able to dig into the code/API on those yet.
Wheels = omg...don't know where to start.. but... ugghh... going to be even more of a PITA to setup non-stock wheel setups (e.g. multiple wheels or legs on the same part).
Engines = well... not terrible... but it is going to take some figuring out to get the new split-thrust-per-transform setup working..... and I can only -hope- that it will work with the engine cluster setup.
Stock Fairings = much improved; set the # of panels and deploy type in the editor (confetti or clamshell).
Gimbals = like the engines... going to take some adaptation to get things working again.
RCS = well, they added the per-axis toggles, so I can remove the hard-coding from many parts (or just set defaults), as players can now alter the axis limitations while in flight.  This should clean up the problems with RCS input for non-default control transforms for most of my RCS-enabled parts (SC-A/B/C/E parts).

 

I -might- start on the update stuff tonight.  Likely going to take me a day or two to get Unity 5 setup, clean up my private dev repository (it is....bloated and full of old stuff at the moment), get VS setup with the new libraries, and even get to a point where I can -start- on the update.  Will definitely be starting on the update by this weekend.

There is NO ETA on any 1.1 compatible release;  I have so much planned work to do, and have not even yet looked at how badly the plugin is broken.

 

Also -- fair warning (I've said it many times before, and will say it a few more times...) -- this update WILL break saves.  There will be no update compatibility between 1.05 and 1.1 for save games or craft.  I'm not even going to try.  -After- the initial 1.1 update I'll start using the save-game conversion methods that were introduced... but there will be so much changing during this initial update it would likely take months just to get the conversion stuff in place (part names, locations, etc).

[blowfish]

9 minutes ago, Shadowmage said:

Engines = well... not terrible... but it is going to take some figuring out to get the new split-thrust-per-transform setup working..... and I can only -hope- that it will work with the engine cluster setup.

I took a look at this and it looks relatively simple ... basically it loads a node which defines proportional thrust by index for all of the transforms.  If you set up the node correctly and then tell the engine module to load it things should work.  Let me know if you need any help with this.

9 minutes ago, Shadowmage said:

Gimbals = like the engines... going to take some adaptation to get things working again.

I don't think anything has broken compared to how it used to work.  The main new things to think about are the axis and control input limits, both of which look pretty easy to set up.  Again, let me know if you want help figuring out what the parameters are / what they do.

9 minutes ago, Shadowmage said:

RCS = well, they added the per-axis toggles, so I can remove the hard-coding from many parts (or just set defaults), as players can now alter the axis limitations while in flight.  This should clean up the problems with RCS input for non-default control transforms for most of my RCS-enabled parts (SC-A/B/C/E parts).

Could I suggest leaving the default configuration as it is?  Players can change it in-flight if they want, but I think having the defaults makes things easier.

[Shadowmage]

21 minutes ago, blowfish said:

I took a look at this and it looks relatively simple ... basically it loads a node which defines proportional thrust by index for all of the transforms.  If you set up the node correctly and then tell the engine module to load it things should work.  Let me know if you need any help with this.

I don't think anything has broken compared to how it used to work.  The main new things to think about are the axis and control input limits, both of which look pretty easy to set up.  Again, let me know if you want help figuring out what the parameters are / what they do.

Could I suggest leaving the default configuration as it is?  Players can change it in-flight if they want, but I think having the defaults makes things easier.

 

Engines -- do you have any working examples of how the config is supposed to be setup?  Pretty sure that I'll need to read in the array of values and clone+concat that array for each engine in the engine cluster; I just have no idea what the array is supposed to look like or what the values are supposed to do (is it a multiplier, percentage, scalar, other? -- how does the array of values get calculated out to the individual thrust per-transform?).  And how does it work with multiple engines?  How does it determine the 'order' of the thrust-transforms? (seems likely that it just takes the order returned by the transform.find() function... which is...?)

E.g. RD-108A; four main + four vernier transforms.  Total thrust ~400kn, 80kn for each main + 20kn for each vernier... what would this input array look like?  And then what will it look like if I had -two- of those engine models in the part?

 

Gimbals -- mostly the problem is that I'm going to have to re-rig and re-export nearly every engine and gimbal-enabled part that I have, as my gimbal transforms were/are rotated arbitrarily, and from talking with NathanKell when he changed the gimbal stuff, they are now orientation sensitive (e.g. need Z+ aligned with thrust direction) (previously, gimbal orientation did not matter).  Other than that, seems fairly simple.  Just massively time consuming (~30 mins per engine part, if everything cooperates... times how many parts?).  Axis-limitation stuff seemed easy to setup, though again may require some adjustment during the re-rigging to ensure the same axis can be locked for each gimbal transform.

 

Will likely know much more sometime this evening after I can begin poking at the code and Unity side of things

[Sudragon]

If I'm loading the game, in sandbox, and none of the 'variable' parts are visible in the VAB, what am I missing? The capsules are all there, and all the other parts.

[Jimbodiah]

Concentrate on 1.1 and halt new development until it's updated. Maintaining a 1.0.5 while also making a 1.1 is double the work for no reason at all. Everyone will switch to 1.1 when it is released, and things are working properly in 1.0.5 to keep it as-is.

[blowfish]

38 minutes ago, Shadowmage said:

Engines -- do you have any working examples of how the config is supposed to be setup?  Pretty sure that I'll need to read in the array of values and clone+concat that array for each engine in the engine cluster; I just have no idea what the array is supposed to look like or what the values are supposed to do (is it a multiplier, percentage, scalar, other? -- how does the array of values get calculated out to the individual thrust per-transform?).  And how does it work with multiple engines?  How does it determine the 'order' of the thrust-transforms? (seems likely that it just takes the order returned by the transform.find() function... which is...?)

E.g. RD-108A; four main + four vernier transforms.  Total thrust ~400kn, 80kn for each main + 20kn for each vernier... what would this input array look like?  And then what will it look like if I had -two- of those engine models in the part?

The clusters might complicate things, yeah.  It definitely relies on order, which is difficult to guarantee, although there's probably some pattern.

The basic way it works is this: All the thrust transforms for a particular engine module have the same name.  If you had 3, and you wanted 2 to have 25% of the thrust each and the other to have the remaining 50%, you would put a node something like this in the engine module (obviously I don't remember the exact names):

NODE
{
	something0 = 0.25
	something1 = 0.25
	something2 = 0.5
}

 

[Shadowmage]

1 hour ago, Sudragon said:

If I'm loading the game, in sandbox, and none of the 'variable' parts are visible in the VAB, what am I missing? The capsules are all there, and all the other parts.

Without logs?  No clue

[Shadowmage]

Could be worse.  Some of the Minecraft updates I went through saw my mod with 1000's of errors...

Most of these are just the changes in Unity itself; lack of direct access to render/rigidbody/collider/etc Components.  In fact... looking more closely, there are only 3 errors that are not related to that.  For most I can use direct getComponent<> access as it is a very infrequent occurrence.  A few though will require a more thorough caching system as they operate on every tick/frame, but that was on the to-do list anyway (esp material caching as that was a huge cause of the memory leaks).  One error is part resource related..no clue what is up with that one yet.  The last couple errors are shader related, looks as if there were some static global constant shader-ids that were removed (related to highlighting); those were only used in the highlight-fix-hack I had setup... can only hope it is no longer needed

However that is just the -compile- errors, my landing leg and wheel modules will need to be replaced (and/or parts converted to use stock modules), and there are a few other code-side adaptations that need to be made.  Haven't even looked at the Unity/models/assets end of things yet, but will likely know more in a few hours/day or two.

[RedParadize]

Thats sound good!

OMG, stock stuff is so... stock. 

[Shadowmage]

3 hours ago, blowfish said:

The clusters might complicate things, yeah.  It definitely relies on order, which is difficult to guarantee, although there's probably some pattern.

The basic way it works is this: All the thrust transforms for a particular engine module have the same name.  If you had 3, and you wanted 2 to have 25% of the thrust each and the other to have the remaining 50%, you would put a node something like this in the engine module (obviously I don't remember the exact names):

NODE
{
	something0 = 0.25
	something1 = 0.25
	something2 = 0.5
}

 

Thanks

I'll likely have to 'adjust' the config nodes when I reload the engine modules, duplicating/adding to the list for each additional engine, while at the same time dividing the 'base' thrust mult for each entry by the number of engines in the cluster.

-If- my observations are correct, there will be a reliable pattern to the order of the returned transforms.  I believe Unity does depth-first recursion when finding multiple transforms, so it will find all the transforms from the first model before moving on to the next.  And within each model the depth-first search will return the transforms in order of the alpha-sort of their branch/root/parents.  The only indeterminate is when there are multiple transforms of the same name, with the -same- parent that are supposed to have different thrusts (I don't personally have anything setup like this, but I' would imagine you will have to examine the model carefully in Unity in order to find the sequence).

In short -- the transforms should be returned in the sequence that you find them if you scroll down the expanded model tree in the Unity editor (if all of my observations and inferences are correct).

Will hopefully be able to start in on all this ..soon... and will know much more shortly after.

 

In other semi-related news.. there is now also a stock supported resource-based thrust curve multiplier...(SRB thrust curves) so yay for some simplification on the RO interaction front   (I'll have to add in support for this to the MSRB plugin in the near future, with curve-switching per body length... or something...)

[Shadowmage]

Well.. got the plugin to compile last night, and work in-game for the few parts I was able to convert/get working.

Sadly, is going to take several days to get all the parts transferred as I'm also cleaning up naming/formatting/location of many files... and of course the .mu files hard-code the texture name in there (and are... inconsistent if you try to edit them manually...some edits work...some don't).

So, I've got to setup Unity 5, Part-Tools, and try and locate -all- of my old modeling files for every part so that I can re-rig and re-export them.  Total PITA. 

Anyone know a reliable way to edit the texture names in a .mu file?  Hhex editing works for textures with similar-length names, but if they are more than 2-3 chars difference in length it doesn't work; I would have to know more about the byte encoding format to fix it.  Hmm...perhaps I'll bug tanihwa for details and/or peek at the blender ksp importer code to find the encoding... as I do know a little bit about how to code stuff and could likely write my own updater after I knew how the bytes are laid out.  Yes, I would rather write a program to hack the file names than deal with Unity.  Perhaps U5 is better...but very doubtful.

I had wanted to go with a more traditional folder layout; one folder per-part, fully self contained; like the stock setup.  Sadly, this will -not- work with the texture sharing.  I tried to use the MODEL node texture = function to replace the  missing texture from a model with a shared texture... and if you don't have a texture in the directory for it to load, it won't populate the texture slot, and then there is nothing to replace; in order to get it working I would need to add a dummy/placeholder texture in the same folder as the model, so that the slot gets filled with the placeholder, and then replaced with the proper texture when the model is added to a part; giant PITA and adds confusing duplicate-named placeholder textures all over... not going that route.  So.. still going to be one giant /Assets folder full of stuff.  Nothing I can do about it, sorry; I tried.

Alternaitvely, does anyone know if the AssetBundles system is intelligent enough to not load duplicate textures if I include them in multiple bundles?  Likely it is not, and will load them each by unique URL....

 

On to the (really) bad news:

Lander Core is being removed, at least the fuel tanks, decouplers, and engines.  Without the integrated landing legs they are not useful to me, and there is no way that I'm going to get those legs working with the new stock leg/wheel system.  And the engines just don't fit appropriately without fuel tanks, and were a bit OP to begin with (too small of geometry).  No tanks = no need for those terrible decouplers either.

Might leave the pods available as they have some generic utility to them... but debating on whether to include those either; they are less useful with the reasonably light-weight CMX series of pods.  Still would require a full re-setup for those models, as I need to replace the RCS port geometry... which is currently integrated into the models.

For the engines, I'll prioritize finding a replacement engine for standard use, and add some of those layouts as regular engine layouts (e.g. 12x with 3 on each side, hollow center).

For the fuel tanks... I've got a few ideas for some MFT variants that will replace them.  Still not sure how to do the integrated legs/solar/modules stuff...but is on the list of things to investigate.

 

SC-E parts will also require a full re-rig and re-export; or at least the landing gear will (probably good I already split those off into separate MODELs ).

Most other stuff will likely work fine as soon as I get all the naming and structure updates in place.

 

Still at least several days out from anything usable.  Well..technically it is usable now... but there are only like 3 parts working

 

Edit:

Apparently the .mu files encode the string-length -with- the string... which makes a bit of sense as far as file-byte encoding goes (have done similar in the past when writing byte-streams).  So..now I just need to determine if there are any pointers in the header of the file that denote where to look for the texture names.. update those (if present), find the start of the text strings, and just start re-writing the bytes.

Ahh... low-level hacking goodness... been awhile since I've had to break out the hex editors and resort to byte-level manipulation.

(... breaks out Eclipse and starts writing some Java.... yes.. high-level-language for low-level-hacking...strange..I know )

 

More edit:

Asset Bundles are dumb as far as texture-sharing is concerned; any such issues have to be resolved through code when loading the bundles; which I cannot do as I am not the one loading them (they are loaded by the stock KSP code...).

Source: https://docs.unity3d.com/351/Documentation/Manual/AssetBundles.html

So the big blob of assets will not be going anywhere, sadly.  Why so hard to share textures between models in an intelligent manner?

Edited March 31, 2016 by Shadowmage

[blowfish]

Even if splitting up every part isn't possible, I'd still recommend trying to segment things as much as possible - for instance, the tanks don't depend on the engine textures, so the tanks can be put in their own folder   Since the main use case is people wanting to remove certain parts, I think this makes sense anyway, since it prevents them from accidentally removing a texture that something else depends on.

[Jimbodiah]

Are we talking about the 1.0.5 version, or the 1.1 re the LC? I'd keep the 1.0.5 with the LC and make it a 1.0.5 Final that will no longer be supported.

[tater]

I love the LC parts for airless landers. Even just the pods and default LC tanks. Really, they are very nice to have.

[Shadowmage]

1 hour ago, blowfish said:

Even if splitting up every part isn't possible, I'd still recommend trying to segment things as much as possible - for instance, the tanks don't depend on the engine textures, so the tanks can be put in their own folder   Since the main use case is people wanting to remove certain parts, I think this makes sense anyway, since it prevents them from accidentally removing a texture that something else depends on.

Sadly, you would end up with basically three folders:

Tanks

Fairings

Everything else

There might be a few specific parts that could have their assets self contained in the part folder; but I'm not going to put together some incoherent and inconsistent asset layout;  either all of the assets will be in a shared folder, or they will all be in the part folders.  And since they cannot be in the part folders due to limitations with KSP texture sharing, they will all be in a single shared folder.  I would rather have consistency on dev setup than make it easy for people to delete stuff.  Yes, I said it; helping people remove parts from my mod is not one of my priorities.

 

27 minutes ago, Jimbodiah said:

Are we talking about the 1.0.5 version, or the 1.1 re the LC? I'd keep the 1.0.5 with the LC and make it a 1.0.5 Final that will no longer be supported.

1.05 is done; the last testing release that I posted is the final 1.05 release.  I've already started converting stuff / updating my dev environment, and there is no (easy) way to go back now; any future releases will be for 1.1.x.

So yes, the LC stuff will still exist for 1.05 (because it actually works in 1.05).

[Jimbodiah]

OK, thanks! Clean break is always the best.

[Shadowmage]

1 hour ago, tater said:

I love the LC parts for airless landers. Even just the pods and default LC tanks. Really, they are very nice to have.

Sadly they are unfixably broken by this update.

I -might- be able to make an MFT style tank out of the LC fuel tank models, but it will not include any module / part switching (e.g. no solar panels, no landing legs, no RTG/monoprop, no ladders).

 

Ahh.. byte-hacking... so beautiful... on a hacky kind of level.

 (Java in case anyone was wondering)

    byte[] allInputBytes = Files.readAllBytes(modelFile.toPath());
    String stringVal = new String(allInputBytes);
    
    String textureName = "SC-A-CM-DIFF.png";
    int index = stringVal.indexOf(textureName);
    String[] split = stringVal.split(textureName);
    
    String replaceName = "SSTU-SC-A-CM-DIFF.png";
    int len = replaceName.getBytes().length;
    byte[] startBytes = split[0].getBytes();
    startBytes[startBytes.length-1]= (byte)len;
    
    String output = new String(startBytes)+replaceName+split[1];
    System.out.println("Hacked output: "+output);
    
    FileOutputStream fos = new FileOutputStream(new File("SC-A-CM_hacked.mu"));
    fos.write(output.getBytes());
    fos.close();

Haven't been able to test if it is a valid model and loaded by the game... but the hex/bytes all look proper

That bit of code will save me days worth of time on updating texture names in the models by removing the need to even set those models up in Unity.

Edited March 31, 2016 by Shadowmage

[tater]

Yeah, I know, I meant as "regular" parts, not cool, SSTU parts. I suppose the tanks could at least have fuel types, if the gear won't work. I guess the fuel types could include mono or even EC as a consolation prize for the lack of panels, etc.