.flow - Misdetection as 2k3 game causes missing menus

[chaoskagami]

So, this may or may not affect other games besides .flow, but this is the main one.

Autodetection when running .flow chooses rpg2k3, which causes menus to be wrong - the only entry listed is quit. .flow is a 2k game. Screenies:

Wrong (as 2k3): Right (as 2k):

It's possible to play for a while without realizing it's wrong if you haven't played it on windows before, since literally everything but menus work as expected (seriously, kind of odd.)

If just for the sake of compatibility, could the version of the RPG be specified in the ini file? I see no such support for this from a quick grep, and it would involve a very simple hook as far as I can tell. Either that or the autodetection code needs fixes.

[carstene1ns]

We are aware of this issue. However, the wrong detection is not really our fault. This game's latest version(0.19) has been opened and saved in RPG Maker 2003, so it inserted a chunk into the database that is exclusive to rpg maker 2003 (ldb_id chunk, see liblcf) and we use this to detect the engine. The RPG Maker 2000's RPG_RT ignores the chunk of course and therefore works fine. Besides this, 2k3 also changes some battle system related structures, but .flow makes no use of battles, so this goes unnoticed. The version 0.18 of .flow works fine btw.

To fix this kind of issues we want to ultimately have some compatibility database that fixes common errors in known games, but this is not being worked on yet. About forcing the engine in the RPG_RT.ini, this could be added to #627.

---

Edit: I forgot to explain why the menu is gone: RPG Maker 2003 has a feature that you can disable all menu entries individually and this was not being set when .flow was edited in 2k3. 2k does not have this feature and therefore we just add all entries (code).

[chaoskagami]

So the engine code of .flow is actually screwed up in the latest version, but since the screwed up code never gets hit due to battles going unused, it isn't an issue? Interesting.

I didn't know whether you guys were aware or not. Did a quick forum search and went through the issue tracker first, decided to report anyways since I'd gone through the usual issue reporting checks.

I think adding to #627 would be useful. The type of game isn't going to change, so it's a set once and keep persistent type of thing which seems suited for the ini. This would also help the ports like the 3DS one - it's not possible to override autodetection there currently without the ability to pass args.

---

Edit: I see the code. So .flow was opened in 2k3 and the menu bitmask was left as 0. That could probably be fixed via external patching, I imagine.

[Ghabry]

Iirc you can fix it by just opening the game once in RPG Maker 2000 editor and pressing save.

Maybe we should just hardcode a check for ".flow" and switch the engine...

[chaoskagami]

Obviously I haven't commited any code here, so my opinion isn't worth much. I just don't want to see any more open source projects end up like PCSX2 or VBA-M. Reading through that code is utter hell. IMO Hardcoded compatibility hacks are bad and a slippery slope to unmaintainability.

I would pop .flow it into RM2k to fix it, but I don't own a copy of RM2K and last time I checked it worked awful in WINE. I don't mind passing args every time either; I always have a terminal open. That said, I can't pass the args on a 3DS build.

On May 5, 2016 11:34:55 AM EDT, Ghabry notifications@github.com wrote:

Iirc you can fix it by just opening the game once in RPG Maker 2000 and pressing save.

Maybe we should just hardcode a check for ".flow" and switch the engine...

---

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/EasyRPG/Player/issues/885#issuecomment-217188000

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Ghabry]

We respect your opinion and you make a valid point. Game specific hacks are awful and our code is completely free of them. Well, it contains some performance optimizations that were added because some games performed badly or did strange stuff but they apply to all games without any regressions so these aren't really hacks.

But someday we will have to support hacks because some games use assembler hacks to modify RPG_RT and at least the most common ones must be supported to not break games.

.flow is the only game we are aware of that uses the wrong engine version. Concerning hardcoding the game name I would only see this as a temporary solution until a game database with compatibility options is prepared. Then the hardcoded stuff should be removed asap.

But #627 is of course the much better way for this because it also solves the argument passing problem.

[scurest]

Since its really the RPG_RT.exe binary that determines it in the end, couldn't we use that for the detection? For example, a fairly robust method is probably to look for, say, the string BattleCharSet in the binary. If it's there, its very likely a 2003 game.

[chaoskagami]

Since EasyRPG is a replacement for RPG_RT.exe, there's no guarantee there even will be a RPG_RT.exe in the folder, honestly. I don't think that's an acceptable fix.

[fdelapena]

Unfortunately with broken games with mixed 2000/2003 content there is no reliable way to determine which interpreter are using apart of examining the bundled executable. For games without bundled RPG_RT it is not the case, obviously, just relying on database and map data.

Checking RPG_RT version (if exists) as the last bullet version check when other heuristic checks have clear contradictions is still worth in my opinion as scurest points. This way is not the most elegant and adds extra code stuff but if we don't go with a final executable check we will keep getting bad reports from end users (mostly Android gamers and unfamiliar with RPG Maker). There are also games with custom logo entries before the title scene which would need some executable check anyways (see #605 and #623).

In any case, allowing to manually force engine (as in the force region setting) from the .ini file should be in.

[chaoskagami]

I would think the ini would be the only appropriate way to get the information.

That said, a one time executable check/extraction in an nxengine-ish way is a legitimate approach, but I think requiring the executable subsequently when the goal is to replace it seems kind of silly.

I'm not working on EasyRPG, you guys are. I'll support however this gets worked around. I am a developer, so I'm just offering my two cents (for whatever it's worth.)

[Ghabry]

Maybe we could also add an additional heuristic here. By looking at the database you can see that a converted game has by default:

1 empty class no menu commands no system2 battle graphic defined no default battle commands 1 empty animation 2

[Ghabry]

Want to propose this one, also helps yume nikki: https://github.com/Ghabry/easyrpg-liblcf/commit/6602cf14e95b4208d1a6ac14c7d328485ee5d74f

and https://github.com/EasyRPG/Player/compare/master...Ghabry:encdetect

[chaoskagami]

I won't be able to test immediately here - I need to rebuild my copy on Linux. Assuming this heuristic doesn't hit any false positives, it'd be completely valid to close this at this point.

I'll close it myself after testing unless you guys would like to close it yourselves.

[carstene1ns]

No problem, this has been tested by me also now (it should have been closed by the merge of the pull request anyway). So closing this, be sure to open another issue here, if you encounter any problems.

[Ghabry]

Only time will tell if this heuristic causes problems in other games, but is unlikely because it won't trigger when the menu contains items or the 2k3 battle system is used (and creating a new game directly in 2k3 won't trigger it either). Lets wait for the corner cases >.<