8 replies to this topic

[Wizards_Hat]

I'm reporting this problem here after posting a problem in another thread - it appears it's a VP9 only problem

I'm was trying to update a table from vp8 to vp9 and found an issue with key presses from message boxes running over into the game play once the message box has gone.
To illustrate what I mean see the attached table - pressing "enter" causes the lights to come on & then flash in sequence. Pressing 1,2, or 3 brings up that same number of message boxes.

Now, if you press enter to "ok" the boxes there is a difference between vp8 & 9.
Doing this in vp8 has no effect on the lights.
Doing this in vp9 causes the lights to be lit - i.e. the key presses carry over into gameplay

Hope this information is of use.

Regards,
Dan.

Attached Files

•  Testing_message_box_key_presses.vpt   59KB   4 downloads

[Shockman]

I would say that VP8 had the bug, if that's the case. If you are counting the return key presses, you are counting the return key presses.

Just subtract 1 from keypresses for each of the text input responses.

If keycode=2 then MsgBox("Hi"):keypresses=keypresses-1
If keycode=3 then MsgBox("Hi x1"):MsgBox("Hi x2"):keypresses=keypresses-2
If keycode=4 then MsgBox("Hi x1"):MsgBox("Hi x2"):MsgBox("Hi x3"):keypresses=keypresses-3

You have also spelled keypresses ketpresses at the start, but that should make no difference.


Sorry if you already knew that but was just commenting on the behavior.

[Noah Fentz]

Based on the info I've gathered on this, it is indeed unique to VP9, and the dev responsible has been contacted.

[Shockman]

Yes it's unique to VP9.something. So it could be considered a bug I guess. It could however be considered a change of behavior.

Even though VP somewhere<9.7 handled text input functions differently, I think it may be for the best that it was changed.

If you just move those three lines out of the Key input sub, they will still work, and they will still work with the return key without adding to keypresses.

I moved them to keyUP and they work.

What if someone wanted to count input functions as well as plunger functions? What if someone wanted to count the responses, what if they were a map of mission choices?

The way it is now any hit of the return key is going to be counted, but only if it's inside the loop that is counting return key presses.

[Wizards_Hat]

I would say that VP8 had the bug, if that's the case. If you are counting the return key presses, you are counting the return key presses.

Just subtract 1 from keypresses for each of the text input responses.

If keycode=2 then MsgBox("Hi"):keypresses=keypresses-1
If keycode=3 then MsgBox("Hi x1"):MsgBox("Hi x2"):keypresses=keypresses-2
If keycode=4 then MsgBox("Hi x1"):MsgBox("Hi x2"):MsgBox("Hi x3"):keypresses=keypresses-3

You have also spelled keypresses ketpresses at the start, but that should make no difference.


Sorry if you already knew that but was just commenting on the behavior.

Yes it's unique to VP9.something. So it could be considered a bug I guess. It could however be considered a change of behavior.

Even though VP somewhere<9.7 handled text input functions differently, I think it may be for the best that it was changed.

If you just move those three lines out of the Key input sub, they will still work, and they will still work with the return key without adding to keypresses.

I moved them to keyUP and they work.

What if someone wanted to count input functions as well as plunger functions? What if someone wanted to count the responses, what if they were a map of mission choices?

The way it is now any hit of the return key is going to be counted, but only if it's inside the loop that is counting return key presses.

Yeah I understand what you're saying - this "table" was slung together in literally 2 minutes to try & demonstrate the issue.

On the actual table I'm trying to upgrade from vp8 to vp9, the enter key is used to move the game on in a completely different way, and the actual number of keypresses isn't counted at all - basically after the message box, the game is paused with a "press any key" routine used - obviously this buggers that right up - especially as the number of message boxes popping up changes depending on what's happening in the game. Also, the enter key is used for other function at different points of the game

If it makes it clearer, I'm updating my "Hat-Trick" head-to-head football table to a World Cup version...and the message boxes are used to convey results, and info about goal replays etc... The enter key is used to start games, and move the game on in-between player fixtures etc.
I am aware I'm doing things with message boxes (& vp in general) that isn't normally done in any other pinball game - so it doesn't surpirse me that this hasn't come up until now.

Regards,
Dan.

[Shockman]

I see. So have you figured out how to work around it until the behavior is restored in a later version of VP?

[destruk]

When VP9 was multithreaded, the second thread 'ate' the repeated enter keypress as it was supposed to. Since VP is singlethreaded again the enter key from a messagebox popup is being seen by VP again. It's not your fault it doesn't work - the behavior can be duplicated with more than just the enter key so it will need to be fixed. Of course, clicking the OK button with the mouse doesn't put anything into the keyboard buffer.

[destruk]

Well, I didn't get any real help from the dev I contacted about this issue, but I spent a few minutes on it this morning and fixed it.

[Wizards_Hat]

Well, I didn't get any real help from the dev I contacted about this issue, but I spent a few minutes on it this morning and fixed it.

Thanks for your efforts

(Though it comes too late for what I needed - it was really needed for my World Cup table...and as I intend to release it by the end of the week I don't think people will have a new version of vp by then - anyway...I've sort of introduced a work around for it for now - not message boxes, but reels)

Thanks again,
Dan.