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

[Mark Wedel]

Kevin R. Bulgrien wrote:
 > 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?

  By default, the client typically shouldn't get more than 10 commands.  Now 
there are settings to change this.  And some commands get sent no matter what.

  If you client is lagging but you are entering commands but more than that 
number of commands has not been acknowledge by the server, the client just drops 
the keystrokes/commands.  Thats the entire point of this - don't send so much 
stuff that has been unacknowledge that the characters actions are defined for 
the next 3 minutes.

  Note however this is separate issue from keyboard buffering or things that the 
client may not be aware of.  However, even in a keyboard buffering type case, 
presumably the client finally gets time to process them all at once, and will 
process the first ten before it is beyond its window size, and then just drop 
the rest.

  If queueing commands during run mode bother run, just reduce the command 
window size to 1.  The exact value of this can be tricky - if you are in a big 
combat, you may very well want a few commands to get buffered and not lost.  Eg, 
something like:

  attack monster (move north).  Do that until notice hp getting low
  drink potion of healing
  attack monster (move north)

  You really don't want that drink potion command to get discarded.

  Looking over the code, I do notice there are some odd issues with the run/fire 
code on the client that I'll need to fix up - the 'higher up' functions presume 
that the run/fire command will get sent, but if the window is full, it may not 
actually happen.

 >
 > ---
 >
 >>> 4. MAP1 / MAP1A Is 1a only used for large faces ?
 >
 > 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.

  Nope - the reason is probably that you are on a p-120 :)

  Currently, the map1a does nothing different than the map1 command, because 
there are currently no arch's whose many small images have been combined into 
one big image.

  X isn't really great about using any hardware accelleration for draws.  What 
this basically means is that for the client to draw stuff, at a lower level, the 
system needs to move memory from the client's (or xserver) memory to the video 
card.  Moving lots of memory imposes some additional costs.  Huge open fields 
probably choke things more because there are yet more things to draw each time. 
  If your standing in the middle of town, for example, only a few squares change 
each tick.  If your in the middle of a dungeon full of monsters with spells 
going off, it is very possible that every square is changing, thus needing a redraw.

  The actual processing of unpacking the map information from the server and 
figuring out what to draw probably has some performance impact, but probably not 
much compared to moving the actual bits around.