SushiTee / teeworlds

A retro multiplayer shooter
http://teeworlds.com
Other
12 stars 1 forks source link

Race Client / Server messages in the future (0.7.0) #4

Open GreYFoX opened 12 years ago

GreYFoX commented 12 years ago

We have to reach some kind of messages in networtk.py that works for both DDRace and race so that we can support eachother's client/server

heinrich5991 commented 12 years ago

maybe add a general method from the client to tell the server what he can do instead of inventing a msg for each client.

GreYFoX commented 12 years ago

@heinrich5991 that doesn't make sense to me, what i actually wanted for example instead of DDRace and Race messages overlapping because they have the same location in an enum, that we could give them different IDs

like NETMSGTYPE_CL_ISRACE=200,

so that Race messages would not overlap DDRace messages at 100 and not over lap teeworlds at 0

but i'm no python expert and replacing it in the pythin code doesn't work NetMessage("Cl_IsRace=100", []), makes the structs in protocol.h have invalid names

GreYFoX commented 12 years ago

and adding dummies in the python is not really cool

@SushiTee do you have a super solution like always :) ?

heinrich5991 commented 12 years ago

I don't think that messages like CL_ISRACE are a good idea, I think we should solve that problem more general.

Like for example CL_CLIENTFEATURE, sending a list of client features in like: racesupport, 1 ddracesupport, 5 fastdownloading, 3 nclient, 1

And then the server responds with the next message, specifying, which additional protocol it will use: ddracesupport, 4 fastdownloading, 3

Afterwards, not sure if this step is needed, the client will send the protocols actually used in the session.

And then we create an additional protocol for those extensions, each one sending the hashed name of the module with it, so we don't have overlapping message IDs.

SushiTee commented 12 years ago

jap overlapping message ids are a very bad thing. i had some problems with it before already. i have to admit i didnt really thought about this at all yet how to solve this better. what heinrich said sounds like a plan though.

GreYFoX commented 12 years ago

but still, we need to have them at a place far than teeworlds messages but adding dummy/blank messages before our client support message sounds and feels bad

@heinrich5991 and @SushiTee i accept @heinrich5991 proposal

heinrich5991 commented 12 years ago

@GreYFoX will see what I do @GreYFoX @GreYFoX t-t-t-triple highlight