A piece of advice to overcome bots.

[visual pier]

We are familiar with the working principle of multiplayer games and wanted to offer you a suggestion. Our recommendation is essentially related to altering packet names between the client and server at irregular intervals and automatically banning players who use old packet names. For instance, if the header for the walking packet is "mv," you could change it to "mov" with an update, thereby automatically kicking out characters that send the old packet and adding their names to a list.

The development team understands that this process is indeed challenging, but we are here to support you. As players, we truly need a real innovation. Please ❤️

[latent ore]

Whilst I understand that this might be efficient, you should take note that big rework that aren't about gameplay won't be done, why ? because they wants money ^^'

Knowing that there is tons of other way to prevent bots :

• Changing game cryptography
• Adding an anti-cheat
• Blocking packetlogger

and so on, this is definitly not the best idea xD

[digital wraith]

There are many ways (hard & easy) to anti them. but GF don't want to do anything about it

[frozen imp]

Dave said something about an anti cheat being in progress. But dont expect anything yeah

[signal galleon]

Let's be real - as many developers Entwell & gameforge has...5x more developers are currently nostale players. There is not a 100% bullet-proof security. The one which was recommended in the first post is dumb as hell.
All the packets are hardcoded in the executable. Even now with simple pattern scanning you can change the packet headers. You don't even have to update the bot with each patch because with those little changes most of the signatures would be still updated.

The real way to, at least, try to block cheaters would be implementing a heartbeat anti-cheat which would also send a packet with each X sec with specific encrypted string of a "secret key" and something unique (like current time). Constant updates of the secret key with complete signature changes would require many updates of the internal bots.

After all it wouldn't block botters. Hatz makes few k€ monthly from the bot. No chance he won't spend the time to update it even every few days.

[signal galleon]

yes, there are easy ways to block botters completely. We live in 2023. Each one game developer fights with hundreds of RE-based specialists.
Let's take a look at League of Legends. The scripting platforms completely fucks the game. Even tho they just spend a little time to work with cheaters. Instead they prefer to add new skins and stuff like that.
In case of gameforge it's pretty similar. New "perfect solution" will be bypassed by cheaters in max few days, while implementing this solution would take months of work by the entire team. Instead they preffer to add new stuff. And it's good.

Also..let's be real - cheaters keeps the economy going. Without botted gold there would be probably like 50x less gold on the Dragonveil. Of course there is an inflation..but after all now "legally-playing" players loads more NosDollars because they see higher amounts of money they get for those NosDollars. And it doesn't matter thay they will buy more or less the same items they would be able to buy without inflation. It doesn't matter. After all people like having more gold. That's the fact.

[digital wraith]

I have my own point on this subject, and also solutions to reduce or limit those who bot, but I will not publish it because I will not benefit anything from this, and I agree with this ||(cheaters keeps the economy going)||

[signal galleon]

as I said - there is no real way to protect the client from bypassing it. The only real solution (which wouldn't also be 100% bullet-proof) would be making a custom kernel-level-based anti-cheat...but not shit like EAC or Xigncode3. Both would be pretty easy to bypass.
So yeah - it's impossible to completely block usage.
There are multiple ways to limit it..but at the same time it's not worth doing for a company like GameForge (I suppose this type of coding would be done by GF instead of Entwell because already few entwell servers uses xigncode3). This is why the anti-cheat will never be added. Same thing with limiting the amount of alts. Simply nothing in that area will ever change. And I am okay with that. It's better to make new events or focus on the class balance instead of wasting time for something what will be bypassed 100x faster than the preparation to implement took in total.

[signal galleon]

also...except the reason I wrote few messages above...the method you presented is even more dumb after I read it for the 2nd time.
First of all - you showed example of a RECV packet (client-side). This packet is never sent to the server. but it doesn't matter.
The bigger problem is that you talk about bots...while all bots are internal. It means these bots are using a memory function to send the packets, call walk functions etc. It means the change you suggest would do exactly nothing because the bot would use the "modified packet" anyway. The only thing what this solution would "block" is a packetlogger (sending the packets from client to the server).

Anyway...in that case much easier would be changing the cryptography of the client. It would take much longer to update the bot (and everything what is injected into the client). Also it would be great idea to add additional cryptography alongside the current one. For example with AES. This way all packets would be encrypted with a secret key before sending from the client to the server. Then server before handling them would decrypt them with the same key. And exactly the same thing with the packets from the server to the client.
Probably easier to implement + it would be enough to update one "key" on each patch instead of changing the "walk" (and every other packet header you want to modify) to "walkk" etc