1031 replies to this topic

[Gaston]

 

One request: Adjustable flippers strength via script or ROM controlled to be able to fully support Capcom games. Especially the flippers in KingPin are important (get weaker and stronger while playing).

 

In the case of KingPin, I think the tricky part is getting the solenoid strength out of the ROM.    It would work in theory for SAM/WPC with the UseVPMModSol option.    Even then it probably won't work that great, ModSol is an "averaging" technique that would probably produce strange results with flippers.   Since I think we're only talking about one game (KingPin) it would probably be more appropriate to try and use something like CheatEngine or MAME debugger to determine what memory values hold the flipper strength state, and try to pass that along to the table.    

 

 

I had a look at how the game (most likely) does it...

the result is: flippers are pulsed using solenoids 9 & 10.

 

On activation of a flipper button, there will be a pulse stream of this kind: "10111101011101111011101101111011", 1 meaning energy is applied and 0 is not.

Now after a few milliseconds, only rarely a pulse will follow to keep the flipper finger up: "100000000000000001000000000001000000000000000000100000..."

So the emulation could count how often the bit was 1 in a given period of time and calculate a value from that, but it would be flaky because the pulses are not evenly spaced.

 

We might also provide the bits as they are happening to some other output (say, Solenoids2 or GI lamps) and leave it to the table author to handle them, but my guess is no update would be fast enough to keep track, and single pulses could easily be missed.

[DJRobX]

 

One request: Adjustable flippers strength via script or ROM controlled to be able to fully support Capcom games. Especially the flippers in KingPin are important (get weaker and stronger while playing).

 
In the case of KingPin, I think the tricky part is getting the solenoid strength out of the ROM.    It would work in theory for SAM/WPC with the UseVPMModSol option.    Even then it probably won't work that great, ModSol is an "averaging" technique that would probably produce strange results with flippers.   Since I think we're only talking about one game (KingPin) it would probably be more appropriate to try and use something like CheatEngine or MAME debugger to determine what memory values hold the flipper strength state, and try to pass that along to the table.    
 

 
I had a look at how the game (most likely) does it...
the result is: flippers are pulsed using solenoids 9 & 10.
 
On activation of a flipper button, there will be a pulse stream of this kind: "10111101011101111011101101111011", 1 meaning energy is applied and 0 is not.
Now after a few milliseconds, only rarely a pulse will follow to keep the flipper finger up: "100000000000000001000000000001000000000000000000100000..."
So the emulation could count how often the bit was 1 in a given period of time and calculate a value from that, but it would be flaky because the pulses are not evenly spaced.
 
We might also provide the bits as they are happening to some other output (say, Solenoids2 or GI lamps) and leave it to the table author to handle them, but my guess is no update would be fast enough to keep track, and single pulses could easily be missed.

yes that is what the modulated solenoid feature in WPC and SAM deals with. It sends average “intensity” but as you also note, determining the right cadence intervals is key for it to work well.


Sent from my iPhone using Tapatalk

[chepas]

When creating a lamp. The initial size has a falloff of 600 and bigger than the table?

[fuzzel]

Hmm didn't touch the lamp code in the last couple of revisions maybe something went wrong for your default values in the registry?

[chepas]

Yeah that was it. I never knew the values were saved back there, I think that is the first time I've ever seen a different size when you click the light button. It got me thinking that a few light sizes would be great as presets.

[nFozzy]

'set as default' does in the context menu change the defaults for each type of object

[toxie]

@DJRobX: Are you willing to tackle this maybe? 

[wrd1972]

Fuzzel, Toxie,

I am pretty certain there is a bug with the global flipper physics...which I am using a great deal now to mange the tons of tables on the cab.

 

I am ASSuming that any flipper value recorded in the global flipper set, should over-ride any value in the flipper properties of any table. At least I hope that is the intent. The once exception being flipper strength...whereas a -1 in the global flipper physics, will then defer to the strength value entered into the flipper properties. So it appears that the other values that I am using in global flipper physics such as mass, return strength etc. are NOT over-riding the values in the flipper properties. SO any changes to global, does NOT affect the table but changes to the flipper properties...do.

 

I am also running the latest beta version. I am gonna blindly ASSume that the other global values are likely broken as well. Will you guys kindly take a look at the code and ensure that the global flipper physics are indeed working as designed.

 

Many thanks for the continued efforts and dedication.

[gtxjoe]

Read the flipper settings while the table is running.  I did see some values not being over-ridden like eostorque, but there are others also

 

Add this to bottom of script.  Start table, Escape and click on debugger, click on > and then type in checkflippers  then press enter key to dump all the flipper values

Sub checkflippers
	debug.print "LEFT"
	debug.print "mass: " & leftflipper.mass
	debug.print "str: " & leftflipper.strength
	debug.print "elas: " & leftflipper.elasticity
	debug.print "elfa: " & leftflipper.elasticityfalloff
	debug.print "fric: " & leftflipper.friction
	debug.print "ret: " & leftflipper.return
	debug.print "ramp: " & leftflipper.rampup
	debug.print "scat: " & leftflipper.scatter
	debug.print "eost: " & leftflipper.eostorque
	debug.print "eosa: " & leftflipper.eostorqueangle

	debug.print ""
	debug.print "RIGHT"
	debug.print "mass: " & rightflipper.mass
	debug.print "str: " & rightflipper.strength
	debug.print "elas: " & rightflipper.elasticity
	debug.print "elfa: " & rightflipper.elasticityfalloff
	debug.print "fric: " & rightflipper.friction
	debug.print "ret: " & rightflipper.return
	debug.print "ramp: " & rightflipper.rampup
	debug.print "scat: " & rightflipper.scatter
	debug.print "eost: " & rightflipper.eostorque
	debug.print "eosa: " & rightflipper.eostorqueangle

