357 replies to this topic

[BorgDog]

The only thing left at that point would be disabling the flippers at the appropriate time, and speeding them up, of course.

 

 

You keep talking about speeding them up, what speed are you talking about? Because if you are talking time from start to end (speed being distance/time), all the mechanisms for doing that are already there. Speed from start to end is a function of the flipper mass, coil ramp up, and strength.  Lower the mass, it goes faster, lower the coil ramp up it goes faster, increase the strength it goes faster.  It's that simple.  The hard part is balancing those with the other settings for accuracy and proper ball interaction.  

[Drybonz]

Isn't the real problem the perception that there is a microscopic delay from when a person hits the flipper button to when they perceive the video image of the flipper is moving?  In my mind, it's a game performance issue, like any video game system that has control lag, which is a commonly discussed issue all over in gaming... I also don't understand the "speed" vs. "delay" notion... maybe I'm missing something.

[Thalamus]

For me it is hard to say anything for certain. I have only one computer where I play VP on at the moment. What I believe to have noticed is that VP can be very accurate on the shots compared to previous versions. But, I feel that almost all the time, when the ball comes over the flipper with speed instead of from a cradled ball I'm often too late for the shot and will need to play for a long time before my brain compensates. However, putting in the code mentioned earlier in this thread, really changes this problem for me. Or, at least I believe it does ( placebo effect ?? ).

 

Everyone should try out the T2 WIP in this thread and see if you don't notice any difference.

[Ben Logan]

Or, if anyone is interested, you can easily add the "flipper / vpinmame interaction bypass code" found earlier in this thread to one of your table's scripts (one that has a DMD). It takes two cut and paste actions. The improvement in flipper response time (elimination of lag time between button pressing and onset of flipper movement) is dramatic. You can't miss it.

You'll know the code is working if your flippers still flip even if you haven't started the game. Also, flippers will still work after ball is drained.

Edited by Ben Logan, 17 October 2016 - 12:09 AM.

[Noah Fentz]

The only thing left at that point would be disabling the flippers at the appropriate time, and speeding them up, of course.

 

 
You keep talking about speeding them up, what speed are you talking about? Because if you are talking time from start to end (speed being distance/time), all the mechanisms for doing that are already there. Speed from start to end is a function of the flipper mass, coil ramp up, and strength.  Lower the mass, it goes faster, lower the coil ramp up it goes faster, increase the strength it goes faster.  It's that simple.  The hard part is balancing those with the other settings for accuracy and proper ball interaction.  

I believe it's also been already mentioned that the current mechanisms in place aren't conducive to accurate flipper speed representation.

[BorgDog]

The only thing left at that point would be disabling the flippers at the appropriate time, and speeding them up, of course.

 

 
You keep talking about speeding them up, what speed are you talking about? Because if you are talking time from start to end (speed being distance/time), all the mechanisms for doing that are already there. Speed from start to end is a function of the flipper mass, coil ramp up, and strength.  Lower the mass, it goes faster, lower the coil ramp up it goes faster, increase the strength it goes faster.  It's that simple.  The hard part is balancing those with the other settings for accuracy and proper ball interaction.  

I believe it's also been already mentioned that the current mechanisms in place aren't conducive to accurate flipper speed representation.

I believe you are the only one saying that, but I haven't reread the entire thread.

[Noah Fentz]

Reading the entire topic would probably be a good idea.

Sent from my SM-G930T using Tapatalk

[toxie]

@Noah: But it is like this: What was previously speed is now a function of coil ramp up (mainly, so set this to 0 for maximum effect), strength and mass. So did you experiment with these?

[Knorr]

@Noah: But it is like this: What was previously speed is now a function of coil ramp up (mainly, so set this to 0 for maximum effect), strength and mass. So did you experiment with these?

I wrote earlier in this thread:

Paul is right. I think its almost a year back when i talked to toxie/fuzzel if its possible to change/reduce the strenght/mass parameter in relation to the rotation. When i adjust the flipper side by side with my other pin i end up with Mass 0.7 and strenght 10000...

[BorgDog]

 

@Noah: But it is like this: What was previously speed is now a function of coil ramp up (mainly, so set this to 0 for maximum effect), strength and mass. So did you experiment with these?

