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

Ability to retrieve client actions/packets #16

Open
TheMode opened this issue Feb 18, 2022 · 3 comments
Open

Ability to retrieve client actions/packets #16

TheMode opened this issue Feb 18, 2022 · 3 comments

Comments

@TheMode
Copy link

TheMode commented Feb 18, 2022

I am currently looking at ReplayStudio with the goal of using replays in junit tests for an anti-cheat, the fact that server-bound packets are not recorded make it a bit confusing.

Are self-movement packets automatically converted to their client-bound equivalent? What about including client packets in the API?

@Johni0702
Copy link
Member

Johni0702 commented Feb 18, 2022

Yes, the mod synthesizes client-bound packets for any actions which it knows the server won't echo back.
Once the replay is recorded, the recording player entity is (conceptually, technically it probably gets updates at different rates, etc.) no different than any other player.

Server-bound packets are never even recorded because they cannot be played back (converting them to client-bound ones on the fly is significantly more difficult than synthesizing client-bound ones during recording), so there's been no use for them.

@TheMode
Copy link
Author

TheMode commented Feb 18, 2022

Are those packets listed somewhere? The wiki page mentioned in the readme is not accessible (https://github.com/ReplayMod/ReplayStudio/wiki)

Ideally, I would prefer having an option to record server-bound packets (even if unused during the IG replay). As this would make much more sense in my situation.

@MWHunter
Copy link

I'd suggest against doing anything with ReplayMod. There's a lot of netcode things that you wouldn't be able to emulate with replaymod, such as:

  • Mojang not sending position packets when moving < 0.03 blocks (This screws up predictions with thousands of lines of code for this stupidity)
  • Mojang not sending position packets when it's required such as when a client's pose change without informing the server
  • Mojang sending duplicate position packets when right clicking with a bucket (ironic!)
  • Mods screwing with packets to try to find bypasses
  • High latency conditions with block updates, block placing, and using items
  • Handling players splitting transactions such as with knockback. Splitting transactions means the transaction before the knockback arrives but not the knockback. This can cause the server to think the client took knockback, but they didn't. This was solved by sending a transaction before and after knockback, but good luck trying to simulate this with ReplayMod.
  • A ton of other netcode issues such as clients and servers fighting over vehicle and using item control, as both control these things in 1.9+ creating a glitchy mess that grim has to handle.

Instead, for JUnit tests, I'd probably dump the raw bytes sent in the packets and then feed it into PacketEvents to call events. This way any client could have their data dumped for JUnit testing. This would include paid clients running in VM's to protect against backdoors.

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

No branches or pull requests

3 participants