1353 replies to this topic

[gtxjoe]

Please don't call this an issue or bug with those analog plungers, those plunger were designed to auto calibrate this way.  What's being requested is a design change request not a bug fix...

 

We would all be asking for this behavior to be addressed in VP, if the Pinscape did not come up with a novel approach that does not require auto calibration across the full range of motion

[TerryRed]

 

 

I wish I had a fancy plunger so I could argue about it 

I was thinking about getting a fancy plunger but now I'm scared.

 

 

nah dont be (none of the talk here is a deal breaker)... you already have a pinscape setup, so you're there .... if you can solder ger the optical sensor , if not you can do the linear potentiometer....

I've done both and both work perfect... and also the best reasonably priced option out there.... a  linear pot costs I think $5 or less , you just need the plunger its self, that can be had for $5-$10

 

 

This...

 

I don't have a Pinscape but would have gone this route if I didn't also have arcade controls in my pincab.

 

With my hacked up gamepad approach, I also use "linear potentiometer" / slider potentiometer. They are very cheap and it has been working very well for me. No issues with VPX at all.

[Drybonz]

 

I was thinking about getting a fancy plunger but now I'm scared.

 

nah dont be (none of the talk here is a deal breaker)... you already have a pinscape setup, so you're there .... if you can solder ger the optical sensor , if not you can do the linear potentiometer....

I've done both and both work perfect... and also the best reasonably priced option out there.... a  linear pot costs I think $5 or less , you just need the plunger its self, that can be had for $5-$10

 

Are there any good, existing threads about making a pinscape plunger?  I don't want to butcher this one any further by asking questions about it here, but I am interested.

[BorgDog]

OK, so now I want to ask about physics. To be clear this question is about physics and plungers.

 

ScatterVelocity "amount of randomness added to ball velocity on firing" does not seem to do anything.  The analog plunger in the cab gets randomness just by it's mechanical nature, but when working on my laptop or desktop and using a key for plunge there does not seem to be any variation regardless of what settings I put in there.  Easy to test by just doing a full pull and watch repeatedly where it goes, assuming it's not striking objects that have scatter built into them it will be identical every time.

[hauntfreaks]

 

 

I was thinking about getting a fancy plunger but now I'm scared.

 

nah dont be (none of the talk here is a deal breaker)... you already have a pinscape setup, so you're there .... if you can solder ger the optical sensor , if not you can do the linear potentiometer....

I've done both and both work perfect... and also the best reasonably priced option out there.... a  linear pot costs I think $5 or less , you just need the plunger its self, that can be had for $5-$10

 

Are there any good, existing threads about making a pinscape plunger?  I don't want to butcher this one any further by asking questions about it here, but I am interested.

 

 

here is the most extensive thread on the pinscape plunger.... any and all questions answered   (as low as $20 for button controls / accelerometer "real" nudge / analog plunger)

http://www.vpforums.... plunger&page=1

first pic linear potentiometer , second optical sensor  -   both have been working flawless since 2014

Edited by hauntfreaks, 05 September 2016 - 05:46 PM.

[hauntfreaks]

OK, so now I want to ask about physics. To be clear this question is about physics and plungers.

 

ScatterVelocity "amount of randomness added to ball velocity on firing" does not seem to do anything.  The analog plunger in the cab gets randomness just by it's mechanical nature, but when working on my laptop or desktop and using a key for plunge there does not seem to be any variation regardless of what settings I put in there.  Easy to test by just doing a full pull and watch repeatedly where it goes, assuming it's not striking objects that have scatter built into them it will be identical every time.

  this is something that we might have to settle for, since in a real planger there is more going on other than it being pulled back and released....
no matter how smooth you get a real plunger on a real machine, its always has some side to side movement , binding, slop....that i dont "think" it will ever be simulated

as for the scatter i dont think any version of VP I ever seen it really effect the plunger.... I'm sure shock will disagree that VP3 had the best plunger...

[BorgDog]

