Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
GreYFoX opened this issue May 18, 2012 · 7 comments
Open

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

GreYFoX opened this issue May 18, 2012 · 7 comments

Comments

@GreYFoX
Copy link

GreYFoX commented May 18, 2012

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
Copy link

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
Copy link
Author

GreYFoX commented May 19, 2012

@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
Copy link
Author

GreYFoX commented May 19, 2012

and adding dummies in the python is not really cool

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

@heinrich5991
Copy link

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
Copy link
Owner

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
Copy link
Author

GreYFoX commented Jun 5, 2012

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants