[FEATURE] Spoof fake packets to the own client

[lbirkert]

Would be useful to test features that require server side packets to be sent without a bunch of server reloads/restarts. (Certain packets for NPC actions example)

[Ari24-cb24]

So you mean kind of like a packet-resender? I actually thought about making this project a bit like burp suite where you have the Repeater option.
To do that, I will have to save every ByteBuf (and packet type) in the client for later uses and if the frontend want's to resend something, I'd need to implement deserializers for each packet.

Sure, I'd be down to 😅

[lbirkert]

More ment to target testing the client specifically:

I can spoof an PlayerJoin packet (probably doesn't exist - doesn't matter) and then a new Player pops up to my screen.

I can see how this would make the entire project a lot more complex tho, also this wouldn't really have to do stuff with logging but rather packet testing in particular.

[lbirkert]

Might be simpler to create a server plugin which does that.

[Ari24-cb24]

Hm, for your particular use case, a server-side plugin would probably better (there are also already scripts out there doing exactly that). But I think I might still introduce a repeater feature in the future. But for know I still have to implement every client-side packet 😅, I'm still missing out on 40 packets. But definitely a nice idea!

[Ari24-cb24]

Also, when I might introduce server-side packets as well, this feature could come in handy.

[lbirkert]

I also thought of a way to roll-back to some point in history and inspect the games state at that position - with some kind of freecam. It would probably be good if the packets from a recording could be dumped into a snapshot file containing a snapshot of the games state before the recording was taken and then the packets that have been sent meanwhile recording. This would introduce a more modular system allowing different inspectors/tools to be written separate from this project - not only in java, but really in any language that can somehow read a file.

[Ari24-cb24]

It is possible except for "rewinding", as most packets are relative or use client-side physics. Tho, we use such a ReplaySystem for moderation tools at thejocraft.net. Interesting idea!

[lbirkert]

It is possible except for "rewinding", as most packets are relative or use client-side physics. Tho, we use such a ReplaySystem for moderation tools at thejocraft.net. Interesting idea!

You mean the client state is relative to the clients physics? Yep this could be problematic.

[Ari24-cb24]

If you rewind 10 seconds back (only option), the plugin basically re-creates the state at the time 10 seconds before that. So it is possible to do something but it requires a lot of work (I think pianoman took some months to develop it)

[Ari24-cb24]

Also, when I might introduce server-side packets as well, this feature could come in handy.

I'm now at a point where I can say that I will work on this. Packets are currently being stored on the client and I support all packets, so re-sending a packet is not really difficult.
What I think I might need is probably some kind of serializer. There are two ways of doing this

1. Just implement another method for every packet to construct a new packet (takes a lot of effort but will work)
2. Annotate the serialized outputs and give them indecies so that they can be parsed in again later (I don't quite know how I would go on and do this, probably having unique names via some sort of mapping....)

It might hopefully end up in a mix of both of them as some packets are quite complex.