Nested loops in coroutine

Scripting
,
1 
IEnumerator ModifyAttributesWhenKeyPressed()
    {     
        while(unspentSkillPoint>0)
        {
            bool pressed = false;
            while(!pressed)
            {
                if(Input.instance.RiseAttribute_1||Input.instance.RiseAttribute_2||
                      Input.instance.RiseAttribute_3||Input.instance.RiseAttribute_4||
                      Input.instance.RiseDeffensiveAttributes||  Input.instance.RiseDeffensiveAttributes)
                {
                    pressed=true;
                }
                yield return null;
            }
            if(DeffensiveAttributesPanel.activeInHierarchy)
            {
                if(Input.instance.RiseAttribute_1)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(Input.instance.RiseAttribute_2)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(Input.instance.RiseAttribute_3)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(Input.instance.RiseAttribute_4)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else break;
            }
            else if(OffensiveAttributesPanel.activeInHierarchy)
            {
                if(Input.instance.RiseAttribute_1)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(Input.instance.RiseAttribute_2)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(nput.instance.RiseAttribute_3)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else if(Input.instance.RiseAttribute_4)
                {
                    //+att here
                    unspentSkillPoint--;
                }
                else break;
            }
        }
        print("end ;oop");
        DeffensiveAttributesPanel.SetActive(false);
        OffensiveAttributesPanel.SetActive(false);
        AttributesPanel.SetActive(true);
    }

This is my coroutine. All I want is these 4:

print("end ;oop");
        DeffensiveAttributesPanel.SetActive(false);
        OffensiveAttributesPanel.SetActive(false);
        AttributesPanel.SetActive(true);

keep standing still until unspentSkillPoints reaches 0 or the menus are closed, but instead, they start even when unspentSkillPoint is >0. The question is: do I misunderstand the coroutine- instead of the normal order in nested loops, it ends the outside loop too? Thank you for your time, I really appreciate it.

2

When the code executes yield return ...; then no more code in the entire function will run, and then on the next game loop Update cycle, code will continue immediately after that point. If your yield is inside twelve for loops, a switch, six while loops, two ifs and an else, it will still do the same thing: pause execution of this function until the next Update cycle.

I really don’t see why you’d design this kind of feature in a coroutine but that’s a separate topic.

3

Yeah, definitely not a useful place for a coroutine. Yes you can use one but it doesn’t improve the problem space and actually tangles it up a bit.

Just make a regular old event-driven UI with spend / assign buttons.

Have outstanding unspent tokens, let players spend them.

Bonus: have “revert all” to unspend all and restart.

Bonus bonus: have “unspend” buttons on individual attributes.

When all unspent tokens are spent, continue. This is easiest accomplished by having a “Continue” button and set it not interactable while any points re unspent.

Otherwise if you want to debug any code, use this approach:

Time to start debugging! Here is how you can begin your exciting new debugging adventures:

You must find a way to get the information you need in order to reason about what the problem is.

Once you understand what the problem is, you may begin to reason about a solution to the problem.

What is often happening in these cases is one of the following:

  • the code you think is executing is not actually executing at all
  • the code is executing far EARLIER or LATER than you think
  • the code is executing far LESS OFTEN than you think
  • the code is executing far MORE OFTEN than you think
  • the code is executing on another GameObject than you think it is
  • you’re getting an error or warning and you haven’t noticed it in the console window

To help gain more insight into your problem, I recommend liberally sprinkling Debug.Log() statements through your code to display information in realtime.

Doing this should help you answer these types of questions:

  • is this code even running? which parts are running? how often does it run? what order does it run in?
  • what are the names of the GameObjects or Components involved?
  • what are the values of the variables involved? Are they initialized? Are the values reasonable?
  • are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

Knowing this information will help you reason about the behavior you are seeing.

You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as Debug.Log("Problem!",this);

If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

You could also just display various important quantities in UI Text elements to watch them change as you play the game.

Visit Google for how to see console output from builds. If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer for iOS: How To - Capturing Device Logs on iOS or this answer for Android: How To - Capturing Device Logs on Android

If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

