4027 replies to this topic

[fuzzel]

I put a timer on a table and renamed it, however in the script is did not take the new name, it still had the original name. Also, I changed the interval from 100 to 10 and when I clicked off and back on the timer, it went back to 100. Sorry to report these bugs, but I guess thats what we are here for. The latest build.

Thanks for the feedback. That's the main reasons for this thread

[grunger106]

I've noticed something similar when adjusting the POV settings manually in 10.6 actually - if you adjust a Y setting for example, it will work, but if you then attempt to adjust any other setting it will revert when you click off it.
If you launch the table and then exit it you can then do another setting.

Not a big issue of course (and maybe most people are doing their POV adjustments via the live route these days?)

[LynnInDenver]

Reported over at VPinball in 10.6... someone noticed that you can Disable a trigger, and it no longer posts Hit events... except when the ball has a Z-axis change while passing the trigger (falling from a ramp/platform onto the trigger), at which point it still reports a Hit event even when disabled. They were using Disable to keep the trigger from posting a Hit event unless a certain number of Targets were hit, at which point they would Enable it, but their playfield design revision has provided for the Z-axis change from certain angles. I provided a workaround using If Then, but it doesn't hurt to point out the difference in behavior in a Disabled trigger.

[fuzzel]

I put a timer on a table and renamed it, however in the script is did not take the new name, it still had the original name. Also, I changed the interval from 100 to 10 and when I clicked off and back on the timer, it went back to 100. Sorry to report these bugs, but I guess thats what we are here for. The latest build.

Fixed in the next version

[fuzzel]

Reported over at VPinball in 10.6... someone noticed that you can Disable a trigger, and it no longer posts Hit events... except when the ball has a Z-axis change while passing the trigger (falling from a ramp/platform onto the trigger), at which point it still reports a Hit event even when disabled. They were using Disable to keep the trigger from posting a Hit event unless a certain number of Targets were hit, at which point they would Enable it, but their playfield design revision has provided for the Z-axis change from certain angles. I provided a workaround using If Then, but it doesn't hurt to point out the difference in behavior in a Disabled trigger.

Do you have a test table? I tried to reproduce it with a ramp where the ball falls down onto a trigger with disabled hit events and everything works as expected.

[LynnInDenver]

I don't have a test table for it, I'm afraid. Just a report from another user, makmak. I'll see if I can get him to pipe up over here. But he described it as specifically from the ball falling onto the trigger from a higher point.

Edited by LynnInDenver, 30 April 2020 - 01:13 PM.

[toxie]

I would imagine it is related to the mesh playfield, but the geometry is sound, normals facing up, and works fine in 10.6.

 

http://vpforums.org/...162/pf_mesh.jpg

oh cool, all holes in, like the real one.. neat.. maybe related to the tiny changes in the physics engine, thanks for the hint!

[makmak]

Sry dudes, I tend to post to the wrong threads... have not installed .7 yet , but the following i noticed on .6:

animation of gates is strange when set to both ways open and back. Wires tend to stay open then against gravity, see AfM table upper gates for example.

disabled triggers react on a ball moving in z-axis (only), means a ball falling from a ramp onto the trigger fired the event although it was disabled. Not sure if I can find the exact version of my table with this effect again as i am scripting right now. Found a good solution to prevent. Maybe the fault was on my side, maybe not, cant tell, but most likely my fault.

Great stuff you guys hammer together here ;-) thanks for so much fun you provide!

[jpsalas]

Just a small note: in AFM the top gates are not normal gates, they are controlled by the ROM, so they keep open sometimes, yes  

[makmak]

Its the same behaviour on my original/non-romcontrolled table. Movement of the ball (through or bounce) is correct, but the animation of the wires is wrong.

[toxie]

if possible, please provide a simple(!) repro table for both the trigger and gate issues.

 

in general:

the simpler a bug is to repro for us, the higher the chance that we will look at it earlier.

[mfuegemann]

Hi,

 

