3889 replies to this topic

[fuzzel]

I'm a bit confused. Do you want a flip functionality? To flip the shape you can use FlipX and FlipY from the context menu.

[hauntfreaks]

I'm a bit confused. Do you want a flip functionality? To flip the shape you can use FlipX and FlipY from the context menu.

no just the shape.... so I believe you answered my question... again I'm a dumbass....lol   

[fuzzel]

no comment

[hauntfreaks]

"I shouldn't have drank all that cough syrup"  

Edited by hauntfreaks, 04 August 2015 - 11:59 AM.

[jpsalas]

@ fuzzel: About the flippers using a primitive which you can change the image: yes do that! It will be like the bumpers, if you need another shape then simply make it invisible and add primitive like we have been doing. I guess the standard mesh should be the shape of the Williams/Stern flippers, since they seem the ones most used.

[fuzzel]

Yes I would add a Williams standard flipper maybe I add an old style flipper too. I mean the old ones used in EMs in the 50's and 60's

[jimmyfingers]

Guys on thing on my to-do list is to change the mesh of the flipper arm. I would like to use a complete mesh primitive based flipper arm like those you see in various tables. The main issue with that is that you would loose the ability to change the rubber thickness/height and width because it would be modeled together with the rest of the flipper but you could scale the length of the flipper. The color would only be changeable by a texture but you could add a logo on the flipper without twiddling with multiple images or primitives. I could add a bunch of different textures with different logos to the default table so you could use that out of the box.

The current flippers are very basic and creating a good looking procedural flipper arm is complicated, especially when you have to texture them. So what do you think? Leave it as is or replace it with a better primitive based mesh?

I vote for leaving as is for a few reasons.  Using a primitive now, if one wishes to, is only a few lines of code so in keeping the old method, one can still easily have the best of both worlds and create finely tuned native / editor flipper sizes with better rubber tuning options - that you say will all be lost.  Also, one major thing that has already been a problem is that with all the push / mandate for using materials in VPX, choosing just one mesh / object for flippers will force one to not properly model / pick the materials of the rubber and the plastic arm independently (correctly).  This seems to go against everything that's been pushed about the need and reason why everyone has had to adapt to this new material system - for these lighting / material interaction benefits / requirements.. That's already a bit of a problem when using external / primitive meshes for the flipper visuals as they have rubber and flipper arm in one mesh so one has to compromise when choosing a material to represent both these elements at once and not pick something too much like plastic (shinier) vs. rubber (much more dull).  The plastic arm and rubber portion are greatly different as to how the material should be chosen, so doing away with this is going to leave the flippers looking less realistic and not more.  The native ones have looked very nice when the materials have been set accordingly on the rubber portion vs. the plastic arm up to date with VPX.  So if anything a change to this would really have to allow a flipper mesh to be composed of two parts with each having the ability to be bound to a different material and at that point isn't it just simpler to use the method the way it is now and add primitive flippers (as they currently are now with only one material allowed for both rubber and plastic) using the scripted fashion?

 

Bottom line is forcing one material for both components of a flipper seems like a step backwards and with the proposal on making it native / built-in, even more numerous and complex routines and external meshes, then used now for primitive / mesh based flippers, would have to be used to try and get back to what we already have now with the ability to define a different material for each flipper component.

[fuzzel]

Ok agreed with the material problem when you only have one mesh for both flipper and rubber. But what if I separate them into two meshes one for the flipper and the rubber? Then you could apply two different materials. Another reason why I would like to change the flippers is when using the reflection option they look terrible at the moment A well modeled mesh(es) the look would be much better.

[jimmyfingers]

Ok agreed with the material problem when you only have one mesh for both flipper and rubber. But what if I separate them into two meshes one for the flipper and the rubber? Then you could apply two different materials. Another reason why I would like to change the flippers is when using the reflection option they look terrible at the moment A well modeled mesh(es) the look would be much better.

Ah, throwing in the reflection sweetener to the discussion  The flipper reflection does seem to be arguably the most important / noticeable missing element right now with the pf reflections and even though we currently only have static elements if it was static plus even just flippers it would become quite a reasonable starting point / illusion it would seem (and of course the better the flipper reflection the better that would be).  

 

