Instantiate breaks Update

Hi everyone

I'm having an issue with Instantiate().
I have an GameObject which is made to duplicate an other gameobject each 5 seconds :

Code (CSharp):

1. void Update()
2.     {
3.         time += Time.deltaTime;
4.  
5.         if(time >= 5)
6.         {
7.             time = 0;
8.             nb_star += 1;
9.             choosen = rand.Next(0, nb_routes);
10.             starList.Add(Instantiate(starpack));
11.             starList[nb_star].transform.Find("star red").GetComponentInChildren<PathFollower>().pathCreator = route_list[choosen].transform.Find("route").GetComponentInChildren<PathCreator>();
12.         }
13.     }

But when the command "starList.Add(Instantiate(starpack));" executes it break the Update() and goes on Update() of the other scripts.
Do you know why and how I could fix it?

Many thanks, tell me if you need the rest of the code

 

How did you determine that it does this?

 

What do you mean by "break the Update()?" There's only one more line after Line 10, and it's not clear to me what you would see anything happen as a result. Certainly, all Updates will be called once each update cycle. What is happening that makes you think the other Updates are being called improperly?

 

Ok I was wrong, it's not line 10 but line 11 which stops the Update.
By break the Update I mean that it stops the function and call other updates' scripts.

I've put a Debug.Log() after line 11 and it's never executed.
Line 11 is supposed to define a public Variable to the new cloned gameobject but it doesn't define it.

 

Do you have any errors in your console?

 

Nope

 

This is the public variable I need to define


And this is the location of the public script

 

also, I found an error message on the debug, but it's weird because the object is not null in unity window

 

Your line 11 is way too long. Split it into like 6 lines and find out what specifically is not working as intended.

 

I rarely comment just to say, "What he said," but...

What @Yoreki said.

 

Haha thank you so much to everyone for helping me!
The problem was really stupid... I was calling an element of the list which didn't exist.
I just had to call startlist[nb_star-1] instead of starlist[nb_star] ^^

Apologies for this stupid thread, I had not developped for 4 months.

 

Happens to the best of us. Just remember: when a problem seems to complicated, break it down into smaller, less complicated problems and solve those. Same goes for errors and debugging. Divide and conquer!

 

So true, yet I think it is pride that sometimes gets in the way of this simple and effective approach. One often looks at a line of code that isn't working, and says, "I shouldn't need to break this down. I should just see what's wrong with it."

As the years have gone by, I have learned to put my pride aside in favor of just getting things to work.

It is amazing how often "divide and conquer" is all it takes. Back about 1980, I read a short article in (I think) "Communications of the ACM." It was about debugging with a method the author called "the moose in Alaska." It goes like this: Somewhere in Alaska there is a moose, but you don't know where. To find it, you can split a region of Alaska, starting with the whole state, into two parts and ask if the moose is in one of them. If not, then the moose is in the other part. When you know what part it's in, split that part and ask the question again. Continue doing this until you have a part of Alaska containing the moose that is so small you can see the moose directly.

Code with a bug in it can often be debugged the same way. Just split your program into pieces repeatedly, until you have the smallest piece you can that still causes the bug. Odds are, you'll see what's causing it then. (People familiar with numerical methods will recognize this as a simple way to find the zeroes of a function, but not everyone ever does that kind of programming.)