834 replies to this topic

[Shockman]

Absolutely right on the nudge explination shocky

It was not meant as an explanation. You all know what a nudge is. It was premise to a question on how VP10 nudging is going to be. And in a way an expression of understanding that if the only way to have working nudging in a desktop application of VP10 was to treat the ball as the object having force applied to it. It would be better than ignoring the need at all. Perhaps a warning also that any one method is going to not work for both environments. It is also the only reason I would expect a dynamic camera in either environment, which was where the conversation was at the moment.

 

The reason such a statement would give me away is because this is one of the most basic functions of pinball and it seems that that can not be expressed enough in this forum.

Edited by user, 22 January 2015 - 08:04 PM.

[mukuste]

In a pinballs world, it's trajectory is changed by a nudge and it's also changed back more or less by the same action (this is what has been missing only since VP9). We that nudge nudge the ball into things, not just off of things.

 

 

That's pretty much exactly how PM5/VP10 keyboard nudging works. The ball moves sharply in one direction, then sharply back (relative to the table, of course, since it's the table that actually moves, but that makes no difference to the simulation as it doesn't matter which frame of reference you choose). The net effect is essentially no change to the trajectory of the ball, unless it hits a table object during that short movement, in which case it will bounce off that object and change its path accordingly. This is all simulated from first principles, so I believe it to be reasonably accurate.

 

For those who prefer VP9 nudging, it should be very simple to write a table script which simply changes the ball's velocity directly when a nudge key is pressed. This would correspond to what VP9 did.

[The Loafer]