maybe it is this behaviour, we had in VPX10.6 and maybe earlier too. Once You control a gate manually, the visuals are broken.

After a hard hit the gate stays visually open but is closed for the ball.

 

Attached You find a table with a gate at the plunger. The gate can be opened by pressing the left flipper key. 

If the left flipper key has not been touched, the gate operates as it should. The ball passes and the gate shuts again.

Once You opened the gate manually, the next plunge will leave the gate visually open, but the ball cannot pass through and the gate.open property is false.

 

I had to use pairs of gates for some tables to get the visuals right (one controlled, one visible with a link via gate.currentangle).

 

Michael

 

Attached Files

•  Gate_Demo.zip   6.38MB   5 downloads

[makmak]

Exactly what i wanted to describe;-)

[DJRobX]

I noticed in the most recent version it is hard to set the flasher images in the drop-downs if using the arrow keys to browse.   It doesn't accept <enter> to confirm the selection.   If you <tab> away from it it goes back to its earlier setting. 

[DJRobX]

Hi,

 

maybe it is this behaviour, we had in VPX10.6 and maybe earlier too. Once You control a gate manually, the visuals are broken.

After a hard hit the gate stays visually open but is closed for the ball.

 

 

I think that's expected - the move function is intended for scripted gates.  Once you touch it, the gate relinquishes its visuals to the script.    Otherwise you'd have the script and the physics fighting with each other for what to show. 

It's even described that way in the code comments:

STDMETHODIMP Gate::Move(int dir, float speed, float angle) //move non-collidable gate, for graphic effects only

I think altering this behavior is dangerous now as it would affect backward compatibility.   But perhaps a new function could be added to reset 

  m_phitgate->m_gateMover.m_forcedMove = true;
 

back to false, resuming regular VP-controlled movement...

 

-- Rob 

[jpsalas]

I just got this error/crash. I loaded a table, then I wanted to copy the flippers from another table, loaded that table, but it was the wrong table, so I clicked on the File menu and the editor closed. I guess it didn't manage to draw the window. Maybe the crash report will tell you something:

 

Crash report VPX rev4066

============

Process: VPinballX7.exe

Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:76808CA7

Attempt to read from 0x00380078

Thread ID: 0x254 [596]

 

Call stack

==========

76808CA7 KERNELBASE.dll MultiByteToWideChar + 0x187 (0x00000000 0x00000000 0x00380078 0xfffffffffffffffe)

00581648 VPinballX7.exe (0x00380078 0x00581700 0x00000000 0x0000002c)

00581741 VPinballX7.exe (0x00380078 0x0A78D6B0 0x0000002C 0x02f658b0)

0058195C VPinballX7.exe (0x0019EC34 0x0057B1BD 0x0000002C 0x00000000)

00581A73 VPinballX7.exe (0x004255F0 0x0015022E 0x0000002C 0x00000000)

762E67BC user32.dll CallWindowProcW + 0xB2C (0x004255F0 0x00000000 0x0000002C 0x00000000)

762E635A user32.dll CallWindowProcW + 0x6CA (0x039A0B80 0x00000000 0x0000002C 0x00000000)

76343959 user32.dll RegisterLogonProcess + 0x1589 (0x0019EC24 0x00000030 0x0019EE1C 0x77602a10)

77602ADD ntdll.dll KiUserCallbackDispatcher + 0x4D (0x039A0B80 0x00000000 0x00220146 0x00000001)

762D6F77 user32.dll SendMessageA + 0x277 (0x0015022E 0x00000112 0x0000F095 0x00220146)

748602E3 uxtheme.dll EnableThemeDialogTexture + 0xE3 (0x05984930 0x0019ED84 0x00000001 0x74853460)

74862D37 uxtheme.dll OpenThemeData + 0x2707 (0x0000F095 0x00220146 0x00000000 0x0019ee2c)

74853478 uxtheme.dll GetThemeBackgroundRegion + 0x578 (0x0015022E 0x00000112 0x0000F095 0x00220146)

