2087 replies to this topic

[kruge99]

 

 

In my humble opinion, fixing a kicker that cuts a locked ball in half with an invisible wall is a lot easier than having to replace a plunger animation and script it.  But to each his own I guess...

 

 

The problem is that the invisible wall thing isn't that easy for people without a lot of table editing experience.    If we had a "one checkbox" fix it would be better if possible (much like the fix we're doing for bias adjustment).   Having a basic object working doing its intended function should come before "creative misuses" of it.   

 

 

Strange, I didn't realize that using the "surface" property of a kicker was considered a "creative misuse" to paraphrase... But I digress, fix the kicker however you see fit, I'm not one of the VP devs anyways.

[DreamTrap]

i don't have that saucer problem in afm i'm using the dark mod?

[DJRobX]

 

Strange, I didn't realize that using the "surface" property of a kicker was considered a "creative misuse" to paraphrase... But I digress, fix the kicker however you see fit, I'm not one of the VP devs anyways.

 

 

Using a kicker to draw a plunger image certainly sounds creative to me.    Creativity isn't a bad thing at all (as I said, you table authors have done some absolutely stunning things with very limited capabilities), but I just think actual kickers that are using the kicker object should come first.  From what I've seen this same issue comes up on many tables. 

Edited by DJRobX, 21 March 2014 - 02:09 AM.

[Bob5453]

When the ball doesn't drop into a kickercup, then it looks silly to me. Raising the kicker only makes the ball roll to a spot and stop. This isn't as noticeable when playing in FS where the view is more above, but in desktop it was more visible. I always used JP's fix of adding a light (then use playfield image for light image) over a kickerhole to achieve the ball dropping into the kickercup. I'm not sure when the ball cutting in half first started, but it wasn't broken in VP8 and earlier versions.

 

Anyway, a kickercup is all about a ball dropping in a cup, it would be nice to achieve this again.

Edited by Bob5453, 21 March 2014 - 02:05 AM.

[ClarkKent]

 

I still wonder what causes the distortions on some textures of Roadshow.

 

Looks like Lighting Enabled?

 

I disabled lighting but it does not change. Can you have a look at it?

https://www.dropbox....916_MOD_1.2.rar

[mukuste]

Look more carefully: you have to disable lighting on all the mouth surfaces (rm0 through rm12, tm0 through tm12).

[kruge99]

 

 

Strange, I didn't realize that using the "surface" property of a kicker was considered a "creative misuse" to paraphrase... But I digress, fix the kicker however you see fit, I'm not one of the VP devs anyways.

 

 

Using a kicker to draw a plunger image certainly sounds creative to me.    Creativity isn't a bad thing at all (as I said, you table authors have done some absolutely stunning things with very limited capabilities), but I just think actual kickers that are using the kicker object should come first.  From what I've seen this same issue comes up on many tables. 

 

 

That's exactly my point.  By unilaterally adjusting all the kickers 8 units higher in the source code, you're potentially breaking all of the creative uses that table authors have invented, beyond just the saucer feature.

 

Take the four kicker types for example: Cup, Hole, Hidden and Invisible.  In my mind, by raising all 4 kicker types 8 units, you potentially break 75% of the tables out there that employ kickers for uses other than a Cup. (aka Saucer)  Then go and add the tables where the other kicker types were used to make a saucer with a light or raised by a wall and you can add those tables to the broken pile that need to be fixed, raising the total of broken tables above 80% when there is a better solution.

 

Why not simply add an optional, user definable Z parameter that allows the author to add eight units (or any other number) to the height of the kicker object that defaults to '0' (zero)?

 

Doesn't this make more sense?

Edited by kruge99, 21 March 2014 - 10:28 AM.

[fuzzel]

In the next version the CurrentAngle function for spinners is available.

[unclewilly]

In the weekend test release. The weekends are so nice now. With these test versions

[mukuste]

Take the four kicker types for example: Cup, Hole, Hidden and Invisible.  In my mind, by raising all 4 kicker types 8 units, you potentially break 75% of the tables out there that employ kickers for uses other than a Cup. (aka Saucer)

 

Of course such a fix would only be applied to the types actually causing this problem.

 

But anyway I'm not the biggest fan of this workaround since, as someone pointed out, it looks plain weird on desktop tables. A proper solution will have to be found. Having kickers not working properly for the most basic use case isn't really acceptable.

[ClarkKent]

Look more carefully: you have to disable lighting on all the mouth surfaces (rm0 through rm12, tm0 through tm12).

But wouldn't this result in a too dark texture?

Will this lighting bug be addressed in a future release?

[fuzzel]

another new feature: with the next test version you are able to define the diameter of wire ramps and you can define the distance X/Y of a multi wire ramp to eachother.

[unclewilly]