A dynamic camera certainly comes in handy at some point (bam type tracking, multiple custom camera views available on the fly - let us remember that not everyone sees the pin layout from the same angle, we aren't the same height ) but I am very happy that although it's not available now and may not be available for a while; it's on the radar and that's good enough for me.

[gtxjoe]

Here is the physmod nudge test table that demonstrates the real behavior.  The balls in the lower portion of the table will just rock back and forth when you hit nudge, ending up in the same place.  The balls resting next to the walls collide with the wall causing the ball gain momentum

 

In the vp9.9 nudge table where you do see that keyboard nudge sets all the balls in motion, which some people got used to but it is not realistic.  Put a ball on your kitchen table and bump the table and you will see that the ball remains in the same location

 

 Nudge tables.zip   117.31KB   12 downloads

[mukuste]

Static primitives are already collidable in vp 9.9. Just need to uncheck the istoy box.
mukeste was going to work on making dynamic primitives collidable when he wasdoing the physics modifications if i remember correctly

 

Yes, (static) primitives can be collidable since the later versions of VP9 already. To be fair, though, their collision code has always been somewhat buggy and I still want to fix that for VP10.

 

The dynamic collidable primitives are still on the list. There are unfortunately a whole list of complications associated with them, one of them being performance; I worry a bit about having to check collisions against thousands or even more triangles for high-poly meshes every physics frame. How would table authors think about creating a second, much lower-poly mesh purely for collisions? I think modern 3D programs have fairly decent options for detail reduction, so hopefully it wouldn't be much extra work?

[chepas]

 

How would table authors think about creating a second, much lower-poly mesh purely for collisions?

 

Perfect.

[StevOz]

Nudge aside and I totally agree with the changes, they have been long overdue. Will there be a visible shake for desktop users?

 

About the collision deal, I really see virtually no reason to degrade performance when a simple invisible basic VP object can do the trick.

Edited by StevOz, 22 January 2015 - 10:01 PM.

[BananaBoat]

In a pinballs world, it's trajectory is changed by a nudge and it's also changed back more or less by the same action (this is what has been missing only since VP9). We that nudge nudge the ball into things, not just off of things.
 

 
That's pretty much exactly how PM5/VP10 keyboard nudging works. The ball moves sharply in one direction, then sharply back (relative to the table, of course, since it's the table that actually moves, but that makes no difference to the simulation as it doesn't matter which frame of reference you choose). The net effect is essentially no change to the trajectory of the ball....
 

See it's this concept that has me somewhat confused , and it might just be due to the terminology being used in describing the result of a nudge, however, I would argue that in the real world, the trajectory of the ball should change, because if it didn't then why would anyone bother to nudge at all?

Consider the ball coming towards the flippers at a trajectory best described as an arc. Lets assume the ball is headed for the drain. In the real world you would nudge the machine in one direction to apply sufficient force the the table to 'effect' the trajectory enough so that you could hit it with a flipper, thus saving it from draiining. This is changing its trajectory. The magnitude of this effect may be small, as it is in the real world, but it's definitely there.

Therefore, Are we saying this is, or is not possible in VP10?

[mukuste]

Yes, during the nudge itself, the trajectory is of course changed. You can easily see that in pm5 on a zero slope table.

[BananaBoat]

Ok, bravo, as you were then.... Apologies for the interlude...LOL

[Shockman]

The trajectory is changed, That IS the whole point. But just as the plunger is returned when you let go, so is the table, and on nice stiff legs the reaction is equal and opposite. Timing is the key to getting it moved over to the flipper. Do it too early and it could have been there but moved back.

 

Nudging is a huge factor and it is not as simple as it may seem. It is more than a skill. It is a skill set.

 

Bumping is a skill. It draws from you just to bump the table. Just bumping, if that is not your game, takes a conscious decision.

Timing is a skill. Obviously. because of the recoil, you have to have the ball over at the right instant, or have the table element move at the instant the ball is hitting or extremely close to it.

Direction is a skill. A bump on one side could have good results while a bump on the other not.

Speed, force, frequency and range are each skills. Not only for control, but in avoiding a tilt. Knowing the limits of these is important.

Speed and force are basically the same until some of the advanced skill is used. Duration is an advanced skill that can actually change the vector permanently when you don't just bump but push and hold pressure on the table. The slower you release that pressure, the more impact you will have on the balls direction.

Tables can be slid a bit without brutality also. Getting what needs to be done deliberately instead of desperately is a skill.

 

Nudging started out as the primary control method, predating flippers. To not nudge these early games reduced them to games of chance. That's not what they were.  Flippers imposed skill without taking away the importance of a good skill set in nudging. 

Edited by user, 23 January 2015 - 02:48 AM.

[BananaBoat]

so what's your point?

[chepas]

 

 

About the collision deal, I really see virtually no reason to degrade performance when a simple invisible basic VP object can do the trick

 

Well, that's not true in some cases. Take this he-man for instance. The ripper ramp is so sub standard is actually pretty difficult without using a model to achieve that angle.

 

Right now the ball disappears into the ramp model before it can make it to the fake ramp.

 

Unless you could drag an extra point from the corner of a VP ramp model its pretty difficult as it is.

 

Also it's saving you loads of time without faking the collidables, it is twice as much work if you work with alot of primitives.

Edited by chepas, 23 January 2015 - 08:59 AM.

[StevOz]

 

 

 

About the collision deal, I really see virtually no reason to degrade performance when a simple invisible basic VP object can do the trick

 

Well, that's not true in some cases. Take this he-man for instance. The ripper ramp is so sub standard is actually pretty difficult without using a model to achieve that angle.

 

Right now the ball disappears into the ramp model before it can make it to the fake ramp.

 

Unless you could drag an extra point from the corner of a VP ramp model its pretty difficult as it is.

 

Also it's saving you loads of time without faking the collidables, it is twice as much work if you work with alot of primitives.

 

 

Actually it is true in all cases if you know your VP there are ways and means to solve such, that is the beauty of the beast.

 

VP has always been about thinking outside of the circle and as it has been it should be...

Edited by StevOz, 23 January 2015 - 09:14 AM.

[chepas]

For starters you haven't explained how, so I'm guessing compared to dropping in a model and checking collidable it's a massive pain in the arse, hacky & time consuming.

[StevOz]

Flexibility above simplicity, if you know the history and nature of the beast, just look to how ramps where turned into posts, there are so many more examples of those that have, it's not for me to explain how, it up to you to rise to the challenge.

Edited by StevOz, 23 January 2015 - 09:40 AM.

[chepas]

Haha, I'm done with you already! Just add low poly collisions and we can move on.

[StevOz]

As you are done with me I have been there and done that.

[toxie]

If any of the options/variables could be set before launch you could do away with having duplicates of tables for FS & DS. After all, most tables these days can be changed without harming it.

 

This is also already on my todo list: Have two (or more) settings per table, and you can select in the video preferences which one to use by default (or override per table).

 

The same goes for day/night mods. There is already code included now that helps script authors to do a unified version, and the user could then select freely between night and day.

If it will work out like planned remains to be seen though.

I guess for a "perfect" night/day look there will always be the need of specialized tables, but maybe over time (VP10.X) we can get something

that at least works out for most tables (with the help of scripting by the table author, optionally).

[Nidwin]

Is it humanly possible to change the trajectory of a ball coming down the table?

 

My understanding about nudging on a real table is that the trajectory of the ball can't be changed but it's the position of the table and it's physical elements that you modify vs the trajectory of the ball to achieve the nudging effect. This is of course once the ball is in motion and not with a ball with zero motion.

 

But I could be wrong of course.