Re: cheating & LOS

["Carl Edman" <>]

From: Philip Brown <>:
> >>>>[From Carl Edman]
> 

>     Why don't we want asynchroneous updates ?  Because we like
>     wasting   processor cycles and network bandwidth ?  Or because we
>     can't admit   that we could possibly be mistaken about something
>     ?
>     

> asynchronous updates WASTE bandwidth, because they generate many many
> more packets than would otherwise be sent.

Can you please give one single common game situation in which an async  
protocol (as proposed and explained in the example I posted) will cost  
"many" more commands than if used synchroneously ?

> Having timer clicks for updates is neccessary because
>   1)  that's the way the game code is currently designed

If that was a trumping argument, we wouldn't be talking about  
client/server at all because "that is not the way we do it here and  
now".  We are talking about the significant changes which client/server  
involves just _because_ it allows us to improve the design of the game.

> 2) it preserves a concept of relative "speed" between
>    monsters/players/etc nicely

That is certainly a concept worth preserving.  How it relates to the  
fact that you have to do things synchroneously I do not see.  


> 3) It equalizes play between fast-update and medium-update players.

Do you mean to say that you deliberately add unnecessary latency to  
fast connections to punish those players ?  I don't think that is a  
virtue.

> You seem to be taking into your hands how the server will use the
> protocol, instead of just sticking to your proposed protocol itself.
> I'm pointing out how it will actually be used.

You can not separate the two.  What the correct server/client behaviour  
is depends on the meaning of the protocol commands.  Separating the two  
is sure to produce gibberish.

> As for your last comment.. you were the one you pleaded for
> un-personal mail.  Don't be a hypocrit.

I did not mean to attack you.  But in the last few days you have  
appeared to be so obstinately opposed to even for a second think about  
how things can be done differently and better and have instead always  
been defending the status quo regardless of consistency.   For example,  
yesterday you within an hour both attacked the protocol as (a) too easy  
on the players because it tells the client about items in plain view  
and (b) as too hard on players because it doesn't tell clients what's  
behind solid walls.  At times that is a triffle frustating to me.

I promise that I do try to be open to your suggestions and criticisms  
and am sure that they will improve the protocol.  But please do also  
try yourself to be open to the idea that the client/server protocol may  
change things for the better and more rational and that should be its  
goal and not a slavish replication of _exactly_ the way the current X  
client looks and works.  Ok ?

	Carl Edman