Interface differences

[beowuuf]

There are two interface differences that have remained in RTC, and I wandered why they were chosen

a) Not being able to click on party icons while the hand icon is full. It's is very annoying, especially in combat where hands get filled with potions, swapping weapons, etc to not be able to quickly spin or swap characters while doing something else. It's a strange restriction considering that even doors can be opened with an itewm in the hand (not possible in DM).

b) Key stroring - being able to press keys and knowing that you will go ahead that many spaces. In RTC areas with intense activity like the Diamond Edge trap are impossible to negotiate as pressing keys can be ignored if a spell interrupts, or worse a long key stroke acts twice and the party thump into a wall. Same with moving around in combat, trying to manuever round a creature and finding that the party instead stop short. It makes movement an all consuming task at times when it's nice to be able to concentrate on other thigns.

That was all, I seem to recall you hinted that there was a reason for the party icon thing, and just wandered why : )

[George Gilbert]

The party icon thing is bad design

Basically you can only hold one object in your hand at any one time and the character icon counts as an object. I've therefore deliberately blocked the ability to pick up the icon when you've already got something in your hand, as you've got no-where to put the object you were first carrying down.

It's a trivial point, but would require a reasonable amount of code to change it!

The second point (key pressing) is an empirical choice. An earlier version of RTC had keys being stored, but people here didn't seem to like it so I removed it...

[Rick]

Hmm.. buffered keys - why not putting it as an option? Like sound on/off etc.

[beowuuf]

Thanks for changing the party icon thing! Weee, I can click on them during combat...mmmmm

As for the key storing/buffering thing, I remember being confused as to what was what when it first came up...maybe time to put it to a vote again...i'm guessing coding for both might be a pain?

It would be nice if key/mouse presses were stored though, so

keystroke (turn)
keystroke (move forward)
mouse click (left, in spell area)

would turn me move me fire the spell, rather than as would happen now possibly blast a fireball in my face if i was facing a wall, then turn me cause i was overloaded, then nothing else

As for buffering (keeping finger on key means that the time pressed is converted into appropriate no of steps right?) i think that isn't needed, as i think people play with one press = one step, and don't try to move fluently like in an fps

[amaprotu]

I beleive the original problem was that it was queing key strokes way too fast, hitting a key hard could send you ahead two or three paces. The solution George used was to cut out key cacheing all together, you can't do anything unitl the current key press action is done.

I would like to see some form of key caching that is slow enough not to be annoying and fast enough not to be annoying. Thats the problem though =p

I would rather it be the way it is than the way it was (I was constantly runing into walls).

- Amaprotu

[Rick]

Well, the original DM had an interesting solution.

Anihilate completely key repetition. that way, until you have lifted the "up key" (which curiously was the 5 and not the you don't walk 2 times, just one. This way you have to press up five times to advance five squares.

In windows this can be handled with the event stuff (in dos it's also possible, in pascal for example you had the OnKeyDown event.

You wait for a key to go down, queue it. That way if the key STAYS down, you won't queue it again. (If you want a certain amount of repetition, just add a timer. If the key stays pressed for x milliseconds, just queue it again).

Ah, good old DOS

[Rick]

Errata.
I said:

I should have said: eight)

(darn emoticons!)

[beowuuf]

yeah, it's this i like the best...i've just never kjnown how to say it