1353 replies to this topic

[gtxjoe]

I have Zeb's plunger, and the first time you pull the plunger on a table, it auto calibrates.  When it calibrates, the plunter travels from position 0 to 1.  If the park position is .1667 and there is a ball in the shooter lane, the auto calibration causes the plunger to jump to 0 initially then move to 1.  This initial jump to 0 from .1667 can launch the ball 1/2 way up the shooter lane.   I think this was the reason for the request to change park position to .01, to eliminate that unexpected short plunge due to the plunger auto calibration.

 

I have no idea if Virtuapin plunger, or mot-ion or pinscape behave this way

Edited by gtxjoe, 25 August 2016 - 07:34 PM.

[Carny_Priest]

VirtuaPin Plunger Kit behaves similarly. I have a v1 controller.

[ICPjuggla]

I don't have either in my cab just a button so I'm of no help here! :-(

[hauntfreaks]

I don't have either in my cab just a button so I'm of no help here! :-(

 

Boooo 

[sliderpoint]

Pinscape controllers do not behave that way.

 

-Mike

[Umpa]

I have zebs and it acts the same as gtxjoe described

[Shockman]

VPX has a nice working plunger with a park position as described by gtxjoe. So did the Physmods. I recall the change as he described that too. MY VPX plunger works fine. I don't recall. I probably reset it the day the default was changed. I think it would not be too hard to pull the plunger before ball launch though, if you needed to do that. Defaults should always be as close an approximation as possible to that which you are simulating, in this case a plunger, instead of a catering to any minority.

 

A lot of new people might not even know that the plunger can be set to work much better than it is presented to us. I'm talking about how it was presented to them (these devs).

 

VPX default is set at .01 (disabled for ALL intents and purposes)

 

I use .1 (just a bit less than the old default)

Edited by Shockman, 26 August 2016 - 12:50 AM.

[freneticamnesic]

v1 virtuapin plunger had a similar bug. I mean it had many more bugs but that was similar to the way zebs behaved.

 

I have a VPX issue I don't know how to properly resolve. The table I'm working on has 5 flashers in a row on the back panel, when one is lit up by itself it looks good (to me) but when 3 or more are lit up and all overlapping it opens up to the darkest, hottest pits of hell...

 

 

Any good solution? I hate to just make the lights dimmer since one by itself looks wicked but if that's the consensus then so be it.

[Shockman]

If you have the spare time in the cycle maybe you could run a tab (how many lights are on) and set the dimmer as they increase. The parts that don't over lap might seem to dim, because they would be.  A more perfect way would be to have a light that individually changes, not just the brightness, depending if no  neighbors, one on the side, or flanked by two on.

[mjr]

I have Zeb's plunger, and the first time you pull the plunger on a table, it auto calibrates.  When it calibrates, the plunter travels from position 0 to 1.  If the park position is .1667 and there is a ball in the shooter lane, the auto calibration causes the plunger to jump to 0 initially then move to 1.  This initial jump to 0 from .1667 can launch the ball 1/2 way up the shooter lane.   I think this was the reason for the request to change park position to .01, to eliminate that unexpected short plunge due to the plunger auto calibration.

 

It's all relative, I suppose, but in my opinion it would be better to address this in the plunger firmware than to change the long-time VP behavior.  VP has had an established standard for this since it originally supported mech plungers - I'm pretty sure this was based on the Mot-Ion plunger behavior, since the earliest plunger code in VP looks to be specifically written for that kit.

 

VP's expectation from the device is as follows.  The device reports joystick axis coordinate 0 when the plunger is at the park position.  It reports the maximum positive joystick axis coordinate when the plunger is pulled all the way back.  It reports the extreme negative joystick axis coordinate when the plunger is pushed all the way forward.

 

My first preference would be to just have that be the universal standard and expect all new plunger devices to conform, and consider it a bug in the device if it doesn't.  It's a simple convention, and it's the way it's always worked since VP had plunger support to begin with.  All of the plunger devices that I'm aware of have upgradeable firmware, so if everyone can agree this is the right convention, it should be a simple matter of tweaking the firmware for any existing devices that don't already follow it.

 

If the firmware writers can't all agree on the one convention, the next best thing would probably be to just add more special-case code per device to VP.  VP already has code that recognizes six or seven different plunger/nudge devices so that it can apply special-case handling to each.  So any devices that really must follow different conventions can just have the necessary compensating code added to VP, and we can leave the main body of the code as it's always been to maintain compatibility. This isn't as nice as everyone following one convention, because special-case code means more complexity and more opportunities for bugs, but I think it's better than breaking the long-standing behavior for everyone.

Edited by mjr, 26 August 2016 - 04:30 AM.

[toxie]

v1 virtuapin plunger had a similar bug. I mean it had many more bugs but that was similar to the way zebs behaved.

 

I have a VPX issue I don't know how to properly resolve. The table I'm working on has 5 flashers in a row on the back panel, when one is lit up by itself it looks good (to me) but when 3 or more are lit up and all overlapping it opens up to the darkest, hottest pits of hell...

 

 

Any good solution? I hate to just make the lights dimmer since one by itself looks wicked but if that's the consensus then so be it.

 

I fear that you are hitting the max value we can have at the moment, which gives you infinity in practice.

[freneticamnesic]

 

v1 virtuapin plunger had a similar bug. I mean it had many more bugs but that was similar to the way zebs behaved.

 

I have a VPX issue I don't know how to properly resolve. The table I'm working on has 5 flashers in a row on the back panel, when one is lit up by itself it looks good (to me) but when 3 or more are lit up and all overlapping it opens up to the darkest, hottest pits of hell...

 

 

Any good solution? I hate to just make the lights dimmer since one by itself looks wicked but if that's the consensus then so be it.

 

I fear that you are hitting the max value we can have at the moment, which gives you infinity in practice.

 

 

 

Is it that a light with intensity set to 100, and a light with intensity set to 100 near it, will produce an intensity of 200? Is it that simple? If so, what's the max intensity you would expect to be possible? I suppose I could just as easily add a if statement to bring the total intensity down below that at any given time... 

 

If you have the spare time in the cycle maybe you could run a tab (how many lights are on) and set the dimmer as they increase. The parts that don't over lap might seem to dim, because they would be.  A more perfect way would be to have a light that individually changes, not just the brightness, depending if no  neighbors, one on the side, or flanked by two on.

 

There's that, I could call different lights and shape them so that if a and b and c are on, a and c are the correct shape and b is sort of squished in between to prevent them from overlapping.

[toxie]

Its not that simple. :/

On GPUs you store things in a framebuffer, and these framebuffers always need to have some kind of precision. To save memory and bandwidth, we use a half-precision float buffer to render/sum up all things, and i guess there you max out the value of half floats (if you add multiple large values like these flashers (note that the intensity you set is not directly the same as what is summed up in the end!), then you hit this border rather quickly, and get 'infinity' (above 65504 in this case)).

 

 

EDIT: on the positive side, we are nearing 2 5 0 VPX tables rather soon (at least in my directory, not properly cleaned of some dupes most likely )!

Edited by toxie, 27 August 2016 - 07:31 AM.

[sliderpoint]

I'm getting a lot of "construct not closed" messages when I am opening more than one table or if I have closed a table and then open another one without closing the editor.

 

The title of the window says "Parse error on line:638"

 

Then just an OK button.

 

-Mike

Edited by sliderpoint, 27 August 2016 - 09:36 PM.

[freneticamnesic]

I'm getting a lot of "construct not closed" messages when I am opening more than one table or if I have closed a table and then open another one without closing the editor.

 

The title of the window says "Parse error on line:638"

 

Then just an OK button.

 

-Mike

 

I get this a lot as well, doesn't seem to affect anything.

[jpsalas]

I too get that "construct not closed" when running some tables. But that doesn't prevent me from running the tables.

The problem with that error is when you are editing the table, and you can't get away from that error popping up continuously and I loose my work. That's something Brandrew should take a look at. But I have learned not to write a Sub without an End Sub

[wrd1972]

Same here.

[ICPjuggla]

I also get "construct not closed"

[fuzzel]

In the next build this message won't show up again. It looks like that Brandrew left some debug message in the code

[Shockman]

It still should not give the message unless there is a problem. You are most likely going to accept a memory leak or worse a massive non release if you 'solve' it by suppressing the error message.

 

The only way that message could be an error, instead of flagging an error is if it was programmed to announce the construct not closed message if the construct instead is closed.

 

I would take this up with Brandnew if I were you.

Edited by Shockman, 28 August 2016 - 09:48 PM.