[CF-Devel] Protocol Questions (Server to Client)

Kevin R. Bulgrien kbulgrien at worldnet.att.net
Sat Aug 31 02:55:17 CDT 2002


Umm... I'm not protocol questions here, but the reply got me thinking:

---
>>
     
     2. NCOM/COMC
     
     >>
     
         Where to find out which Value to use for <packet> ?
     
     >
     
     
     >
     
      Start at 0, and re-wrap to 0 when you get to 255.  What this is used for is so that the client can know if the server has executed a specific command. Basically, if the player is moving really slow, you don't want to send 200 commands to the server, because that gets way too far ahead for the players action.  So the client can look at the last comc value and see how many unexecuted commands it has sent to the server and decide not to send this one.
     
     ---

This may be an "out in left field" question, but, I've seen situations with
the latest GTK client RPM where more than 256 commands have been buffered
up when SDL was running on my machine and I didn't know how bad things
were for the machine I was running on.

a.  Wonder what happens if you wrap?  There are times I could hardly believe
    that the vast numbers of buffered commands were even possible.

b.  Does it even make sense to queue commands during run mode?  This has been
    what has gotten me into trouble over and over and over and over again.
    Run overshoots.  Now you are stuck in the room with that nasty ball
    lightning, and you die.  

    I suppose something like "oh crap, I'm lagged, gonna die, and buffered
    up, but how can I just sit here and not fire:  run, shoot, run, shoot,
    run, shoot, run..." does this...  Is there some way to avoid a problem
    in this situation, or is there something in the protocol for the client
    that makes it unavoidable?  I can see that you should do the fires, but
    do/should you really keep queueing run commands?

---
>>
     
     4. MAP1 / MAP1A
     
     >>
     
         Is 1a only used for large faces ?
     
     >
     
     
     >
     
      The client can use the setmode command to request which one to use. currently, there are no 'big faces' on the server, yet I have the unix clients using the map1a command.
     
     >
     
     
     >
     
      I note that the docs on that is incorrect - currently, the map1 and map1a command are exactly the same in terms of format, only the map1a command sends maps off the edge of the viewable map (the doc says that the two MSB bits in the face are used for other stuff - that isn't true).
     
     ---

Eeesh... Is this another reason why the huge, open fields of monsters choke
the GTK client to death on like a P-120?  Is it processing monsters on more
than just the viewable area, or just the map features?  Could it be that this
is part of the root cause for marginal performance on a client?  I've turned
off SDL so a huge part of the problem is gone, but still find that I get lagged/buffered-up on dungeons with large open areas that are full of creatures.


    
    


More information about the crossfire mailing list