Floating Parts in KSP 1.0.5 with IR 0.21.4

[taleteller]

I like to combine Interstellar receivers with robotic arms for targeting. However, these parts tend to "float" away after a while:

They were perfectly fine at launch and still react to movement, but are totally off axis. This happens randomly at loading the vessel. I typically scale them down to Medium, but displacement is not just off scale. When landing a spaceplan like this, the parts get "ripped" of.

[ZiwKerman]

Seems like an issue with TweakScale interaction to me. Can you reproduce on a simpler craft and post craft and logs?

[taleteller]

Sure, i will try it with different scales.

[taleteller]

As typical with such things, the game wont reproduce it deliberately. Maybe it lacks the "load" for a simple craft to trigger. I may use "normal" sized arms on "Large" on the next missions for testing, sending a savegame and logs.

[taleteller]

This clearly is an issue with TweakScale. After several testflights, it only happens with scaled parts. However, its very hard to reproduce, only with complex games after hours of playing, therefore its hard to catch the moment. Log files gets huge on such sessions, unless you meet the kraken. I found nothing strange in the logs concerning IR and TweakScale.

All i can provide is more screenshots and an extracted part of the vessel before and after this problem. The only parts ever affected by weird scaling are IR parts. No matter what else I scale, they load perfectly fine.

scalebug.zip

[ZiwKerman]

Thank you. I'll try to coordinate efforts with pellinor to finally fix this bug. It only happens with IR parts (most likely only translating IR parts) due the fact that not only their scale needs to be changed, but the min/max translating distance and anchor points as well.

[pellinor0]

A few bits of theorizing, so far just from memory and without looking into the IR code:

Question: What exactly is misplaced in the craft from the zip file?

The picture in the OP looks like a rotating part broke. The parent attachment and one mesh look still right and the other mesh and the children look misplaced. So it looks like the problem does happen to rotating parts.

Has the same thing happened to the other craft? I can't see as clearly in those pictures in the zip. Is is also an offset happening between the two meshes of a (rotating?) IR part?

Note: the attachment points also need to scale for rotating parts. More precisely, stack node positions are probably non-persistent and need scaling on load, radial attachment nodes are probably reconstructed from the position of the child part (which persists, so no moving needed on load).

Question: which values are corrupt in the craft from the OP? Do you still have that craft? My understanding is that the offset between the two meshes of the IR-part should be something non-persistent that we recalculate on part load. So there should be some value in the IR or TweakScale module that causes it.

The ships are hard to compare because the order of the parts is different. Probably the tree was rebuilt by docking, therefore all the positions and attachments are not comparable. In the IR and TweakScale modules I haven't found anything suspicious so far.

Question: which of the persistent values make the craft broken? The only thing I can think of is the position of a part (likely the servo itself). This would probably leave a permanent offset that is impossible to distinguish from an offset that was already in the craft file. As far as I recall, the IR part is the moving mesh, so its position is also wrong for the OP craft. Then what makes the fixed mesh stick to the parent part correctly?

Another Idea is that some sporadic effect might break the order of operations between scaling and IR setup, but I have no idea what that could be.

[ZiwKerman]

@pellinor0 maybe some exceptions on load prevent TS or IR to initialize properly? BTW Squad messed with joints a little bit in 1.1, maybe it's worth to wait a little bit until dust settles

[taleteller]

First something i noticed. I took the 0.21.4 release from github, and 0.21.4 is stated in InfernalRobotics.version, however the Log tells me ...

InfernalRobotics v0.21.3.0 SHA256 cf17c88b71c1b21c6f74355cfd9d24e3c6d406975780427732d39e110e9b4cec

Forgot to update the dll version, or just a packaging issue?

Its not just hinges, and its also possibly not just attachment points. In the editor, as you can see, i placed two arms on the opposite faces. The first element is a surface attached angled extendatron.

On the bugged vessel, the left (upper) arm went far right. The rotational looks like it would have hit the attachment point had it been scaled "Large". Also on screen, Issue pellinor0/TweakScale#3 but afaik its just visual, not persistent.

On the initial screenshot i added, the hinge is ripped into two parts and the range is far beyond scaling displacement. Yes the vessel had docked in the meantime, as do most of my ships. I never encountered displacement to happen during dock/undock but only in between switching them.

I am curious, would it be possible to retain the part values for "position" and "rotation" in their original state, calculating the true values using MuMechToggle module data during load. That way persistent displacement would be avoided entirely.

[pellinor0]

I don't think memorizing part positions is a good idea, because this kind of information can get messed up in all sort of ways. For example the positions change when the part tree is rebuilt on docking or decoupling.

These instances where the two meshes of a part are ripped apart are probably a good starting point because moving them relative to each other is something non-persistent and happens only in IR. And should not happen at all for rotateJoints.

Yes exceptions can mess things up by causing code to be skipped. However those relative displacements are something we actively do, so at least this code is called.

Edit: just to confirm, we are talking about a sudden jump that sporadically occurs on reloading, and not about a slow 'creeping' issue that builds up over many load cycles (the second one was an IR issue in the past).

[ZiwKerman]

We do need some simpler reproduction case. And with 1.1 where I can actually use a debugger for IR it would not be hard to find the bug in the code.

[taleteller]

I think its part of the catch with this issue not to happen on simple cases but only when things get "out of order" in high loads. Version 1.1 should be focus anyway.

[ZiwKerman]

@taleteller Have you tried reproducing this bug with latest versions of KSP, IR and TweakScale?

[taleteller]

No, not yet. I have a game with KSP 1.1.1, the latest patch seem to have raised more issues than it solved. IR is one of them. Therefore I decided to let the code mature for a while. But I will test when getting some time to invest.

[keyspace]

I'm seeing this in KSP 1.1.2 with IR 2.0.4 and TweakScale 2.2.12 (however, many other mods, long game, so no simple reproduction yet).

Happens when the part is surface attached. Will test with a radial attachment point (scale tweaked).

(EDIT: I'll file a new issue.)