Re: cheating & LOS

["Carl Edman" <>]

From: Jason Fosback <>
> >  But the protocol I proposed does not require you send every single
> >  visible square every time you move.  It requires the server to
> >  send every square once when it _becomes_ visible.  After that the
> >  server doesn't need to concern itself with that square at all
> >  until it becomes invisible again.  And by invisible I mean outside
> >  the LOS -- just having items (like monsters or more common
> >  objects) on the square does not make it invisible.
> 

> Right, but squares outside your line of sight come and go
> continuously, every time you move.

That's for sure.  So do the number of squares within the 11x11 square  
centered around the player.   It is that which you propose should  
always be sent to the client requiring the update of 11 squares in  
every single move ?  It is doubtful that my proposed protocol will do  
worse than that. 


> Take this ASCII (!) example:

Yes, lets take your worst case scenario and calculate the cost.  I  
believe what you suggest is this with the player moving from A to B.

    | |
    | |
    | |
    | |
----+ +------------
 A        B
----+ +------------
    | |    

    | |
    | |
    | |    


Cost under your scheme: 9 step * 11 MAPs/step = 99 MAPS

Cost under my scheme: The entire cross-corridor is mapped in (once) for  
a cost of 3x11 MAPs.  For the remaining 6 steps only the 3 new squares  
in the narrow corridor need to be mapped in for a cost of 6x3 MAPs.   
Total cost: 51 MAPs.

So even in your worst case, the proposed protocol uses almost half the  
number of MAPs which your proposed protocol requires !

> Alternatively, since this is a little redundant, you could make the
> move command a little more restrictive (since you're always in the
> middle of the screen:
> 

>   C:  MOVE [N,NE,E,SE,S,SW,W,NW]

The move command needs to have more arguments, because it is used not  
only to move yourself but also all items i.e. dropping/pick up is done  
by the MOVE command.  The reason the proposed MOVE allows you to give  
an arbitrary location is that this allows clients to request long moves  
without being limited by a round-trip delay for every step.  I would  
expect the server to internally convert a MOVE to a distant location to  
a straight-line approximation by single steps.

In particular a client would express a run command (currently trigged  
by the control key in crossfire) by sending a command like this:

	MOVE <player-tag> <current-x-coordinate> <some-huge-number>
	
This command would make the player character run as far south as  
possible as quickly as possible.

	Carl Edman