snafaru
commented
1 year ago Hi Reiska42.
OK, I have never seen or heard of those issues. I will test this weekend. Concerning the second issue I always thought it displayed “Disarm Failed” and you try again... but you say it just says nothing after an incorrect identification... I will take a look at the code...
I am curious how many “unknown” issues have slipped under the radar that will be reported to me with this release!
Thank you, your feedback is much appreciated.
Eric
From: Reiska42 @.> Sent: Thursday, March 30, 2023 10:03 PM To: snafaru/Wizardry.Code @.> Cc: Subscribed @.***> Subject: [snafaru/Wizardry.Code] Problems with disarming chest traps (Issue #3)
I've observed two issues with chest disarming in the March 23 release, one of which is also an issue with the original Sir-tech build of 1/22/1982 and one which appears to be unique to this release.
The issue that also occurs in the original final Sir-tech build is that the text input for the name of a chest trap isn't properly bounded at 14 characters and will allow you to continue typing outside of the window frame; continuing to enter text will overwrite the "# CHARACTER NAME" text on the status display. Upon entering more than 25 characters, the display will corrupt entirely (in AppleWin it reverts to the last text mode screen to be displayed). If you press Return at this point, the game will recover (but with some lingering display corruption); if you continue to enter text the game will appear to have hung, but in fact the game does not actually appear to hang until 36 characters have been entered. (I was able, for instance, to type 12345678901234567890123456789012345 for a trap name, hit return, and have the game screen recover, but adding one more character onto that appears to cause a hang, at least on AppleWin.)
The second issue I've observed is that in some cases, after having a thief attempt to identify a chest trap, when they identify the trap incorrectly and the player then goes on to enter the name of an incorrect but valid trap in the disarm prompt, instead of blowing up the chest trap as expected, the disarm will just fail with no message printed, and the player can continue attempting to disarm the chest with different inputs until the correct trap is tried. In my limited testing this only seems to occur after an incorrect identification; entering an incorrect but valid trap after a correct identification produces the expected "OOPPS!" result, as does entering an invalid trap name in any circumstance.
— Reply to this email directly, view it on GitHub https://github.com/snafaru/Wizardry.Code/issues/3 , or unsubscribe https://github.com/notifications/unsubscribe-auth/A43GBF5JRBIM6LZTGFUQJ43W6Y3MFANCNFSM6AAAAAAWOBKUNI . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/A43GBF56SE4LMWOQXL62IVDW6Y3MFA5CNFSM6AAAAAAWOBKUNKWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGEQXD2I.gif Message ID: @. @.> >
Reiska42
I've observed two issues with chest disarming in the March 23 release, one of which is also an issue with the original Sir-tech build of 1/22/1982 and one which appears to be unique to this release.
The issue that also occurs in the original final Sir-tech build is that the text input for the name of a chest trap isn't properly bounded at 14 characters and will allow you to continue typing outside of the window frame; continuing to enter text will overwrite the "# CHARACTER NAME" text on the status display. Upon entering more than 25 characters, the display will corrupt entirely (in AppleWin it reverts to the last text mode screen to be displayed). If you press Return at this point, the game will recover (but with some lingering display corruption); if you continue to enter text the game will appear to have hung, but in fact the game does not actually appear to hang until 36 characters have been entered. (I was able, for instance, to type 12345678901234567890123456789012345 for a trap name, hit return, and have the game screen recover, but adding one more character onto that appears to cause a hang, at least on AppleWin.)
The second issue I've observed is that in some cases, after having a thief attempt to identify a chest trap, when they identify the trap incorrectly and the player then goes on to enter the name of an incorrect but valid trap in the disarm prompt, instead of blowing up the chest trap as expected, the disarm will just fail with no message printed, and the player can continue attempting to disarm the chest with different inputs until the correct trap is tried. In my limited testing this only seems to occur after an incorrect identification; entering an incorrect but valid trap after a correct identification produces the expected "OOPPS!" result, as does entering an invalid trap name in any circumstance.