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.