That's the thing, I WANT the randomness of the real plunger, my real cabinets do not give the exact same plunge every time even if I do may best to pull all the way back and release exactly the same way.  I may be able to get them close, but can't get them exact.  VP is all calculation based, pull the plunger all the way back it will give you the exact same thing every time.  now for the plunger since the variables are exposed I could (and just did for fun) script in some randomness for the release speed, but I thought that is what the ScatterVelocity variable is for, it just doesn't seem to do it.

[sliderpoint]

I know that it does have an effect when used in the script for a plunger.fire.  It was baffling me a bit.  It was set very high - 100. I have never looked at it with the mech plunger though.

 

-Mike

[toxie]

from my understanding of the source, the current impact of scatter on the plunger is very minimal. so unless you have the scatter set high (and of course also the global difficulty setting not zero) it will not do much. and even then its limited to one axis (y).

[BorgDog]

ah, global difficulty, another thing I have not messed around with as I don't really know what it does exactly. So just reading the global difficulty description in the command reference, i really need that set high for any of the scatter variables to have an effect.  I just did a few tests with difficulty set at 100 and plunger scatter at 100 and there seemed to be very very slight variances from full plunge to full plunge as you say Toxie.

 

I'm really looking for it on the non-mechanical plungers as the mechanical/analog plungers vary just in their nature, this is really just for the desktop and launch ball button folks.  I play a lot on my laptop, so I notice the consistency. all the time.

 

I did a little scripting that only effects key based plunger pulls.  I tested my real table by doing a bunch of plunges to see where the max I could get was, relatively easy to see on em tables. I matched that action as best I could in my VP version to give me a max plunger speed.  In the init of the vp table I store the defined max plunger speed with plunger.uservalue=plunger.firespeed, and then in the _keydown sub under If keycode=plungerkey I put in a random variance with plunger.firespeed=plunger.uservalue*(1-((Rnd*5)/100)) so basically every time you pull the plunger it can go up to 5% less than that max randomly.  Easy enough to change from 5 to 4 or whatever once it's in there, and has no effect upon analog plungers.  I kind of like the effect, or basically like not seeing the exact same plunge.

[gtxjoe]

If you want to take actual ball speed measurements, put a trigger at the end of the shooter lane, and you can print the actual ball speed when it triggers it

 

Sub trigger1_hit

    debug.print "Ball speed = " & activeball.vely

End Sub

 

This will be displayed in the debug window as long as you have it opem

[BorgDog]

that's pretty cool Joe.  not sure what I could do with that, but it's cool  oh, and that pigs got issues man 

 

I was just thinking I could tie my little random code to the global difficulty as well, so if it was 0 then there would be no variation.  

[DJRobX]

Please don't call this an issue or bug with those analog plungers, those plunger were designed to auto calibrate this way.  What's being requested is a design change request not a bug fix...

 

We would all be asking for this behavior to be addressed in VP, if the Pinscape did not come up with a novel approach that does not require auto calibration across the full range of motion

 

If your controller is reporting negative values when you first pull it, that's a bug / design flaw / glitch whatever you want to call it.   Why report negative values at all if they're going to cause "misfire" on the first use?   Setting the park position to 0.01 effectively makes negative values useless.   

 

That is NOT to say that we can't or shouldn't work around it in VP!     I continue to recommend a software fix.     Software has to work around hardware idiosyncrasies all the time.  Just that we should look at a fix for this specific hardware type, not changing table defaults.    You should see the mess that I have going to work around the fact that the Mot-ion's nudge sensor is garbage.    

[Shockman]

... I'm sure shock will disagree that VP3 had the best plunger...

 

 

 

I do indeed disagree that VP3 had the best plunger.

Edited by Shockman, 06 September 2016 - 03:35 AM.

[BorgDog]

Feature request!

 

Brought up by fren in THIS thread about a vp version of FPs FlashforMS command to blink lights for a duration, and I thought it would be handy to add to light objects in VPX.  

 

 

 

 a light object BlinkDuration(integer) which by default would be 0 or -1 for blink until shut off, then you could call Light.blinkduration, 50 and it would start it blinking whatever the pattern was currently set as for 50ms. 

 

