[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[Stone Blue]

1 hour ago, dok_377 said:

It's in my previous comment, just a clean install with the dependencies for the mod. 

 

Dont want to beat a dead horse, but when you set up your fresh install, was this a completely *new* copy of a KSP you installed to, or did you just delete mods, then install these minimum mods in that?

if you did the second, did you also delete the bottom 4 ModuleManager files, as well as your /saves folder??

Edited August 11, 2022 by Stone Blue

[damerell]

I sit corrected. My apologies. I'll try and reproduce this myself when I get home.

[dok_377]

34 minutes ago, Stone Blue said:

Dont want to beat a dead horse, but when you set up your fresh install, was this a completely *new* copy of a KSP you installed to, or did you just delete mods, then install these minimum mods in that?

if you did the second, did you also delete the bottom 4 ModuleManager files, as well as your /saves folder??

Any of this most likely has nothing to do with it, I don't even know any of the mods that change game files permanently, but just for the sake of being thorough I did this:

Redownloaded the game from Steam, downloaded the mod and each dependency from scratch, started a new save in this freshly downloaded game. No way there's something that might've leaked or even touched any of the files.


The bug remains. 

[linuxgurugamer]

10 minutes ago, dok_377 said:

Any of this most likely has nothing to do with it, I don't even know any of the mods that change game files permanently, but just for the sake of being thorough I did this:

Redownloaded the game from Steam, downloaded the mod and each dependency from scratch, started a new save in this freshly downloaded game. No way there's something that might've leaked or even touched any of the files.


The bug remains. 

Ok, here is the problem which @Stone Blue is talking about:

If you deleted the game fro. Steam, it doesn't delete any non-stock files, you have to manually delete the entire game directory.  Did you do that?

[dok_377]

Just now, linuxgurugamer said:

If you deleted the game fro. Steam, it doesn't delete any non-stock files, you have to manually delete the entire game directory.  Did you do that?

No, because I didn't even have the game installed in steam initially. It was in a completely different folder. So when I downloaded the game from steam again, it was, in fact, downloaded from scratch. 

I know how folders work. 

[Starwaster]

@dok_377

This is easily reproducible using the steps you provided. The log doesn't have any errors and I don't think it's going to show anything useful in tracking this down. 

Regarding your repro steps, this actually starts happening with the first iteration of saving/reloading. The very first time you do that, the wheel is irreversibly corrupted. Subsequent saves of the vehicle make it worse. The attach node moves further and further away every time. I don't get that instability when the vehicle is launched. Maybe because I stopped after 3 iterations. It might be that the wheel gets increasingly unstable the further it is from its attach node. Or maybe my vehicle is just too light, I don't know.

I'm going to look at the  craft file next and see how it changes between saves. It's probably not writing out the correct position. Or maybe it's rescaling the position twice? Once when you rescale and then rescaling that when it saves.

(and actually it is reversible... sort of... you can set the scale below 1 and then save/reload and the attach node position will move closer instead of further)

[dok_377]

7 hours ago, Starwaster said:

I don't get that instability when the vehicle is launched.

Maybe it gets unstable when you reattach a corrupted wheel. I don't get any instability either, but i don't reattach already corrupted wheels at all, it's easier to just grab new ones. And after I discovered the bug, I try to do way less resaving and reopening of the vehicle with KF wheels in general.

I don't get why this mod even has nodes on wheels, as you can clearly attach them radially. Maybe we can somehow just delete the node? I tried doing that, but without any luck.

 

7 hours ago, Starwaster said:

It's probably not writing out the correct position. Or maybe it's rescaling the position twice? Once when you rescale and then rescaling that when it saves.

It has to be in the rescaling code somewhere. I think I've seen something similar with Infernal Robotics NEXT, very similar thing when the robotic part is rescaled. The node just drifts as well. And that mod also has its own rescale code, it's not using TweakScale, although judging by the file name, it might as well be from TweakScale. 

[Starwaster]

1 hour ago, dok_377 said:It has to be in the rescaling code somewhere. I think I've seen something similar with Infernal Robotics NEXT, very similar thing when the robotic part is rescaled. The node just drifts as well. And that mod also has its own rescale code, it's not using TweakScale, although judging by the file name, it might as well be from TweakScale. 

There’s a section of the code that caught my attention but I haven’t been able to investigate too closely. 

[dok_377]

Tried to remove the node from one of the parts again and after checking I remembered why it didn't work. The scaling actually not only offsets the node, but also the surface attachment point as well. 

Then I tried changing the surface attachment line in the KF-WheelTruck-Single.cfg from node_attach = 0.31517, 0, 0, 1.0, 0.0, 0.0 to node_attach = 0, 0, 0, 1.0, 0.0, 0.0 and it seems to be working. Probably because the rounding error or whatever the scaling does isn't applying to zero. There's a side effect: the wheel is now attaching inside of the part it's getting attached to, this can be fixed with the offset gizmo, but this is still inconvenient. 

[NippyFlippers]

3 hours ago, dok_377 said:

Tried to remove the node from one of the parts again and after checking I remembered why it didn't work. The scaling actually not only offsets the node, but also the surface attachment point as well. 

Then I tried changing the surface attachment line in the KF-WheelTruck-Single.cfg from node_attach = 0.31517, 0, 0, 1.0, 0.0, 0.0 to node_attach = 0, 0, 0, 1.0, 0.0, 0.0 and it seems to be working. Probably because the rounding error or whatever the scaling does isn't applying to zero. There's a side effect: the wheel is now attaching inside of the part it's getting attached to, this can be fixed with the offset gizmo, but this is still inconvenient. 

Editing the .cfg files is a workaround I can live with. Not sure if it fixes the kraken, though.

[Stone Blue]

6 hours ago, dok_377 said:

Tried to remove the node from one of the parts again and after checking I remembered why it didn't work. The scaling actually not only offsets the node, but also the surface attachment point as well. 

Then I tried changing the surface attachment line in the KF-WheelTruck-Single.cfg from node_attach = 0.31517, 0, 0, 1.0, 0.0, 0.0 to node_attach = 0, 0, 0, 1.0, 0.0, 0.0 and it seems to be working. Probably because the rounding error or whatever the scaling does isn't applying to zero. There's a side effect: the wheel is now attaching inside of the part it's getting attached to, this can be fixed with the offset gizmo, but this is still inconvenient. 

Almost sounds like when the scaling is being done, its being done on either `rescaleFactor` or `scale`.... (but `scale` *outside* the MODEL node...
Pretty sure changing rescaleFactor, scales not only the model, but all the attachment/stack nodes, too... dont remember if changing `scale` *outside* the MODEL node does it or not, too

Using/changing a `scale =` *inside* the MODEL node, scales the model but *NOT* any attachment/stac nodes with it.

In your example, changing the X value to zero, just means its now sclaing the node against zero, which results in a 0.0 result no matter what the scaling is doing... so, yeah, a workaround

EDIT:
Ahh.. so i just poked that wheel model... i see why the attachment node X value is set that amount, as I figured...
The root origin for the part, is not on the backkside of the attachment collider, but at the lower, outer pivot point of the suspension.
So any scaling is being done from there, which is scaling that distance between the two...
Another option to fixing this in code, would be to fix the model, and set the origin point to where the bac of the attachment collider is... then the scaling would always be applied from there, which would be your new 0,0,0 point, and scaling wouldnt change that point

Edited August 12, 2022 by Stone Blue

[Starwaster]

This is where rescaling is happening.

https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/Utils.cs#L461-L488

Problem is, that file has not changed in three years. And the function in question hasn't changed in five years. So this is being caused by KSP changes. Probably because of changing the value of originalPosition. Maybe related to the KSP changes that cause robotic parts drifting.

I have an idea for fixing this if I can find some time to work with the code and compile and test. Or at least see if I'm barking up the wrong tree.

[NippyFlippers]

Oh, man. It would be so great to see that mod getting an updaten and getting brought back from the brink.

[damerell]

11 hours ago, dok_377 said:

I don't get why this mod even has nodes on wheels, as you can clearly attach them radially. Maybe we can somehow just delete the node? I tried doing that, but without any luck.

Precise positioning is easy in a node-node world.

1 hour ago, NippyFlippers said:

Oh, man. It would be so great to see that mod getting an updaten and getting brought back from the brink.

I'm not sure "fit first then resize" in newer KSP versions is on the brink, even if it is mildly annoying.

[Starwaster]

3 hours ago, damerell said:

Precise positioning is easy in a node-node world.

I'm not sure "fit first then resize" in newer KSP versions is on the brink, even if it is mildly annoying.

I just realized, whether or not it has a stack node is irrelevant. The stack node just happens to coincide with the surface attach node. It's a good visual indication of what's happening but its presence or absence won't affect anything. They're both being rescaled the same way.

[dok_377]

2 minutes ago, Starwaster said:

I just realized, whether or not it has a stack node is irrelevant. The stack node just happens to coincide with the surface attach node. It's a good visual indication of what's happening but its presence or absence won't affect anything. They're both being rescaled the same way.

Yep. 
 

11 hours ago, dok_377 said:

The scaling actually not only offsets the node, but also the surface attachment point as well. 

 

[Stone Blue]

yeah.. this is why I think its a good idea, to try to set the root origin on the model, as 0,0,0, but in a way, so that that point is actually where the surface attach node, or at least a main stac node, are gonna be... if the root origin is in the *center* of the geometry for the model, as in this case, any scaling has to do sclaing along both the positive/negative side of *every* axis... you can eliminate quite a lot of scaling along both sides of every axis, and keep at least one (main) attach node always @ 0,0,0 so it *never* moves

[Starwaster]

Ok so, the damage is actually being done when the craft (with rescaled wheel) is loaded.

I think I see where the problem is and it's been staring me in the face the whole time. I just didn't want to see it because it means that this problem (with the nodes specifically) has always existed. And that we just never noticed it.

From UpdateAttachNode(Part part, AttachNode node, float prevScale, float newScale, bool userInput)

            Vector3 basePosition = node.position / prevScale;
            Vector3 newPosition = basePosition * newScale;
            Vector3 diff = newPosition - node.position;
            node.position = node.originalPosition = newPosition;

I think the problem there is because prevScale defaults to 1 and I don't think it's being changed when the craft is loaded (and the PartModule initialized)

But newScale comes from the persistent field scale which is saved with the craft file.

• So let's say I set the scale to 10 (this will give you immediate feedback with the first iteration)
• Save and reload craft.
• basePosition = position divided by prevScale (1)
• newPosition = basePosition times newScale (10)

Aaaaaaand we just multiplied our attach position by 10. Every time the craft file is loaded.

Should be pretty easy to fix, just set prevScale to scale in initializeScaling().  I'm getting ready to test that now, but that only fixes the node issue. I haven't been able to repro the instability. If anyone wants to throw an unstable rover my way (using just KF + stock + any DLC; I have them all) then I'll try testing with it.  Or I can provide dll with the fix for someone else to try. (it would not fix already affected craft, those will need their wheels replaced)

[Starwaster]

Here's the dll to test with. I tried it out, looks good, nodes are behaving themselves between loads

https://www.dropbox.com/s/kqnicwc26m4ba98/KSPWheel.dll?dl=1

[dok_377]

2 hours ago, Starwaster said:

Here's the dll to test with. I tried it out, looks good, nodes are behaving themselves between loads

https://www.dropbox.com/s/kqnicwc26m4ba98/KSPWheel.dll?dl=1

Seems to be working without issues. Resaving, reopening, saving as subassemblies. Nodes are staying in place. Also built a simple rover and drove around for 20 minutes, saved and loaded the game, left the scene and came back, timewarped. No issues as well. I'll let you know if I find something in the future. 

Thank you for this fix. 

Edited August 13, 2022 by dok_377

[NippyFlippers]

7 hours ago, Starwaster said:

Here's the dll to test with. I tried it out, looks good, nodes are behaving themselves between loads

https://www.dropbox.com/s/kqnicwc26m4ba98/KSPWheel.dll?dl=1

You are doing wonders, man. Will that KSPWheel mod get an offical update with your .dll? Other players should profit from that, too!

The wheel seems to work fine now. I subjected the rovers to every obscenity I could come up with and it stays stable, no more kraken.

I mean, look at her! Isn't she magnificent?

[Starwaster]

Just now, NippyFlippers said:

You are doing wonders, man. Will that KSPWheel mod get an offical update with your .dll? Other players should profit from that, too!

The wheel seems to work fine now. I subjected the rovers to every obscenity I could come up with and it stays stable, no more kraken.

I mean, look at her! Isn't she magnificent?

 

Looks beautiful!

As far as an official update, that's up to @Shadowmage. I can do a pull request with the fix, it's just a single line if he's still around. I'm not actually involved with this mod except as a user.

[dok_377]

26 minutes ago, NippyFlippers said:

You are doing wonders, man. Will that KSPWheel mod get an offical update with your .dll? Other players should profit from that, too!

The wheel seems to work fine now. I subjected the rovers to every obscenity I could come up with and it stays stable, no more kraken.

I mean, look at her! Isn't she magnificent?

That's a unit! Reminds me of this one: 

[Starwaster]

I made a pull request with the fix for the node scaling issue.

https://github.com/shadowmage45/KSPWheel/pull/78

Edited August 15, 2022 by Starwaster

[AbacusWizard]

Anyone know if there’s a way to fix the big pink pixellated rings that emanate from the antigravity engine? I tried installing the latest version of Textures Unlimited, but still get the big pink rings. (I also have Waterfall installed but I don’t know if that would make a difference or not.)