void Start() timing is waging war with one of my gameObjects

I know it's a little bit of a vague Title I put there, but I really could not think of another way to word it haha.

Anyways: I have a List<GameObjects> that is supposed to get initialized and filled in the Start() method of my _GameManager gameobject. However, right after that is filled, I need one of my other gameobjects to query the List for a gameobject it needs a reference for in order to pull it's transform.position. Sometimes the list gets built on time and the game runs great. Other times, however, it seems like the List it built after the query happens and my console goes haywire with "object reference not set to instance of an object" exceptions. The script in question is as follows: https://hastebin.com/pozanusese.cs and the script for the GameManager is as follows: https://hastebin.com/jolegabulo.cs.

Obviously I'm not the most advanced programmer but I still wouldn't consider myself a beginner as well. I suppose I'm mostly just confused as to why the timing works out great in some cases and in other cases the timing is way too far off. Sorry if this post is a little vague, I just got up and haven't had my coffee yet. Thanks y'all!

 

Oh, and the "Object reference not set to instance of an object" exception is thrown in line 19 of LightController.cs

 

I had already answered your question in another thread.
You may want to add a getter (either get-method or property) and initialize it when something needs a the reference to it.

Or you just use the field initializer so that it gets initialized as soon as your type is accessed.

Not sure why you haven't tried that until now.

 

Simple stupid answer is to make Start a coroutine on the thing that is dependent on the list and have it wait one frame before accessing it.

I'd still most likely go with what @Suddoha suggested. The only issue I see with it is attempting to access the property in an Awake method would fail in an unrecoverable way (and corrupt the list data).

 

I just tried this:

Code (CSharp):

1. public List<GameObject> CurrentGameObjects
2.     {
3.         get
4.         {
5.             if (CurrentGameObjects == null)
6.             {
7.                 foreach (GameObject Obj in GameObject.FindObjectsOfType<GameObject>())
8.                 {
9.                     OnObjectCreated(Obj);
10.                 }
11.             }
12.             return CurrentGameObjects;
13.         }
14.         set
15.         {
16.             CurrentGameObjects = value;
17.         }
18.     }

and I got myself a stack overflow error. I'm assuming that I am not using the getter properly

 

What does OnObjectCreated do?

 

for right now this is all it does:

Code (CSharp):

1. private void Event_OnObjectCreated(GameObject obj)
2.     {
3.         CurrentGameObjects.Add(obj);
4.     }

 

The setter is probably screwing it up. I'd just do this

Code (csharp):

1.  
2. private List<GameObject> current;
3. public List<GameObject> Current
4. {
5.     get
6.     {
7.         if (current == null)
8.         {
9.             current = new List<GameObject>();
10.             current.AddRange(FindObjectsOfType<GameObject>);
11.         }
12.         return current;
13.     }
14. }
15.  

 

welp, looks like you were right my good sir! Many thanks to you!

 

Why would it fail?

 

If it relies on a list of GameObjects that haven't initialized yet because you called it in Awake

 

Ah that's what you meant. Ye, that's correct. Of course I assumed he'd use Awake, Start and so on properly, so that shouldn't be an issue. :S

 

Thats because you're calling the getter recursively, infinitely, so its always gonna overflow. Not sure how noone caught that...

 

Simplest would be to do every initialization in Awake, and accessing other objects in Start. That way you'll never have any timing issues.

 

This doesn't work when your initialization depends on other GameObjects in the scene.

 

Control your script execution order using the project settings, and then structure your awake and starts so dependencies already exist before being called / referenced.

A good way I do this is to create a startup manager, which calls the start method (called CustomStart in my scripts) based on the defined order I decide.

I also do the same with updates and run everything through an update manager to combat this problem:

https://blogs.unity3d.com/2015/12/23/1k-update-calls/

 

I'd leave the order alone whenever you can, instead try to design a system that does not rely on an order or simply resolves this in different ways - one example is this thread, where lazy initialization might be handy.

A growing SEO is one of the worst things to have in a Unity application, it needs to be well documented for serious projects and is just a root for various problems.

This arcticle has never mentioned all the pitfalls you can run into, as you re-invent the wheel. Still something to keep in mind once you are serious about implementing this properly.

Because that wasn't the original issue. @KelsoMRK spotted and fixed it, he just did not elaborate any further.

 

Dont worry, I have a very fleshed out start and update manager and the performance gain from it is around 50% increase depending on how script heavy the application is. Further more, controlling my script execution by use of a start manager ensures that everything is where I want it to be, and when I want it to be, similar to the type of initialization logic you would code into a "pure" c# or c++ program. I definitely recommend you giving it a go, and profiling your performance before and after to see what I mean

