Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  obi rope breaks after build.
#1
Hi again, I have the following problem.

I have some logic that changes the length of a rope. Everything works fine, however after I make a build in IL2CPP or BuildIn, both in build and in Unity happens what is shown in the video. I have tried a lot of things, but I can't solve it.
Code
Video
Reply
#2
(27-09-2023, 09:22 AM)Alexander34 Wrote: Hi again, I have the following problem.

I have some logic that changes the length of a rope. Everything works fine, however after I make a build in IL2CPP or BuildIn, both in build and in Unity happens what is shown in the video. I have tried a lot of things, but I can't solve it.
Code
Video

Hi,

The code executed is the same in both builds and editor, so there should be no difference in behavior. I'd suggest checking the player log for errors that might be affecting execution, specially NullRefExceptions as it's common for references to assets/resources to be missing in the build but not in the editor.

Also, be mindful of the order in which MonoBehavior methods like Awake(), Start(), etc are called since it's undefined, and may change between the editor and builds. A common source of problems is expecting a specific call order, things may work in the editor but as soon as you build the app the update order changes and things stop working. See: https://docs.unity3d.com/Manual/ExecutionOrder.html

Quote:In general, you should not rely on the order in which the same event function is invoked for different GameObjects — except when the order is explicitly documented or settable. (If you need a more fine-grained control of the player loop, you can use the PlayerLoop API.)

You cannot specify the order in which an event function is called for different instances of the same MonoBehaviour subclass. For example, the Update function of one MonoBehaviour might be called before or after the Update function for the same MonoBehaviour on another GameObject — including its own parent or child GameObjects.

kind regards,
Reply
#3
(27-09-2023, 02:01 PM)josemendez Wrote: Hi,

The code executed is the same in both builds and editor, so there should be no difference in behavior. I'd suggest checking the player log for errors that might be affecting execution, specially NullRefExceptions as it's common for references to assets/resources to be missing in the build but not in the editor.

Also, be mindful of the order in which MonoBehavior methods like Awake(), Start(), etc are called since it's undefined, and may change between the editor and builds. A common source of problems is expecting a specific call order, things may work in the editor but as soon as you build the app the update order changes and things stop working. See: https://docs.unity3d.com/Manual/ExecutionOrder.html


kind regards,
NullRefExceptions no, your answer doesn't explain why the rope breaks after a build (both in build and unity) and then after a unity reboot everything works properly again.

It's very likely that rope no longer reacts to its dynamic unity connections as if they become static. Similar behaviour can be achieved when isKinematicForParticles is enabled on both dynamic connections at once. However, I checked isKinematicForParticles is turned off after the build. The interesting thing is that I don't change anything other than clicking on the build button, and after that obiRope stops working properly until unity reloads.

Console logs after build (in build and in unity)
Reply
#4
**Preliminary**

The bug is due to RigidBody.velocity on players being changed from other scripts. Thus Obi rope could not affect RigidBody of players.
Now we need to figure out why this has no effect on ObiRope physics before the build, and why it does afterwards

I don't know why yet, but if you manually enable and disable ObiRope FixedUpdater it starts working correctly
**Update**
So far I just switch off at startup and after a couple of seconds switch on ObiRopeFixedUpdater with unitask and it works.
I am waiting for comments from @josemendez
Reply
#5
(27-09-2023, 03:42 PM)Alexander34 Wrote: **Preliminary**

The bug is due to RigidBody.velocity on players being changed from other scripts. Thus Obi rope could not affect RigidBody of players.

Hi,

Where do these scripts change the rigidbody velocity? Do they do it in FixedUpdate()?

(27-09-2023, 03:42 PM)Alexander34 Wrote: Now we need to figure out why this has no effect on ObiRope physics before the build, and why it does afterwards

I don't know why yet, but if you manually enable and disable ObiRope FixedUpdater it starts working correctly

This really sounds like your scripts are changing rigidbody velocities in FixedUpdate(), and Obi's FixedUpdater is also doing the same. As I mentioned in the previous post the order in which Unity calls MonoBehavior events for different scripts is undefined by default (essentially random), so either the rope will overwrite the velocities set by your script or the other way around. Depending on things like editor/build, or which component/object gets activated last, the order will change.

To check if this is the case, subscribe to ObiSolver.OnEndStep and place a Debug.Log there, then place a Debug.Log in your script's FixedUpdate. The order in which these are written to the console will probably change between the build and the editor.

Assuming this is the problem, there's many solutions to it. Simplest is to set your script execution order explicitly. Another one would be to subscribe to one of the solver's callbacks and change the rigidbody velocities there, so that the order is consistent.

kind regards,
Reply
#6
(27-09-2023, 05:56 PM)josemendez Wrote: Hi,

Where do these scripts change the rigidbody velocity? Do they do it in FixedUpdate()?


This really sounds like your scripts are changing rigidbody velocities in FixedUpdate(), and Obi's FixedUpdater is also doing the same. As I mentioned in the previous post the order in which Unity calls MonoBehavior events for different scripts is undefined by default (essentially random), so either the rope will overwrite the velocities set by your script or the other way around. Depending on things like editor/build, or which component/object gets activated last, the order will change.

To check if this is the case, subscribe to ObiSolver.OnEndStep and place a Debug.Log there, then place a Debug.Log in your script's FixedUpdate. The order in which these are written to the console will probably change between the build and the editor.

Assuming this is the problem, there's many solutions to it. Simplest is to set your script execution order explicitly. Another one would be to subscribe to one of the solver's callbacks and change the rigidbody velocities there, so that the order is consistent.

kind regards,
Indeed, I zedebagged and the reason was that ObiRope affects RigitBody at the same time as another Monobehaviour apparently in FixedUpdate. The script execution order solved the problem.
Most Solver callbacks were after execution of FixedUpdate on other MonoBehaviour. Such as OnSubstep I didn't even check because it is very common, I assume it will be even more common than FixedUpdate.
Anyway, this topic will serve as a great guide to solving bugs when using ObiRope with other assets (Invector in my case)
Thanks!
Reply