Refined_Nudging

[Shockman]

This example is a result of a discussion Noah Fentz, 'Oz and I had over at VPF.

I have seen examples of better nudging in the current builds of VP, but I think this is the simplest way.

I pointed out that side nudges are kind of silly for a typical and predictable nudge, and 'Oz pointed out that VP nudging is side to side meaning you would have to be nudging the side of a table, and mentioned that he uses diagonal nudges, which immediately made sense to me. Noah pointed out that the dynamics are different up top than they are on the bottom, which makes sense too. I think that would be true as VP nudges now, and his example is correct for that type of nudging.
It then occurred to me that the proper motion that is now missing in VP would be better created by changing the force to a negative number to simulate the motion of the table returning to position. Because if you want to change the vector, you could easily apply the opposite force, without figuring out the opposite direction.
It is true that nudging has a different result if the ball is loose or against another object, but uses the same physics.

With all the work done on nudge settings, this here may already be in use, but again, to touch on a touchy subject (for an unknown reason) the biggest problem with nudging is that it is implemented in the script not as well as it could be. For one, the motion is too side to side. For another, it does not have the return motion so you can actually 'drive' the ball in unrealistic ways, in my opinion and experience.

If keycode = LeftTiltKey Then
Nudge 120, 1.3
NudgeTimerLeft.Enabled=True
End If

If keycode = RightTiltKey Then
Nudge 240, 1.3
NudgeTimerRight.Enabled=True
End If

If keycode = CenterTiltKey Then
Nudge 180, 1
NudgeTimerCenter.Enabled=True
End If

End Sub


Sub NudgeTimerLeft_Timer()

Nudge 120, -1.3
NudgeTimerLeft.Enabled=False

End Sub


Sub NudgeTimerRight_Timer()

Nudge 240, -1.3
NudgeTimerRight.Enabled=False

End Sub


Sub NudgeTimerCenter_Timer()

Nudge 180, -1
NudgeTimerCenter.Enabled=False

End Sub

This has the advantage of adding a little diagonal motion to the nudge simulating the more common corner, but on the front of the machine nudging. It also adds the effect of the table returning to center, counteracting the motion of the nudge.

