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

[Shadowmage]

11 minutes ago, blowfish said:

Ah yeah, it does get a lot more complicated when you have to change it dynamically, doesn't it?

The previous value is definitely passed into the on value changed event as a parameter (just as an object but it should be safe to cast). I know there are also (as of 1.1.2) checks in KSP to make sure the event is fired only if the value actually changes, but maybe there are some circumstances under which those checks aren't run. Might have to experiment a bit.

I'll poke around with it as well in the next few days; if some of the fake-update-callback/event stuff has been resolved that would eliminate a good portion of the extra-code-overhead (previous value caching and validation).  I haven't checked on it since the early 1.1 pre-releases, so it may well have been fixed/cleaned up.

Will also check on the value passed in to the callback methods; I always assumed it was the 'current' value and so never investigated uses for it; if it is the previous value then that would allow me to remove tons of fluff code from my existing modules (yay for simplification!).

Have you run across a better way to update the cached index when you manually change the backing field's value?  If I could get rid of that mess it would make the conversion/updating much less painful and time consuming.

 

And, btw, thanks, in general   Your posts are always well thought out/put together/constructive/helpful, and a nice 'breath of sanity' amidst the chaos that seems to reign.  I'm not sure how you keep your own sanity while helping and being involved in so many disparate projects.

[blowfish]

@Shadowmage It appears that you are correct that onFieldChanged can be triggered even if the value hasn't changed.  My best guess at the issue  :

Spoiler

Probably using == on boxed floats (and strings cast as objects), which doesn't return the correct result

object a;
object b;

a = 1.2345f;
b = 1.2345f;

Console.WriteLine(a == b); // false
Console.WriteLine(object.Equals(a, b)); // true

 

Pinging @taniwha on this issue.  If I'm right about the cause it should be a pretty simple fix.  I can file a bug report if need be, but wanted to confirm that I'm not completely crazy on this first.

Edited May 20, 2016 by blowfish

[blowfish]

More info on refreshing the sliders ... there is a method UIPartActionChooseOption.UpdateDisplay which appears to re-adjust the min/max/current indices and update the string.  It's private though (you can still call it by reflection but it gets messy because obfuscation is apparently still in effect for some builds so the name isn't reliable).  So maybe your current solution is the best option, although I don't think it's necessary to null out onFieldChanged while updating things ... was that done as a precaution or specifically because you saw it being called unnecessarily?  I'm pretty sure that if the slider triggered an update just by having it's value changed via code, it would result in infinite recursion.

[taniwha]

blowfish: thanks for that. Yes, a bugrep will be appreciated (so I don't forget).

[Shadowmage]

7 hours ago, blowfish said:

@Shadowmage It appears that you are correct that onFieldChanged can be triggered even if the value hasn't changed.  My best guess at the issue  :

  Hide contents

Probably using == on boxed floats (and strings cast as objects), which doesn't return the correct result

object a;
object b;

a = 1.2345f;
b = 1.2345f;

Console.WriteLine(a == b); // false
Console.WriteLine(object.Equals(a, b)); // true

 

Pinging @taniwha on this issue.  If I'm right about the cause it should be a pretty simple fix.  I can file a bug report if need be, but wanted to confirm that I'm not completely crazy on this first.

That would make sense, and lines up with the behavior that I was seeing when I was messing with it.

However with the knowledge that the object/value passed into the callback method is the 'previous' value, this should allow me to eliminate most of the extra code overhead associated with verifying that the status was actually changed.  Worked fairly well during the few tests I did on it last night.

 

6 hours ago, blowfish said:

More info on refreshing the sliders ... there is a method UIPartActionChooseOption.UpdateDisplay which appears to re-adjust the min/max/current indices and update the string.  It's private though (you can still call it by reflection but it gets messy because obfuscation is apparently still in effect for some builds so the name isn't reliable).  So maybe your current solution is the best option, although I don't think it's necessary to null out onFieldChanged while updating things ... was that done as a precaution or specifically because you saw it being called unnecessarily?  I'm pretty sure that if the slider triggered an update just by having it's value changed via code, it would result in infinite recursion.

Aye, I've been avoiding reflecting private stuff for mostly that reason; did not think it would be the most stable way to handle it.

The nulling/reseating of the callback was actually needed in the earlier versions as there was something in the 'setup'/'initialization' methods that was calling the onFieldChanged method.  This may have changed in the later builds/updates, but I've never gone back to re-investigate;  probably not harmful to leave it in, as nulling and seating references is cheap from a performance standpoint (as far as I know it is mostly updating the memory address referenced by a pointer).  I'll see about doing some investigation to see if this is still needed; would be nice to get the code cleaned up a little.

 