Anyway, back to the other aspects of the flipper changes.  A separate material / mesh for the rubber and arm would seem to allow what would be needed for proper lighting / material interaction.  However, another element, which I didn't delve into initially, is the physics.  Would the collision mechanism underlying the graphical aspects / proposed changes remain the same or would it then be relying on the primitive collision mechanism that has more recently had issues with accuracy as well as performance (especially with wire rails)?  The flipper physics / turning has come a very long way and changing them into a realm that may throw all that off could really take a bite out of the benefits in game play / physics that has had most people very excited, upgrading, and adjusting to the learning curve for PMv5 / VPX.  

[fuzzel]

No I would leave the physics handling as is. I'm not 100% sure how to change the flipper properties because the start/end radius of the current flipper is used by the physics engine so I have to scale the mesh flipper ends in some way so you see the change...I will do some testing and see if it works as expected but I won't change the physics it's only all for a better look Will take some time because I have to setup my rig here first (new hardware and win10)

[jimmyfingers]

Thanks for clarifying the physics aspects and that does sound like a small challenge regarding the start / end radius options.

 

By the way, there is a bug in the new revision with the pf reflections showing over lights.  For some reason, even if the ball on playfield reflection strength is 0, it still shows a distorted (overly exposed / bright) outline of a ball reflection image on top of light objects (whether an insert or used for a PF lighting trick).  It also shows this odd ghost ball reflection image over the spots where a static image's reflection is displayed even if no light object is underneath.  I will shoot you some screen shots and maybe a bit more detail in a PM but wanted to get you a quick heads-up here.

[cyberpez]

I found a bug, "maybe?"  If not, any ideas?

 

I'm using a collecton to change the material/color of all my peg's..  Doing so the first two items in the list render funny  First is invisible, second is only half rendered. (see pic)  If I change what is at the top of the list it changes what peg is affected accordingly.  If I set them to static, they all render fine.  I get the funny rendering in both desktop and full screen.  Here is the code I'm using to change the material...

 

 

--------------

 

Sub SetPostColor ()

Dim i

If PostColor = 1 then

For each i in NW_Pegs:i.Material = "Peg":Next

Else

For each i in NW_Pegs:i.Material = "Peg Yellow":Next

End If

End Sub

 

--------------

 

Thanks!!

Attached Files

•  screenshot.jpg   130.33KB   19 downloads

[freneticamnesic]

Are those walls? Remove the first "Next"  in the if statement

[cyberpez]

Are those walls? Remove the first "Next"  in the if statement

 

No they are Primitives..  It give an error when you compile it.....  Expected 'Next'.

[freneticamnesic]

Ok try to do two for statements like:

 

Sub SetPostColor ()

If PostColor = 1 then

Dim i

For each i in NW_Pegs:i.Material = "Peg":Next

Else

Dim q

For each q in NW_Pegs:q.Material = "Peg Yellow":Next

End If

End Sub

[cyberpez]

 

Ok try to do two for statements like:

 

Sub SetPostColor ()

If PostColor = 1 then

Dim i

For each i in NW_Pegs:i.Material = "Peg":Next

Else

Dim q

For each q in NW_Pegs:q.Material = "Peg Yellow":Next

End If

End Sub

 

 

Same weird rendering issue.

[freneticamnesic]

i came i tried i failed

[cyberpez]

i came i tried i failed

 

No worries, thanks for trying.  I ended up creating two dummy pegs and put them at the top of the collection.  Issue still remains, but at least now its off they playfield where no one will notice. :-)

[Lapse]

The sound is double with the stern rom in VPX

Thanks for the Help.

[paulohotline]

Hey guys, I am randomly losing sound when playing any table in VP10 on the latest VPX_beta_rev2157.zip  build.

 

This happens rarely and very randomly, and does not appear to be related to the activity in gameplay (lots of balls in ball in play) but it does cut out for 2-3 seconds then comes back. Anybody else experiencing this?

Edited by paulohotline, 05 August 2015 - 05:23 PM.