If your problem is with OnCollision-type functions, print the name of what is passed in!

Here’s an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

“When in doubt, print it out!™” - Kurt Dekker (and many others)

Note: the print() function is an alias for Debug.Log() provided by the MonoBehaviour class.

4

Sorry if I misunderstood you, but this is what I intended to do.

I’m pretty new to Unity, then this is what I wanna try, of course, I can do this with some scripts on the menus, just I’m learning anyway so I wanna understand the above case. Through your explanation - sorry if I misunderstood something - I still can’t see why the 4 lines of code still execute. As your saying, after the line 64, the code must return to the first while loop, but it wouldn’t.
Btw, could you please explain to me why shouldn’t we design this kind of feature in a coroutine? Thank you for your time.

5

Coroutines are for fire-and-forget stuff that takes place over a number of frames. Not stuff that requires stopping and starting, or this kind of UI management.

Basically, it doesn’t need to be a co-routine. It just needs to be normal code that runs when invoked by user input.

If you want to let the player hold a key down to steadily assign points, this can be done via normal Update means.

6

Thank you for your time!

This is what I do every time. In this case, as you can see, I put the print() line first, and they write line as I expected (If the misunderstanding is the case). That’s the reason I - after 2 hours of testing with every kind of print() I can think of- decided to ask this noob question: does startcoroutine() make the yield return works differently from itself in the original.

7

Thank you so much, clear answer.

8

See how in your code you ask the same question twice? How you spin waiting for anything, then once anything happens you set pressed, exit and go decide again what to do? You want to alway avoid repeating yourself.

The best way to structure this is to have two panel scripts, one for each: offensive, defensive, etc.

Display the appropriate panel (perhaps have left/right buttons to switch)

When on a panel, respond to the user intents and update the data.

When a panel is inactive, its script should ignore all input intents.

The usual way to do this is to enable and disable input contexts in the OnEnable() / OnDisable() methods of each panel’s script. That way only one panel is listening at a time, if any.

Otherwise, coroutines work like any other code. Check this out:

Coroutines in a nutshell:

Splitting up larger tasks in coroutines:

Coroutines are NOT always an appropriate solution: know when to use them!

“Why not simply stop having so many coroutines ffs.” - orionsyndrome on Unity3D forums

Our very own Bunny83 has also provided a Coroutine Crash Course:

9

Thank you, this is what I think of when the first time I was designing this. I tried the above approach because I don’t want to make more code, besides, I wanna understand the coroutine more, that’s why I have made the above question.

And for this, thank you so much, I’m gonna read them asap.
Thank you so much again for your attention.

10

You have 6 conditions in your if statement which makes your statemachine advance outside your nested loop (though the last two are actually the same!!!). If any of those conditions is true, the nested loop would finish the next frame. I’m not sure why you structured your code like this. Currently when in this frame one of the conditions is true, you still have that yield return after your if statement which would make the coroutine wait for another frame before continuing with the rest of the code. This has a lot potential for a “logical” race condition in case your condition(s) is (are) only true for one frame.

If your coroutine advances right the next frame when it’s started, it just means one of those 6 (actually 5) conditions are already true when you start it.

Waiting for input inside a coroutine should be done like this as your additional bool variable just makes the code more complicated and introduces the potential race condition I mentioned.

            while(!(
                      Input.instance.RiseAttribute_1||Input.instance.RiseAttribute_2||
                      Input.instance.RiseAttribute_3||Input.instance.RiseAttribute_4||
                      Input.instance.RiseDeffensiveAttributes
            )) {
                yield return null; 
            }

If you really want to keep the if statement, the yield should either come before the if statement or make the if actually break; out of the while loop instead of setting that boolean to true.

Now in order to debug your actual issue, just make a Debug.Log right after the nested while loop and print out your 5 conditions with it. So you know which one was the reason the while loop was exited.

