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. 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: 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: 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!