Repository navigation
Conversation
`D2GameStrc::nGameData` at 0x20 was a bare `uint32_t`, filled by a callback declared to return `uint32_t` and read by a callback declared to take `uint32_t*`. The rest of the table makes clear what actually lives there: - `pfLeaveGame`, `pfGetDatabaseCharacter`, `pfSaveDatabaseCharacter` and `pfRelockDatabaseCharacter` all take `D2ClientInfoStrc** ppClientInfo`, and the call sites pass `&pClient->pClientInfo` or a local `D2ClientInfoStrc*`. - `pfUnlockDatabaseCharacter` is the odd one out, typed `uint32_t* pGameData`, and `GAME_JoinGame` passes it `&pGame->nGameData` — the *game's* slot, in the branch where `CLIENTS_AddToGame` failed and there is no client to take a `pClientInfo` from. So the same kind of handle is reached through two different types depending on whether a client exists. Field 0x20 is now `D2ClientInfoStrc* pClientInfo`, `FnUnlockDatabaseCharacter` takes `D2ClientInfoStrc**` like its four siblings, and `FnSetGameData` becomes `FnCreateClientInfo` returning `D2ClientInfoStrc*`, which is what `CLIENTS_SetGameData` stores into the slot. The layout is unchanged: `D2GameStrc` is packed for a 32-bit target, where the pointer occupies the same four bytes the `uint32_t` did. ThePhrozenKeep#160 also gives the callback a `D2ClientStrc* pClient` parameter. That half is left alone: the only call site, `CLIENTS_SetGameData`, is reached from `GAME_AllocGame` and `GAME_FreeGame` with no client in scope, and passes no argument today. Deciding whether the original takes one in ECX needs the disassembly, not this tree. Syntax-checked both touched translation units with g++ -fsyntax-only -m32 and the DLL_DECL macros defined. Error counts are identical before and after (Game.cpp 14, Clients.cpp 4) — all pre-existing MSVC-isms under GCC, including the struct-size static_asserts, which fail on the unmodified tree too. Fixes ThePhrozenKeep#160
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #160.
D2GameStrc0x20 was a bareuint32_t, filled by a callback returninguint32_tand passed to one takinguint32_t*. The rest of the callback table says what lives there:pfLeaveGame,pfGetDatabaseCharacter,pfSaveDatabaseCharacterandpfRelockDatabaseCharacterall takeD2ClientInfoStrc** ppClientInfo, and their call sites pass&pClient->pClientInfo.pfUnlockDatabaseCharacterwas the odd one out (uint32_t* pGameData).GAME_JoinGamepasses it&pGame->nGameDatain the branch whereCLIENTS_AddToGamefailed, so there is no client to take apClientInfofrom.So 0x20 is now
D2ClientInfoStrc* pClientInfo,FnUnlockDatabaseCharactertakesD2ClientInfoStrc**like its four siblings, andFnSetGameDatabecomesFnCreateClientInforeturningD2ClientInfoStrc*. Layout is unchanged (4-byte pointer on the 32-bit target).Not done: the issue also gives the callback a
D2ClientStrc* pClientparameter. Its only caller,CLIENTS_SetGameData, is reached fromGAME_AllocGame/GAME_FreeGamewith no client in scope and passes nothing today, so I left the signature argument-less. If you know the original takes one in ECX, I'll add it.