Player: Incorrect battle behavior in Shitigadianzu

[RyutheXIIIth]

Name of the game:

Shitigadianzu (City Guardians)

Player platform:

Windows (Windows 7 64-bit), Android (Android Nougat 7)

Attach files (as a .zip archive or link them)

easyrpg_log.txt

Describe the issue in detail and how to reproduce it:

The game doesn't seem to work as intended in EasyRPG for Windows and Android, tested with the latest continuous builds. The monsters are supposed to be able to attack the player and also fill up the yellow bar while they are down, but they seem unable to. Only the octopus pet seems capable of filling it up. Also, the player should not be able to access the menu screen while they are down. It should only be accessible once the player is released.

[Ghabry]

Thanks for the bug report.

Could you provide a download link for the game?

Does the game use a the default RPG Maker 2000/2003 battle system or a custom battle system? According to the logfile it should be custom.

[RyutheXIIIth]

The game is hard to come across, and I found it on a thread in ulmf. Here's a direct link to the game:
mega.co.nz/#!boI0WSrK!16FgVnyxUwwzaIoDhMWqnU6MK9ixJ2VRtQgpv1vUYn4

And indeed, it uses a custom action-oriented battle system, similar to VH01.

[Ghabry]

the player should not be able to access the menu screen while they are down

This will be fixed as part of #1404

The other part is hard to figure out because the event code is really complicated and I have no idea which part of the code is important.

Variable 76 controls the bar but no idea how the incrementing works.

[RyutheXIIIth]

If it helps, I can narrow down the case when the bar actually fills later today, by running it in RPG_RT.

[Ghabry]

It would help if you could figure out which event is responsible for assigning to Variable 76 while the heroine is "down". I already tried yesterday for one hour to do this but wasn't able.

[RyutheXIIIth]

I'd like to help, yes, but I have little idea to go about doing that. Anywhere I can start?

Edit: I used vgperson's rewriter tool to extract all data from the game, and I've found some events that affect said variable. Unfortunately they only seem to set the value to 0, no increments of any kind yet.

Here's something interesting. I was only looking at map events while I was searching, however there are commons that directly affect the variable. Hope this doc helps.
AllCommons.txt

Here are all the map events as well in case you need it.
AllMaps.txt

[Ghabry]

I didn't knew about this dumping tool yet, useful and I see some increments of Variable 0076 there, maybe it helps me to figure it out. thanks!

Variable 77 and 405 look related.

[RyutheXIIIth]

Found the tool here if you want it:
http://vgperson.tumblr.com/post/83749711667/so-you-want-to-translate-an-rpg-maker-20002003

[Ghabry]

Variable 202: Contains the ID of the enemy that is currently pleasuring the heroine

The enemy stuff begins on event touch, assigning 202 and invokes Common Event 214 (M10 Demon 2 Direct Attack).

Then this calls on line 8 common event 50 which does the incrementing of the enjoyment progress bar at line 13. (related Switch 307: Equipment damage must be on)

[Ghabry]

Seems that Hero State (V21) never becomes >= 7 <- this is the issue, but why?

Switch 101 is on in easyrpg but not in rpg_rt

Also relevant: Switch 0315 which is "Unable to fight"

Event 21:
@> Conditional Branch: Variable [0407:VariableC] >= Variable [0061:Hero HP]
@> Control Switches: [0315:No Move] = ON
@>
: Branch End
Somehow never called

What is V0407?

To be captured (V81) becomes 10, then flow diverges (E71, L50)

[Ghabry]

The problem is something completely different: When the heroine is down touch triggers don't execute anymore because of the if (Main_Data::game_player->IsInPosition(x, y) && !Main_Data::game_player->IsBlockedByMoveRoute()) { check. When removing "IsBlockedByMoveRoute" it works. Player collision triggers still behave correct with a IsBlockedByMoveRoute check.

That the check is bogus in general can be shown by simply having a move route that hangs the Player while an event touches him -> the touch is still executed.

This was the fix for #687 but I can't reproduce this bug even after deleting the check... Was properly fixed somewhere else?

The "corner case fix" in https://github.com/EasyRPG/Player/commit/1ef2aff2546a97f084b2b93b06320aa39b962cc9#diff-4299889fa0e5668d3e562f24f1f26ce2R361 is sufficient to fix #687, therefore deleting this one check should be okay :+1: