Return Different Value Within Awake() and Start() Function

My Instance class return different value within awake and start function.

Here a picture :

 

http://docs.unity3d.com/Manual/ExecutionOrder.html

in Awake there is no guarentee what other gameobject's awake functions have been called, so you shouldn't use awake to reference things in other scripts. Awake is for "setting me up", Start is for "setting us up"

 

And of course you can manually assign an execution order of scripts relative to other scripts.

I find this useful for Singletons that may need to be accessed during Awake for whatever reason. I just set my Singleton to execute at like -3200. Guaranteeing its Awake to occur before any other.

Of course, this implies that the GameObject the singleton is attached to exists in the scene.

 

How can i fix this problem ? My function should be return True. If False, it's not working properly.

Code (CSharp):

1.  
2. This return TRUE,
3. private void Awake() {
4.         Debug.Log("[TileSpawnerBehavior::Awake()] -> " + DestructionBoardRenderer.Instance.IsTestBoardAvailable());
5. }
6. This return FALSE,
7. private void Start() {
8.         Debug.Log("[TileSpawnerBehavior::Start()] -> " + DestructionBoardRenderer.Instance.IsTestBoardAvailable());
9. }

 

something, somewhere is causing that bool to be false after all the awake functions have been called... with what you've given us we're not going to be able to find that for you...

 

Using your C# sharp editor ( MonoDevelop or Visual Studio) you can used the "Find All References" feature to check where that bool is set.

I am suspecting your problem is related to script execution order. The object that used your DestructionBoardRenderer might be calling Awake() before your singleton has called its Awake() and get initialized. If that the case, you can set the order from "Edit > Project Settings > Script Execution Order".

 

Thank you, thank you, thank you !!!

"Edit > Project Settings > Script Execution Order" ;
1) DestructionBoardRenderer 100
2) TileSpawnerBehavior 200

After that, the TileSpawnerBehavior working properly very very nice. But why ? Why do you need this "Script Execution Order" ? Do we need to add all script(s) (maybe 50+) into here? It will be complex, I don't know why, but It's worked for me. It's interesting...

Edit: And what's difference between "Behavior" and "Behaviour" words ?

 

Read this it will explain the script execution order for you
http://docs.unity3d.com/Manual/ExecutionOrder.html

"Behavior" and "Behaviour" words are the same thing the word is just spelled differently depending on what form of English you are using. Canadians and British include the U in words like behaviour and Colour while Americans do not. Just be mindfull in code you tend to see the American spellings.

 

Because MonoBehaviour scripts (and pretty much everything) do not run all at the same time, so they have to run in an order! Because a CPU, however fast, runs one instruction at a time and so does any program running on a CPU, including Unity. This does not applied quiet well with multi-threading on multi-cores CPUs, but that's another story...

So the scripts run in order, one after another. But that order might not be what your want. That's where setting the Script Execution Order comes in handy. Though, you don't to have specify the order for everything scripts, just the ones that have a time dependency with others scripts to work properly.

"behavior" is US english whereas "behaviour" GB english. They mean the exact same thing.

 

You should especially note what @LeftyRighty has already said in his first post.

If you always just decide to set the execution order instead of using Awake for the own initialization and Start for inter-script communication/initialization you'll end up with an order that can be difficult to maintain after some time because you always need to think about 'why have I chosen that order' etc and when you REALLY need that feature, i.e. for Update functions etc you'll be completely lost because the original order may not support what you're about to implement in update and so on.

It's often more cleaner and easier if you just try to avoid the access of other script's variables in Awake and only do the initialization there that does not rely on another script's state.