emoose
commented
1 year ago Alright, got Em09 spawning & receiving damage fine as its own separate Em09 now (rather than replacing any existing Em class), and was even able to pattern-match for most of it too - unfortunately not sure if prologEm09 is able to be pattern searched though, seeing as nothing calls it and it normally went unused, and the func itself matches almost every other prologEmXX function too...
Was thinking of working back from the cEm09 class and find the func that inits that, then from there find the prolog func that calls that, but since the j_ thunk functions between those calls use relative jumps I'm not so sure that can actually be searched very easily... might just have to include a table of the prologEm09 addrs for each game version, but any ideas about that would be welcomed.
(E: ah, looks like prologEm09 is actually the first prologEmXX func in the EXE, so it's not too hard to find actually, updated the code below to search it - seems to work fine on 1.1.0, need to check other versions.)
Here's what I got so far, added to ModExpansion.cpp atm:
struct OSLinkData_mb
{
uint32_t rel_filetbl_no_0;
void(__cdecl* prolog_4)();
void(__cdecl* epilog_8)();
void(__cdecl* unresolved_C)();
};
#define OSLINKDATA_ORIG_COUNT 75
OSLinkData_mb g_OSLinkData_Em_Extended[OSLINKDATA_ORIG_COUNT + 1];
BOOL(__fastcall* cEmMgr__construct)(cEmMgr* thisptr, void* unused, cEm* pEm, uint32_t id);
BOOL __fastcall cEmMgr__construct_Hook(cEmMgr* thisptr, void* unused, cEm* pEm, uint32_t id)
{
BOOL ret = cEmMgr__construct(thisptr, unused, pEm, id);
// Make Em09 pretend to be Em39 instead, see "Em09 fixing" comments below for why
if (pEm->id_100 == 9)
pEm->id_100 = 0x39;
return ret;
}
void re4t::init::ModExpansion()
{
[...]
// Em09 enabling: code & data exists for the Em09 / Tyrant enemy from REmake, code seems to be setup to call into the proper RE4-engine functions fine(!)
// Unfortunately what doesn't exist is any link for the actual Em id 09 to call into the Em09 code that's available for it
// Main things missing for it to work:
// - EmFileTbl defines the link between the ID & the Rel/Dat file number to use (number from there then gets looked up in the FileTbl array)
// Em06 - Em0c are setup with the Rel/Dat IDs for Em10, for whatever reason, maybe as placeholders
// Would need to change the EmFileTbl[9].Rel/.Dat to point to Em09 entries inside FileTbl, but unfortunately...
//
// - FileTbl doesn't contain any entry for the Em09 Rel/Dat
// Not a huge deal though, since luckily it does include unused Em06 Rel/Dat entries, which can be easily overwritten
//
// - Func that associates DAS files with imagepacks needs updating, would normally set em06.das to use imagepack 6, can just set it to imagepack 9
//
// - g_OSLinkData_Em array links Rel IDs up to the actual prolog/epilog/"unresolved" functions
// (those are normally loaded/ran from the Rel itself, but UHD merged all the Rel files into the main EXE, so this is how those merged-in functions get mapped)
// Sadly there's no Em09 mapping defined there though, and even worse all the mappings that are defined seem to all be for things that are actually used
// (with no spare room at the end of it neither, there is one blanked out entry, but seems to be used by the code to signal the end of the array, so can't be overwritten)
// Would need to make a copy of the existing array into our own array that has extra space for the new entry
//
// ... and hopefully that's it! Then can just edit ESL to use Em id 09 and hopefully it should spawn in fine
// First let's find the FileTbl:
struct FileTblEntry
{
const char* path;
int dvdEntryNum;
};
pattern = hook::pattern("0F B7 D0 8B 04 D5 ? ? ? ?");
FileTblEntry* FileTbl = (FileTblEntry*)(*pattern.count(1).get(0).get<uint8_t*>(6) - 4);
// Patch path inside entries for em06.das/em06.rel to use em09.das/em09.rel instead
auto& entryDas = FileTbl[0x1C];
auto& entryRel = FileTbl[0x1D];
Patch(entryDas.path + 6, '9');
Patch(entryRel.path + 7, '9');
// Locate EmFileTbl and patch the Em09 entry to point to the FileTbl entries above
// TODO: seems each playable char has it's own EmFileTbl for whatever reason, would need to patch those too...
struct EMD_READ_SET
{
uint16_t Dat;
uint16_t Rel;
uint16_t LowDat;
uint16_t Dll;
};
pattern = hook::pattern("8D 04 CD ? ? ? ? 89 85 ? ? ? ? 8B 8D ? ? ? ?");
EMD_READ_SET* EmFileTbl = *pattern.count(1).get(0).get<EMD_READ_SET*>(3);
EmFileTbl[9].Dat = 0x1C;
EmFileTbl[9].Rel = 0x1D;
// Patch func that sets up FileTbl <-> ImagePack mappings, change em06.das = 6 to em09.das = 9
pattern = hook::pattern("01 C7 05 ? ? ? ? 06 00 00 00 C7 05");
Patch(pattern.count(1).get(0).get<uint32_t>(7), uint32_t(9));
// Patch OSLinkData pointer to point to our own array & copy data for it over
pattern = hook::pattern("8B 45 10 8B 4D 14 C7 45 F0 ? ? ? ?");
OSLinkData_mb** g_OSLinkData_Em_ptr = pattern.count(1).get(0).get<OSLinkData_mb*>(9);
// Copy orig data to our extended array
std::copy_n(*g_OSLinkData_Em_ptr, OSLINKDATA_ORIG_COUNT, g_OSLinkData_Em_Extended);
// Locate the unused prologEm09 func, easier said than done since nothing ever calls it, and almost all prologEmXX funcs share the same instructions...
// Fortunately prologEm09 appears to always be the first instance of a prologEmXX func, so we can just search for the prologEmXX pattern and use first result
pattern = hook::pattern("C7 05 ? ? ? ? ? ? ? ? C3");
void* prologEm09 = pattern.count(1).get(0).get<uint8_t>(0);
// Set up the g_OSLinkData entry for Em09
g_OSLinkData_Em_Extended[74].rel_filetbl_no_0 = 0x1D;
g_OSLinkData_Em_Extended[74].prolog_4 = (void(*)())prologEm09;
g_OSLinkData_Em_Extended[74].epilog_8 = g_OSLinkData_Em_Extended[0].epilog_8; // nullsub from [0]
g_OSLinkData_Em_Extended[74].unresolved_C = g_OSLinkData_Em_Extended[0].epilog_8; // nullsub from [0]
// End-of-records indicator
g_OSLinkData_Em_Extended[75] = { 0 };
// Patch game to use the extended array
Patch(g_OSLinkData_Em_ptr, &g_OSLinkData_Em_Extended);
// Em09 fixing: of course enabling & spawning it is only the first step, there's also some issues with the Em itself that need to be fixed.
// The above lets it spawn in fine, but none of the targeting/hit detection code actually responds to it
// Seems the detection code checks what Em ID it is and only allows certain IDs to be hit, with ID 9 left out of all those checks...
// Rather than trying to find & update each of them, we can overwrite the instances cEm::id_100 field to an Em which is known to work
// (fooling those checks into thinking it's a different Em, while it still runs the Em09 code)
//
// The question is which Em should it masquerade as - some rooms do perform searches for certain Ems and then call functions on them
// eg. r205 searches for Em2d and tries calling a vtable func on it, which Em09 wouldn't contain, causing a crash...
// Em10 also seems to crash for some reason, but Em39 appears to work fine, so we'll go with that for now, until someone eventually finds a room that breaks it...
// Unfortunately easiest way to handle this is hooking cEmMgr::construct, which is only referenced in the cEmMgr vftable, ugh
// Need to find offset for the vftable and grab addr for construct from it
// Kinda ugly method which grabs the vftable from the static EmMgr instance
pattern = hook::pattern("? ? ? ? 00 00 00 00 00 00 00 00 08 0E 00 00 02");
uint32_t* cEmMgr_vftable = *pattern.count(1).get(0).get<uint32_t*>(0);
uint32_t cEmMgr_construct_thunk = cEmMgr_vftable[6];
ReadCall(cEmMgr_construct_thunk, cEmMgr__construct);
InjectHook(cEmMgr_construct_thunk, cEmMgr__construct_Hook, PATCH_JUMP);
}With this in place just make sure EnableModExpansion is set inside dinput8.ini, and edit one of the ESLs to spawn Em 09 somewhere, and you should be good to go.
Here's an edited emleon03.esl, should spawn it on r205 like the earlier method did: emleon03.zip
nipkownix
Mister-Curious
Wasn't able to get textures working for that though, but looks kinda promising, just too bad we don't have any code for em06 ;_;
Is this the model your seeker mod uses too? (probably not related to the bug, but wondering if anyone has done anything with this model yet...)
qingsheng8848
linkthehylian
Atomoksetin1996
DarthxVoid
FutonGama
SaacK12
As discussed at #21, seems Em09 actually has working code/data in the game, a video of it & instructions to make it spawn (replacing the Em2d Novistadors) can be found at https://github.com/emoose/re4-research/issues/21#issuecomment-1332362257
Unfortunately it does have some issues though:
Waitstate, which then checks some conditions and either: goes back toWalk, goes toAnger, or if close enough to player, attacks withHarai/Turn90_Harai- butWalkitself has no way of going back toWaitunless the player HP is 0, must be missing something there...Anger(@ 0x426D66) seem broken with contradictory checks being made (eg only allowing to activate if player distance is both greater than and less than N units), maybe those checks were using different distances at some point but some change accidentally made them check for same thing - need to figure out what it's actually trying to do there.The code responsible for setting it as
Angercan be seen here:I think the main breakage there is the less than/equals line
if ( pEm->l_pl_378 <= 2250000.0 ), with that removed the code seems to make much more sense, but maybe there is a reason for that check being there, could be meant to check against a larger distance to limit how far it allows activatingAngeror something.Unfortunately the way those checks were actually assembled into x87 instructions makes it hard to change one without also changing the other, will probably need to hook something there instead.
E: figured out a way to get it to work as
Em09without needing too many patches, unfortunately that brings a big issue with it though: a lot of the code likeGetWepTargetList2only checks for/returns Ems that use id 0x10 or above, and there's a big switch statement there which would be hard to add Em09 to... guess it could maybe be worked around by temporarily overriding the ID to a different one if it was09.No idea how many other parts of the code might only allow certain Ems too though, right now the Tyrants spawned as Em09 can't be damaged at all, even with knife, and bullets just go through them :/
Might end up easier to replace certain Em number with 09 instead, maybe could add an INI setting that lets modders pick which Em to overwrite.