What do you mean.
Like the spacing between the wires.
Like the upp en wires and the lower ones

[fuzzel]

Yes! The diameter of one wire and the spacing between two wires and the spacing between the upper and lower ones.

[unclewilly]

Cool. Can't wait to try that out. Hopefully I won't need anymore full ramp models from fp.

Just the rings

[atarian]

Fantastic - many thanks for the awesome work. I just tried the test 11 and it plays so many tables with no problems in my 2 screen setup. Initially I had bad stutter but that was because I stupidly didn't flip to Windowed Fullscreen (read the manual!). I use FXAA in nVidia under win7 and get NOT even a tiny stutter -nothing! b2s and directb2s with separate exe works perfect.

Found issue with the excellent FS Robowar table:
http://www.vpforums....s&showfile=6033

Ball runs over top of 3 pop bumpers. I tried Bring to Front but no joy, but I maybe doing it wrong. If anyone knows if a table adjustment can be made could they please describe the steps. Thanks.

 

Sorry to bump my own post.  I have tried to play with the Bring to Front, etc. for the various objects around the bumper but the ball still goes over the top of the saucer image on the bumper as follows:

 

 

Does anyone know how to fix it (if possible)?  Thanks

[kiwi]

 

Fantastic - many thanks for the awesome work. I just tried the test 11 and it plays so many tables with no problems in my 2 screen setup. Initially I had bad stutter but that was because I stupidly didn't flip to Windowed Fullscreen (read the manual!). I use FXAA in nVidia under win7 and get NOT even a tiny stutter -nothing! b2s and directb2s with separate exe works perfect.

Found issue with the excellent FS Robowar table:
http://www.vpforums....s&showfile=6033

Ball runs over top of 3 pop bumpers. I tried Bring to Front but no joy, but I maybe doing it wrong. If anyone knows if a table adjustment can be made could they please describe the steps. Thanks.

 

Sorry to bump my own post.  I have tried to play with the Bring to Front, etc. for the various objects around the bumper but the ball still goes over the top of the saucer image on the bumper as follows:

 

 

Does anyone know how to fix it (if possible)?  Thanks

 

It is not a quick and easy solution, perhaps by adding three walls as high as the three bumpers,
and moving the cap lights over the three walls.
In DX7, pure blacks bumpers  are invisible but still cover the ball when it goes under,
in DX9 pure blacks bumpers are completely invisible.

 

Max
 

[DJRobX]

I figured out what's going on with the display board in Monopoly.  There are actually two different bugs conspiring together on this one.    Each led element has two "light" objects ... i.e. Light40 and Light40f, the F being the gray "off" state, with Light40 being the red "on".

 

Bug #1 - in the script, the on/off states are toggled simultaneously, and VP doesn't try to determine which was the most recently changed item, so it isn't sure which light to bring to the top.     This is super easy to work around though, just toggle only the light we want to come to the top:

 

old:

If (stat and 1) = 1 Then
                             ledf(num)(y).state = 0     
                             Led(num)(y).state = 1
else
                             Led(num)(y).state = 0                  
                             ledf(num)(y).state = 1                 
end if

new:

If (stat and 1) = 1 Then
                             Led(num)(y).state = 0       
                             Led(num)(y).state = 1                   
     Else
                         ledf(num)(y).state = 0                         
                         ledf(num)(y).state = 1                        
 End If
 

Bug #2:  Of course, I did this and no matter what I did I couldn't see the red light ... ever, even if I never turned on ledf.     After a lot of WTFs, I sat in the debugger for a while.   The reason: the lights live in the backdrop!   There's some code that blocks all backglass items from going into the light vector, which is what allows them to come to the front when the state changes.  If I change that a little:

 

if (pe->m_fBackglass && pe->GetItemType()!=eItemLight)
                m_vHitBackglass.push_back(ph);      // VP9COMPAT: fixes Homer head on TSPP, remove in VP10

  else if (pe->GetItemType() == eItemLight)
                m_vLights.push_back(ph);            // VP9COMPAT: special treatment for lights

 

the lights start to work again.

Edited by DJRobX, 21 March 2014 - 06:13 PM.

[Arcade4]

awesome find on the Monopoly.

Looking forward to having that working again.

[bodydump]

Mukuste,

It seems there is an issue with solid ramp transparency in Rev 10 and 11.  Please see the red circled areas in the SS below.  This is on my WIP of NGG but is also present in other tables (Airborne, Car Hop).  Edges look fine in Rev 9.  All of the circled objects are solid ramps.

The green circle represents another strange problem.  If an image that extends to the edge of the table is used on an alpha ramp in World Mode and the alpha ramp object extends off the edge of the physical table in the editor, the image gets extended.

Here is a simple table showing the problem.  Doesn't happen in 9.2.1

Attached Files

•  test edge.vpt   464KB   5 downloads