I wrote earlier in this thread:

Paul is right. I think its almost a year back when i talked to toxie/fuzzel if its possible to change/reduce the strenght/mass parameter in relation to the rotation. When i adjust the flipper side by side with my other pin i end up with Mass 0.7 and strenght 10000...

 

 

So I have to ask, how did you take the lag time until flipper starts to move out of the equation when doing that?

[toxie]

 

@Noah: But it is like this: What was previously speed is now a function of coil ramp up (mainly, so set this to 0 for maximum effect), strength and mass. So did you experiment with these?

I wrote earlier in this thread:

Paul is right. I think its almost a year back when i talked to toxie/fuzzel if its possible to change/reduce the strenght/mass parameter in relation to the rotation. When i adjust the flipper side by side with my other pin i end up with Mass 0.7 and strenght 10000...

 

 

But is the flipper otherwise behaving well with this setting? If yes, then why the need for an additional parameter?

 

EDIT: Actually if i use your 0.7 and 10000 setting with a EOSTorque of 0.25 on the default table, it feels pretty fast and reasonably realistic.. More opinions??

Edited by toxie, 17 October 2016 - 11:41 AM.

[Knorr]

 

@Noah: But it is like this: What was previously speed is now a function of coil ramp up (mainly, so set this to 0 for maximum effect), strength and mass. So did you experiment with these?

I wrote earlier in this thread:

Paul is right. I think its almost a year back when i talked to toxie/fuzzel if its possible to change/reduce the strenght/mass parameter in relation to the rotation. When i adjust the flipper side by side with my other pin i end up with Mass 0.7 and strenght 10000...
 

 
But is the flipper otherwise behaving well with this setting? If yes, then why the need for an additional parameter?
 
EDIT: Actually if i use your 0.7 and 10000 setting with a EOSTorque of 0.25 on the default table, it feels pretty fast and reasonably realistic.. More opinions??

I will try that with the eos torque. This option wasn't available back then...

[BorgDog]

Any coil ramp up with that? Oh, and just tried that on a table, and ball was flying all over the place like crazy!

Edited by BorgDog, 17 October 2016 - 11:53 AM.

[toxie]

i've used 0 for this (as the ramp up is responsible for the majority of the "speed"-like-effect).

Or, if anyone is interested, you can easily add the "flipper / vpinmame interaction bypass code" found earlier in this thread to one of your table's scripts (one that has a DMD). It takes two cut and paste actions. The improvement in flipper response time (elimination of lag time between button pressing and onset of flipper movement) is dramatic. You can't miss it.

You'll know the code is working if your flippers still flip even if you haven't started the game. Also, flippers will still work after ball is drained.

 

There is one minor downside with this (just mentioning it for others to also think about it):

With this simple tweak, the rotation to end of the flipper will be called twice: once by the key handling sub, once by the solenoid handler. so if one is able to do pretty fast flipper button tricks, then it could be that the key release (rotate to start) will "overlap" with the solenoid callback. So to be safe if one has super-human reflexes, one has to disable the flipper handling code in the solenoid handler.

Edited by toxie, 17 October 2016 - 11:51 AM.

[Slydog43]

Is there a simple way to disable the sol handler in vpm?

[toxie]

you still need it in general, just make sure that rotatetoend and rotatetostart of the flippers is only called once (e.g. either in the keydown and keyup OR in the solenoid callback of the flippers). but it should really only matter for the most hardcore players.

[sliderpoint]

10000!!? That tries to shoot the ball through the back of the table!   I've also guessed over the years that the ball must have a mass of 1.  When the flippers have a mass less than 1 they will have strange interactions with the ball, little extra bounces and what not where it seems like the ball is pushing the flipper down and then it is recoiling and hitting the ball again.

 

-Mike

[toxie]

the latter one can adapt with the eos torque nowadays.

and i also think that 10000 might be a bit much, but then again a real machine is also pretty fast, but maybe not that fast.

[toxie]

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)

Attached Files

•  Untitled2.jpg   92.37KB   13 downloads
•  Untitled.jpg   91.37KB   13 downloads

[Thalamus]

Uh - now I'm really confused. Can someone explain to me why the opposite solution = profit !