Hello there 3dgs community. Long time no post from me, I've been busy with other projects I really don't have the time to read this entire thread, but I just want to comment on some things. Forgive me if this has been said before.


That's right, but for performance reasons you don't want to encrypt everything. So I consider this problem not solved. It is very important to note that switching to another library in the way that jcl envisions is not a solution either. The problem (as I mentioned several years ago when I found this flaw) is at the core of the 3dgs network architecture; if you use another network library to implement the functionality of "updating variables by index", you'll still have the same problem.

The only way to fix it "properly" is to break with the current 3dgs MP programming model. Something I don't think conitec would like to or should do (from a commercial perspective, not a software engineering one). The current model is pretty good for newbies (although it does regularly lead to confusion). What I propose is that conitec or an independent company/contractor develops a plugin binding RakNet, but with a new (well thought out) programming interface that is more suitable for large scale multiplayer games. This way you won't have issues with backwards compatibility and avoid licensing issues with RakNet (conitec only distributes a binding plugin, RakNet dll must be gotten from jenkins software).

Such a plugin should use the more traditional programming model where the user sends "packets" and not "variables". Packets can be inspected by user code upon receiving them (to check what kind of packet it is, and then to see if it is within the range of allowable values). Basicly just stay close to RakNet's interface by writing a thin C-style layer over the C++ RakNet library. I have written such a plugin and it works well but unfortunately I am not allowed to distribute it.