Bug Touch events that just set hidden switches and then do nothing else stop mouse navigation

rpg_el

Veteran
Veteran
Joined
Sep 3, 2020
Messages
84
Reaction score
35
First Language
English
Primarily Uses
RMMZ
I really liked the RPG Maker MZ UI overhaul, but was somewhat disappointed to see that one mouse navigation bug is apparently still unfixed, which was already in MV:

To reproduce,

1. Open any RPG Maker MV or MZ project
2. Add a new event to any map, set to Priority -> "Below Characters", and Trigger -> "Player Touch", and keep it invisible/no image
3. Clear all event pages, and then add just one single instruction to the event "Contents": Control switches #<any switch you like> = ON
4. Click apply to save the event
5. Launch game, position the player on one side of the event, then click once to walk to a position past the hidden player touch event

Expected behavior: the player keeps walking until the goal is reached, even when crossing the event. However, this is not what happens: instead the hidden event toggle on player touch stops the player, and mouse navigation abruptly stops with no obvious indication to the player why. Why is this bad: This will likely make most players feel like mouse navigation is just inherently unreliable and may randomly stop at any point, which will ruin the fun of playing.

Usefulness of non-interactive player touch events: hidden floor toggles like this may not occur that much in more straightforward RPGs, but they're useful for more complex story driven experiences where e.g. stuff may later happen based on having discovered some areas previously. This can also be an issue when having player touch events that contain a conditional that only sometimes (e.g. based on randomness, or a complex combination of conditionals) triggers a dialog, and otherwise does nothing. I use both variants a lot, so it would be very cool if this could be patched. Is there any chance it will be fixed in MZ now, given it wasn't ever fixed for MV?

Suggestion of how it should behave: MZ should store the mouse navigation target as soon as a player touch event starts. If a player touch event 1. doesn't take control away from the player for 1+ frames (=no wait), and 2. doesn't do any other visible cutscene action (=no dialog items or balloon icons, no event or player movements, no battle scene start), and 3. returns control right away after just conditionals, loops, variables, and switches, then MZ should restore the mouse navigation target afterwards. As a result, the player would resume walking as if nothing happened. Basically, I would suggest to add an event interpreter instruction whitelist, and as long as a player touch event only uses instructions of that whitelist the movement will resume.
 
Last edited:

rpg_el

Veteran
Veteran
Joined
Sep 3, 2020
Messages
84
Reaction score
35
First Language
English
Primarily Uses
RMMZ
Is there a GitHub for MZ corescript yet? If there is ever going to be, I would be interested in trying to provide the official fix myself. I think one good way to address this while making it work for plugins that might introduce unknown blocking actions might be:

<removed, since SmoothTouchMove.js already exists, and it is way simpler than my convoluted proposal>
 
Last edited:

Ghost of Christmas Kloe

The Icecream Princess
Veteran
Joined
Nov 15, 2015
Messages
1,548
Reaction score
958
First Language
English
Primarily Uses
RMMZ
I think the SmoothTouchMove.js plugin included with MZ fixes this bug, at least according to the description.
 

rpg_el

Veteran
Veteran
Joined
Sep 3, 2020
Messages
84
Reaction score
35
First Language
English
Primarily Uses
RMMZ
Interesting, I just tested it and apparently it does. I guess it works somehow by clearing the target only if there was a blocked frame of not moving? I can't fully decipher the code just yet...

Is there a reason this isn't integrated into the corescript itself? Seems like as a plugin form, most game devs are bound to be unaware and not include it, which will probably lead to this slightly frustrating issue remaining in most games.
 
Last edited:

Ghost of Christmas Kloe

The Icecream Princess
Veteran
Joined
Nov 15, 2015
Messages
1,548
Reaction score
958
First Language
English
Primarily Uses
RMMZ
Is there a reason this isn't integrated into the corescript itself? Seems like as a plugin form, most game devs are bound to be unaware and not include it, which will probably lead to this slightly frustrating issue remaining in most games.
I assume because, in a sense, it's intended behaviour. When the event occurs, the game runs that code and in doing so stops the current movement of the player, just like any other event would and therefore it's consistent with how most (non parallel) events work.
The reason it stands out as weird here is that the eventing of just flipping a switch isn't something that you'd expect to halt the player, since it doesn't take long or require extra input - but it's still following the concept of code runs => player stops movement.
This change makes eventing less predictable while making gameplay smoother in this one control style which isn't used by a large portion of players, so it doesn't make a lot of sense to have this as default behaviour (adding unpredictability into eventing to make this one edge case smoother) but by providing it as a launch plugin (that MZ users have by default) it makes it so the developer can implement this intentionally if they want to, which I think is a more elegant approach.