I did get the easier parts converted to use the ChooseOption GUI stuff last night for texture swapping;  Procedural-decoupler, petal adapter, interstage decoupler, resizable fairing.  Were all pretty simple to get converted -- they only have a single set of texturesets, so I did not need to worry about any run-time updating of stuff; just initialize the fields and let it run.  Also got the engine-cluster module mount-texture selection converted to the new GUI controls.  It was a bit more difficult to get setup properly as it needed re-validation and re-setup every time the mount changed... but its working now

Will work on converting the rest of the parts likely a bit later today/tonight, and hopefully these will all be available with tomorrows update.  Sadly, they really do take ~30-40 minutes each to implement, so... not going to get get anything else constructive done today/tomorrow.

 

 

 

[superm18]

1 hour ago, Shadowmage said:

Also got the engine-cluster module mount-texture selection converted to the new GUI controls.  It was a bit more difficult to get setup properly as it needed re-validation and re-setup every time the mount changed... but its working now

Does that fix my problem with the Merlin A1 engine cluster only giving thrust of one engine, when going to the launchpad?

[Shadowmage]

8 minutes ago, superm18 said:

Does that fix my problem with the Merlin A1 engine cluster only giving thrust of one engine, when going to the launchpad?

That is a new one for me; are you using RO by chance?  And are there any errors in your log file when this happens?   (engine thrusts were fine last I checked, which was...a week or two ago)

Either way, no, the mount code has no effect on the engine thrust output.

[superm18]

No RO, I suspect tweakscale might have a thing going on. Ill look into it later and report back.

On another note. Your mod is absolutely amazing! Huge customization with few parts and very high quality. I think its hugely underrated (WIP I think) really hope that changes when you hit 1.0 

[Shadowmage]

43 minutes ago, superm18 said:

No RO, I suspect tweakscale might have a thing going on. Ill look into it later and report back.

On another note. Your mod is absolutely amazing! Huge customization with few parts and very high quality. I think its hugely underrated (WIP I think) really hope that changes when you hit 1.0 