Please Note: Also if you look inside of unity decompiled code on github it is easy to see that the way they handle multiple updates are not good and running them through a single update manager reduces this overhead (less in 4.6 experimental but still an increase)

 

I've got a project setup to test this whenever I want since I experimented with it the first time, I know about the benefits.
My point was that the blog post simplified it alot, but once in a while you find posts that refer to threads or tutorials that miss quite of alot of it so that the "improved" system does behave quite differently and even inconsistenly from what you're used to in Unity.

It wasn't my intention to talk negatively about it.

 

Dont use start, its buggy and unreliable, use your own Interface method. Do your own initialization discipline.

 

Elaborate and provide examples if you're going to toss out a statement like this.

 

Wat mate?

 

Sure. MonoBehaviour it self has it lifespan that does not always match your project lifespan. Now Awake is ok since it will only happy ones, but start will trigger when things are happing. You want to control what happen. Even the word start is missleading since what you really want is initialization. You don't want start to happen. Ok i show some code to explain:

An Interface example

Code (CSharp):

1. public interface ISkillSystem
2. {
3.  
4.     float TimeDuration    { get;set;}
5.     bool SkillReady    { get;set;}
6.  
7.     void Execute ();
8.     void StopSkill();
9.     void Initialize();
10.  
11. }

Implementation:

Code (CSharp):