Note that in your current code those two logs may not print the same thing due to the yield in between:

            while(!pressed)
            {
                if(Input.instance.RiseAttribute_1||Input.instance.RiseAttribute_2||
                      Input.instance.RiseAttribute_3||Input.instance.RiseAttribute_4||
                      Input.instance.RiseDeffensiveAttributes||  Input.instance.RiseDeffensiveAttributes)
                {
                    pressed=true;
                    Debug.Log("Input1: " + Input.instance.RiseAttribute_1 +" " + Input.instance.RiseAttribute_2+" " +
                        Input.instance.RiseAttribute_3 +" " + Input.instance.RiseAttribute_4 +" " +
                        Input.instance.RiseDeffensiveAttributes
                    );
                }
                yield return null;
            }
            Debug.Log("Input2: " + Input.instance.RiseAttribute_1 +" " + Input.instance.RiseAttribute_2+" " +
               Input.instance.RiseAttribute_3 +" " + Input.instance.RiseAttribute_4 +" " +
               Input.instance.RiseDeffensiveAttributes
            );
11

Thank you so much. These are actually great advices. I’ve learned so much from your answer. God Blesses You.

12

@Bunny83 T’m sorry, may I ask you one more question: in play mode - or testing mode- my Unity freeze randomly. Could you brighten me up with a way to find out where is the problem? Like, which is the most potential function, or how to catch the running call. I’m using visual studio for student, and when attach to unity, VS’s call stack shows up nothing. Thank you for your time.

13

That usually happens when you have an infinite loop that doesn’t have a yield statement inside. The yield return makes it leave the coroutine so other things can happen. When there’s no yield inside a loop, NOTHING outside that loop can ever happen. That includes new user input. The whole process does nothing else except running your loop. So when you have any kind of loop, make sure it’s not infinite. The only place where an infinite loop “can be” not a problem is inside a coroutine but only when you have a yield instruction in it.

14

Since it hasnt been mentioned yet here, Unity is single threaded, which is why the above is true and important. Even async code execution, like coroutines, are handled on the same thread. Just to clear up potential misunderstandings.

On another note, when you think you should solve something using a Coroutine: think twice. I personally think they are beginner traps. While im not saying there is no usecase for them whatsoever, im fine without ever having used one outside of prototyping. Usually when you solve something simple with a coroutine, you may aswell handle it manually. And if you handle something complex with a coroutine, they simply take control away from you, reduce maintainability and readability and thus oftentimes cause bugs people cant solve on their own, which then end up on this forum.
“Set and forget”, as spiney described it, is a good rule of thumb. If you ever need to stop, interact or micromanage the code in that coroutine againa after it started, coroutines make it a hassle instead.

15

Thank you so much.

16

Wise advice! Can you suggest me 1 example? Like I need one action to be delayed some seconds, would I have another way? I’m pretty new to unity and C#, so…Of course, if you have time.

17

By using Time.Deltatime, right?

18

If it’s a set-and-forget kind of thing, you can get away with using a WaitForSeconds Coroutine. Usually what was once set-and-forget has a tendency to evolve into something that is not tho.

For most things, such as cooldowns, you want to either have a timer running (increment or decrement some value by Time.deltaTime each frame), or memorize the last time it was activated and check the current time and compare it to some value to determine whether a sufficient amount of time has passed.

If the action you want to delay is the SetActive art from your first post (closing the skill menu), this sounds like a set-and-forget case on the surface. However, imagine you make it close 1 second after the skillpoints were spend, and the player is quicker and closes, but also reopens the menu during that duration. Suddenly you wanted to implement a convenience for the player, but actively worked against them in this case.
Personally i would argue that you have to be careful whenever you take the control from the player. It is oftentimes just better to offer the player a convenient way of dealing with things themselfes. For example by supporting hotkeys, like ESC. Or by letting RMB close the menu once all skillpoints are spent. Something quick but intuitive to use like that. If the menu pops up or otherwise becomes relevant so frequently that you are worried that it not closing on its own is negatively affecting the player experience, i would dare to say that mechanic itself needs to be reworked.

If you absolutely must automate this, you could handle it any given way (coroutine, timer, …). But make sure you keep track of further player interaction to then stop this timer or kill the coroutine, if you have to.

19

Wise talking. Thank you so much for your advise, and your time too. Gods bless you.