JCL is right.

If you have a system that selective update clients, we have found that it's easier to "link" the join/update procedure with this selective update.

In other words, a client is going to get updated on what other users are close to it's avatar. Upon joining, the only user close to itself is itself... so we do a self-update. After this, this self-update continues to work (with less information) until we meet another person at which point this update is now sending two pieces of information: your updates and the person in range of you. As you can see, the join event should be no different than the update event except for whatever extra information is needed at login on the client.

Hence the solution (once again) is to either re-write the GS Network Architecture such that selective updating is natural and login is taken care of that way
or
not use GS Architecture at all and make it part of your selective update routine like we have.

A dll plugin would be great, sorry if im spamming but we need this mmog thing and i need too, and my knowledge in making plugins is low, and gs should support mmog

When a player joins I want it to be fully updated (so to say initialized) on ALL machines. That's mainly visual things like the model itself, its scale, the skin....
Of course I can code this and do an update for every single entity parameter - but it's so much easier to have this done automatically if desired.
So my workarund was to activate automatic updates (reseting NOSEND) for a short period after a client joined and once everysthing is initialized, switch over to manual updating.

The cyclical updates in my case are kept to a minimum. Mainly only keystroke information, movement stuff, entity status mode (used for animation and certain entity events). Things like animation (generally visual things) are done by each machine itself without transfering such information between server/client to keep traffic low. At least low enough for like 4 players via ISDN connection - since I'm not working on a MMOG no distance dependent update and other thigns are required.



Summarizing: This is not a blocking point, it's just a matter of easy use

I think it would not a bad idea to go with RakNet as it seems to be quite good, but to be honest.. I would rather not have to pay a separate fee just so I can release my MP projects.

Anyways, if all this is going to change, I'll definitely buy A7 asap.

JCL,

Can we set up a poll on the issue of paying for commercialization with RAknet?

If the only reason to not use RakNet is because of the licensing fee, I would like to see for how many people this would be an issue. A poll asking this question could remove this as a potential barrier to integrating raknet into the engine.

Yes, I already offered to start a poll. A poll that pointing out non-commerical usage is free and license fee is $100 can be started.

Non-commerical usage is already free.And if someone wants to go commerical, $100 should not be problem.(id rather paying $100 for raknet instead of going commerical with dplay.)

and lobby system,auto patcher,security,Voice communication, far better MMO capability than play. I could pay more than $100(you know, you pick the price) for such robust library if i ever do something commerical.

check the class/function list on the raknet manual, such funcs. exist:
RakNet::ClanJoinInvitationAccepted_Notification

nearly everything needed for a mp game.

Polls are unnecessary for feature request. I've understood that problem anyway.

We can't require from our users to pay additional license fees for multiplayer applications. On the other hand, I also see the demand for advanced multiplayer features, such as voice communication which is not offered by lean free libraries such as ENET.

At the moment we tend to a solution like an open library interface that allows end users to implement their own mp library and override the engine mp functions. We're also thinking over a similar approach for a physics engine.

I'm confused. Your first quote makes it sound like if the majority of users wanted to pay the license fee, then it wouldn't be a problem to integrate raknet. Your second quote however makes it sound like RakNet is completely out of the question.

Which one is it?

Neither. A Raknet option is not completely out of the question, but basic multiplayer must work without additional license fees.

bump