I do wish it was maybe documented better somewhere, since most people don't know about the issue or that this is a solution, but I think it works for now.
 

rpg_el

Veteran
Veteran
Joined
Sep 3, 2020
Messages
84
Reaction score
35
First Language
English
Primarily Uses
RMMZ
Interesting!
Why that bothers me is that I would argue for developers that never think about this edge case (which is likely the majority) the behavior with the plugin on is a way better default than the other way around. Exploiting this to intentionally stop the player movement seems like a really arcane use case to me which has never occurred to me: and I think anyone who would come up with that unusual idea would have the presence of mind to at least try it out, see it doesn't work with an empty autorun event, and then try a wait 2-3 blocking frames next which still works with the plugin anyway. Like, the only legit reason I can think of to not change this is not breaking legacy projects that somehow use this, but MZ is a new release right now.

Therefore, IMHO it would make way more sense to offer a plugin to disable the "smooth" behavior. It's like, protecting a quirk that has almost no use while in the end having the very real impact of players usually ending up with sometimes weirdly misbehaving mouse input. Shouldn't the default be the behavior that works best for both unaware devs and players for a good experience? I think it should be. In any case, thanks a lot for explaining it, very appreciated!

I wonder if there is a way to poke the devs about this?
 
Last edited:

GBJackson

Veteran
Veteran
Joined
Dec 11, 2016
Messages
90
Reaction score
105
First Language
English
Primarily Uses
RMMV
There is a way to bypass this issue without using a plug-in.

Set up a parallel event like so:

◆Get Location Info:Region ID, Region ID, Player
◆If:Region ID = 1
◆Control Switches:#0002 test = ON

:End

Use a region ID on the tile you want to turn the switches on. Being able to get the region ID directly eliminates the need to first get the map coordinates and then check the ID at those coordinates.

It may be worth considering that there is not a bug or bad design involved here, but rater a reasonable expectation of us simply knowing when to use region IDs to control things rather than a triggered event.
 

rpg_el

Veteran
Veteran
Joined
Sep 3, 2020
Messages
84
Reaction score
35
First Language
English
Primarily Uses
RMMZ
This workaround doesn't work at all anymore if you have more complex conditions: you would have to trigger a common event that runs parallel with that switch to evaluate them, but now you waste a region and a parallel event for any map spot with a complex condition which does not scale - in general you'll get a giant unmaintainable mess for any game with many map local complex trigger scripts for nice non-trivial interactions. It is very hard already as-it-is to maintain such a high interactions game in RPG Maker because there are no map-local switches and map-local common events when needed for other reasons, which would help a lot to keep things from not growing super messy, but oh well.

So I maintain that for complex projects it would be way better if this workaround plugin being on was the default behavior, since intentionally stopping the player isn't hard, just put wait 1 in a player touch event, or if you really considered that too much work to use the plugin to turn it off (rather than the other way around as it is now). And working around this behavior without the plugin however becomes a giant unmaintainable pain really quick.
 
Last edited:

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Profile Posts

Having problems with enemy/monster designs. :kaosigh:
While we prepare the official trailer, enjoy this kind-of-second teaser! ^^
-Ele
New Episodes of RPG Shenanigans Uploaded to Youtube!

Episode 5 - Surprise Party!
Youtube Link:
Episode 6 - Killer Gin
Youtube Link:
Episode 7 - Gaia's Melody: Echoed Melodies
(Coming soon!)

Episode 8 - Clarent Saga: Tactics
(Coming soon!)

Episode 9 - Star Shift
(Coming soon!)
When the Map Generator throws in the assets in the most dumbest way possible - your path is blocked :D

I went to sleep at 3 am because of my anxiety. Set up my alarm for 7 am so that I could have sasagues for breakfast and do morning routine before lessons starts at 8 am. I knew I wouldn't be able to sleep even after my lessons finished because I have to visit my grandparents today I was sad bc I was really tired. Thats when I realised. My lesson starts at 9 am. I could get one extra hour of sleep if I didnt forget it

Forum statistics

Threads
107,565
Messages
1,030,604
Members
139,671
Latest member
WDRS
Top