Important or counter-intuitive eventing points.

[Zeriab]

Hey all!
I made a list of what I considered important points in event or points which could take a long time to discover on your own. (If you discover it at all)
I sent it to our very own global mod Wyatt and here is his response I got from him in the chat:

Wyatt[/url]":a9lswuox]* wyatt reads
* wyatt didnt know a lot of that stuff and it explains why his games never work :x

I know that I would personally have loved such a list when I started.

Feel free to add any points you believe are important. I have surely missed a couple.

• Set Move Route overrides previous move route for the player or given event
• Set Move Route and Player Touch
• Wait for Move's Completion issue
• New Event Tab cancels Move Route
• Reluctance of events moving onto other events
• Tileset events and Through
• Parallel/Autorun events loops
• Common events on parallel trigger restart on map change
• Force action does not work on turn 0 in battles
• Defending actor + force action
• Self-switches in common events
• 'This event' in common events

Set Move Route overrides previous move route for the player or given event
I have seen a lot of support questions regarding which is due to this.
A typical cause are evented dash systems. You have to set a move route to change the speed of the player.
You can for example set a move route for the player to do something in a cutscene. The dash system then sets a new move route for the player and the player stops after one step or so.
The same holds for any events. Note that each event has their own move route (or none).
Note that events and the player don't have to have a move route. This is important for the following issue:

Set Move Route and Player Touch
If you have a passable event on Player Touch trigger, the event will NOT trigger if the player walks over the tile using a Set Move Route. If the player stops on the tile the event will trigger, but it will not trigger if the player continues.
You can fix this by setting the event trigger to Event Touch.

Wait for Move's Completion issue
Its wait until the player and no event have a move route. If you set a move route for an event which is on repeat action, then it never ends.
This can cause the game to practically freeze. As a general rule don't use Wait for Move's Completion. It can lead to hard-to-spot freezes which in the worst case can appear to happen randomly.

New Event Tab cancels Move Route
Let's say you have an event with two tabs, each with the same character. The condition on the second tab is not true (so the first tab is 'active').
You have another event that executes a "Set Move Route" on this character event. The character starts moving across the screen.
If the condition on the second tab becomes true while the character is in the middle of the move route, the move route will be cancelled and he will stop walking.

Reluctance of events moving onto other events
An event will not move onto a tile occupied by another event unless either of them has Through ON. (Or both)
The same holds for the player. The player basically treated as an event when other events move around.

Tileset events and Through
The passability settings are ignored for events which has Through ON. The same holds for the player.
Tileset events are interesting in this regard because they can turn impassable tiles to passable tiles.
Let's say you have a tileset event which turn an impassable tile into being passable. If we set Through ON for the event then its passability settings will be ignored. Yes, the passable tile will now not be passable anymore.
It is something to keep in mind. Especially for bridges that will be built some time into the game.
If you events to be able to cross the bridge without having Through ON then you must make the tiles underneath passable and use blocking events for when the bridge is out. Let the pages displaying the bridges have Through ON.

Parallel/Autorun events loops
When a parallel or autorun event has finished processing it will be processed again (next frame in case of parallel events).
Typical issues happens when you use event commands which takes several frames to complete.
For example showing an animation or moving an event or the player with a parallel event. Only the first few frames are shown over and over with the show animation and only the first move command is considered.
The solution simple to change the condition so that it doesn't loop after it has finished processing the event, which can be done by erasing the event or changing the page. Or in terms of common events, turning off the triggering switch.
In this aspect the Exit Event Processing command may lead to confusion since it ends the processing of the event. You may therefore get unwanted loops. Just change the conditions before the exit event processing command.

Common events on parallel trigger restart on map change
A typical case where this is a problem is if you want to have an invisible time running across maps.
If you have a Wait 999 frames event command, then it'll start over each time you transfer to a new map. (A solution for this is to wait say 4 frames, add to a variable and Exit Event processing if the variable is not over some value (conditional branch))

Force action does not work on turn 0 in battles
You can for example not have an item which causes on of the actor to attack immediately, nor can you have the monsters attack immediately. (I.e. before you can run away)
You can mimick it with animations and deal damage, but it's very tedious.

Defending actor + force action
This may not be an issue, but it's worth noting.
Let's say you set Actor 2 to defend and have a force action which causes Actor 2 to attack in Normal sequence. (Let's say the force action is in a common event triggered by the skill of Actor 3)
If Actor 2 acts before Actor 3 then Actor 2 will not attack when Actor 3 acts, but Actor 2 will not defend anymore. This means more damage for monsters attacking Actor 2 after Actor 3 has acted.

Self-switches in common events
I have wrote a tutorial about this matter ~ viewtopic.php?f=48&t=60373

