Updates to Fellowship locking

[LtRipley36706]

No description provided.

[gmriggs]

This does not match https://acemulator.github.io/protocol/Messages/0x02BE-S2C.html, nor does it match any of the code in pdb for acclient.exe

See the relevant functions: UIQueueManager::ProcessNetBlobData -> CM_Fellowship::DispatchUI_FullUpdate -> Fellowship::UnPack
-> ClientFellowshipSystem::Handle_Fellowship__FullUpdate
, specifically Fellowship:UnPack

The fellowship data structure ends at DepartedMembers, according to the client processing for this packet

Is this a feature that was added after the client pdb?

[LtRipley36706]

its not found in UnPack, but is sent across wire. Not sure where in the client, but aclogview decodes it

[gmriggs]

"Is this a feature that was added after the client pdb?"

Any answer to this question?

The pdb client doesn't use this data after DepartedMembers at all. The only explanation would be if this locking data structure was added at the end of the game, after the pdb client.

These PRs also need an explanation of what the changes actually are, the reasoning for the changes, and repro steps to test them. What effect does this have on the client, and how can it be tested?

[LtRipley36706]

Not sure where in the client, but aclogview decodes it

it was sent across the wire. it probably has no purpose to the client

[gmriggs]

looking in the final client, sub_5BA630 is Fellowship::UnPack

it looks to have no additional logic, and matches the pdb verison... DepartedFellows is the last thing it uses

if this data is completely unused by anything, and has 0 effect on the client or anything in the game, what is the purpose of this code if it does nothing?

[LtRipley36706]

to fill out aclogview parse.. the data was there as Writer.Write((uint)0x00200000);

[LtRipley36706]

from retail pcaps