Bloodybone wrote: ↑Tue Oct 29, 2024 9:23 pm
slysmy wrote: ↑Sun Oct 27, 2024 11:59 am
Bloodybone wrote: ↑Sun Oct 27, 2024 11:48 am
Are you the host? Which Cheats cause the desync?
yes im the host, all of them cause it
Maybe try the attached Script. Can't test myself though it might stop the desyncs from happening. Will only work for the host
Edit: Might still not work if the Clients themselves check for desyncs (and disconnect) as macks said in the above post.
That function you found is called ServerMultiplayerManager::receivePlayerDesynced. By the time this is called, the player is telling US they've desynced, which is bad. We have to prevent us from telling them to desync disconnect.
cursor_mod_bypass is apart of a CPP file called CursorStackChangeGuard.cpp. So clearly they implemented some kind of anti-cheat in this game and the anti-cheat is what is detecting us.
What we should look for, is what is read/compared to when we issue the desync packets to the other player. There's probably some value it stores upon picking up the item. We need to set the old value to our new value, and that should defeat both the CursorStackChangeGuard class and the desync protection.
EDIT: The guard is located at +0x1C from character.cursor_data. If you set both of these at the same time, the CursorStackChangeGuard code won't get executed.
Digging deeper, it seems the guard is set inside the Character::postTransferHook function, which is done each time the inventory is interacted with. This is probably emitted to the client, then when we place the item down, they're given another packet, which they compare to the first packet. If it's different, it desyncs us. We would have to emit the change before we pick it up (or maybe just edit the inventory without cursor interaction?)
EDIT: Nope. I tested with my cousin, and he desynced the moment I changed it, even without picking it up. This protection is a fucking pain in the ass.