'This event' in common events
It refers to the map event calling that common event (either directly or indirectly)
If there's not a map event calling that common event then the event command has no effect.


Special Thanks
Animus
Kipe
Regi
Shaz

*hugs*
- Zeriab

 

[regi]

These are useful tips, Zeriab. I remember when I first encountered the "Common Event on Parallel trigger" when working on a background screen flashes and SE's for a fire dungeon, it was driving me crazy :P

I'd like to add one that probably many already know, but would be useful for those that don't:

Through
The "Through" feature works differently between events and the player. When you set the player to "Through", he will automatically walk through any tile. This is not the case for events, however.

Events on "Through" will take the passibility of the tile or event on the highest priority or layer directly underneath. So if you have a bridge event over impassable water, and you set it to "Through", it will not turn passable, but have the opposite effect, because the water underneath is impassable.

 

[Zeriab]

I can imagine that Regi XD
I bet you noticed that I based the event trivia on them ^^

Actually, the Through feature works the same between events and the player. Their passability is ignored.
The potentially confusing part comes in when you are dealing with tileset events. They can make otherwise impassable tiles passable. If such an event is set to Through then it's passability settings will be ignored and thus the tile will be impassable.
I think the biggest chance of confusion is when it is mixed with the reluctance of events to step onto other events.
And event will not step into the same field as another event unless at least one of them is Through.

Think about it. You have a chasm which you later built a bridge on. You want both the player and events to cross it. How do you do it?
If you don't set the event to 'Through' other events won't be able to cross. If you set it to 'Through' it's passability settings will be ignored.
The key here is to use invisible 'block' tiles. I.e. have purely invisible tile which is impassable. Put on the third layer tiles which are passable. (possible invisible)
Then use tileset events which use the invisible 'block' tile as graphic while there are no bridge and put it on through for when the bridge is up.

Anyway thanks a lot for the reply.
You gave one and made me think of another :3

*hugs*
- Zeriab

 

[Zeriab]

I have updated the list ^^

 

[Brewmeister]

*Brew reads
*Brew learns some shit too :scruff:

 

[Zeriab]

*Brew reads
*Brew learns some shit too :scruff:

The mighty brew actually learn something :3 (Is it a stout?)
Do you have any new points to share?

On a side note: Do you guys think I should post this list in the general support area as well? (RMXP)

 

[Brewmeister]

"Mighty!" (I like that :smile

Indeed, a hearty Oatmeal Stout! Good stuff.

Advice/Common mistake: When choreographing a cutscene, put all of the controls in a single event. Many new 'eventers' try to synchronize commands in each individual event (I even did this once. not fun.)

I'm thinkin' this forum should be moved up to the support area. (sub-forum of General Support?)
It's hidden down here & doesn't get much attention. I've seen several topics "up there" that would
fit better in here.

 

[Zeriab]

^_^
Your advice is that, an advice about general eventing design.
I don't think it really belongs on the list, but also having general eventing tips and advices is a good idea. I like that.
I'm not really sure how to structure it. Give me some time to think about it.

*hugs*

 

[Brewmeister]

I was trying to think of stuff that snagged me...

Common Event commands not executing until battle ends.
Separating long statments with "\" in the Script Command Dialog
F2 to preview text messages
Pages get evaluated from Right to Left (seems to baffle the newbs)

 

[dearjym]

I have to admit, the passability issue has been (despite its otherwise seemingly simplistic concept) a challenging one for me. Depending on the specific situation, I find that passability requires a variety of solutions. The steps here just seem to be missing some little fact that could make it crystal clear...even though it's just my brain shutting down.

For example, I thought setting the event's THROUGH to ON "WAS" making it passable

but Zeriab describes:

"Let's say you have a tileset event which turn an impassable tile into being passable."

How is this done? I guess I always thought it was done by the THROUGH option...but Zeriab goes on to explain the following...

"If we set Through ON for the event then its passability settings will be ignored. Yes, the passable tile will now not be passable anymore."

Again the mention of "passability settings", and I'm understanding this to be coming from the event, but not from the THROUGH ON option. From this statement, it's two different processes, two different steps. First you set the passablitly options, then IF you set the THROUGH to ON, it nullifies the passability options that were set.

Just to confirm, I know to use the Priority, 4 Dir, and Passage to set the initial state of each tile, and that higher layer level means passability seniority. I used to make blank screens and ADD the same autotile 3 times to the tileset- making one 'X', one 'O', and one a square & then makes different designs with the autotiles and learn that way, by gradually adjusting the priorities and etc...noting the effects of each.

What I'm having trouble with is the

A. "changing an impassable tile to passable", and the

B. "setting the THROUGH option to ON
(essentially nullifying the event's passability command, leaving it impassable as it originally was)

That's what I am trying to get my head around. Basically, I fully understand B. (and all its implications) IF, and only IF, there is something I'm missing from A. I've been in and out of the event menus, read tutorial's, watched videos, studied DEMO's, 100's of trial & errors- but aside from the THROUGH option, how do you manipulate passability setting in an event?

I've had very little luck with the invisible tile placed in the third level- I know I'm doing it wrong- just unsure how.

Now, I've had success- as I mentioned earlier, the other 'tools' of the trade have helped me solve passability issues in the past, but they leave me feeling like I cheated, because I didn't force myself to fully understand WHY I didn't learn it the proper way.

I've use the following with success:

1. If there is only one level containing a tile in the place that I want to change passability, then there is no problem. This is easy. I usually just delete all 3 layers of this tile (basically just the one layer containing a tile), and just use the desired tile graphic in an event with THROUGH ON. This works fine. (The problem comes when there are more than one layers containing a tile, and so deleting all the levels isn't an option.

2. I use a tileset swapping script. I import the same tileset as the one im already using, and I change the particular tile to the passability desired, and just have an event control the tileset swap between the two identical tilesets.

3. I edit the tileset I want to use by making an copying and pasting the tile I was to use, so that it exists on my tileset twice, each set to a different passability, and in this one square, I use the copied tile. Use events to turn THROUGH ON or OFF as desired.


But these are all pains, and they are limiting, either by its application, or the time spent preparing it. And another thing causing confusion is that I get, for the most part, what you are saying about the bridge- but what about other applications that aren't necessarily horizontal? Like climbing a wall or entering a secret door/room- or just any unpredictable application of manipulating the passability of a tile.

I read what I can by you Zeriab, and you always make sense. I've come a long way with RMXP from posts like yours. I also appreciate HOW you say things. So thats why, when I read this, I finally broke down to ask for a little more help understanding. Because I never post.

The way you explained it here, I was finally able to point out what part is bugging me. If you could even point me toward an explanation I'd be grateful (I've search, searched, searched the web over) I find tons of forum topics on the web that is the same rehashed stuff. But this is the closest I've come to understanding...in fact, writing this out has helped me understand your explanation a little more- despite the part that seems missing in my brain.

On a side note:

Is there a script that FORCES a particular tile to be passable- regardless of other factors that lead to the THROUGH option to be negated?

Is there a set of event procedures that could do it?

No doubt that if I fully understood this concept, drastic measures like these wouldn't be needed- but I'm not just asking so I can have the easy fix. I want to understand, and that includes knowing the true limitations of scripting and eventing.

I think the last time I was this hung up was grasping the concept of pointers in C++. Which is embarrassing, considering pointers were actually difficult for everyone in the class, at first. This here just seems like a concept that's eluding me, not the whole class.

 

[Kipe]

This is a response to the post above.

Index of Event Passage

I) Event vs Player

i To the player, events with the graphic set to (None), or default, are automatically defined as passable, meaning: The player may always pass over this event, but only, if and only if; the tiles on all three layers below it, are set to passable (as defined with an O in the Tilesets tab in the Database).

ii Events with graphics, excluding those with (Tileset) graphics, will automatically be defined as impassible to the player.

iii Events which use (Tileset) graphics will retain their passage (as defined with an X or O in the Tilesets tab in the Database), as long as the Through check box remains unchecked.

iv Upon clicking the Through check box, after defining the (Tileset) graphic of an event, the event will then ignore the passage that it was initially set to (via the Database), and instead, become passable. This is, of course, as long as all three layers in that specific tile location are also passable.

v It is recommended to note, that, when erasing tiles, you should always use the upper left empty square. This is because it is the only tile that is specifically designed to erase other tiles. Other 'empty square' tiles (as defined in the Database) are either passable(O) or impassible(X). Using any other 'empty square' tile, to erase other tiles, may cause issues during Playtest.

vi To create an empty event in which the player is unable to pass, it is recommended that you define an 'empty square' tile (in the Database) as impassible(X), then use that tile when setting the graphic of the event.

II) Event vs Event
For this section, an NPC event is defined as one which moves, or has a move route.

i NPC events will automatically recognize other events (which do not use (Tileset) graphics) as impassible objects. This means, that, unlike Event vs Player; events with the graphic set to (None), or default, are automatically defined as impassable, meaning: The NPC event may not pass over this event, even if the tiles below it are set to passable.

ii Non-(Tileset)-graphic events with the Through check box checked, do not retain a passage layer height priority. In other words; an impassible object such as a tree stump placed on any layer, 1-3, underneath the event set to Through, will disallow an NPC event from passing over it.

