Hi Arvid, I have discussed these issues in some detail in the IRC channel. I believe I can answer your questions and propose solutions, sadly I lack the talent to make any changes.
> There are a few things that we are both annoyed with though. One is the key press handling. If I "walk" by holding a direction key, it seems key repeats are queued so that the PC continues to walk long after the button is released. Usually into a trapped door... > > Similarly with search: hold down the search key to make a thorough search of the immediate area (say, 4 x 5 searches), and after the key is released, and additional 2 x 5 searches or so are made before the PC can do anything else. The delay is a couple of seconds and makes the client feel really sluggish. This usually happen when something horrible shows up, like a "sweet little girl". (She killed me. Oh, the shame!) This is client side effect. The client will store up to 10 commands before 'overflowing' and ignoring further commands. For very slow actions this is very noticeable. When a player starts running the client will continue to send running events (i think this is actualy server side, sorry beyond my knowledge) until an interrupt is sent to stop. The solution I have discussed was that the client should queue commands as long as they are the same action as per the current system, however, if an alternate action is pressed it should interrupt the queue and immediately do this action instead. I believe it was added to someones to do list right down the bottom but I agree that this seems to be a really powerful aspect of crossfire which adds a laggy or delayed feel to an otherwise rapid paced game. I suggested this might be a client setting that users can set a preference for. Basically, yes I agree with your concerns and questions that this aspect of crossfire could be improved and I believe the current bottleneck is simply time. The age old #crossfire response: "sure, code it". In the short term I found it very valuable to understand how the client works, I have changed the way I make key pressed to minimize such "sweet little girl" scenarios as you have described :). Regards, dnh On Thu, Oct 24, 2013 at 11:58 AM, Arvid Brodin <arv...@kth.se> wrote: > I recently started playing Crossfire (on a private server, together with > my girlfriend, if you can believe it! :). > > It's a surprisingly addictive game! And we're slowly finding nice features > like auto-pickup and -mapscale. So thanks! :) > > > There are a few things that we are both annoyed with though. One is the > key press handling. If I "walk" by holding a direction key, it seems key > repeats are queued so that the PC continues to walk long after the button > is released. Usually into a trapped door... > > Similarly with search: hold down the search key to make a thorough search > of the immediate area (say, 4 x 5 searches), and after the key is released, > and additional 2 x 5 searches or so are made before the PC can do anything > else. The delay is a couple of seconds and makes the client feel really > sluggish. This usually happen when something horrible shows up, like a > "sweet little girl". (She killed me. Oh, the shame!) > > Is there a reason not all buttons are "level-triggered" during > non-text-entry? I've taken a look at the code, and it seems the server > handles run/fire differently than other commands? > > Also, it would be great to split run into attack and run, so that running > into doors does not make one sick (and only trying to open them with > "attack" does). (And I accidentally slaughtered a cleaning lady the other > day for the same reason.) I.e. only direction key == move (and move only) > while pressed. And CTRL modifier for attack, SHIFT for fire, as today. > > > Another somewhat related thing that really confused me in the beginning > are the built-in keybindings. These do not show up in the Keybindings > dialog. Somewhere in one of the beginner's maps, I think I was told to bind > "use_skill find traps" to something - and I naturally chose 's'. And was > told: > > "Warning: Keybind search may conflict with new binding." > > OK, now just what does that mean?? (I understand it now, but as a complete > beginner that was just weird. Hmm, it's still weird - why have two commands > for the same thing?) Why not just use default keybindings instead of the > built-ins (i.e. if no keybindings file was found)? This would mess things > up a bit for people upgrading their client, but should be easily fixed by > binding 'a', 's', 'd' etc. > > > > Maybe I can take a look at these things. Would there be interest in > patches, or are there reasons things are like they are? > > > -- > Arvid > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire >
_______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
