Autorun Events (Or: Why Can't I Move?)

Discussion in 'RPG Maker MV Tutorials' started by taarna23, Jan 1, 2016.

  1. taarna23

    taarna23 Marshmallow Princess Global Mod

    Messages:
    2,349
    Likes Received:
    4,630
    Location:
    Saskatoon, SK, Canada
    First Language:
    English
    I've seen a lot of people struggle with autorun events, and I too have done the same. Character won't move and I know I've done something wrong with that new event, but I don't really know what. It wasn't until I recently learned how events process that it all made sense, and I wanted to share that so that others can learn from my repeated mistake.

    Part 1: Event Pages

    Pages are important for autorun events. Primarily, these are how you jump out of the loop that is an autorun event. Under ideal circumstances, an autorun event will process through its commands only once and be done. Something needing to loop until a condition is met is generally the realm of parallel process events.

    [​IMG]

    When an event is processed, it actually, counterintuitively (at least to me) processes the event pages in reverse order, from the highest to the lowest. As it goes through these, it looks at your conditions for that page and will process the first one that has its conditions resulting in a true statement.

    Part 2: Event Page Conditions

    The commands on an event page will be run if its conditions are met. If they are not, the page is skipped and the next page is looked at until one is found where conditions are met. An example:

    [​IMG]

    This set of conditions means that if TestCondition1 is on and Self Switch A is on, the commands in this page can run. However, if either one of TestCondition1 or Self Switch A is off, this event page will be ignored. If the conditions on your pages are set in such a way that no page will be run, this can cause an infinite loop in your event. As such it is a good idea to have one page that has no conditions, as this will always prevent an infinite loop in your event pages.

    What does this stuff mean for your autorun? Let's have a look with an autorun event that looks at a couple of switches and sets self switches accordingly.

    Part 3: Setting Up the Autorun Commands

    The setup for this particular example are pretty simple. Obviously for switches, they would end up being controlled elsewhere, but that is outside the scope of this example.

    The commands for this autorun event look like this:

    [​IMG]

    To put it simply, If TestSwitch1 is on, turn Self Switch A on. Otherwise (meaning TestSwitch1 is off), if TestSwitch2 is on, turn Self Switch B on. Otherwise (meaning both TestSwitch1 and TestSwitch2 are off), turn Self Switch C on.

    An important point about this design is it leaves no open ends. If one or the other of the switches are on, something happens to alter event processing. Same if neither are on. Leaving an unhandled condition can open up the possibility of an infinite loop, which we're trying to avoid. This can also be handled by having the very last line of an autorun alter a switch or self switch, so long as another page of the event is set to handle that condition.

    Part 4: We Have an Autorun, But Where Does it Go?

    If you're like me when planning these, you might start by thinking of the possible end results that you want and making the pages for those first. In this case, we would set one of each of Self Switches A, B and C as the conditions for 3 different event pages.

    These pages would be set to have "Action Button" as a trigger, and no event commands. That way if the player should manage to reach the event and press the action button, nothing would happen anyway.

    So, that just leaves the 4th page for the autorun. Easy, right? Well, let's see what will happen.

    Let's assume that TestSwitch1 is on, just to make it easy.

    Event Page 4 is checked - no conditions. Trigger is autorun type. Start processing the event commands.

    - TestSwitch 1 is on - Run commands along that part of the conditional branch

      - Set Self Switch A to on.

    - End of Event Page commands.

    Return to beginning of event page check.

    Event Page 4 is checked - no conditions and autorun type. Start processing the event commands.

    ...

    See the problem there? When a set of commands is run through to the finish, the whole event starts processing from the very beginning. In this example, only page 4 will ever be run, stuck in an infinite loop.

    To fix this, the autorun event needs to be on Page 1, moving the other pages down, and making the event processing look more like this:

    Event Page 4 is checked - Self Switch C is required and off. Skipping Page 4.

    Event Page 3 is checked - Self Switch B is required and off. Skipping Page 3.

    Event Page 2 is checked - Self Switch A is required and off. Skipping Page 2.

    Event Page 1 is checked - no conditions. Trigger is autorun type. Start processing the event commands.

    - TestSwitch 1 is on - Run commands along that part of the conditional branch

      - Set Self Switch A to on.

    - End of Event Page commands.

    Return to beginning of event page check.

    Event Page 4 is checked - Self Switch C is required and off. Skipping Page 4.

    Event Page 3 is checked - Self Switch B is required and off. Skipping Page 3.

    Event Page 2 is checked - Self Switch A is required and on. Trigger is Action Button. Wait to process event commands.

    Now that is more like it! The autorun event commands will run, and then stop on Page 2. Also, because Page 2 has no commands, if the action button is pressed and triggers the event, all that will happen is the pages will be checked again, and it will stop at page 2 again. No more infinite loop!

    Conclusion

    So hopefully after all of that, creating an autorun event is a little bit clearer. The overall takeaway is pretty simple:

    • Make sure your autorun has low, or ideally no conditions on its page and is one of the first pages in the event.
    • Make sure pages with a greater number of conditions are on higher numbered pages.
    • The whole event structure will get checked over again when a set of commands is complete.
    • Make sure conditional branches and command sets in general have outcomes set to help avoid loops.
    • Plan your events carefully and you should be able to avoid infinite looping autorun events!
     
    #1
    Shaz, Guiguimu and Rayhaku808 like this.
  2. Acnolowgia

    Acnolowgia Villager Member

    Messages:
    24
    Likes Received:
    1
    First Language:
    English
    This looks pretty good, but there is one slight problem- I can't quite tell from your explanation exactly what the event pages are supposed to say on them. Could you post screenshots? I thought I was following the directions, but apparently I messed something up because my project got stuck in a loop. The way you have it shown, it suggests that the screenshot of the if/else branches are for a version with everything on just one page, so I'm not sure how they're supposed to look after being split into multiple pages.

    Update: Ok, I figured it out- I was thinking, for some reason, that when you were talking about "conditions" it was specifically referring to if/else loop structures on the page, and not for the "conditions" box itself. Anyways, now that I've got that figured out, I think this is going to save me a lot of time and head-scratching.
     
    #2
  3. Trihan

    Trihan Speedy Scripter Veteran

    Messages:
    1,483
    Likes Received:
    981
    Location:
    Buckie, Scotland
    First Language:
    English
    I find it interesting that you consider the reverse-order processing of event pages counterintuitive. Imagine the alternative: if it processed them in the order of creation, you would have to have the conditions preventing a page from running on a page that comes before the page that activates them. This would be incredibly confusing to developers, I imagine.
     
    #3
  4. Andar

    Andar Veteran Veteran

    Messages:
    28,703
    Likes Received:
    6,600
    Location:
    Germany
    First Language:
    German
    Primarily Uses:
    RMMV
    I think the easiest way to remember page ordering is to think of it as
    "highest page number" = "highest priority"
     
    #4
  5. Shaz

    Shaz Veteran Veteran

    Messages:
    37,960
    Likes Received:
    11,615
    Location:
    Australia
    First Language:
    English
    Primarily Uses:
    RMMV
    I usually think of them as first page = what happens first. Next page is what happens next, after a certain condition is met. The higher the page number, the later in the game it will become active. So the conditions on each subsequent page will become true later and later as the game progresses, which means the pages will become active sequentially as the game progresses.
     
    #5
  6. Trihan

    Trihan Speedy Scripter Veteran

    Messages:
    1,483
    Likes Received:
    981
    Location:
    Buckie, Scotland
    First Language:
    English
    That's how I think of it as well.
     
    #6

Share This Page