Split from here -- Smacky

I though it would be like this:



In case of the accept/decline for example when taking quest accept would be num 7 and decline num 9...
It would be definitely faster than tab+enter+chars
Imagine binding /talk to 0 on numpad and you could do talking in game with other hand free to eat pizza/drink coffee whatever...

Also it would be better if hypertext was not used as it is... so instead of highlited Jahrlen in block of text a "[1] Who is Jahrlen?" on the end would be better... also this would mean players not jumping on other topics during conversation...

Definitely it would be nice if home and end keys worked in the conversation window...

And sorry I didnt have time to check out SENTInce yet, because Im not mapmaking yet...

EDIT: since this was split from the original topic I have to point to my previous post as a reference:
http://www.daimonin.net/index.php?name=PNphpBB2&file=viewtopic&p=55206#55206
http://www.daimonin.net/index.php?name=PNphpBB2&file=viewtopic&p=55260#55260

Gotta say that's horrible.

But practically it's problematic too. The numbering you have takes up 4 characters. Space is a valuable commodity in an interface. Links do not wrap so you have one line to play with (what's that? about 40-50 chars in this font?) and buttons are even worse, where the limit is 10 or 11.

Now I could maybe accept hardcoding (in the client) 1-9 (or maybe just KP1-KP9) to automatically select the first 9 links and, say, - and + (or KP- and KP+) to do the buttons. But this would not be visually represented. The interface would look just the same as it does now but there'd be these extra shortcuts for ingame snackers.

Home and end don't work? No, they don't. I agree, they should.

Also it would be better if hypertext was not used as it is... so instead of highlited Jahrlen in block of text a "[1] Who is Jahrlen?" on the end would be better... also this would mean players not jumping on other topics during conversation...

I disagree completely here. The current system (in-text keywords) works well as long as the scripter takes a little care in how he places his keywords and a sensible conversation navigation system is used so you can return easily from tangents (both things are sorted by SENTInce). IMO a general Back button is not the way to do it which is why SENTInce uses an action button.

hypertext just takes away what I find important - feeling of real conversation...

LOL That's exactly my feeling about a list of links at the end of a dialog.

Although there is a place for links, just as there is a place for hypertext. It's when you rely on one or other too much that you run into problems.

This 'feeling of real conversation' is a big reason why SENTInce emphasises typing more than current interfaces (well, at all would be more -- although you can point and click as well.

Yes. This is the Monkey Island approach (although you can argue it ultimately comes from CYOA books).

The problem (not a major major problem admittedly) with transferring this approach to a MMORPG is that the scripter should avoid putting words into the player's mouth -- that's one thing where the player takes on the specific persona of Guybrush Threepwood but another where the character's persona is up to the player (ie, the RP bit (I say should because there's a balance between freedom of expression and story).

So yes, that's an option in specific circumstances, but should not be considered the way. And no, hypertext can't do it, only links (or free typing) can -- that's no reason to get rid of hypertext. Just use the appropriate method for the specific situation.

Quote

Now I could maybe accept hardcoding (in the client) 1-9 (or maybe just KP1-KP9) to automatically select the first 9 links and, say, - and + (or KP- and KP+) to do the buttons. But this would not be visually represented. The interface would look just the same as it does now but there'd be these extra shortcuts for ingame snackers. Smile

Thats all I want

OK, I just had a quick look at the client source. I'm tired now, but I'll patch it Iand post diffs to devlist) either tomoorow evening or the next day.

It looks as if this wouldn't cause conflict (either doing the main keys or the KP keys or both) because while the initial character of either button is always uppercased (if a letter) and emphasised (interface.c), only the letter keys are actually checked for being pressed (event.c). So perhaps also interface.c should be patched to not emphasise non-letter buttons (and the ib docs should inform scripters not to use non-letters, if they don't already). Anyway, - and + hardcoded to the buttons should be an easy patch to event.c and 1-9 hardcoded to the first 9 links should also be an easy patch to event.c. I can't immediately think of any drawbacks.

My comment in Skype: would it be more intuitive to have KP+ mean accept and KP- decline, rather than the other way around?

Smacky: My original idea was that the controls would be all on numpad for reasons I already stated... so - and + as yes and no is not ideal now thinking of it wouldnt 0 as yes and . as no be better?

yeah thats really good... laptop users definitely shouldnt be overlooked...
I will rebuild my client soon...
will it work OK on both servers with the SENTInce patches?