It's not perfect. The nudge is kind of strong, I like that, others don't, but if set lower the table movement does not work. (I'll see what I can do about that).

To make a long story even longer, another problem is what I mentioned before about the reaction being different if the ball is free or against something and that is that if it is on something, a small, hardly noticeable, real, but exaggerated, delay will exist. The physics seem fine though, as does the ball in free space.

Anyway I put some work into this so I would like to share it. Submit it for approval if you will. It's certainly better than the existing scripting in regard to desktop, digital, keyboard control, and I think it is as good as I could come up with as far as limited to scripting. I don't know what effect it would have on analog nudging hardware, but being limited to a keystroke, I don't foresee any compatibility issue.

I created a path so you could easily test this with linear motion. Used a shallow slope to slow it down, and give it a good test by trying to nudge from flipper to flipper too. It's got the power to do that, and it shows the diagonal movement you would expect from nudging a corner.

One of the biggest changes here is a complete 180 on the center nudge which I think is correct.

Of course the timers and every number used are adjustable, so you may want to play with them.

 

[bob]

The current VP9 nudge changes the direction of the ball when nudged by the amount of force you choose. Until that is fixed in VP9, nudging is nothing more than a joke.

Look at this table. Let the ball free fall without nudging. See how high it bounces off the wall?

No ShartShake here to help show this example.

Now nudge the ball back up to the top of the table and let it fall. Nudge one time right before the ball hits the wall. See how high the ball bounces? Not very high at all, because you changed the speed of the ball with your nudge. So if you nudge too soon the ball actually bounces away from the wall at a slower speed than if you never even nudged.

WTF kind of physics is that?

 

[Shockman]

You're preaching to the preacher Bob.

My example will do that too as it is, but you have to pound the key fast to beat the timer that will make the correct adjustment, but you did make me have another look see. If you change the -1 in the -.5 the effect is gone. no momentum will be lost, except for the moment of nudge and the ball will not climb.

Plug my settings on your table and I think you will be happy with it. Or just put a flat wall below like you have. As VP is with the defaults you can climb and you can roll the ball off that wall with the side nudging. With these settings (with -.5 in the center timer) you will do neither.

 

[Shockman]

here.

For some reason it works for a while and then gives up. The side motion will return with the table more or less, but keep pounding and it will eventually give up and the ball will act like you slapped it.

It might be a timer issue getting out of sync. But under normal operations it works fairly well. There is something foul about it in the program though. I think VP needs a key hit as well as a key pressed routine. A key hit will event once when a key is pressed regardless of if it is held or not. Having nudge on a key pressed routine is more pushing than bumping. VP does not act that way, but basically it is still the problem, I think. This and an internal timer would be the ticket, and spastic key presses would not be a factor. Again, I think.

 

[bob]

Phil, I don't think you understood what I was referring to. You table just disguises it or minimizes the nudge, just like everyone else does who tries to change the default nudge. I'm talking about nudging moving the ball away from objects before it hits them. If you nudge right before the ball hits the wall in your example the ball stops dead on the wall. WTF? This is what I'm referring to. How can a nudge make the ball less active when it hits a wall? The whole system sucks. Period. Without redoing it, it will always suck. You just disguise it and think it's better, but LESS ball reaction doesn't equate to realism. The ball should not lose its momentum going downward just because you nudged the table upwards. Unless you are kicking the table with the force of a madman, the ball will not lose all of its downward momentum.

 

[Shockman]

I didn't think it did loose all of it's momentum in my example, but if it does it is surly wrong. A center nudge is no different though than a side nudge in that the table coming back down to center, for purposes of discussion has an instance where an opposite force to the nudge is applied and momentum of the ball going down (table going up) is reduced based not on it's previous ballistics, but the nudges increase.

It's wrong. But for now the best we can do is make it as manageable as possible and that would include adding the previous movement back into the equation.

You may be happier with deleting the center nudge timer and call to it, and have center nudge add downward momentum without table spring reaction. I strongly considered that myself.

Let's at least get it working as well as we can, so we have a complete understanding of exactly what the hard coded routine needs to be.

 

[Shockman]

If we can imagine a pinball's entire world as being inside a pinball machine and not the whole of space, and I think we can, then we can rightly say, instead of conditionally speaking in that the table is actually moving up, that the ball is moving down. For purposes of discussion anyway. Then we can say that though it is not going to be moving up ever because of a frontal nudge, or even due to the return of the table, that it's momentum is indeed decreased and possibly stopped depending on it velocity (if zero) and if zero perhaps moving up, at least for an instant, after the jolt down (in it's own world).

 

[tiltjlp]

Phil. take a look at either of the templates I sent you. I have used diagonal nudging on most of my tables for years. And as Bob said, VP9 nudging stinks, but mine at least tries to correct the problem, although it obviously doesn't. The nudging in previous versions wasn't perfect, but it was much better than what is in VP9.

 

[Shockman]

I should have made it clear that I was talking about VP9.

However what we are talking about when we mention diagonal nudging is a little up force being applied to every nudge. Left nudge being more than 90 but less than 135. Your templates are 90 and 270. Discussion involves more than that, but pertaining to that that's about it.

Nudging has been switched, at least once. I don't know why, but that's not all. Like startshake, the variable that provides visual feedback now, I assume the fact that the recoil was taken out is because cabinets provide that. The key might call the routine, but if the hardware devices are using the same routine, then that would explain the reciol being gone. Cabinet focus development might have saw it as another not big deal for us desktop users, but I don't want to break cabinet use, and if it is not necessary, I will not do it. This is what I was, as they like to say, ranting about at VPF.org. Like startshake, if it is better for anyone that it is not in the program, then I agree it should not be, unless we are talking about a version that is not a mere pretense to be a dual platform build. Until that is undeniably required, I am willing to, as I would expect obviously wrongly, that they would be chomping at the bit as well, to put it in the default table script, and as far as the recoil, it is just as benign in the script as startshake is. Sure if you were going to build a cabinet version with my build of VP you would want to Rem out startshake, and possibly the timers that give the nudge recoil, but talk about no big deal, this is my definition of no big deal, not not having it show at all to either be used or not.

This is now two problems that cabinet users have that is at least cured as far as visual feedback, but greatly improved as well as nudge recoil, and of course any table that you have that you load into it is not even going to know it's part of Table1's script and is going to work as it was scripted to. People need to relax and understand that solutions to our problems are not a threat to theirs. I already said if I had to break cabinet use, it would be labeled as VP8.[new] not VP9, and it will be for a niche as well and would still not exist unless all problems with VP8 compatibility was reset to VP8 standards as far as the settings used on VP8. If it falls between then it will be a special version indeed in that it would be no good for cabinet use or VP8 existing table use but a desktop only version of VP9, as so far that is what it has in it. Two major fixes that make desktop use easier and function.

These days I use VP9 as much as I can, and if a table was made for VP9 and they don't use graphics that will not hold the intended transparent color, there is really no problem with them, other than raped visual feedback and totally raped nudge physics.

I told them I was not beating the drum for program source changes, and that we could accept that the effort is going to have to be made to make preexisting tables work, those that would otherwise. But as far as building with their program, it should be in the script for us, but they would not hear that because it does not have anything for them.

They said a VP8 build could co-exist, but that is not good enough. If they are going to call desktop building problems 'no big deal', a VP9 version that has these lost, raped, sacrificed, bugged, whatever you want to call it (not you John, this is another rant) needs to co-exist as well. Desktop development might not be as cool anymore, but it is no less important than the 10% or so of cabinet users development. I'm here to tell you though what I told them. It is a big deal because these problems with using their version is not necessary. I think it would be better in the program .exe, but I am doing it exactly as I suggested to them they do it. Just put it in the damned script so it is there. Visual feedback and any other problems, like nudging recoil. VPM authors use a different syntax and if you are using VPM you do not even need nudging in your table script. Even with those lines removed you will have nudging, just not startshake, but the cabinet version builders don't want that anyway. Passion trumps logic at VPM.org. If it is not broke for cabinet use, it is not broke.

 

[tiltjlp]

I've been toying with the idea of a narrow range, random variable diagonal nudging system, so I guess now is the time to see if I can come up with something. It would be a very small variance, but I think it would be much more realistic for bagatelle games. I'll try to come up with something for your template Phil.