destruk, (about balls through the flipper, and a new VP)

[Shockman]

Sorry, but I don't have PMs at this time.
I want to clear up something that you said at VPF.
You are right of course that the collision works on the forward swing, but to make it more clear it misses the flipper when they & the ball are going in the same direction being forward or back. Otherwise you could reverse the swings and have them rotate to start on key up, and rotate to end on key down, and everyone knows that the flippers react the same as if you did not do that.
This, I think, kills the idea that collision is tied to the rotate to end command.

Take table1 and in the editor, switch the values for the start and end of the swing for the flippers, and in the script change all rotatetostart to rotatetoend and the rotatetoend to rotatetostart, and add LeftFlipper.rotatetoend and same for the Right on line 1. Also put a faster, or the default speed for the up swing, rotatetostart in this case, and slow for the down, rotatetoend.

Little, if any difference.

I have tested everything I can think of. The collision sometimes works on the downswing if you set the table up like that, and never if you don't. Elastic of 1 (not .1) works every time I tried it, but elastic of 1 is no good, it's like a slingshot. It proves though, that collisions are being polled all the time, it just most often fails when the ball is going in the same direction.

The point is only that unless a new VP is released, by anyone, that has fixed this, then it is up to us to minimize the problem any way we can.

I don't know about anyone else, but I find upswings that are fast enough to work for downswings is too fast to act realistic. I don't need a mod to show this. Have you checked out mmpac bb6.1? And I was being honest when I said I can pick off individual targets in the bank of Sorcerer, for example, with the settings I use, instead of hoping merely to hit the bank.

Unlike what you have read from those that could not care less about this, it is not something that you notice, unless we are talking about overly drastic differences to the speeds. If you are flipping up, when in most cases you will be there is no noticeable difference at all. If the flipper IS going down, I think I can expand on this, with the use of active ball, to shift momentum of the ball towards the base of the flipper, which is what this maneuver does in real situations.

My question to you is, is there a way that I can make a core.vbs change, for my own use, if that's what everyone really wants, that would speed up the flipper when the ball is on a trigger? In other words, how can I transfer a variable from VP to the core.vbs file?

If a new VP is released, it is my hunch that it is going to be so drastically different that we will have two versions, that one, for new tables made for it and those converted to it, and the one that we have now, for the ones that are not. At least for quite some time.

Right now though, I am working with the one I have now.

Please if you will, tell those at VPF that PN is not allowing me to release mods of tables in any way. People are being turned against both me and this site due to misinformation. I am guilty of trying, but this site is not guilty of allowing it.

Thanks.

 

[destruk]

Rotate to start and rotate to end won't make a difference. It's the forward (meaning direction flipper is moving in) side that has collision on a moving flipper object. So if the flipper is moving from top to bottom toward the player, it's the bottom side that detects the collision. If flipper is moving from the player to the back of the table, it's the front side. The ball has 50 units of mass, so flipper checks are polled more frequently on the front than the back at the moment and it's always been this way. VP7 has more code tossed at the problem, but it's still not solved by it. The updated VP has this corrected - balls can't occupy the same space as another object, multiple balls do not confuse it, no going through flippers/walls/etc etc. As far as two versions of tables, there are not many incompatibilities - mainly z-axis kicks, ramp/wall heights might need to be changed on a case/case basis. Perhaps some graphical changes for the higher resolution sizes, and elasticity changes to make it play better than it does already.

For changing core.vbs, your best bet would be to call a new vbs file to replace the routines in core that you want to play with, and ignore the ones that are already there. Or do it in the script per table.

 

[Shockman]

As far as I'm concerned, VP7 IS the updated version. I think the ball has 50 units of size, but not mass. It will go through objects 5 tall and objects that's bottom is at 45, has this been fixed as well? Is that why you say walls and ramps may need to be adjusted? How about platforms setting on the playfield like dropwalls used for light spots? Does the ball react to those now?
I have not had problems with z-axis kicks, or elasticity settings. What is new with those?

 

[destruk]

Like so many people keep reminding me, until it's available it doesn't make any difference.

 

[Shockman]

That's my WHOLE point.

 

[destruk]

Master of the obvious. Anyway, I'll keep my mouth shut from here on.