Thesis Project – Concepts for System to Control Script Timings

October 24, 2019

Working with the HFFWS

System for Properly Timing Running of Scripts

Discovering the Timing Issues with the HFFWS Tools

While working with the Rope script in the Human API, I was again encountering timing issues when trying to accomplish tasks through script. I was having trouble instantiating and connecting rigid bodies to the ends of the rope in script. I ran several tests to confirm the timing issues I was having again.

Test #1

• 2 Rigid Body objects exist in scene
• Script has 2 gameObject references for those objects
• Script sets startBody and endBody references to those objects at Start

This did not work. The references could be seen as being properly assigned in the Rope script in the editor, but that connection was being made too late and having no affect on the objects.

Test #2

• 2 Rigid Body objects exist in scene
• Script has 2 gameObject references for those objects
• Script sets startBody and endBody references to those objects at Awake

This did have the intended result of connecting the rigid body objects to the rope.

Test #3

• All done in Awake
• 2 Rigid Body objects instantiated into scene
• Script sets startBody and endBody references to those objects at Awake

This did work once, although I had some issues repeating it afterward. The objects were prefabs which were instantiated in Awake. GameObject references were created for these, and used for the values of the Rope script startBody and endBody, all done in Awake as well.

Test #4

• Start or Awake is irrelevant here
• Object with Rope script starts deactivated
• 2 Rigid Body objects instantiated into scene
• Script sets startBody and endBody references to those objects
• Rope object is then activated

This is the best solution that works, as it can be done in Awake or Start. This leads to a much more controllable environment which is ideal for our system. This will be the foundation for the main systematic approach.

System for Controlling Awake Calls for HFFWS Objects

Deactivating/Activating Objects or Enabling/Disabling Scripts

The combinations of all of these tests, most notably Test #4, showed that some important connections are made during the Awake phase of many HFFWS objects. It is important to note that Test #4 specifically indicates that a lot of the important functionality may be happening in the Awake method of the scripts of the individual objects themselves (which is important to differentiate from some system wide class that is making connections in Awake). This important differntiation leads to this option of simply deactivating objects with HFFWS scripts (or possibly disabling the scripts specifically) to force their Awake methods not to run before my systems are ready for them. I can run my scripts, and then activate the HFFWS objects so their Awake methods run at that point instead.

This concept seems the most promising for safely and consistently controlling the timing of my script elements versus those of the HFFWS objects (since I do not have access to their core scripts). As this is a common issue I have run into with many objects, it makes sense to make a small script to attach to any prefabs I will be instantiating which can just hold references to gameObjects and/or scripts that I will need to have deactivated or disabled initially, and then activate or enable after everything is properly set.

Script Execution Order

This was actually the first idea to get around these timing issues, but it seems less safe so it will most likely only be used as a last resort. The HFFWS package already has a lot of various scripts ordered in the script execution order of Unity, so there is already a precedent set by them for when a lot of things should run relative to each other.

To test that this worked in the first place, I ran a test with everything being set in Awake not working but moving it to the first script in the script execution order actually made it work. This was a similar test with connecting rigid bodies to a Rope script object.

This is not an ideal process to use however as it can easily lead to weird behavior that is very hard to debug and will not scale well in general. Because of these factors, I will mostly be looking to expand upon the other system concept.