The Happy Fun Game: Boss does not move (not bug compatible)

[Ghabry]

Name of the game: The Happy Fun Game

Download in the forum post: https://community.easyrpg.org/t/image-animation-error-in-the-happy-fun-game/1594

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

Savegame also in the forum post.

Describe the issue in detail and how to reproduce it:

Move to the right after loading the save. During the boss fight the boss will be stuck instead of moving.

Thats because we detect engine 2k3 1.0.3 and consider this version to have a bug (see #1741) which disabled coordinate changes in move events.

Turns out this bug was already fixed earlier than what we believed (1.0.5). It is already fixed in 1.0.3. Though is a bit more confusing, there are at least 3 different 1.0.3 versions: https://www.makerpendium.de/index.php/RPG_RT.exe

In a Japanese RPG_RT 1.0.3 which is 1.0.3.0_1.0.3.0_1 the bug persists (though the picture movement is actually broken in a different way than we emulate, so 2k3 has a different bug compared to 2k here 😓 ).

In the bundled RPG_RT 1.0.3 which is 1.0.3.0_1.0.4.0 the bug is fixed and the boss moves correctly.

We consider this fixed later (in 1.0.5), so the boss is broken.

[florianessl]

Oh good, we already have an issue for this one. I thought I'd need to create another for one for this game .:D

Game: Die Reise ins All
Savegame: Save08.zip

(This game is not RM2K3 though - this is Don Miguel's RM2K version 1.07b)

Continuing into heavy spoiler territory, right after the final boss fight (#3415) a monument to our fallen hero is revelead.

RPG_RT

But in EasyRPG, the crane hook seems to miss its target & the curtain remains in place...

EasyRPG

[florianessl]

Here's some suggestion for improving the engine detection, so that we could narrow down specific RPG_RT build versions more reliably.
The Borland Delphi compiler is broken when it comes to metadata. The PE field for the compilation date always points to some specific date in 1992, but it looks like the resources section for many Delphi builds (including RPG_RT) has the actual compilation date stored.

std::time_t EXEReader::DosTimeToUnixTimestamp(uint32_t dostime) {
	std::tm tm{};

	tm.tm_year = ((dostime >> 25) & 0x7F) + 80;
	tm.tm_mon = ((dostime >> 21) & 0x0F) - 1;
	tm.tm_mday = (dostime >> 16) & 0x1F;
	tm.tm_hour = (dostime >> 11) & 0x1F;
	tm.tm_min = (dostime >> 5) & 0x3F;
	tm.tm_sec = (dostime << 1) & 0x3E;
	tm.tm_isdst = 0;

	return std::mktime(&tm);
}

// After reading the section data:

if (resource_ofs != 0) {
	file_info.compilation_ts = DosTimeToUnixTimestamp(GetU32(resource_ofs + 0x04));
}

I tested around a bit with different EXEs, & it seems to even work with UPX-packed executables. I also got reliable results for executables that were modified with Resource Hacker, so it looks like this date is not overridden by third-party modifications. (But more thorough testing is needed to verify that..)

The extracted Dostimes seem to closely match the build dates documented in Makerpendium, with them being commonly offset 1-4 days for the RM2K builds I tested.
(The build timestamps mentioned in Makerpendium are likely based on the original file modification dates of the shipped products & patches)
https://www.makerpendium.de/index.php?title=RPG_RT.exe

[Ghabry]

great finding! Also more useful than the CODE section size imo for log-output.