#5727 closed defect (fixed)
AGI: Predictive Input Dialog
| Reported by: | (none) | Owned by: | digitall |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
The numlock above my numeric keypad at the left side of my keyboard is ignored and instead the numeric keys can only be used as directional movements in the predictive dialog. Also when I use the numbers above my alpha numeric keys a lot of the predictions are ignored, like "open" for instance (6736). So maybe I should have said that the Predictive Input Dialog only works partially.
Ticket imported from: #3309376. Ticket imported from: bugs/5727.
Change History (15)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Checking our code, Predictive Input seems to indicate an AGI game. Please confirm the game and version.
comment:3 by , 13 years ago
The 'canned response' I added earlier is maybe a bit too generic in this case, but the scummvm version and operating system you're using are also particularly important.
comment:4 by , 13 years ago
I think he is using Win32 check this thread on the forums: http://forums.scummvm.org/viewtopic.php?p=67245#67245
I can confirm that the numpad doesn't work with 1.3.0 under Linux/amd64, it seems like it is detected as cursor keys rather than numeric input. Can't say much about the prediction issue he had, since I am not sure how this is supposed to work. (Tested with KQ1 AGI)
Anyway could this be a regession on the numpad handling changes we had? (Can't remember if this was before 1.2.x though).
comment:5 by , 13 years ago
The problem I'm having occurs in all my AGI games and in win32 with ScummVM version 1.3.0. The problem did not occur in version 1.2.1.
comment:6 by , 13 years ago
Notes for devs looking at this: See section 3.15 of README for description of intended behaviour of AGI predictive dialog. To enable on desktop systems, just requires pred.dic in either game data path or extra path.
Looking at the code in AgiEngine::processEvents() (engines/agi/agi.cpp) , AgiEngine::predictiveDialog() (engines/agi/predictive.cpp) and AgiEngine::doPollKeyboard() (engines/agi/keyboard.cpp) together, it is clear why the number pad keys are processed as cursor movements on the predictive dialog. The events are not being flagged as synthetic, so the code in processEvents() rewrites e.g. KP_4 key value to key = KEY_LEFT which is then interpreted on the predictive dialog as a cursor move.
martzuid: Could you please clarify here? Did the number pad work as 1-9, *, 0, # in v1.2.1, as none of the recent changes are likely to have caused a regression here.
comment:7 by , 13 years ago
The other issue with the predictions not matching could either be a data issue with pred.dic or the loader for this in engines/agi/predictive.cpp. The most likely commit here would be : 4b2f92b5e56a1fc273c8c8d2e69b747f938ea92f Max Horn <max@quendi.de> 2011-01-06 21:11:24 AGI: Rewrote predictive code matcher
The new code is simpler, avoids a potential buffer overrun (by avoiding to to use a buffer in the first place), and hopefully has slightly more sane matching properties.
svn-id: r55135 But this will need confirming by bisection, assuming we can work out a specific regression test case
martzuid: Again, could you clarify against the README section 3.15 description of the AGI Predictive Dialog behaviour, what exactly is your observed regression between v1.2.1 and v1.3.0. Thanks.
comment:8 by , 13 years ago
| Summary: | Predictive Input Dialog → AGI: Predictive Input Dialog |
|---|
comment:9 by , 13 years ago
I compared both version 1.2.1 and 1.3.0 today and noticed the numeric keypad behaves exactly the same in both versions. I thought I could use it in the past but apparently I couldn't. Anyway the thing that doesn't work in 1.3.0 but works 1.2.1 are the predictions. For example when I type "6736" with the numbers above my alpha numeric keys I only see those number flicker in the dialog in 1.3.0, but in 1.2.1 the word "open" is predicted.
comment:11 by , 13 years ago
| Owner: | set to |
|---|
comment:12 by , 13 years ago
Corrected Predictive Text Regression in dbaf9e49c7358a2cdcee396bfe3381fd5571a30c.
Looking at allowing Num Pad usage as Numbers, not Directions while in Predictive Dialog.
comment:13 by , 13 years ago
Changed Numeric Keypad interpretation in Predictive Dialog from Cursor Direction to Numbers in b5bb4125690e6277e001d0a1356ff50b2e361578.
I suspect that the last paragraph of Section 3.15 of the README suggested that this behaviour was already the case : "The dialog is fully usable with the mouse, but a few provisions have been made in some ScummVM ports to make its use more comfortable by naturally mapping the functionality to the numeric keypad. Also, the dialog's buttons can be navigated with the arrow and the enter keys."
This was referring to mapping the numeric keypad of handheld devices to the 0-9 keycodes, not the numeric keypad on desktop keyboards, which in AGI games is interpreted as an 8 way directional arrow set, and was still interpreted as cursors arrows in the predictive dialog.
I have changed this as it is more sensible and less surprising to the user with a dialog showing a numeric keypad of 0 to 9 to respond to the numeric keypad values :-)
MartZuid: Closing this bug, but will leave comments open. Please get a nightly development build i.e. master and indicate if you can successfully complete the game now.
comment:14 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:15 by , 5 years ago
| Component: | → Engine: AGI |
|---|
To process your bug report appropriately, please be so kind and provide the following information, if you have not done so yet:
* ScummVM version (PLEASE test the latest SVN/Daily build) * Bug details, including instructions on reproducing it * Language of game (English, German, ...) * Version of game (talkie, floppy, ...) * Platform and Compiler (Win32, Linux, MacOS, ...) * Attach a save game if possible * If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!