This should fix the issue with Noctol eyes, along with other attached motes being drawn away from the pawns they are attached to. This was likely never really noticed before due to no other vanilla attached motes having their position as important as here.
Getting a DrawPos of a pawn during ticking will cause PawnTweener.TweenedPos to return TweenedPosRoot in MP to make the method deterministic. However, MoteAttached updated during simulation will draw it in an incorrect position due to the pawn position not being where it is visually.
The fix here is to cause PawnTweener.TweenedPos patch not to run while calculating the position of the attached mote.
Potential alternative approach would be to make a method that works like Pawn_DrawTracker.DrawPos, but using PawnTweener.tweenedPos field directly rather than PawnTweener.TweenedPos getter.
Another potential approach would be to make a reverse patch on PawnTweener.TweenedPos, but (again) replace the call to the getter with a direct field access in the transpiler.
There's possibly other ways to handle this situation, but those 3 are the only ones I could think of.
This should fix the issue with Noctol eyes, along with other attached motes being drawn away from the pawns they are attached to. This was likely never really noticed before due to no other vanilla attached motes having their position as important as here.
Getting a DrawPos of a pawn during ticking will cause
PawnTweener.TweenedPosto returnTweenedPosRootin MP to make the method deterministic. However,MoteAttachedupdated during simulation will draw it in an incorrect position due to the pawn position not being where it is visually.The fix here is to cause
PawnTweener.TweenedPospatch not to run while calculating the position of the attached mote.Potential alternative approach would be to make a method that works like
Pawn_DrawTracker.DrawPos, but usingPawnTweener.tweenedPosfield directly rather thanPawnTweener.TweenedPosgetter.Another potential approach would be to make a reverse patch on
PawnTweener.TweenedPos, but (again) replace the call to the getter with a direct field access in the transpiler.There's possibly other ways to handle this situation, but those 3 are the only ones I could think of.