Autorun and Parallel triggers

[Dimwit_Flathead]

Hi,
I do not understand the difference between Autorun and Parallel triggers.
I tested both and did not see any.
Could someone explain, please?
Thanks.

 

[DK]

Autorun blocks player movement.

 

[Andar]

not only movemnt but all player input.

and on entering a new map, parallels are executed before autoruns

you can also have multiple parallels but only one autorun active at any time

 

[gstv87]

autorun doesn't necessarily block player movement.
what it does, is be executed when the player enters the map window.
common events on autorun start when the condition is fired... map events on autorun start when the player enters the map.

if your autorun event ends before requiring any player input, the player won't notice the difference.

 

[caethyril]

Spoiler: technical rambling

When an event starts, it puts its commands into an "event interpreter". This interpreter converts the commands into their proper game effects, with the correct delays etc.

Autorun, Event Touch, Player Touch, and Action Button triggers all run in the main interpreter (defined on the map), so you can only have 1 of these events run at any time. If such an event is already running when it changes page or is deleted (e.g. by changing map), the event's commands will still continue to be processed because the interpreter remains intact. As mentioned, these event types also block standard player input: movement & menu access.

Parallel events run in an interpreter defined on the event itself, which causes some differences:

• They can run even when the main interpreter is busy, e.g. during fade-in from Transfer Player.
  
  
• They will stop immediately if the event changes page, or is deleted (e.g. by changing map). Common events are refreshed on map change, so they are affected by this as well.

Some event commands require shared resources, e.g. Show Text needs to use the message window. If that window is currently in use, then Show Text from another event cannot be processed until the first event is finished with it.

By default, the updates go like this (CE = common event):

• Process running events (Game_Map#update): main interpreter, parallel map events, parallel CEs.
• Then start new events (Game_Map#setupStartingEvent): reserved CE, map event, autorun CE.

Parallel events start automatically during the "process" check, if they're active and not already running. When an event is triggered, it is marked as "starting", which basically queues it for the "start new event" check.

 

[Dimwit_Flathead]

gstv87:
So, what you are saying is: when I walk down stairs to join a new map, I do not need to step on a tile to start a message such like "Welcome". I can create an autorun and, as soon as I'm entering the new map, the message will display, right?
(see ).

 

[Mac15001900]

gstv87:
So, what you are saying is: when I walk down stairs to join a new map, I do not need to step on a tile to start a message such like "Welcome". I can create an autorun and, as soon as I'm entering the new map, the message will display, right?
(see ).

That's correct, you can just make that event autorun and it will happen whenever a player enters this map.
Of course you'd probably also want to set a self switch inside this event, and have another page that requires said switch and is not set to autorun, since otherwise it will just keep going forever.

 

[ATT_Turan]

autorun doesn't necessarily block player movement...
if your autorun event ends before requiring any player input, the player won't notice the difference.

Of course it does.

Just because some usage scenarios might mean the player doesn't notice it doesn't mean it isn't a part of autorun's functionality.

That's like saying the player won't know that an event had a conditional branch with two possible outcomes so the other one doesn't exist.

 

[gstv87]

Of course it does.

it may block player movement, but not player input.
a cutscene with dialogue blocks that can be skipped can be triggered by an autorun event, and for the player to be able to skip dialogues, player *input* is required.

I can create an autorun and, as soon as I'm entering the new map, the message will display, right?

you can hook up the message to the end of the transfer instruction between maps, so it will run when the player is on the new map, still leftover from the previous event that transferred the player to the current map, while still having been triggered on the previous map.
an event (autorun, manual, or parallel) is a call to the interpreter to run whatever bunch of instruction blocks you load in it.
*THAT* is what takes priority over player input: the interpreter being active, which runs on top of the map window.
that's why when you exit a menu to go back to the map, common events are *queued* for execution upon transfer to the map window.
"transferring" actually being "redirecting your input from controlling a cursor on a window to controlling the avatar on the screen".
the avatar being on this map or another is irrelevant.... maps are always the same construct, responding to the same set of inputs and having the same effect, as are menu windows, on their own.

 

[ATT_Turan]

it may block player movement, but not player input.

Okay? But your prior post, which I quoted, said:

autorun doesn't necessarily block player movement.

(emphasis mine)

So I don't understand what you're trying to rebut here. If you were trying to correct Andar who said "not only movement but all input," you didn't actually say that

 

[gstv87]

it doesn't *block* player movement, the player can still move if you add a command for it.
what it does is halt the passing of the instruction from the input to the player object, by loading instructions to another block that has priority.
it only "blocks" player movement if it gets stuck on a loop.
that's why "parallel" events are "parallel": every time the control is released *TO* the interpreter to load another instruction, the interpreter loads whatever input was triggered by the player and then loads the next block.
nothing is ever "parallel"... everything is linear.
the only difference is, one keeps loading instructions to the interpreter without minding other processes.

 

[ATT_Turan]

it doesn't *block* player movement, the player can still move if you add a command for it.

Okay, man...you can be as pedantic as you like, but this thread is trying to clarify things for a user who has no understanding, starting at square one.

What you said in Post #4 would not increase any understanding for anyone in that situation.

The OP does not need a technical understanding of the event types as they relate to the interpreter, they need to know what to expect will happen when they select Autorun vs. Parallel Process.

I've said what I felt was necessary, I'm not going to get into sparring with you over this ridiculousness. If you think your expounding is helpful to a complete newbie, have at it.

 

[gstv87]

this thread is trying to clarify things for a user who has no understanding, starting at square one.

is that not what I just did?
I was explaining how it works.

that is how it works: autorun events don't consider player input, while parallel events do.
it has nothing to do with blocking movement or input.
you can still input instructions when the autorun event loads a window that waits for that input, but that's not the point of the autorun... it is to load a bunch of instructions that should run regardless of input.

 

[Andar]

is that not what I just did?
I was explaining how it works.

no - you gave a technical description that is not fully comprehensible without a very good to advanced understanding of programming. And that is something that most users of the program do not have. Do not automatically assume that everyone else here is a professional programmer.

best example is your correction of my explanation above.

if your autorun event ends before requiring any player input, the player won't notice the difference.

Your own words confirm: While the autorun is active, nothing else is happening and no player input is processed.
It doesn't matter how long or how short that time is - it still means that while the autorun is active, all player input is ignored, only after the autorun is no longer active anything else can be processed.

And you top that off with an incomplete listing of where and how autoruns can be used.
map event autoruns start when there conditions are fulfilled - that might be on entering if they have no condition, but if they have a condition that can be much later.

 

[gstv87]

nothing else is happening and no player input is processed.

and how can I select whether to enable comments or not, via an autorun event that runs on a middle-step map that I send the player to, in their way to the actual play map? 0o
that's what I do in the demo I've uploaded back in 2016! it's been up for years!
it's an autorun, with a choice window.... that's player input!