client-server communication and additionally server-to-server transport.
Yes, that's why it _could_ be possible to place some independant chat servers on trusted platforms to get the chat off the psserver. But that would pose the trouble of not really being able to control stuff, therefore a bad idea. When/if we ever use multiple servers (for different levels, etc) it could be possible to use those in a client-server-server-client (dunno the exact name) network.
I don't think there is available OpenSource version written in C++, easy to include in PlaneShift code.
Well. You can't say that without having checked beforehand, can you?
Basically You want to divide maps to more, smaller sectors, nothing more.
It is similar to sectors, but not the same. I want to add an additional info to the maps. Actually, it's possible to change those
dynamically culled mini-regions for reducing unnecessary DR
on runtime, and change them generally a lot easier than sectors.
The graphic loading, the sector loading and loading in general client-sided, doesn't get affected by those mini-regions. It also doesn't pose a problem to the artists to place such mini-regions as they are in already existing sectors, while adding/dividing sectors isn't that easy.
This would be a big waste, as sending that data would be more than just donig the DR.
That actually depends on the number of entities that are covered by those mini-regions.
Think about that suggestion in a year again, when we'll have 1000+ players and all the NPC moving
You would like to implement TCP+, I mean TCP
Not at all. I like to have the clock on server and clients synchronized. Then add to all DR packages (that are already there of course) a timestamp when they are being sent.
The clients then reconstruct the scenery by taking the timestamps into account.
With that it doesn't matter whether packets got lost or not, so no need for TCP.
