868 replies to this topic

[toxie]

depth bias is also very evil in general, so please really just use it carefully and if desperately needed.

[hauntfreaks]

is it possible to add a file size column in the  image and sound managers, ??

 

Brog and i were just talking about this could be used to help keep table file sizes down to a minimum

[ICPjuggla]

Yes it's the same problem!
 
@ICPjuggla: the reason why it did work for you is the depth biaz. If you place a dynamic primitive very close over a kicker you have to raise the depth biaz to tell the engine that the primitive is higher than the kicker. You don't need the depth biaz if the primitive is bigger/larger and has a higher z position.

Hi all-
 
I wanted to share an editor feature suggestion that could be helpful when creating ramps/walls (particularly for original tables.)
 
It would be awesome to have a "split ramp at breakpoint" to allow for quick and easy division of a ramp into separate parts. This would make it easier to plan features like Y intercepts, etc. Also, a similar option  would be quite helpful for walls as well when designing channels, etc.
Keep up the great work!
 
-Lodger

Yep Blender and 3DSMAX can do that Sorry but this feature isn't feasible with the current UI.

Thx fuzzel that totally makes sense.. I always forget about that depth bias.. lol :-)

Edited by ICPjuggla, 18 May 2016 - 08:13 PM.

[fuzzel]

is it possible to add a file size column in the  image and sound managers, ??
 
Brog and i were just talking about this could be used to help keep table file sizes down to a minimum

Hmm i have to check that. VP doesn't know the file size of the images or sounds because they are already in the table and the file names of the images are just references to a file that was used when you imported the image into VP.

[xenonph]

Just want to ask a question.

I realize that the bigger the pictures, the bigger the file size is of the table.

But do the bigger pics make the tables play any different? Does it make them lag? What effects does it have on tables?

i am specifically asking because of the NFL Mods I have been making, but the info would probably be good for others as well who don't know.

 

Thanks for everything and the new nvram 32 sets are uploaded for the first 3 tables...Seahawks, Broncos and Eagles. just awaiting approval.

 

I am truly just a beginner at all this and really never messed with picture editting ever before.

 

Keep on Pinballin'

Edited by xenonph, 18 May 2016 - 11:43 PM.

[Umpa]

Is 10.1 64 bit or is that still in the experimental stages?

[hauntfreaks]

Just want to ask a question.

I realize that the bigger the pictures, the bigger the file size is of the table.

But do the bigger pics make the tables play any different? Does it make them lag? What effects does it have on tables?

i am specifically asking because of the NFL Mods I have been making, but the info would probably be good for others as well who don't know.

 

Thanks for everything and the new nvram 32 sets are uploaded for the first 3 tables...Seahawks, Broncos and Eagles. just awaiting approval.

 

I am truly just a beginner at all this and really never messed with picture editting ever before.

 

Keep on Pinballin'

 

so being a designer before ever knowing there was such a thing as VP.... I've had to design everything from business cards to a 40' tailers and billboards bigger than a house....
if at any time a photo needed to be used,.. to get it that big and not look like crap, is a whole art in itself.... 
that being said, from day one of my playing with FP and VP I've updated PF images.... and I have tried every size from way way to big, too high of resolution.... and the the other was around....
what I found on my cab was the best looking non taxing size PF is (again with my tests)  2048x4096 or abouts.... running on a 1080 TV its been the best looking jaggy free image size i found....
this of course is only possible if you have that size or bigger to start with.... there are times I have manipulated a 1024x2048 image to 2x the size... but its rare to get it to look good... even when i do a from scratch redraw I make it way bigger than needed then at the final save to a PNG (never use a JPG) I save it to 2048x4096 .... most DT users don't see the difference because most times its on a smaller monitor then a FS user

so thats my 2 pennies

Edited by hauntfreaks, 19 May 2016 - 09:45 AM.

[toxie]

Is 10.1 64 bit or is that still in the experimental stages?

 

It can be both. The build that is available for now is always "just" 32bit, as currently there is no immediate improvement in performance or anything else when using the 64bit variant.

In the future we might change to 64bit as the main target, but not yet.

[Umpa]

Is 10.1 64 bit or is that still in the experimental stages?

 
It can be both. The build that is available for now is always "just" 32bit, as currently there is no immediate improvement in performance or anything else when using the 64bit variant.
In the future we might change to 64bit as the main target, but not yet.

Thank you!

[toxie]

I realize that the bigger the pictures, the bigger the file size is of the table.

But do the bigger pics make the tables play any different? Does it make them lag? What effects does it have on tables?

 

It can make the table render slower (which can also mean more lag in the end) on lower end graphics cards, but only if you're going to use an extreme amount of large images.

So on the average the answer is no.

[ClarkKent]

The official VPX TZ table has problems with the rocket kicker (and maybe magnets) since rev 2620. Can you have a look why?

[fuzzel]

which was the last revision that worked? I'm asking because there weren't any changes on the kicker for weeks.

Edited by fuzzel, 19 May 2016 - 07:00 PM.

[ClarkKent]

I used 2604 for some time and it works perfect there. With 2620 the rocket kicker does not work the same, the ball is not shot into the hitchhiker lane but hits the post in front of it. Just try it - you will see it!

[ICPjuggla]

Quick question....

I know there is a check box for the light object to reflect on balls..

Is it possible to add values to that so we can adjust how much each light object reflects on balls.. In a table I did I'm getting a massive over powering 'glow' on the ball and it looks unnatural.. If there is already an option for this can you point me in the right direction..

[nFozzy]

It doesn't look exactly the same as intensity, but transmit will brighten the light without reflecting more light onto the ball.

[ICPjuggla]

See that's what I want, I want the intensity of the light but less reflection on the ball.

[fuzzel]

rev2621 is up with a small bug fix:

 

- use rubber's Height as HitHeight on pre 10.1 saved tables

 

Keep in mind that this feature only works if you have a table that was never saved with 10.1 (rev2615 or higher). If you have saved a table with say rev2620 and the tables suddenly plays stranges it's most likely because the rubbers have a HitHeight of 25 but the real Height is different. The new Twilight Zone for VPX is an example (as reported by ClarkKent).

[jimmyfingers]

rev2621 is up with a small bug fix:

 

- use rubber's Height as HitHeight on pre 10.1 saved tables

 

Keep in mind that this feature only works if you have a table that was never saved with 10.1 (rev2615 or higher). If you have saved a table with say rev2620 and the tables suddenly plays stranges it's most likely because the rubbers have a HitHeight of 25 but the real Height is different. The new Twilight Zone for VPX is an example (as reported by ClarkKent).

I was thinking about this a bit after discussing the rubber Hit height idea / updates and default for making it 25. It would cover it on most tables but I take it that with TZ it's the Upper level rubbers that have a problem as the default isn't sufficient being 25.  So, manual adjustment of any table with rubbers on an upper playfield will be required but the calculation should be easy at least.  It will just have to be 25+whatever the height of the raised / upper PF object is.  Also of course, the fact that it can still be set vs. depending on the visual aspect is still going to make customization overall easier / more definable for balancing views and physics aspects.

[Slydog43]

Am I the only one that sees a much longer load time for starting tables, pausing at initializing Visuals for a few seconds.  Maybe I messed up something just asking

[fuzzel]

I don't see any noticeable slowdowns compared to 10.0 or even 9.9. If a table has lots of primitives and big textures it will take some time.