Tweakscale -- quite possibly; if it is trying to scale those engines than it is certainly doing it wrong (unless it has done quite a bit of special handling code... and I'm not even sure I have an API that would let them do that).

Give it a try without tweakscale installed and see if the problem persists;  I haven't personally ever tried SSTU+tweakscale, so unsure/unaware if there are compatibility problems.  Please let me know if that was the issue though, I can likely PR some patches to tweakscale to fix the problem on their end.

 

And thanks   Approaching the first 'stable' versions pretty quickly; mostly just wrapping up things on the TODO list (which is pretty short at the moment) and general enhancements/cleanup.  Hoping that I'll be able to move out of the pre-release status fairly soon.  That won't mark the end of the updates, but it will signify a change in how I handle the updates (e.g. running a concurrent dev branch where new stuff happens, only updating the 'main' branch and releases occasionally as new things are finished and stable).

[superm18]

Turns out that its Kerbal Research & Development. Ill post it over there as well. Anything you need to make it work, if at all?

[Shadowmage]

10 minutes ago, superm18 said:

Turns out that its Kerbal Research & Development. Ill post it over there as well. Anything you need to make it work, if at all?

Thanks for taking the time to research.

I do not use that mod, and have never even heard of it before.  Any 'fix' that is needed will have to be done on their end (they are the ones messing with other peoples' parts/mods, thus it is their responsibility to ensure compatibility with any parts/mods they are messing with).  I suppose you can let me know if there are any API level changes that they need to make it work.

Edited May 20, 2016 by Shadowmage

[superm18]

46 minutes ago, Shadowmage said:

Thanks for taking the time to research.

I do not use that mod, and have never even heard of it before.  Any 'fix' that is needed will have to be done on their end (they are the ones messing with other peoples' parts/mods, thus it is their responsibility to ensure compatibility with any parts/mods they are messing with).  I suppose you can let me know if there are any API level changes that they need to make it work.

Np. Sure, ill do what I can.

[Shadowmage]

2 hours ago, superm18 said:

Np. Sure, ill do what I can.

I'll try and pop into that thread and drop a note for them;  I'm willing to make minor code-side changes to aid in compatibility where needed... but there is no way that I could just 'support' every random mod out there that manipulates other mods' parts... just too many of them.

 

And... in general dev news:

Got all of the fuel tanks, engines, fairings, etc converted over to use the slider controls for texture selection.  Should have them available with tomorrows' update.

Have also adjusted the VolumeContainer code so that it is compatible with resources that start empty, and added the LanderCore pods to the life-support patches.  Increased the min/max range for the engine mounts by an additional increment so that it should be much closer to the previously available range.  And also fixed the tank resources not being updated immediately on tank volume changes.  Fun stuff; all will be available with tomorrows update.

[Jimbodiah]

Is there a reason why SSTU is now over 300MB in size?

[Shadowmage]

2 hours ago, Jimbodiah said:

Is there a reason why SSTU is now over 300MB in size?

In a word: Textures

In a few words: Lots and lots of new texture set options for various parts.

As I already stated I'll be splitting off most of the textures into a separate download today, only including the original set of texture-swap options for tanks/etc in the main distribution.

Should have these available here in a few minutes... just doing some last minute testing/verification before I pack it all up.

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.4.31.114

Lots more bugfixes, few enhancements, and break-out of most of the texture sets into a separate download.  As usual see the link for full change-log and download links.

[123nick]

hey i have a couple of questions,

1st, is the texture set needed too use SSTU? or is it just additional textures?

2nd, the lander fueltanks, couldnt you at one point add RTGs or solar panels or landing legs too the landing tank? it was a configurable option and didnt need a new part, right? can u still do that?

[Shadowmage]

58 minutes ago, 123nick said:

hey i have a couple of questions,

1st, is the texture set needed too use SSTU? or is it just additional textures?

2nd, the lander fueltanks, couldnt you at one point add RTGs or solar panels or landing legs too the landing tank? it was a configurable option and didnt need a new part, right? can u still do that?

No, Yes.  Textures are optional.

Yes, yes, no.  Not anymore, Unity5 destroyed the legs, which was the main reason for setting those parts up like that.  No legs = no other modules either.

[123nick]

Just now, Shadowmage said:

No, Yes.  Textures are optional.

Yes, yes, no.  Not anymore, Unity5 destroyed the legs, which was the main reason for setting those parts up like that.  No legs = no other modules either.

is it possible too just have the landing legs be static animations, the same way as a cargobay deploys and retracts? sure they wouldnt have the suspension, but they would still work, no?

[Shadowmage]

Just now, 123nick said:

is it possible too just have the landing legs be static animations, the same way as a cargobay deploys and retracts? sure they wouldnt have the suspension, but they would still work, no?

No, not with the existing model setups; would have needed major adjustments to the models.  And the real reason that none of the other modules are done anymore was because it was a giant (fragile) hack that was just waiting to explode anytime I looked at the code funny.

[ComatoseJedi]

There's not enough man hours to put into what Shadowmage did to get the results he had back in the 1.0 version of this mod. And even then, it was a hack. Shadowmage has gone as far as to say it was the way it was and will probably never be that way ever again. U5 doesn't play nice as it used to. 

[123nick]

5 minutes ago, Shadowmage said:

No, not with the existing model setups; would have needed major adjustments to the models.  And the real reason that none of the other modules are done anymore was because it was a giant (fragile) hack that was just waiting to explode anytime I looked at the code funny.

did it explode or something?

[ComatoseJedi]

I think there was an update of Module Manager, too @Shadowmage? It was released a couple of days ago. But, I think the .24 version works just as well. 

[Shadowmage]

49 minutes ago, 123nick said:

did it explode or something?

Yep, pretty much.  The leg setup was impossible with the restrictions on Unity5 wheel colliders, and yes.. it caused things to explode.

The entire reason for the swappable modules in those tanks was the legs.  So, no legs = no other swappable bits either.

You can thank Unity for creating and forcing a completely unusable wheel collider system.

 

39 minutes ago, ComatoseJedi said:

I think there was an update of Module Manager, too @Shadowmage? It was released a couple of days ago. But, I think the .24 version works just as well. 

Noted, thanks.  I'll get it updated for the next release.

[123nick]

25 minutes ago, Shadowmage said:

Yep, pretty much.  The leg setup was impossible with the restrictions on Unity5 wheel colliders, and yes.. it caused things to explode.

The entire reason for the swappable modules in those tanks was the legs.  So, no legs = no other swappable bits either.

You can thank Unity for creating and forcing a completely unusable wheel collider system.

 

Noted, thanks.  I'll get it updated for the next release.

but what if you didnt use the landing leg part module? and instead had legs use the generic animate part module? it was called something like that. im sorry if im not understanding something, is the landing leg module sorta required for any of the bits too be swappable? my apologies if i dont understand.