see the linked thread above for more details, but I personally would use this a lot!  Yes it's fairly easy to script something like this, but it would be even easier to do it without having to make a bunch of _timer subs.

 

Thanks

 

edit:  forgot to add in that should probably have an end-state variable on there as well to tell it either on or off after the blink time (0 or 1) so Light.blinkduration, 50, 1 for blink for 50ms then have light be on.

Edited by BorgDog, 06 September 2016 - 05:41 PM.

[Sir Cheddar]

Well, since I'm slowly becoming active in the VP world again I wanted to say thanks for the contoller/DOF settings you guys put into 10.2.

They are perfect. They put the settings in the registry where they belong, are easily configurable and even allow both sounds and DOF toy as an option which is my favorite

 

Thanks for that one, Arngrim, Toxie and Fuzzel. And, of course, for all the other awesome stuff 

[fuzzel]

Feature request!

 

Brought up by fren in THIS thread about a vp version of FPs FlashforMS command to blink lights for a duration, and I thought it would be handy to add to light objects in VPX.  

 

 

 

 a light object BlinkDuration(integer) which by default would be 0 or -1 for blink until shut off, then you could call Light.blinkduration, 50 and it would start it blinking whatever the pattern was currently set as for 50ms. 

 

see the linked thread above for more details, but I personally would use this a lot!  Yes it's fairly easy to script something like this, but it would be even easier to do it without having to make a bunch of _timer subs.

 

Thanks

 

edit:  forgot to add in that should probably have an end-state variable on there as well to tell it either on or off after the blink time (0 or 1) so Light.blinkduration, 50, 1 for blink for 50ms then have light be on.

But isn't that already there? Check the CommandReference.txt under LIGHT:

State(LightState) - 0=Off, 1=On, 2=Blinking

BlinkInterval(int) - the value is in ms

 

Only the mysterious BlinkPattern only works if set to 10. I didn't understand the meaning of it or what it suppose to do so it could be broken

[sliderpoint]

 

 

But isn't that already there? Check the CommandReference.txt under LIGHT:

State(LightState) - 0=Off, 1=On, 2=Blinking

BlinkInterval(int) - the value is in ms

 

Only the mysterious BlinkPattern only works if set to 10. I didn't understand the meaning of it or what it suppose to do so it could be broken

 

 

BlinkPattern is the off/on pattern for the light to use while the interval is going.

 

Like everything 1 is ON, 0 is OFF.

 

So anything with 1's and 0's will work.   111000111000101010101  blah blah.

 

-Mike

[hauntfreaks]

 

 

But isn't that already there? Check the CommandReference.txt under LIGHT:

State(LightState) - 0=Off, 1=On, 2=Blinking

BlinkInterval(int) - the value is in ms

 

Only the mysterious BlinkPattern only works if set to 10. I didn't understand the meaning of it or what it suppose to do so it could be broken

 

 

BlinkPattern is the off/on pattern for the light to use while the interval is going.

 

Like everything 1 is ON, 0 is OFF.

 

So anything with 1's and 0's will work.   111000111000101010101  blah blah.

 

-Mike

 

 

this for sure is working , Mike has implemented this in CARtoons to simulate a grounding issue on one or two of the bulbs, and it looks AWESOME!!

Edited by hauntfreaks, 06 September 2016 - 07:00 PM.

[cyberpez]

 

 

But isn't that already there? Check the CommandReference.txt under LIGHT:

State(LightState) - 0=Off, 1=On, 2=Blinking

BlinkInterval(int) - the value is in ms

 

Only the mysterious BlinkPattern only works if set to 10. I didn't understand the meaning of it or what it suppose to do so it could be broken

 

 

BlinkPattern is the off/on pattern for the light to use while the interval is going.

 

Like everything 1 is ON, 0 is OFF.

 

So anything with 1's and 0's will work.   111000111000101010101  blah blah.

 

-Mike

 

 

O_O  I had no idea that's how it worked