Ra_k_net!

Keep in mind that there's only 1 man behind RakNet. Though he supports his customers in his forum (daily answers, other users help you too) and over icq. So even as a non-commercial dev you get pretty fast and good support. Also, the manual covers all of the code, plus he has video tuts to help the beginners.


*coffee*

How about Enet, I found that recommended on many websites and it seems fast and stable:

http://enet.bespin.org/

When A7 anyway only uses the basic network functions, and uses its own encryption and server handling, it makes no sense to let us pay for Raknet when Enet can do the same.

Well, like I said is what the first page says:

That's why I think it's not suitable.

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.

like I stated ealier, make a "pure mode" low level
networking mode,
that concentrates on transmitting raw data
from A to B.

The rest is up to the user the program the functions to use it.

the whole 3dgs multiplayer concept
(entities updates by the server, all running in
a certain "level") is the problem.

The MP concept is not the problem. You need not use it, if you want not to send variable or entity updates, just send packets and dont send variables and switch off entity updates. But for beginners starting with MP, the concept is good.

I think what's lacking was encryption/security that seems implemented now, and then server to server communication. Updating only clients in range is not necessary I think because I'm with Excessus here, this can be programmed by the user.

When disabling automatic updates you'll run into problems when new clients join.
The entities won't be updated correctly leading to weird results.
To overcome this you either need to workaround a lot or enable automatic updating for a short time so the model file and the like are adapted. After a few waits, disable all automatic updating again. This was my approach for the last time I tested MP.

It would be nice to have another implementation which takes care of removing disconnected client player entities and initially updates player entities of newly joined clients (even when further automatic updating is disabled) without having to fiddle around with such tricks and workarounds.

It already takes care of that, or so I think, with the join and leave event of clients.

It does - but you have to turn on automatic updates.
That's annoying if you only want to have things updated automatically upon join/leave (you have to take care of that on all connected clients, otherwise you could jsut use connect/disconnect events)) but want to do the cyclic updates manually.

If you don't believe me - try it out.

We can implement a flag for activating entity updates only when a client joins. I'll add that to my list. However, when you update entities anyway by script, why don't you do that with the same script when a client joins?