762D3437 user32.dll DefMDIChildProcA + 0x3E7 (0x0015022E 0x00000112 0x0000F095 0x00220146)

0057BA9F VPinballX7.exe (0x004255F0 0x0015022E 0x00000112 0x0000f095)

762E67BC user32.dll CallWindowProcW + 0xB2C (0x004255F0 0x00000000 0x00000112 0x0000f095)

762E635A user32.dll CallWindowProcW + 0x6CA (0x039A0B80 0x00000000 0x00000112 0x0000f095)

762F312F user32.dll IsRectEmpty + 0x20F (0x0019F06C 0x00000020 0x0019F260 0x77602a10)

77602ADD ntdll.dll KiUserCallbackDispatcher + 0x4D (0x039A0B80 0x00000000 0x00220146 0x00000001)

762D6F77 user32.dll SendMessageA + 0x277 (0x0015022E 0x000000A1 0x00000005 0x00220146)

748602E3 uxtheme.dll EnableThemeDialogTexture + 0xE3 (0x05984930 0x0019F1C4 0x00000001 0x74853460)

74862D37 uxtheme.dll OpenThemeData + 0x2707 (0x00000005 0x00220146 0x00000000 0x0019f270)

74853478 uxtheme.dll GetThemeBackgroundRegion + 0x578 (0x0015022E 0x000000A1 0x00000005 0x00220146)

762D3437 us

Environment

===========

Date/time: 1/5/2020, 04:34:27:152

Number of CPUs: 8

Processor type: 586

System: Windows 10 (10.0 17763)

 

Memory status

=============

Total Reserved: 83080K (81M) bytes

Total Commited: 488744K (477M) bytes

Total Free: 3622416K (3537M) bytes

Largest Free: 2095452K (2046M) bytes

 

Registers

=========

EAX=00380078 EBX=7FFFFFFF ECX=00000000 EDX=00000000

ESI=00380078 EDI=000004E4 EBP=0019F270 ESP=0019F228 EIP=762D3437

FLG=00210297 CS=0023 DS=002B SS=002B ES=002B FS=0053 GS=002B

[webby]

Hi Guys,

I must say first, Great work, really appreciated by everyone.

 

Thanks,

Webster

Edited by webby, 01 May 2020 - 04:07 AM.

[makmak]

 

Hi,

 

maybe it is this behaviour, we had in VPX10.6 and maybe earlier too. Once You control a gate manually, the visuals are broken.

After a hard hit the gate stays visually open but is closed for the ball.

 

 

I think that's expected - the move function is intended for scripted gates.  Once you touch it, the gate relinquishes its visuals to the script.    Otherwise you'd have the script and the physics fighting with each other for what to show. 

It's even described that way in the code comments:

STDMETHODIMP Gate::Move(int dir, float speed, float angle) //move non-collidable gate, for graphic effects only

I think altering this behavior is dangerous now as it would affect backward compatibility.   But perhaps a new function could be added to reset 

  m_phitgate->m_gateMover.m_forcedMove = true;
 

back to false, resuming regular VP-controlled movement...

 

-- Rob 

 

my guess is, the states are not defined or a mix up of visual and technical things. IMHO it should be:

 

gate closed: wires down, ball bounces off from both sides

gate open to one side (left or right): ball bounces off and wires down from the one side , but ball goes through and wires swinging to the other side

gate open to both sides: ball through from both sides and wires swinging to both sides as well

 

maybe theres another state but i dont know what its good for: gate open two both sides and wires are up.

[kiwi]

The bottom bar does not display the correct position of the mouse pointer, the reading error value varies with zoom.

 
Primitives: it is not easy to change the number of Legacy/Sides, it does not have an immediate effect, after a few maneuvers it updates itself,
TransY and TransZ, any value used then becomes 100 and it is not possible to change it.

[galahad1966]

Great update! Thank you!

 

Greetz,

Galahad.