End Sub

[wrd1972]

Thanks Joe,

Can I perform a similar test for the other setting in global such as slope, friction etc.

 

Toxie, Fuzzel,

So I can now completely confirm that the global flipper physics are NOT overt-riding the setting in any given tables, flipper properties window. Can this be addressed for your next release?

[ClarkKent]

 

 

 

One request: Adjustable flippers strength via script or ROM controlled to be able to fully support Capcom games. Especially the flippers in KingPin are important (get weaker and stronger while playing).

 
In the case of KingPin, I think the tricky part is getting the solenoid strength out of the ROM.    It would work in theory for SAM/WPC with the UseVPMModSol option.    Even then it probably won't work that great, ModSol is an "averaging" technique that would probably produce strange results with flippers.   Since I think we're only talking about one game (KingPin) it would probably be more appropriate to try and use something like CheatEngine or MAME debugger to determine what memory values hold the flipper strength state, and try to pass that along to the table.    
 

 
I had a look at how the game (most likely) does it...
the result is: flippers are pulsed using solenoids 9 & 10.
 
On activation of a flipper button, there will be a pulse stream of this kind: "10111101011101111011101101111011", 1 meaning energy is applied and 0 is not.
Now after a few milliseconds, only rarely a pulse will follow to keep the flipper finger up: "100000000000000001000000000001000000000000000000100000..."
So the emulation could count how often the bit was 1 in a given period of time and calculate a value from that, but it would be flaky because the pulses are not evenly spaced.
 
We might also provide the bits as they are happening to some other output (say, Solenoids2 or GI lamps) and leave it to the table author to handle them, but my guess is no update would be fast enough to keep track, and single pulses could easily be missed.

yes that is what the modulated solenoid feature in WPC and SAM deals with. It sends average “intensity” but as you also note, determining the right cadence intervals is key for it to work well.

 

Great finding! By the way - the Capcom settings have e.g. "Sol. Voltage Percent" and "Flipper strength". These options can only be used if it's emulated...

[fuzzel]

Thanks Joe,

Can I perform a similar test for the other setting in global such as slope, friction etc.

 

Toxie, Fuzzel,

So I can now completely confirm that the global flipper physics are NOT overt-riding the setting in any given tables, flipper properties window. Can this be addressed for your next release?

Sure...I'll take a look. 

[toxie]

Oh my, it's a mess.. Seems like EOS Torque and EOS Torque Angle are not even wired up at all..  :/

[toxie]

At least that part is fixed now.

[wrd1972]

Thanks Toxie,

Are the other settings in global connected properly too. I think I recall slope working but I have not tested the others. I can test these fixes on your next release.

[osujd]

Ok maybe this is a stupid idea but I figured I would throw it out there.  Could vpx do a couple of different pre-rendered views for table settings (overhead, perspective, custom etc).  By that I mean I feel like a big difference between how good a game looks are determined by how well the full screen settings are set.  This is really hard to achieve even with using the F6 on startup.  The author would still have the authority to set a custom viewpoint, but user could also use default viewpoints to maintain consistency among tables.

[kiwi]

Probably it is a request already made,
currently, the lights used for the playfield inserts don't blend together if placed one on top of the other.

[fuzzel]

Probably it is a request already made,
currently, the lights used for the playfield inserts don't blend together if placed one on top of the other.

Don't know if that was already requested but that is not easily implemented because we had to read back the render buffer to blend the second light with the result of the first light. Such tasks are very time consuming because dx9 doesn't allow to access the render buffer while you're rendering to it.

[gtxjoe]

Ok maybe this is a stupid idea but I figured I would throw it out there.  Could vpx do a couple of different pre-rendered views for table settings (overhead, perspective, custom etc).  By that I mean I feel like a big difference between how good a game looks are determined by how well the full screen settings are set.  This is really hard to achieve even with using the F6 on startup.  The author would still have the authority to set a custom viewpoint, but user could also use default viewpoints to maintain consistency among tables.

 

VPX already has ability to export and import these F6/POV settings. 

 

Export a POV from a table you like and try use that default viewpoint on all your tables.  File->Export/Import -> Backdrop POV

[toxie]

 

Read the flipper settings while the table is running.  I did see some values not being over-ridden like eostorque, but there are others also

 

Add this to bottom of script.  Start table, Escape and click on debugger, click on > and then type in checkflippers  then press enter key to dump all the flipper values

Sub checkflippers
	debug.print "LEFT"
	debug.print "mass: " & leftflipper.mass
	debug.print "str: " & leftflipper.strength
	debug.print "elas: " & leftflipper.elasticity
	debug.print "elfa: " & leftflipper.elasticityfalloff
	debug.print "fric: " & leftflipper.friction
	debug.print "ret: " & leftflipper.return
	debug.print "ramp: " & leftflipper.rampup
	debug.print "scat: " & leftflipper.scatter
	debug.print "eost: " & leftflipper.eostorque
	debug.print "eosa: " & leftflipper.eostorqueangle

	debug.print ""
	debug.print "RIGHT"
	debug.print "mass: " & rightflipper.mass
	debug.print "str: " & rightflipper.strength
	debug.print "elas: " & rightflipper.elasticity
	debug.print "elfa: " & rightflipper.elasticityfalloff
	debug.print "fric: " & rightflipper.friction
	debug.print "ret: " & rightflipper.return
	debug.print "ramp: " & rightflipper.rampup
	debug.print "scat: " & rightflipper.scatter
	debug.print "eost: " & rightflipper.eostorque
	debug.print "eosa: " & rightflipper.eostorqueangle

End Sub

 

I hope all of this is fixed with the next build, but can you guys please check/test this and let me know which ones are still not behaving correctly (if any)?!