New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misbehaviour (again) while scaling parts with VARIANT #261
Comments
Unsurprisingly, the misbehaviour couldn't be reproduced on KSP 1.4.3. So the "Classic" scaling engine is working fine, it's something I let pass trough on the Variant scaling engine. |
The problem was reproduced on KSP 1.4.5. So it is, indeed, a problem on the Variant Scaling Engine. |
I'M AN IDIOT…. Ok, no news here. :) I could reproduce the problem on KSP 1.4.3 too . I forgot there were already some variants on 1.4.3. (Alzheimer, here we go!) |
This zero in the problem on the original Variant Scaling Engine (Scale.PartDB.14x). |
Interesting…. This does not appears to be a problem on TweakScale after all. Launching the test vessel directly into the Runway works fine.
EDIT: I'm not really sure about this statement anymore. It still may be a mishap on hanlding the Variant change - and this only happens on Editor. The situation where reverting to Editor also triggers the problem on 1.7.3 may be caused both ways, so it was a bit premature to declare innocence from my part. Still working on it. |
Well, we have TWO misbehaviours working in parallel. One is on KSP's Editor, and this krapness is happening since 1.4.3 - the very first implementation for the PartModuleVariant. Damn, what a crappy implementation they did… Loading it directory into Launch as the previous comment states always work fine. This will be tacked down on net-lisias-ksp/KSP-Recall#55 The second misbehaviour is related to changing the Variant of a part when it is attached "inverted". This one appears to be on me. Interesting to note that the code is working fine when the part is attached "with the proper orientation". Only when attaching it backwards the problem happens. |
The KSP's Editor misbehaviour is fixed by https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.3.0.2 Now back to the problem that is really on my side. (damn, I wasted too much time on that crap) |
…wing with us, a lot of code is now useless. So instead of fixing things, commenting out code is the most sensible thing to be done! "FIXES" #261
Well.. That's the deal. On KSP 1.4.3 (or 1.4.2, the Brief), when When 1.9.x came and I finally detected a misbehaviour on Editor, this happened because KSP Editor started to screw up the Surface Attachments too. This was detected and "fixed" on Issue #110. The fix, obviously, caused some collateral effects because it was built over a "gambiarra" made due the first Editor misbehaviour - destabilizing the chain of events that everybody needs to happen to co-exist. TL;DR: almost all the issues related to Variant happened due this initial misdiagnosing… (sigh). Oh, well… better late then never. |
OUKEY. The behaviour depicted on his comment and the picture below: can't be reproduced on Beta. However, by changing the Variant after scaling the part, the scaled "sinks" info it's parent!
|
Oukey, zeroed on the problem. I'm failing on fetching the correct AttachmentNode from the new PartVariant - or perhaps I'm doing it right, but I'm being overruled later in the chain? |
Ran out of time for this. But at least I understood where the problem is. I'm postponing this again, and I will release 2.4.6.19 with what I have at hands now. |
… job **before** calling us. Working in progress for issue #261
Less is more (hopefully). I decided to trust (or hope) ModulePartVariant is doing its job (what appears to be true - most of the time), and so just triggering a full Rescale when the Variant is changed. Lets see what's happens - at least for the simpler Variants, this is working. Implemented on commit 7732b7c |
Oukey, the thing is confirmed to work fine on KSP 1.4.x. Fix on commit: 30ce1b3 |
But then it misbehaves on 1.5.x - not a surprise, as I built the thing to be "stacked", one support built over the previous. Since I "broke" 1.4.x to make it "right" this time, it's expected that it broke 1.5.x in the process (and so on). Interesting enough, the fix was just getting rid of the 1.4.x code! Fix on commit cd88578 |
KSP 1.7.x behave as expected. |
KSP 1.8.x also worked fine. Great! This concludes the 1.5.x scaler testings! Now working on the 1.9.x series (that goes until 1.12.x) |
And the KSP 1.9.x series also behaved!! #HURRAY!! The terrible image quality is due the need to shove it into the ground on my rig, as Squad had decided to use 4K textures for everything, screwing up with everybody using cheaper GPUs. I will solve this problem later, on KSP-Recall or pehaps some other add'on? |
Oukey. 1.12.5 is working fine, now I can close this one. This is a historical day. I finally tackled down one of the worst (if not the worst) problems I ever faced on KSP: supporting the The module itself is not bad, the problem is Editor. Since 1.4.x Editor is broken due a bad implementation on supporting this Module - the dudes just shoved some 'gambiarra' on the code that royally screwed everything and everybody that allowed changing things in Editor time. See KSP-Recall's issues and code related to This literally took me years to figure out - I initially misdiagnosed the problem to be 1.9.x related (just because Once I finally diagnose the mess properly, I had to virtually rewrite (to tell you the true, to remove code) support for scaling Variants since the very first implementation - because I was coding around a bug, not a feature, and this code caused a lot of collateral effects, probably on 3rd parties. Oh well.. Better later than never, now I know and and fixed things properly. At least until KSP 1.13.0 (if ever) , when they may create new ways of screwing us over! :P Closing this for good now. |
… job **before** calling us. Working in progress for issue #261
… job **before** calling us. Working in progress for issue #261
… job **before** calling us. Working in progress for issue #261
When you change the variant of a scaled part that it's attached backwards, the part is terribly mispositioned.
On a wild guess, I think I'm using a global coordinate when I should had been used a local one.
On KSP 1.7.3 this is happening too when reverting to VAB/SPH. Interesting… On 1.12.3 I have KSP-Recall installed, on 1.7.3 I don't.
Anyway, I think that by fixing the misbehaviour on the Scaling Engine for Variants I will solve the problem on both KSP versions.
The text was updated successfully, but these errors were encountered: