357 replies to this topic

[BorgDog]

But, they'll still hit the ball. Even wonkier.

Since you don't need flippers when there's no ball in play, disabling them is simple. You can even animate them by comparing the active state when fired, for games like TAF that animate them.

This is all pretty simple scripting, really.

Unless there's a way to make them uncollidable, I definitely foresee an issue with two sets acting independently.

Sent from my SM-G930T using Tapatalk

 

I suggest you read the thread.

[Noah Fentz]

But, they'll still hit the ball. Even wonkier.

Since you don't need flippers when there's no ball in play, disabling them is simple. You can even animate them by comparing the active state when fired, for games like TAF that animate them.

This is all pretty simple scripting, really.

Unless there's a way to make them uncollidable, I definitely foresee an issue with two sets acting independently.

Sent from my SM-G930T using Tapatalk

 
I suggest you read the thread.

I have, three times. You can get off my shit now, thank you.

I also read this ...

As the main difference is there when you are pressing and releasing the flipper button, its very hard to spot that the ball does not perfectly match the visible flipper collision as everything is in very fast motion at that point. But i leave that up to you guys to judge.

I believe this presents the idea of having two identical flipper sets, one invisible. That's simply not going to work if they act on different timings.

Do whatever the hell you want. I'll do it differently.

Nice attitudes around here. Don't know why I even bother participating.

Sent from my SM-G930T using Tapatalk

[BorgDog]

Reading the entire topic would probably be a good idea. 

Sent from my SM-G930T using Tapatalk

 

You're the one that started that shit.

 

 

 

As the main difference is there when you are pressing and releasing the flipper button, its very hard to spot that the ball does not perfectly match the visible flipper collision as everything is in very fast motion at that point. But i leave that up to you guys to judge.

I believe this presents the idea of having two identical flipper sets, one invisible. That's simply not going to work if they act on different timings.

Do whatever the hell you want. I'll do it differently.

Nice attitudes around here. Don't know why I even bother participating.

Sent from my SM-G930T using Tapatalk

 

 

Yes, one is invisible and the other doesn't act on the ball at all.  The key to it is that the one that acts on the ball (the invisible one) is the one that responds when we press the button and not waiting for vpm to respond.  The one that visually moves is controlled by pinmame so only when pinmame says it can move does it.  Most of the time there will only be that slight lag difference between the two and on fast moving shots you won't be able to see the difference, but the ball will respond closer to when you press the button.  

 

 

But, they'll still hit the ball. Even wonkier.

Since you don't need flippers when there's no ball in play, disabling them is simple. You can even animate them by comparing the active state when fired, for games like TAF that animate them.

This is all pretty simple scripting, really.

Unless there's a way to make them uncollidable, I definitely foresee an issue with two sets acting independently.

Sent from my SM-G930T using Tapatalk

 

And yes, one of the sets is made uncollidable as toxie stated in his post, that would be the visible one. 

Edited by BorgDog, 18 October 2016 - 03:21 AM.

[Noah Fentz]

Really? I'm not the only one to notice your short and dismissive replies to each of my posts.

I came into this to share my experience and hopefully improve the VP experience for everyone.

I leave the discussion rather disgusted with the notion that it needs to suit some 'need' I have and met with attitude.

How disappointing.

Considering I've been doing this 8-12 hours per day, at least 5 days per week, for the last 6 years, you'd think my findings would actual count for something. Guess not, eh?

Instead of the attitudes, someone could have merely pointed out invisible=uncollidable.

How simple that could have been.

Have fun, guys. I'm out for a while.

Sent from my SM-G930T using Tapatalk

[BorgDog]

i just tested the idea i mentioned, that was inspired by Thalamus' one (actually exactly the other way round that he suggested, as i did not get his intention first ):

 

1) have one flipper that is not visible and that is enabled, wired to the keyup/keydown

2) have one flipper that is visible and that is not enabled, wired to the solenoid callback of VPM (which also is wired to all the sounds,DOF, as usual)

3) profit!

 

this of course only works if the table does NOT need to turn off the flippers during gameplay itself (like TOTAN, as the player can still influence the balls then, even though at least he cannot see what he's doing )

and if the table does NOT trigger the flippers (like MB, TAF)

 

which still means that a lot of tables could actually use this in practice without any issues!

 

to modify an existing table:

1) copy/paste each of the flippers on the playfield

2) for the original versions of the flippers, disable the 'enabled' checkbox

3) for the new/copied versions of the flippers, disable the 'visible' checkbox

4) in the script, search for the functions that already have some keyboard handling (like Table1_KeyDown and Table1_KeyUp) and insert something like this (if the new/copied flippers are named LeftFlipper2 and RightFlipper2):

Sub Table1_KeyDown(ByVal keycode)
    ...other code, but before vpmKeyDown(keycode)..

    If keycode = LeftFlipperKey then LeftFlipper2.RotateToEnd
    If keycode = RightFlipperkey then RightFlipper2.RotateToEnd

    ...other code..
End Sub

Sub Table1_KeyUp(ByVal keycode)
    ...other code, but before vpmKeyUp(keycode)..

    If keycode = LeftFlipperKey then LeftFlipper2.RotateToStart
    If keycode = RightFlipperkey then RightFlipper2.RotateToStart

    ...other code..
End Sub

to see the difference here the two extremes i could get (minimum and maximum delay, visualized by having both flippers visible for this test)

 

@toxie  Just tried this on the AFM that seems to give me some of the biggest lag, much improved response feel with this setup, and as suspected unless I concentrated on looking for it I could not tell that the flippers that were moving were not the ones moving the ball, and then of course I lost the ball as i wasn't watching it  

 

And just for fun I tilted the game and batted the ball around a bit with invisible flippers.

Really? I'm not the only one to notice your short and dismissive replies to each of my posts.

I came into this to share my experience and hopefully improve the VP experience for everyone.

I leave the discussion rather disgusted with the notion that it needs to suit some 'need' I have and met with attitude.

How disappointing.

Considering I've been doing this 8-12 hours per day, at least 5 days per week, for the last 6 years, you'd think my findings would actual count for something. Guess not, eh?

Instead of the attitudes, someone could have merely pointed out invisible=uncollidable.

How simple that could have been.

Have fun, guys. I'm out for a while.

Sent from my SM-G930T using Tapatalk

 

See and yet again instead of actually reading what was written you have your own conclusions because you know it all after your days and weeks and years.  I'm frankly rather disgusted that you are so condescending and dismissing of anything anyone else might say because you obviously know more.

 

Once again the invisible one does the colliding, the visible one does not hit the ball.

[Noah Fentz]

Wow, dude, you're unbelievable. I treat everyone here with the utmost respect.

I don't know what your issue is with me, but since I'm not around much, I'm going to call bullshit on that. Feel free to PM with your grievances, if you're so inclined, and I'll be happy to address your concerns.

As far as me thinking I know it all, nothing could be further from the truth. That's your own misconception, sorry. I think it's clear I don't, as evidenced by invisible/collidable.

Nonetheless, I DO know the two flipper thing isn't going to work. The more active the flippers, the more 'off' their going to end up. You will definitely want the visible flippers doing the work.

 

[Ben Logan]

Very cool idea, toxie!  
 
@Thalaumus - here is my understanding:
1) There are invisible flippers that will hit the ball as soon as you press the flipper button, i.e. immediate flipper response that we are all looking for  NOTE: These flippers are invisible but they will hit the ball around
 
2) There are a 2nd set of flippers in same location.  These flippers are visible but not enabled (they can not hit the ball around.  balls would pass right through them).  These are connected to the vpinmame solenoid call.  NOTE:  These are visible but can not hit the ball at all
 
3) So, you get the lag free flipper behavior with the invisible flipper, but visually the flippers only move if the vpinmame solenoid moves them.  So, when game is off, the flippers appear not to move at all, but really, the invisible flippers are rotating everytime you press the flipper button

I hesitate to say it, but in order for me to experience snappier flippers, my brain needs my eyes to see reduced lag between pressing the flipper button and the onset of flipper movement. "Snappier" is a visual phenomenon related primarily to flipper movement, and secondarily (but still totally importantly) to ball trajectory.

I'm thinking we have this backwards: The flippers that "hit the ball as soon as you press the button" should be the set that is visible and collidable.

If set this way, is the problem that we'll still see these flipping if we press the flipper buttons post drain?

If that's the problem, could you guys code for drain detection?

Perhaps you could still have two set of flippers: one visible and one invisible. Have invisible rollovers at drain entry and plunger trough that toggle which set of flippers is visible vs invisible. I.e. Make the fast flippers (Visible and collidable) active during gameplay. Code to transfer visibility to the slow (but vpinmame connected) flippers upon drain (which will be frozen by the ROM at this point, so who cares if they're slow). Re-enable visibility of faster collidable flippers when ball enters plunger trough.

Edited by Ben Logan, 18 October 2016 - 05:38 AM.

[Drybonz]

I'm not the smartest guy on the block, and I don't want to stifle the progress of what is going on here... I think it's good discussion and I hope it leads to something good... but I'm wondering if all of these techniques to make the flippers looks like they have less delay are not going to be as effective, or realistic, as actually reducing the delay.  I guess that would require things like good gaming pc hardware, or reducing required hardware through streamlining the operation of the game.  

 

Again, I don't want to stifle progress, and I'm interested to see how these ideas pan out and work, but I just wanted to throw this back into the ring for consideration.

[toxie]

@Noah: Could you please post a table mod here then please that uses your idea? Or at least the parts of the script that need modification?

Cause i do not get at all how the 'simple scripting' part would work that you suggest with your scheme. I only could come up with a rather complicated one, and that would not even handle most of the weird cases. I think BorgDog just wanted to explain the problems here, so an actual code snippet could really help here from your side.

 

@Ben: There is also always still the solution that nFozzy did here: http://www.vpforums....=36111&p=359896

But its a bit harder to implement, thats why i was searching for a rather simple solution that could be added to existing tables rather quickly.

And i disagree on the visual part here, as the important thing IMHO is the ball movement that one reacts to. The actual animation of the flipper and the reaction of the ball to that one is so fast that the eye should not be able to spot the difference really in that moment.

Did you actually try my modifications from http://www.vpforums....=36111&p=360100 on some table? Can you actually spot it like you predict?

 

@Drybonz: There is not that much one can do here, as there will always be a roundtrip necessary to VPM and back. But maybe DJRobX could still come up with something, as he suggested that there could be some faster response possible (but i doubt that it could be instantaneous, but maybe halfing the ms necessary).

Edited by toxie, 18 October 2016 - 07:16 AM.

[jdark]

Stupid question: why don't you resolve the flipper lag problem in VP10 code, so it works like in VP9.

Instead modifiying every table with not 100% reliable scripts?

[toxie]

Because everything that VP9 had to make flipper speedier should already be there in 10.2. As said, try for example Dr.Dude, which has fast flippers. Also see http://www.vpforums....=36111&p=360057

 

And, btw, you can even use these 'not 100% reliable scripts' also in VP9 to remove the VPM<->VP round trip there! As this exact same problem exists since the very very beginning of VPM and VP!

 

 

Can we please get back to suggesting useful solutions and actual testing of the suggested solutions in here? It seems like a lot of people in here just do not even want to try the things that are posted in here. WTF?

[Drybonz]

What's the best table for testing?  Attack from Mars?  I'll plug in the script later today and try it out.

[jdark]

As is said, stupid question

 

I will try it tonight.

[toxie]

What's the best table for testing?  Attack from Mars?  I'll plug in the script later today and try it out.

 

Don't know. Potentially any table, as all should feature roughly the same VP<->VPM turnaround time.

[Ben Logan]

Guilty as charged here, Toxie! I'll test your idea and report back.

[Ben Logan]

First -- My apologies for commenting on Toxie's implementation of Thalamus' idea before testing. Bad form on part!

 

I tested for a few hours this morning with three VPX tables: Super Mario, Bad Cats, and Surf n Safari. I'm happy to report Toxie and Thalamus' technique works really well in most respects! I was pleasantly surprised. 

 

The good: 

 

* Flippers really feel snappier when it comes to batting the ball around the table. 

* The eye (my eyes, anyway) does a good job of compensating for the visual gap between the ball and the visible flipper. Your brain "fills in the blank" so to speak, surprisingly effectively 

* Visual flippers freeze at beginning of table startup, during ball drains (on tables that call for this), and after game ends

 

 

I think it's a great option! Just a few caveats: 

 

1. Flippers still look sluggish with this approach. I know we're primarily wanting to please ourselves, and not folks who play real pinball mainly. But, for argument's sake: When someone who plays a lot of real pinball steps up to the VP cab for the first time, the first thing he or she is going to do is make a few "test flips" while the ball is still in the plunger trough. The old conclusion will quickly be drawn: "VP flippers are noticeably slower than real pinball flippers." The fact that the invisible set of flippers that actually hit the ball are indeed not slow, won't change the rash conclusion on the part of the new player that VP flippers "are sluggish." 

Personally, I love the look of having vpinmame code-bypassed visible flippers. They look and feel snappy as hell! They just don't freeze, ever. 

 

2. Drop catches can look strange. If you watch the video below demonstrating drop catch on a real table, you can imagine why differential between the faster invisible flipper and the slower visible can make for less than perfect visual experience while drop catching...

 

 

Drop catching (not that I think I'm a pro at this -- I'm totally not!) is all about meeting the downward traveling ball and gently cushioning its trajectory back down to flipper at rest position to gain control. During a drop catch the flipper and the ball "become one" for a brief instant and do a little coordinated dance together. 

 

As such, I experienced this look a few times during drop catches with the "Two Sets of Flippers Code:"

 

 

The ball appeared to "sink" into the visible flipper. What's happening here (I think) is...

 

* Invisible flipper has already "met the ball" and made contact at apex of flip

* Flipper button has been released for drop catch and is in process of "guiding the ball" back down to flipper at rest position

* Slower visible flipper is still traveling upward (remember - it's being drawn a few frames behind the faster invisible / active / enabled flipper that has already made actual contact with the ball). Or, slower visible flipper hasn't began it's process of traveling back down to rest, when the faster invisible flipper is already en route. This often results in something like the image above (which I threw together in GIMP to illustrate, hence the HUGE ball!). The ball appears to "sink" into the visible flipper -- just an illusion, since this flipper isn't actually active (balls travel right through it). 

 

 

Personal Conclusions: 

 

* I absolutely LOVE this thread. I'm thrilled so many creative and brilliant people are contributing. I think it's ok if it gets a little messy. After all, we're passionate about this stuff! 

 

* I prefer the "rotate to start" code that bypasses vpinmame (and speeds up flippers) to be active on the visible flippers. I don't mind that this means flippers still activate at game startup (before you've started the game), remain active during drains, and after game ends. It's just a reminder to me that smart people contributed a hack that speeds up flippers tremendously! 

 

* It still seems to me that some sort of drain detection (a rollover target) could toggle between visible / invisible flippers at drain if we want them frozen at drain or before game starts. Visible / invisible flippers could be re-toggled to make faster flippers visible upon plunger activation. I realize this idea would carry more weight if I coded an example myself! I hope to get there one day. 

 

Edited by Ben Logan, 18 October 2016 - 06:22 PM.

[toxie]

Now we're talking! Good investigation and testing! Thanks!

 

I also think that having a whole bunch of options is the best to go for, so this thread (and the many many other older ones that most likely exist somewhere here) will be helpful to all authors and even some users.

And i also hope that after DJRobX will put his VP<->VPM scheme into place that the delay will get even lower.

[Drybonz]

Ben, could you please send me your script for that table (or AFM if you have already done it)... I am too stupid to get the script in the right order and I keep getting errors.  Just want to test.  Thanks for the help.

[Ben Logan]

Sure, Drybonz. I'll send it when I get home from work today. I had to experiment a bit to get it working, myself! 

 

Stumbling blocks I ran into before getting it operational: 

 

* Forgot to assign new invisible flippers to their own layer (for clarity regarding which flipper you're selecting when making changes). Do this by right clicking each of them.  

* Forgot to rename new flippers "LeftFlipper2" and "RightFlipper2" in dialog box (new freshly pasted flippers will have same name as the ones from which they were copied) 

[Thalamus]

@Ben Logan : Thank you for updating this thread with your take in it. I came to the same conclusion but, I would not been able to express myself as good as you just did.

 

I don't want to take credit for this hack. It was all toxie, gtxjoe and your persistence that lead to it. Toxie didn't even want to listen to me ... hehe ;-)

 

Since it is a dirty hack - and can't really be used on all tables. Lets cross our fingers for some DJRobX magic.