Flippers intermittent lock up or don’t respond

[mazjohn]

Flippers fail to fire or intermittently lock up… the issue Occurs with VpinMame build 917 with the following table written for 10.7, run with Vpx X64 build 935 running in 10.8 window mode.

Andromeda v4.0
https://www.vpforums.org/index.php?app=downloads&showfile=14871

• Update: I tested the above scenario extensively with VPX-X64 and VPX-X64-GL builds, and the GL version does not experience the flipper lock up issue- it only occurs on the X64 build of VPX... This leaves me with no idea if the issue lies with VPX or Pin-Mame, but it is certainly occurring with the X64 build consistently after a few plays with this table.
  **Update 2 … I next updated Vpx x64 to build 940 and vpinmame to build 918 and it seems the issue with this particular table is now gone. I also added the table1_init line as suggested to the Vpx goldeneye release as posted in another closed thread which has resolved the same.

I am only reporting this since I recall there was a recent flipper issue recently resolved/ closed with WOF. The issue didn’t happen for a game or two, then started to happen quite a bit where the flippers randomly stay stuck in the engaged position or sometimes intermittently fail to trigger. This Also happened again eventually after restarting the table.

[francisdb]

Link to possible related mentioned issues vpinball/vpinball#1536 and #196

I could not reproduce this here (on standalone). Even without adding the vpmInit Me.

[toxieainc]

@mazjohn Please retest, this should be fixed by now

[mazjohn]

Left flipper stuck engaged until pressing left flipper button then eventually released with following table… Vpx x64 build 1942 and vpinmame build 919…. https://vpuniverse.com/files/file/4626-lord-of-the-rings-hanibals-4k-edition…. happened a few times after coin entered before ball launch… game was very playable otherwise.. 4/7/24 also happened intermittently with this new original table: https://vpuniverse.com/files/file/19404-dark1986-original-2024/… running in 10.8 window mode with same builds as above

[toxieainc]

@vbousquet for vis

[WaRcLaWz]

I get the sticky flippers issue all of the time since 10.8 beta x, usually with table ROM's in the year range of 1979-1983 for some weird reason. The fix for me has always been to just right-click the DirectB2S backglass of the affected table and deselect the button for run as an EXE. Sounds counterintuitive I know, but it works for me every single time, and the tables will behave much faster/smoother. I know... doesn't make sense.

[vbousquet]

Perhaps updating B2S to the latest version (which contains update regarding latest PinMame change) may help : B2S 2.1.1

[WaRcLaWz]

Perhaps updating B2S to the latest version (which contains update regarding latest PinMame change) may help : B2S 2.1.1

I will try that out and report back my findings. I have a few tables that will do it immediately as soon as I switch back to EXE mode :)

[WaRcLaWz]

After installing B2S 2.1.1 it seems the issue of sticky flippers may be gone.

EDIT: The sticky flippers are still occurring, so I have reverted back to deselecting the option to run the DirectB2S as an EXE. Once I do that, the flippers are fast and smooth consistently. On another note, it seems the new 2.1.1 version has affected some of my backglasses to where they will not light up any longer.

[toxieainc]

@JockeJarre for vis

[sverrewl]

I see that you mention different architectures being tested, so, I don't expect that this will be related. But, from years of experience. Starting over with a fresh nvram has often solved this problem on my end.

[JockeJarre]

Sorry, I cannot see this behaviour in any of the releases

[mazjohn]

Fast forward, quick update since submitting this bug- as of today’s date running latest B2s server release 212 with current Vpx 10.8 x32/64 beta4, combined with a current Vpinmame sc1001 build, have not seen the flipper lockup issue return in random play. I will be reloading some of the past tables that had the stuck flipper issue to further verify…. I can also confirm, The andromeda table was fixed with the above patch/ latest JP release

[michroch]

I got the same problem on some tables like Andromeda (Game Plan 1985) v4, the problem of slow flipper and flipper stuck up is when I double click the table directly in the tables file. If starting VPX program first then choose the table in question, everything is fine.

Flipper sticking up also happens when starting the table in Popper 1.5.
So the only way for me to have fast and smooth flippers is to right click on the backglass and deselecting the option to run the DirectB2S as an EXE like WaRcLaWz said.

Open the table directly in the tables file without the B2S, flippers are fine.

I'm up to date with VPX GL 10.8, got the latest Vpinmame V3.6.0.1004 and latest B2S 2.5.0.298

Table : https://www.vpforums.org/index.php?app=downloads&showfile=14871
B2S: https://vpuniverse.com/files/file/11306-andromeda-game-plan-1985-alt-backglass-with-full-dmd/

[Ltek]

I'm working on a table based on the Swords of Fury (Williams 1988), and it has major issues with sticking flippers. You can get it here if you want to test it... you do not need the PuP for it to run just fine.

• VPX 10.8 build 1975 DX64
• VPM 3.6.0.988
• No DirectB2S file running at all, uses PuP Pack.

I've seen a few posts about not making PinMAMETimer.Interval=1 but that is not helpful at all since it doesnt state the proper interval?

What are the correct settings?

Currently...

	PinMAMETimer.Interval = -1
	PinMAMETimer.Enabled = 0
	On Error Resume Next
	vpmInit Me

[sverrewl]

I think that this url has a lot of examples for how to script tables.

https://github.com/sverrewl/vpxtable_scripts

More good info that everyone fiddling with table scripts should read

https://www.vpforums.org/index.php?showtopic=4261

Obviously, in the few lines you've shown, you are requesting and interval that is never enabled. Doesn't really makes sense, just from those lines - does it ? A value of -1 means it runs as fast as possible, basically. Be careful setting other timers too low. It will introduce all kinds of stutter/lag. Put table into lock and unlock it again and you will get some basic checks done to your code.

Not a pinmame issue.

Question belongs to VPU or VPF - not github imo.

[Ltek]

@sverrewl this issue is posted as a bug, by others stating it has happened with many ROM tables. It may not be a VPX bug, it may be VPM, who knows but I added additional evidence (including a full table) that this bug always shows itself within a min or two of play, and just keeps happening. I and VPW testers have seen this table show sticky flippers constantly... not just a little, a lot.

also re: PinMAMETimer.Interval = -1 ... I dont know if the setting is causing it. -1 is the recommended setting from VPW team. I was only stating it is the setting I'm using (as does all VPW tables) and asking if that is somehow causing the issue -and- what is the recommended setting from the VPX devs... this is the correct place to ask VPX expert developer-level questions especially in the thread specifically about the bug you are trying to solve.

AND... the thread from Destruk states... "PinMAMETimer.Interval=PinMAMEInterval -- this line grabs the value of PinMAMEInterval from core.vbs and resets the PinMAMETimer to the new interval value. By default this is 1."
and very clearly in this related post, @vbousquet states NOT to set the value to 1(though he never states what it should be)...
vpinball/vpinball#1536 (comment)

[sverrewl]

Yeah. Well, @vbousquet didn't tell you to disable the flipper keys when it hits the drain. How are you supposed to play mb on this mod ? Like I said. Issue belongs to regular forums.

[Ltek]

Yeah. Well, @vbousquet didn't tell you to disable the flipper keys when it hits the drain. How are you supposed to play mb on this mod ? Like I said. Issue belongs to regular forums.

my table code doesnt disable flippers when it drains. I've played the table a few times a day for the past 5 days. No idea what 'mb' is.
Plus your comment is not on the topic - re: flipper stuck bug.

I dont understand why you are complaining that I posted an example of a bug other people have validated exists. If you dont have value to add to help solve the bug cool, but no need to make it off topic or tell us to go somewhere else where bug reporting is not relevant

[sverrewl]

mb - ok, short for multiball, which this machines has. You posted this as a bug, instead of understanding your own mistake. It has nothing to do with the topic, except that you purposely are disabling the flippers - forcefully making the flippers lock up yourself. I see that you tell me that you aren't - but, yeah ... your wrong.

VPX and Pinmame is complex software. Requires a lot of time from volunteers, we should all strive to let them code instead of having to shift focus onto things that isn't valid.

That is why I ask you to post in forums first.

I haven't checked the other reported problems in this thread, they might be valid.

[Ltek]

mazjohn posted this bug back in March, and others posted it in other tickets. I simply added to it. They didn't close the ticket so its likely still a bug.

If you can really help, then please point to the exact code causing my problem and how to fix... it would definitely be appreciated. If you cannot, you're just wasting everyone's time.

If you mean the code where I disabled flipper keycodes, that doesnt matter I have since disabled ALL the flipper keycode and it works, yet still has the stuck flipper bug.

This is a ROM table so flippers are triggered with Solenoids callbacks. The flipper work without keycodes via cab buttons -and- keyboard. I know because I play it on the cab -and- test via remote desktop with keyboard.

[sverrewl]

Best take this back into forums. It is your code that is faulty. I told you, you are setting a flag - preventing key up and down to work. This gives non responsive flippers in either up or down position. I recommend that you look the latest release of Sword of Fury for properly set timers and through usage.

I haven't spent more than a minute figuring out what the issue is on your mod, and I haven't looked in details to the latest release for that table either. All I can say, it is best to study work from Sixtoe, Apophis or any of those VPW magicians on how to proper create a table - deleting and adding balls is old school stuff and has and still is often a root cause for oddities.

Again, your table mod is not related to the rom, or should I say, it could be - but, you are masquerading it by your code.

[vbousquet]

Regarding this issue, I think there have been a few different things that may make things difficult to understand. On my side, my understanding is the following:

• there used to be a combination of VPX/VPM/B2S version that would cause this issue. So first, these needs to be updated to latest (at the time of typing this message: RC4 for VPX, 2.1.2 for B2S, latest master for VPM),
• the way input is handled is somewhat hacky for VPX GL version (2 message pump running in parallel inside VPX eventually stealing messages from each other, with a message pump running as well inside VPM for fast flips). This needed some deeper change, so I do not plan to fix it for VPX 10.8 (was already like that in VPVR) and the fix for this would be in 10.8.1 (already in, but 10.8.1 is in pre-alpha state and I would strongly advise against using it).

If I'm not missing anything, I would say that the situation (with a known bug for VPX GL) is ok for the 10.8 release. If it's something else, it would need to be looked at.

[Ltek]

I'm getting stuck flippers with DX build. Interestingly, happen far less often with nFozzy flipper code than it did with JPSs.
My system...

• VPX 10.8 build 1975 DX64
• VPM 3.6.0.988
• No DirectB2S file running at all, uses PuP Pack.
• Launching directly with VPX, not popper
• happens with both Full Screen Exclusive and Window
• happened with both JPS's original flipper code, and with nFozzy (added ~12 days ago)
• happens with staged flippers and non-staged (staged flipper code just added 2-3 days ago)

If you want to see it first hand (latest build, beta 23)...
https://mega.nz/file/Vz0AiLZb#ZmADiqoEA9j6SbBfjqKBpWE45Vty8AmMXcU0LuQY0iA