iii An alternate way of changing the passage of an event, would be to utilize the Set Move Route command. Inside you will find two options: Through ON, and Through OFF

There's more, I'm sure, but that just means that I would have to use more of my brain! So please feel free to add to the list.

 

[Zeriab]

I am so sorry I first discovered this now.
Thanks a lot Kipe for answering :3

You got some good points Brewie. I will consider writing about them ^_^

Kipe explained how the event vs. player interaction works, which can pretty much be summed up in:

• Empty events and events with THROUGH ON does not affect the passability of the tile in any way for the player (i.e. it's the three layers which count)
• Tileset events affects the passability of the tile as if it was a fourth layer. You can have some directions being passable and others not.
• Other events all render the tile impassable for the player

Unfortunately Kipe got the Event vs. Event part wrong. From an event's point of view the other event is:

• Impassable if the event has TROUGH OFF
• Ignored if the event has THROUGH ON (I.e. it's the passability of the three layers which count)

You can force a particular tile to be passable for the player with an event. You cannot do it for event vs. event without scripting. (Other than making sure the tiles below are passable.)
If you want the tile to initially be impassable and later passable then there is something you can do. You can make the three layers passable and then create an impassable event. Make a new page which has some precondition and check the Through option. This way you can first block both the player and events moving around and afterward let them all move through that file.

I have never heard of a script which forces a particular tile to be passable.
Here's a quick work on a script which does exactly that:
[rgss]class Game_Map
  PASSABLE_TILES = {#[MAP ID, X, Y] => true,
                    [1, 6, 0] => true,
                    [1, 10, 11] => true}
 
  unless method_defined?("zeriab_always_passable_tiles")
    alias_method :zeriab_always_passable_tiles, :passable?
  end
  def passable?(x, y, *args)
    return true if PASSABLE_TILES[[map_id, x, y]]
    zeriab_always_passable_tiles(x, y, *args)
  end
end
 
class Game_Character
  unless method_defined?("zeriab_always_passable_tiles")
    alias_method :zeriab_always_passable_tiles, :passable?
  end
  def passable?(x, y, d)
    # Get new coordinates
    new_x = x + (d == 6 ? 1 : d == 4 ? -1 : 0)
    new_y = y + (d == 2 ? 1 : d == 8 ? -1 : 0)
    if Game_Map::PASSABLE_TILES[[$game_map.map_id, new_x, new_y]]
      # If coordinates are outside of map
      unless $game_map.valid?(new_x, new_y)
        # impassable
        return false
      end
      # If unable to leave first move tile in designated direction
      unless $game_map.passable?(x, y, d, self)
        # impassable
        return false
      end
      # The other tile is passable.
      return true
    else
      zeriab_always_passable_tiles(x, y, d)
    end
  end
end
[/rgss]

You should be aware that by forcing a tile to always be passable you allow NPCs to run on top of each-other and on top of the player.

*hugs*

 

[SPN]

Sorry for the huge necropost, but this information is helpful, and reading through it brought up a question.

I'm sure a lot of people have done things like this, but I'd like most of my random NPC's to have a certain area of the map in which they walk around aimlessly in. What I'm saying is, if there's someone in the Northeast corner of a large map, I wouldn't want him eventually ending up in the opposite corner, but rather have him stay in the general area.

I know this is possible with a number of Conditional Branches, and a fleshed out "Random" move route but the blank event tiles got me thinking.

If I understand this correctly, if you put a blank event on a map, other events consider it an impassible tile even though the player can walk through it, meaning events won't walk onto those tiles. So instead of setting up custom "Random" move routes with movement direction branches based on X and Y coordinates, could one just surround the general area with blank events, and leave the NPC on Random? I'm thinking this would save quite a bit of time, although it would leave more event clutter on the map.

 

[regi]

That's definitely a solution. You can also use blank events to stop other events from places such as stairs, doorways, etc.

 

[Ellie]

In the event that you do need events to walk through it I believe they should walk through tiles set as "Through" - something I didn't realise for a while that was bugging me.

 

[Zeriab]

SPN = Supreme Pie Ninja?
If so, I am happy to see you again :cute:

As implied in regi's post you can design the maps so there are natural access points you can cut off.
You can also completely surround an area with blank events, but as you can guess this will slow it down, particular if you don't have an anti event lag script.
Such a script could actually prevent sprites from such event for being created.
You have just given me an idea to optimizing my antilag script :cute:

To get a better feel with how this stuff works I suggest you try to make a bridge which is initially out and which later is built.
No events must be able to cross it while it is out, but they must be able to cross it once it has been built.
I have given the answer, but it is still something I suggest to try out.

*hugs*
- Zeriab