167 replies to this topic

[ringorian]

Yes, I can write some guidelines, but avery table is different, I don't know why, but sometimes a setting that works in one table it doesn't work on another. But I'll make a list of the settings I have used in this table, and I'll post them here later today. The settings are very similar to the ones I used in my latest tables, like Scarface and Freefall.

 

Funny , i just wanted to ask why scarface is that "different".For me the ball has less more "weight" and the ball jumps around, floating some times which i don´t like that much .. Star Wars is near perfect ..

But if its nearly the same physics, how does this come ?

[jpsalas]

The only difference is the table slope. In Scarface is 5,5 while in Star Wars is 6. The rest of the settings are the same.

Both tables are quite open in the middle, so changing the Scarface slope to 6 (the Slop Min Difficulty and the Slope Max Difficulty) will make the ball feel heavier.

[jpsalas]

In short the physics of this table are like this, mostly the same as Pinball Ken wrote a long time ago, only with a little increase in the elasticity and reduced friction.

 

Table slope: 6 (both Min and Max the same)

Gravity constant: 1,6774  (as recommended by the Ultrapin developers)

Contact Friction: 0,0005 (this is the friction between the ball and the table, I don't see any reason to increase it, it actually should be 0 since there is practically no friction between the ball and the table)

Dampening Speed: 65 (this is the limit, here you may change it to what you want, but I prefer to do not limit it)

Dampening Friction: 0.95 (I haven't tested much this value so I leave it default)

 

Flippers: I have tried many setting, but I always go back to what PInball Ken wrote. These are the setting for a normal table with Williams flippers (and I use the same for the Sega and Stern tables)

Base Radius 20,5

End Radius : 11,5

Length: 116

Start angle: 121

End angle: 68

Max difficult Length: 0

 

Speed 0,27

Strength 0,34

Elasticity 0,5 (black rubber is harder, otherwise I should have used 0,55)

Scatter angle 0

Return strength 0,07

Recoil Velocity 40 (here I could have used 0 since I don't like the extra bounce if this value is low)

Power law 2 (if this value is lower the ball sits like glue on the flippers)

Oblique correction 4,5 (here I can use from 4,5 to 6,5 depending of the table)

 

Now the walls have different values depending of the material:

 

Post rubbers: these are the round rubber around the posts

Hit threshold: 2

Elasticity: 0,65

Friction: 0,004

Scatter angle 5

 

Long Rubbers

Hit threshold 2

Elasticity 0,75

Friction 0,004

Scatter angle 5

 

Metals:

Hit threshold 2

Elasticity 0,25

Friction 0,0015

 

Plastic and wood I use the same. There isn't much wood in the tablesI make.

 

Elasticity: 0,3 or 0,2

Friction 0,002

 

The targets I use to make them as the plastic materials.

Ramps always with elasticity of 0,3, and I always build a "roof" on top of the ramp at 60 units high so thehe balls don't fall down off the ramps

 

And those are more or less the settings I used in Star Wars Trilogy.The rest are more or less default.

Edited by jpsalas, 18 February 2013 - 04:23 PM.

[toxie]

Thanks a lot! I'll see that i'll get this stuff included into VP then!

[kiwi]

However, this version breaks up the primitive. Does it need to be coded differently? When the ship moves, only 2/3 of the ship moves and the rest stays behind......

 

 

Wow HUGE performance boost Toxie. My rig went from 89fps to 300fps! AWESOME!!!!!!!!!!!!

 

Ok, compiled and uploaded available below in my sig...

Quick test on my main pc... 442 = 15 fps, 444 = 83 fps

With an ATI card, the ship is Ok.

 

Max

Today the problem is also presented to me.
Yesterday was a day most lucky.

 

Max

[ringorian]

Thanks jp

[hmueck]

In short the physics of this table are like this

 

 

Thanks very much for this list!

[Aurich]

Was playing this table last night (the latest 1.01 version) and got this error:



Has anyone else run into that? I'm not sure exactly what I was doing when it was triggered.

[miracle]

I see that some have corrected the Xwing Bug with some script modification ... 

My script skills are limited and i'm a bit lazy

Anyone can provide me the corrected table ?

[jpsalas]

About the XWing bug: it was me who tried to correct it It is not 100% fixed, But I haven't gave up yet By next week I'll have a new version with a few fixes.

 

About the Magnet4: just redownload the table. (I uploaded the wrong file the first time I uploaded the 1.0.1 )

[Bob5453]

Thanks a lot! I'll see that i'll get this stuff included into VP then!

Why not ask JP to make a nice starter table and replace the NEW table that comes with VP?

[Aurich]

About the Magnet4: just redownload the table. (I uploaded the wrong file the first time I uploaded the 1.0.1 )

Thanks.

[toxie]

Thanks a lot! I'll see that i'll get this stuff included into VP then!

Why not ask JP to make a nice starter table and replace the NEW table that comes with VP?

 

 

It's not just about that, but also when adding new table elements..

[koadic]

Yes, I can confirm that only the FS version is affected by the XWing bug. I don't understand why, since both the desktop and the FS tables are the same, only change are the backdrop settings.
 
(Thanks to all who send kind words about my mum)

I figured out the root cause of why it was happening on the FS table and not the desktop table... it is because on the FS table, when the primitive rotates, part of it goes offscreen, and that is where the issue lies... You can test this by taking the FS version and changing the Y Scale to something like 1.8 to make sure the entire primitive stays on screen (even the parts that are transparent)

[toxie]

Okay, this is very weird then.. So if stuff goes offscreen, it is not properly updated? Is this a general bug that also applies to other table elements?

Cause then this screams for a general fix!

[koadic]

I know that gates, if they go off screen, they will completely disappear... and similar graphic issues also happen to dropwalls if they go off screen.

Edited by koadic, 20 February 2013 - 06:04 PM.

[toxie]

Okay, thanks a lot, that could help to track it down!

[kruge99]

I know that gates, if they go off screen, they will completely disappear... and similar graphic issues also happen to dropwalls if they go off screen.

 

I could be wrong, but this may also apply to plunger objects as well as "drain" type kickers.

 

 

Best Regards,

Todd.

[jpsalas]

Okay, this is very weird then.. So if stuff goes offscreen, it is not properly updated? Is this a general bug that also applies to other table elements?

Cause then this screams for a general fix!

It worked fine in 434.

Another thing I tried, and it worked fine, was to change the primitive to use 40 sides instead of 4. Then it is more round, since the corners are gone, and it is redrawn inside the table

 

About the make a new default table: I think a lot of people tried before, and it didn't worked fine since every author is different, and the tables are also different. I think the best is to keep the new table as a minimum or include the one Shiva made as a demo with the firsts releases of VP, including that first shive engine. That's a good table to learn how to make a table. Anyway there are now several templates, but still there isn't a template to make a vpinmame table (maybe because each table is different).

[Liteuser]

The table looks and plays good here in VPinball rev 434 as JP said. This is the best VPM table of the year so far.