Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix local player pointer randomly becoming corrupted after spawning an item #45

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

yyy257
Copy link

@yyy257 yyy257 commented May 29, 2024

Client-side entitites are tracked with an M*LIB dictionary, and inserting a new entity can shuffle other entities around in memory, including the local player:

Elements in the dictionary are unordered. On insertion of a new element, contained objects may moved.

Therefore, insertion of a new entity can randomly make gstate.local_player point to garbage data, usually getting the player stuck at X=0, Y=0 and Z=0, sometimes ending in a segmentation fault.

To fix it, I added a variable separate from the entity dictionary which tracks the local player ID, allowing updating gstate.local_player after spawning a new entity. As long as the game is singleplayer, the local player ID is always 0, but the variable may be useful when multiplayer is added.

@xtreme8000
Copy link
Owner

Good spot! I think the best solution here would be to only store struct entity* pointers in the dict, instead of the whole object.

@yyy257
Copy link
Author

yyy257 commented May 29, 2024

I also think that's a good idea, so I implemented it in a commit. It might not be the best implementation, but it seems to work - I hope it will be useful. This could even save memory, as dictionaries may use a temp array relative to the dictionary's size while resizing.

To reproduce the bug, I dug a lot of blocks without picking them up until the player data became corrupted. I could also reliably trigger it with the code in my fork that drops all items upon death.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants