InterServer Meeting Area?

[_Emme_]

Respect shouldn't be based out of knowledge or wisdom, tard.

[Arcо]

Originally Posted by EmmeTheCoder

Respect shouldn't be based out of knowledge or wisdom, tard.

And you know so much about respect right?

[Korvacs]

Originally Posted by EmmeTheCoder

Respect shouldn't be based out of knowledge or wisdom, tard.

Im sorry, but for thousands of years the oldest and wisest members of many civilisations have been the most respected members of their civilisation.

I think what ulti meant was that realistically you cant do this with a TQ Binary server, not that it is impossible.

[InfamousNoone]

Originally Posted by EmmeTheCoder

Respect shouldn't be based out of knowledge or wisdom, tard.

Respect is given to those who deserve it. Your not one of them.
Yeah Korvacs, I figured as much I suppose I interpreted it a bit too literally.

[-Shunsui-]

Don't start a war, Guys

[DragonHeart]

Originally Posted by -Shunsui-

Don't start a war, Guys

Seeing Hybrid etc starting a war on emme is just funny

[Arcо]

Originally Posted by DragonHeart

Seeing Hybrid etc starting a war on emme is just funny

Well most have reason to do so.
If you really know emme you would know why.

[Zion~]

Great idea and 100% feasible. But would the optional protocols that are being considers increase latency between a player and the server? The other possible errors could be overcomes according to Hybrids theory.

But here's mine: Each user who joins this map gets a guild name refering to the server which he or she came from. Guild name => AcidCO Player => Zion~
although I've not made a conclusion whether this is capable or not give me some feedback on your view.

I absolutely love the idea, and would contribute in anyway possible.
Good luck.

[~Yuki~]

Originally Posted by Zion~

Great idea and 100% feasible. But would the optional protocols that are being considers increase latency between a player and the server? The other possible errors could be overcomes according to Hybrids theory.

But here's mine: Each user who joins this map gets a guild name refering to the server which he or she came from. Guild name => AcidCO Player => Zion~
although I've not made a conclusion whether this is capable or not give me some feedback on your view.

I absolutely love the idea, and would contribute in anyway possible.
Good luck.

No coz there willl be a proxy so ppl get same latency

[IDivideByZero]

Originally Posted by Zion~

Great idea and 100% feasible. But would the optional protocols that are being considers increase latency between a player and the server? The other possible errors could be overcomes according to Hybrids theory.

But here's mine: Each user who joins this map gets a guild name refering to the server which he or she came from. Guild name => AcidCO Player => Zion~
although I've not made a conclusion whether this is capable or not give me some feedback on your view.

I absolutely love the idea, and would contribute in anyway possible.
Good luck.

It's already done so clan shows up with the name of server, like AcidCO EU Server and AcidCO test server once I've been testing it. However, to make it compatible with older versions, guild could've been used as well.

[_DreadNought_]

#Big bump. Mainly for Yuki. -- There's been a abit of talk about interserver meating area lately.

[~Yuki~]

thanks i quess but i was active on that thread...

[_DreadNought_]

Right well,

I am currently attempting to code such a thing

But the thing is, From this thread and a few other people i've been told todo different things and what things are right and wrong.

I know that the Kernel and somesort of "World" class are needed. and that the interserver should "read data through the network" and that its silly if I for eg, "sending the packet of the player spawn/movement to the interserver that sends it to the other server".
Also one connection per player is silly.

But i've then been told different, Like, Have a entity class for a each player that hold VERY small information(uid, x, y, mapid, body, hairstyle) and uhm to have one connection per player.

Any advice? Sitting here scratching my head what todo, I've done that each server only gets one connection and the interserver has its mapping system done + a small entity class.

But I wanted to stop and get professional advice before I go any further.

[pro4never]

Well talked about this very briefly on msn but here's my thinking.


Central Server controls all main calculations for the map (where objects are, etc).


'Shards' (individual game servers) can connect to this server and when needed send packets to it. This means 1 connection per connected server. You would then use very simple custom packets to send updates between the shards. Shards would then handle all the communication between the individual players.


Eg:

Player X (local uid 1000) from AcidCo logs on to the normal AcidServer... They go to a meeting area where other servers can see them.

AcidCoShard>CentralServer:

AddEntity(Name, mesh, location, etc) Basically a shrunk down spawn packet.

CentralServer>AcidCoShard: Confirms (if valid) and assigns a central UID for that player (used in further packets. Central remembers that the player is from that server linked with that uid!)


CentralServer>>All other Shards: Sends spawn packet for player X


Now whenever player X sends a packet to AcidCo, it decides if it's a 'broadcast packet'. Eg: Jump, walk, talk, change direction. If so it sends it to the central server which can then send it to all other shards.


That's the most efficient solution I can think of for this because it allows the user to still be connected to and controlled by the server they started off with (no dc/recon needed when entering/leaving the meeting area) and limits latency because in theory anyways, all shards and the central server would be using high powered connections and would therefor be able to most efficiently transmit data to their players.

[Basser]

The answer to many of these questions is testing.
Try creating x amount of 'artificial' players and do performance checks on w/e you need. E.g. test whether you should use one or multiple connections.