1.  
2. public class SomeSkillName: MonoBehaviour, ISkillSystem
3.  
4.     bool skillReady;
5.    public bool SkillReady
6.    {
7.        get {
8.            return this.skillReady;
9.        }
10.        set {
11.            this.skillReady = value;
12.        }
13.    }
14.    float timeDuration = 1.4f;
15.    public float TimeDuration
16.    {
17.        get {
18.            return this.timeDuration;
19.        }
20.        set {
21.            this.timeDuration = value;
22.        }
23.    }
24.  
25.    void Awake()
26.    {
27.        // Set up components
28.    }  
29.  
30.    public void Initialize()
31.    {            
32.        // What you need to setup your skill here and the first stage in the life cycle.
33.         skillReady = true;
34.    }
35.  
36.    public void Execute()
37.    {
38.        skillReady = false;
39.       // Make your skill start, the next step in your cycle.
40.  
41.     }
42.    public void StopSkill()
43.    {
44.      // things that happens when you stop the skill
45.     // Example Stop your corutines etc.
46.     // The end of your lifespan
47.    }
48.    // -----
49.  
50.  
51.  
52.  
53. {

 

What? What does this even mean?

Are you saying that objects can be destroyed before the game itself is over?

Yeah... of course their lifespan doesn't match, GameObjects/MonoBehaviours aren't permanent.

Otherwise... I have no idea what you mean.

Start only happens once as well.

Huh?

Start will occur once, if enabled, before the first time Update will be called. It's documented how it works:
https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html

Yes, you don't control this... Unity does. Just like Unity controls when Awake is called. But this isn't buggy behaviour... you said that start is "buggy and unreliable". You've yet to describe how that is.

initialize - verb - to set (variables, counters, switches, etc.) to their starting values at the beginning of a program or subprogram.
http://www.dictionary.com/browse/initialize?s=t

You literally picked a word whose definition is 'do stuff on start'.

This argument about the name is purely subjective semantics. You don't like the word, doesn't mean others give two craps about the word choice.

I think we understand the concept of an interface, and how they work.

We asked for you to please back up your claim that Start is "buggy and unreliable".

 

Also, your example code does not demonstrate how 'Initialize' would ever get called.

Without any extra code to auto-call it... it'd have to be manually called by the programmer at some point. When would that point be?

If it was after calling AddComponent, well sure, this could be useful. But this also means you can only add this script via code and never in the inspector. Since adding it in the inspector creates a state where 'Initialize' never gets called.

This doesn't really seem to resolve any buginess, but instead just seems like a programming preference of yours for a very specific case (adding components in code, rather than in inspector). Heck, I don't even know why this needs an interface, unless it's integrated into a factory pattern or something.

 

You don't know what lifespan of MonoBehaviour means? Ok ..

Spoiler: Surprise

No what makes you think i say that?..dont mix other things with this..Poolmanager deals with objects, and can easily access the Interface cycle correctly, before its destroyed.Making sure relative objects also end there cycle.

I lost your point of argument here mate.

Actually your wrong, and this is the whole thing about my statement. After some testing i found out that Start actually happens way more than i was happy with, causing allocation when i really don't want that. I could dig deeper in to it but i figured it was much better to implement my own discipline and leave out Start completely. OnEnable can be useful, but after implanting my own interface i find less use for it.

Well it happens more than ones, but it happens before the first update cycle. Another issue with Start is that
you have to consider script execution order, with my logic implementation you dont have to deal with script Execution order, you use Execute when things are suppose to happen, not just put your finger up in the air and hope for the best.
I think your smart enough to understand what i mean

Getting null exception is not fun because of script Execution order is it? A bug is always relative to something.
Even when you put you script in the right orderby the Execution order it can still bug, because your files can get delay
on load from your harddrive.

Correct..

Start is unrelative, life cycle is..

Well putting the right name or word on class or method have always been important in the development environment.
Don't you think?

Lol its not the concept of Interface, its how its used for a lifecycle. as i explained

Already documented...

 

Sure i make an example, but when this cycle is implemented, how you access it can happen from many different scripts and even other Interface logics, that is the whole purpose of having an Interface in the first place.

In this case i used it for a skill, a skill that drives from a item system and a skillbar system, if you add monoscript from
other classes they trigger the start event even if you like it or not, example pressing the skill button. Why would you need
to depend on Start for a button event to happen? Makes no sense to me.. You want something specific to happen when you trigger a button. Press button "Execute skill", or stopping the skill or skill duration has ended..

There is no basic way of accessing an Interface concept, it becomes a part of your construction.

Lets have a quick overlook what is needed for a game in most cases, you have:

1. A Player
2. Monsters
3. Skills
4. Items or gear
5. Navigation and movement
6. AI etc..

All of this could follow the same lifecycle logic. initialize, Execute, Stop, Duration .

Monster:
- initialize its startup values after awake have allocated its components. (Example Health = MaxHealth)
- Execute (means the Monster is alive and starting its lifecycle) Example after the monster is spawned (Interface access from your spawning manager instead of just start..
- Stop (This could stop all its connected components making sure no other script in relevance to the monster is running, like Corutines events, animation or monsters skills..

etc etc.
Now i have more than one Interface implementetion but i use this as a base system for all my classes so they are more under my control and not the script Execution order. that bugs more than once. You might have 1000 scripts, good luck doing the execution order handling automatic.

Sometimes the lifecycle resets, question is, does this happen on your watch or by MB automatic start ?

 

OK, so you're talking about the event execution order. I do know what this is, your jargon though is often vague and non-specific, so unsure what you're talking about exactly half the time.

You said "lifespan that does not always match your project lifespan", lifespan, not lifecycle... in this weird sentence that honestly I could barely parse in any intelligible manner.

What makes me think you said that? The fact what you said made no sense to me. I had to reach at some possible meaning for "lifespan that does not always match your project lifespan".

See previous statement.

Umm... please, give me an example of Start happening more than once! This would be a bug, but I've never seen it myself.

Start, by documentation, is defined as happening once just before the first time Update is called.

That's it.

If it happens again, submit that as a bug to Unity.

SUBMIT IT AS A BUG if this is true.

Though I won't believe you it is true until you prove it... which was the point of my and KelsoMRK's posts... we wanted proof of it being buiggy.

What are you going on about? Start is causing you null exceptions? In what way? How does your initialize solve this?

Yeah, I know.

OK, 1) you said 'Initilize' and 'lifepsan', not life cycle. And 2) what do you mean unrelative? WHAT? I can't anymore...

What makes a name "right"? You liking a different word doesn't make it "right", it just makes it what YOU like.

Uh-huh... see my follow up post where I go more into that example code.

Already documented... WHERE!? I don't see any documented bugs about 'Start' in any of your rambling.

 

Most of my scripts don't care about execution order.

The tiny percentage that do, yeah, I have a different way of handling it.

But since out of thousands of scripts I only have maybe 4 that care about the order... I don't come up with some alternate system to use in all thousands of scripts.

...

I don't know, your posts are very difficult to follow along. I get the feeling you don't speak English natively, which could possibly be the issue. Not exactly your fault, just hard to follow along what you're saying, stuff probably getting lost in translation or something.

Eitherway, you vaguely talk about "bugs", but never actually document a bug with Start. But more just you don't like the way Start works, and prefer a different model.

Which is fine... work in whatever model you want.

It doesn't mean 'Start' is buggy though. It means you prefer to work it a different way, since you seem to have a hard time avoiding your OWN bugs as a result of the way Start works.

 

Ok so you have issue with script execution order to? would be great if you shared that information, i am not
saying my solution is the ultimate one, it works and using Start is not an option any more.

My apology, yes my native language is Norwegian, but even so that is not an excuse, The real truth is that my typing is abit rusty, it usually warms up after some threads.. Sorry for any convenient it might have. I try to sharpen my typing better.

Isen't it "Either way" not "Eitherway" ? i am just curious..
Start is the main source of script execution warnings i get, maybe not a bug from the system, but it generates exceptions.
If i get time i report the bug i do it. I still haven't seen any of my other bug reports fixed so i see how much time i put in to this. I like when things work.

Well this leads back to the topic of this thread, and the reason for this person to get a null exception, i am not hijacking the thread or trying to change the subject. My tip was simple, dont' use start to avoid null exception and confusion.

 

Start is part of Monobehaviour. A class which is a Component, and spirit of components by nature were intended to be so that they are not co-dependent on other components. So Start() in and of itself isn't buggy. Start is a message which always fires once and on the 1st frame it was active after awake. and while its also clearly documented its less obvious that if multiple objects are to start at the same time Unity will call them in a random order. It doesn't matter that this can cause Execution order errors, it doesn't make it a start bug. Because start is still behaving exactly as it was documented to behave.

When you do write scripts where Script Execution Order becomes an issue, That is usually a hint that your code-base is suffering from dependency-rot and that you need to look at and re-think your design. The common remedy to this is using Dependency Inversion, which usually takes the form of a manager class controlling sub-component lifecycles, or a context class responsible for injecting references when needed.

 

A valid point, and again sorry, i try to clarify better next time, its my fault that i think people have excellent reasoning skills for everything i say.

Well i guess i have better luck with computer compiler than with the human compiler I understand your confusion,
i meant lifecycle not lifespan..But a script have both a lifespan and a lifecycle, a skill can repeat it self, but has a lifespan, hence why duration is there in the interface implementation.

Every time you call the script from another source or Interface. Every time the cycle resets, every time
components on the script access the script. Every time you enable an object with that script. And sometimes it happens without any logical explanation, i figured this it out while doing optimization in the profiler, that "Start" was triggering more than ones.

I know that, but it happens on the top of the chain every time..

When they fix the Mecanim controller yeah i do it. Yet to be fixed thought, it still reset transform every time it changes.

The prof is in the topic of this thread.. even you are doing things differently to avoid it, you said so your self.

Pretty clear what i have done about it. i documented it by examples and code. I solved all of this issues with the Execution order error, no error, no unwanted allocation on top of the chain, no null exception. Full control.

Calm down Lord, this is not the cirus. but i be happy to buy you a ticket.. Its only codes.. I am sure you have scripts that have elements(GO, Components etc) that are relative to your gameobject you currently working on.
Or maybe you dont, i don't know. Maybe you have everything as child object? Simplification might just be your thing then. For me i don't have that choice. I can not deal with limitations.

If you can't see that, then i think we need more light in the cirrus. Keep your rambling for your self, this are codes that have been used 100 of times by 1000 of user without any problems. Zero use of Start() not needed, or has to be included. Null exception with start and execution order is a well known issue. Read the topic again..

 

OnBecameVisible is also part of Monobehaviour. Do you also use this in all your scripts? wow f. me then..

Nope, my rethinking lead to removing Start as it is unreliable. Read what i said previously.. I been using this "design" as you call it for a very long time now, i see no point on going back to Start() Why would i choose problems over solution?

 

this... at lest one person understand things here without a circus attached.

 

Only in the scripts where I need to. I fail see how that factors in this topic.

How you choose to build your projects is completely acceptable, no one has a problem with your preferences. If you want to use your design then go for it. That is a case of opinion so you have the freedom of choice.

The problem everyone here has is the fact that you said [Start is buggy and unreliable] which is completely unproven and (until proven) blatantly false. You haven't been able to supply satisfactory proof. This is a case of fact, not opinion, so such a statement will be highly scrutinized.

In all my years of using Start, the only time I've had issues with it was when I was first starting out and didn't fully understand how it works. what you're describing to me however has never happened to me, and I don't recall anyone else ever saying the same thing happened to them, aside because they were manually calling it.

Which leads me to believe its due to your environment. Your claim has a weakness of internal validity. "Because it happens to me it happens to everyone." is faulty logic. I expect that if Start is buggy for you, it is because something has been set up in your developing environment that makes it buggy.

Can you post example code or provide unity project/package that causes this to happen? Something that allows others to be able to reproduce the issues you are talking about? If you are able to do that and others are able to repeat the issues (against the expected behaviour) that you mentioned in their own environments, it'd go a long way to resolving your issue of internal validity.

 

To expand on what @lordofduct has already said, Start is actually a part of the initialization process for MonoBehaviours, as initialization happens in multiple steps:

[Constructor - Called by Unity, normally not used in MonoBehaviours by the game developer]
Awake - Usually initializes the instance with values that do not depend on the state of other components. It's kind of the alternative for the constructor, because you should not use the latter in MonoBehaviours.
Start - Further initialization that can depend on other components' state, this is always done after Awake with an optional delay if the components is not enabled at the time it's created.

(Unity does as well add OnEnable to it, but that depends on one's usage. Some use it for initialization of another lifecycle, other's use it differently.)

Anyway, the point is: This is usually fail-safe, unless you have weird coupling and/or messy instantiation going on.
If one keeps that in mind, it's even difficult to run into execution-order problems. Like stated in a previous post, one should not mess with the script execution order (SEO) to solve these problems, if a maintainable project and easy-to-reuse components are desired.

IMO, there are still some specific cases in which you can touch the SEO - but they do not involve solving dependency and initialization problems. This itself is a huge and different topic.

Here's an update for your source of information. It's kinda the same in its basics, just extended by features that were either missing in that diagram or have been added with release since... Oh! Hello Unity 3.4 @2012.

You can as well do this using Unity's messages. It's more of a convenience to implement your own system, which is not required to make it work but indeed can be useful for even more fine-granular control and more abstraction.

He's not wrong.
Allocation of what? If it allocates anything in Start, then you've told the component to do exactly that.
(Small fun fact: Replace "Start" with "[Any access modifier] Default / Parameterless Constructor" and that paragraph does actually make perfect sense.)

Neither the previous was an issue, nor is this ( referring to "another issue" ) a problem if you follow the advices given above.

See above.

Erm, what? Oh my... I'm speechless.

Stop twisting his words.
He says his components barely rely on the SEO. And when it does, it's not due to problems you describe.
In contrast to that, you tell us you do implement initialization interfaces for every of your classes - which implies (not says, but it implies!) you're depending ALOT on some kind of SEO.

Which is the proof for the previous statement. So it's you who got the problems with SEO.

Exception was caused by wrong setup of the scene and/or incorrect use of Awake/Start. In the end, this was solved using lazy-initialization using a getter.
Once again, if you use Awake and Start correctly, you do not run into problems unless your implementation suffers from weird dependency issues.

 

What allot of rambling., when you only make games like tetris you never ran in to any of this issue, all your rambling is not relative to this discussion. I am not even going to bother comment them..

"Exception was caused by wrong setup of the scene and/or incorrect use of Awake/Start.". that one made my day..

There is a reason why we have async. and there is a reason why you want things to happen at the right time, not a "start" of the life cycle when the script is active. You failed to understand this part totally.. but hey i am sure it works on Tetris you scene just need to be correct...

 

Oh FFS, just stop. You made some bold statement about Start being unreliable. Multiple people asked you to provide some example where that is true. So either do it or stop posting.....

 

The OP said it's resolved, exactly by doing that. Please read properly.

Again you're starting to hijack, trying to bring other topics in because you've been proven wrong and can't stand it. This thread is not about async. And noone ever mentioned it. And the OP did not even rely on anything being async.

Your other inconstructive comments about one's skills are immature, as you have no valid and solid reference to proof it. Stop losing your credibility, your PMs have been immature and offending enough, hence the report.

 

You can use the script execution order.

With that, you can be sure your manager unity function (awake,start...) run before all other script :

https://docs.unity3d.com/Manual/class-ScriptExecution.html

 

Yes and? Empty argument again? In case you forget the topic "void Start() timing is waging war with one of my gameObjects".

I am not hijacking any thing, you storm in here like some hurricane with copypast material from Unity docs without a slightest understanding of what we are talking about, your clearly not paying attention to what i am saying here, you just punch in with copypast material that every one knows. I never even argued against them...
Before you post its smart to read and reflect what have been said, maybe do some background check.
Again your stealing the attention away from the subject and put the focus on me instead, if you had put the same amount of focus on what i am actually saying we wouldn't have this discussion in the first place. Get a grip on your self and relax.

Did you even understand what i meant with async is there for a reason? Its not relative to Start or Awake?
It pretty much is, if your reading or wring a file in Start without any type of async you be in big trouble. Because start happens no matter what you do, Now you only made games like tetris so for you following the basic schematics works fine.

Example1 : You have an gameobject with a Monobehavoir compontent script, It has start() and update().
What do you think happens when this GO is set to Inactive and then Active again? The whole cycle startes again....
Meaning Start will happen, Awake will not.. Yes both are documented as initializes, and so? its not the same as the code i posted, thats an Interface implementation.. You do know what a Interface is right? or you need to google that to and then come back here and copypast and pretend your Kent from superman? You should really stop with this unless you have some real technical facts on the table and not empty words..

Example nr2. : You have a skillbar with skills, each of them triggers an Interface reference. like other.GetComponented<ISkillSystem>().Exectue().. Now what do you think happens if you have Start on that script? I leave the question to you to answer, lets see if google can answer that for you..

Start only happen ones? No it happens more, want proof? Sure i can make that later after dinner. Or you can try Example 1 or 2 your self it not exactly hidden info..

Why do you think we even have script execution order? Why do people solve issue with script using this?
To avoid fixing things in the scene? No to fix the order of loading scripts...Link about this has allready been posted here just go read that..its there for a reason.

Bla bla bla. yes i have solid proof your just not paying attention. Stop mixing up the subject ,this is exactly what hijacking is, what your doing here now.. Talking about some PM or other unrelated personal things, go for a walk, get some fresh air come back to me with some real argument and then we can see. I still want that question answered in example2.. better get to it.

How you manage to jump out the lifecycle discussion is beyond me. Lord here actually got it, you clearly didn't.. but yet you jump in like a troll from a box with copypast documents nobody here denied where true. Please no more empty arguments

 

Sorry stop what now? Bold or you didn't comprehend? Why do we have execution order in Unity? People have no problem with script execution order? no really they do, hence my tip on not using Start(). Lord here even had his own solution i am very curious about.. Not every one lean on basic schematics. I have now 4 example, please go read
the 2 new ones. #41 <---- go read and here #23 <-- go read I am not really that found on ppl telling me what to do on a forum its disrespectful.

 

This is false. Start happens once. The functionality you're describing is defined in OnEnable.

You really should stop being a dick when you respond to people.

It gets executed. As you would expect a Start on every other MonoBehaviour created from now until the end of time to do.

Put up a code example of a MonoBehaviour that fails to use Start in a reliable manner or invokes Start more than once. Nothing else. No more blathering about async, execution order, interface examples, on and on. No more insulting people. No more BS.

 

Do you want to bet? I am working on test project now i was thinking to share here for every one to see. How much do you bet against that?? Please stop with that language i find it disturbing and unprofessional for a forum standard. calling me a D... makes you then a nice respectful person?

 

Don't bash a classic. Just because a game was made over 30 years ago doesn't make it simple. To make a game like Tetris especially with the Dev tools and hardware at the time took a serious feat of skill.

I believe this is something that was just lost in translation. "async" is a keyword in C#, which is completely different in what i think your trying to talk about. Its easy for us to assume that you meant C# term.

No, it doesn't. Even when reactivated Start only gets called once. Its always been that way.

Tried:

Code (CSharp):

1. public class StartTest: Monobehaviour
2. {
3.     private void Start()
4.     {
5.         Debug.Log("Start is Called");
6.     }
7. }

Added it to a single gameobject, played and then enabled/disabled the gameobject and monobehaviour in all permutations. The Log showed up on the console only once.

Its there so that people can solve their design problem as cheaply as possible. Fixing it "properly" isn't always feasible, redesigns are expensive. The fact that you have to use it hints at code smell.

 

Excuse me, but where do i insult any one? its an insult to confront you with the fact that you didn't comprend/read what i said?
But its ok to call me a Di.. ? What planet do you come from?

 

All the money I make from now until I die. @JoshuaMcKenzie just did it and proved you wrong.

So again -

 

Josh didnt do it correctly. Project coming up soon, just implementing some Inteface as well and some UI..

 

Who is this guy.

I love how he is a dick to people, but then gets confused when people are dicks right back to him.

Get what you give brah!

...

Waiting for this project. Would love to see Start getting called repeatedly, and these exceptions he keeps going on about. This will certainly be interesting at the very least.

Why do you need interfaces to demonstrate Start being buggy?

LOL!

 

It's a good thing I didn't wait with bated breath... I may have suffocated.