1353 replies to this topic

[fuzzel]

That is possible but you loose the possibility to stop balls on the playfield.

[unclewilly]

I'm not quite sure what you mean?

I'm not experienced with this as of yet.
The table i built with a working subway system and real working trough used an elevated wall for the playfield so it doesn't need the fallthrough kickers as there were actual holes in the wall that made the playfield
Out of curiosity, can you swap an objects material via the script?

[fuzzel]

I mean drop balls on the playfield. And yes you can switch materials on dynamic elements via script.

[unclewilly]

Thank you sir. And thanks again for all your and toxie hard work on vpx. It's much nicer creating tables now, not having to use all those crazy hacks we used to use to make things look nice.

It's very much appreciated

[sliderpoint]

I've done one each, raised wall on TAF and subway ramps on X-files.  They both seem to have minimal impact on performance.  The downside of the subway seems only what wrd pointed out the "fall through" on the kicker is slower and you can't re-shape the kicker. The downside on the raised wall was what you mentioned with the debug 'throw balls on PF' and lack of reflections.

 

I don't know, 6 of one; half a dozen of the other, I suppose.

 

-Mike

[fuzzel]

Fuzzel,

Not sure if you saw it in another thread, but I think there is a BUG when the ball falls through a hole in the PF, to an under playfield subway. If there is any object EG: wall, ramp or prim under a fall through hall, the ball dropping speed is very slow. Remove the object from underneath the fall through hole, the ball falls at a rate, very realistically.

 

Anything we can do about this?

Do you have an example table for me? The only thing I know of is if the ramp/wall/prim is collidable and too narrow so the ball can't move easily and always touches the surfaces of that element. You get the same effect if you build a mesh/primitive wire ramp (pipe shaped) with a too small diameter.

[allknowing2012]

Any thoughts to adding some sort of primitive library option or is that too much of a change to implement? Thinking a drop down menu that could perhaps show all the prims found in a directory etc that could allow you to pull them into a table.

In that way we could build a community collection of prims to place on/in our pc.

[Drybonz]

How feasible would it be, at some point in the future, to be able to export a layer from the editor and import it into another table into a blank layer slot?  This would be very helpful for situations where two people are working on the same table (which happens a lot now)... one person could do a lighting layer (as an example), then send it to the other person to import into the table they are working on without losing any of their edits.  It would also be useful in situations where you have made edits to a layer, but then the table is updated and released by the author... you could import your edits and keep the new table version.

Edited by Drybonz, 07 October 2016 - 04:16 PM.

[fuzzel]

Any thoughts to adding some sort of primitive library option or is that too much of a change to implement? Thinking a drop down menu that could perhaps show all the prims found in a directory etc that could allow you to pull them into a table.
In that way we could build a community collection of prims to place on/in our pc.

This was already requested for 10.0. One problem with that is that it breaks the compatibility with current tables. At the moment a mesh is embedded to a primitive. If I change that to use a mesh manager how should I handle the old way? Supporting both ways is too complicated...

How feasible would it be, at some point in the future, to be able to export a layer from the editor and import it into another table into a blank layer slot?  This would be very helpful for situations where two people are working on the same table (which happens a lot now)... one person could do a lighting layer (as an example), then send it to the other person to import into the table they are working on without losing any of their edits.  It would also be useful in situations where you have made edits to a layer, but then the table is updated and released by the author... you could import your edits and keep the new table version.

Hmm nice idea. I think that won't be a big deal to add because all information is already there. Will take a look when I have more time again.

[sliderpoint]

Anyone else ever notice that you can increase/decrease all volume in VP with the +/- keys,  but they are backwards..  -  to increase and + to decrease?  Is that just me?

 

-Mike

[delta6014]

Don't know if this has been addressed in the last 31 pages, but when I run the latest version, my playfield is blurry. The table components seem to be OK, but the playfield itself is blurry. When I run 10.1 all is crisp and clear. Any Ideas???

[Outhere]

Check your video settings in preference to make sure they are set the same as 10:1

[toxie]

And also that your gfx card windows settings are all at default..

[boiydiego]

i got this error when running super mario bros vpx with beta how can i resolve?

[flupper1]

Feature request: is it possible to expose "disablelighting" for balls? It would make the GlowBall code easier and more accurate to implement.

[wrd1972]

 

Fuzzel,

Not sure if you saw it in another thread, but I think there is a BUG when the ball falls through a hole in the PF, to an under playfield subway. If there is any object EG: wall, ramp or prim under a fall through hall, the ball dropping speed is very slow. Remove the object from underneath the fall through hole, the ball falls at a rate, very realistically.

 

Anything we can do about this?

Do you have an example table for me? The only thing I know of is if the ramp/wall/prim is collidable and too narrow so the ball can't move easily and always touches the surfaces of that element. You get the same effect if you build a mesh/primitive wire ramp (pipe shaped) with a too small diameter.

 

Just sent you my table via PM.

[toxie]

Feature request: is it possible to expose "disablelighting" for balls? It would make the GlowBall code easier and more accurate to implement.

 

Already there: Set BulbIntensityScale to 0 for each ball (or DefaultBulbIntensityScale to 0 for the table)

[sliderpoint]

What is the hit pattern of a 1 wire ramp supposed to be?  I can't seem to get a ball to go on top or over one. Seems like a bug.

 

-Mike

[flupper1]

 

Feature request: is it possible to expose "disablelighting" for balls? It would make the GlowBall code easier and more accurate to implement.

 

Already there: Set BulbIntensityScale to 0 for each ball (or DefaultBulbIntensityScale to 0 for the table)

 

True, but that does not make the ball fullbright, like "disable lighting" does for primitives. I would like the ball to be displayed with the actual colors in the texture (so 255,255,255 in the ball texture is 255,255,255 on screen). Is that easily exposed?

[toxie]

Phew.. Not at the moment.. Could you try using a black image as ball image and the "real" texture as decal in logo mode? is that good enough?