1488 replies to this topic

[xenonph]

Well the one light on DT backdrop lower left of GIJOE table doesn't light up at all, no matter what intensity you add to it, or how much falloff you add.

Also if you download Sexy Girl the original table I used for this GIJOE mod, you will see other lights acting strange.

Like the Game Over and Ball In Play lights are really super bright.

I adjusted these on my GIJOE mod, so they wouldn't be so bright.

 

Link to Sexy Girl table..

https://www.vpforums...&showfile=12130

 

Here is Sexy Girl with Version VPX_5_beta_rev3427 installed.

Notice the light on word Sexy is in center of the word.

 

And here is Sexy Girl with Version VPX_5_beta_rev3441 installed.

As you can see in the above pics, the lower left light is dimmed somewhat, and the upper left light has moved to left quite a bit and dimmed, all the way to S in Sexy.

 

Also it is hard to not notice these Game Over and Ball In Play lights have gotten severely bright.

 

Or am I the only person who has loaded this table since then?

 

Also, are you saying these DT backdrop lights on the original Sexy Girl table made by Lizard are too big, and are effecting playfield?

I didn't add these lights to GIJOE mod, I just used what was on the original table.

[jpsalas]

I never used normal lights on the desktop, only "bulb" lights. I saw the change in those lights but the change were minimal and I could change them easily. But I see the big change in the normal lights, and I'm not sure if I like them better now.

 

For VPX5 or VPX6 the normal lights should have the image set to the backdrop image not to the lit backdrop image, and an intensity of about 20, and they work as the normal lights in the table. As they are in the sexy girl table they are set to a lit image and an intensity of 500, and that makes me wonder if those lights were not broken before.

Edited by jpsalas, 15 January 2019 - 09:12 AM.

[xenonph]

I just changed the falloff number from 200 to 400 and no change on that bottom left light on GIJOE mod.

But, if i make the light smaller in size,(The yellow part) it starts showing up!!

So I am not sure what to say, except thanks!!

There is no dispute that something changed with the DT Backdrop lighting from those versions mentioned above.

But if the lights can be made to work, just by making light smaller, and then adjusting position by moving over to right a little bit, then really this isn't a big problem.

Thank you for the help JP and Toxie, and sorry if I wasted everyones time looking into this.

You can expect an update to my GIJOE and Christmas Mods in future.

I can get that spotlight to light up now in lower left on GIJOE table!!! (Which was my original plan.)

Thanks again you guys!!

[xenonph]

Ok so I have found another weird DT light problem.

I have been working on new Halloween table with HiRez00, and added GI Lights to DT backdrop.

So I added a bunch of smaller lights, to do the job of what one light used to do, and all seemed well, until I noticed the upper right plastic blinking along with the DT backdrop lights.

I tried lowering all the lights, adjusted everything and nothing was working.

So I moved all the lights on rightside of table off to side, and noticed plastics were still flashing.

That is when I realized it had to be a light on left side of table causing this.

I then started removing lights one by one on left side to see if it had an effect. Low and behold removing a light from the totally opposite side of table fixed it.

How can a light on one side of table, light up plastics on other side of table?

 

Here is pic with the offending left light moved off to left side of screen.

Notice the upper right plastic is not lit.

 

 

Now here is where I originally put the light. (On the word John on upper left DT backdrop.)

Notice the upper right plastic is now lit.

 

 

So how can a light put over the word John on upper left backdrop, light up a plastic on upper right on opposite side of table?

You can see from the pics above, it is this one light doing it.

Obviously I will just leave that light offscreen, but just thought it was really weird behaviour, so I thought I would tell you about it.

[jpsalas]

Maybe set to 0 the "Transmit" property of the light? Just an idea

[xenonph]

Ok I think I need to quit reporting these things here in this beta topic.

I switched light from 0.2 to 0 and now the light doesn't light up the upper right plastics when I move the light back over the word John.

The weird thing is all the other lights are set to 0.2, but only that one light needed to have this change?

Why arent the plastics on the left not lighting up also, seeing how they have same lights in same postion, opposite side?

I am switching them all to 0 just in case. Just doesnt seem logical that switching the numbers on just that one light fixes all.

Why arent the plastics below that upper right plastic not lighting up like the upper right plastics did? There are other DT lights right under the John name light that caused this.

Why arent the upper left plastics lighting up because of the other lights set to 0.2 on opposite side to the right?

Or maybe everyone except me, knows about this and that any DT backdrop light put in that general area where the word John is in upper left, will light up your upper right plastics on other side of table if it doesn't have a 0 for transmit?

So many questions, but thats the only way someone learns is to ask.

Thanks again JPSalas!! You are a MASTER at this!! I kind of feel like an idiot.

I would have never thought that would be the reason, because all the DT Backdrop lights I added have that 0.2 setting for Transmit, and only that one plastic was effected.

I think in the future I will just start asking about these types of things in Help topic, instead of clogging up this beta thread with my lack of knowledge questions.

Let this be a lesson to those people who are afraid to ask a question fearing they will be ridiculed.

If you don't ask, how will you ever learn?

Thanks again JP.

Carry on.

[sliderpoint]

I'm putting up a problem I've seen for quite a while with VP.  Timing of Light Sequences and (with their addition) primitive animations do not play the same on different PC's.  My Cab is an AMD processor and my laptop in an Intel processor.  They both have nvidia graphics cards.  Here are some videos I captured to show the difference.   The cab and laptop vids are to show how much faster my cab shows light sequences than my laptop.  The TimingTest vids show the difference in animation speeds.  That one is also important because it shows that 'timers' do run correctly.  As you can see in the video, the ball hits the target and starts the animation, it also starts a timer to turn on a light 5 seconds later.  The light comes on at the same time on both machines, but animation is way slower on the laptop.

 

Looking to see how this can be solved. 

 

http://gofile.me/2820O/c9SkZOpxG

 

Thanks

-Mike

[toxie]

@xenonph and JP: so the summary of all these recent discussions, bugs and weirdness with lights is that transmit on backdrop lights was not 0?

I'd suggest that i simply force transmit to 0 for all backdrop lights then?!

Anybody against that?

 

I'm putting up a problem I've seen for quite a while with VP.  Timing of Light Sequences and (with their addition) primitive animations do not play the same on different PC's.  My Cab is an AMD processor and my laptop in an Intel processor.  They both have nvidia graphics cards.  Here are some videos I captured to show the difference.   The cab and laptop vids are to show how much faster my cab shows light sequences than my laptop.  The TimingTest vids show the difference in animation speeds.  That one is also important because it shows that 'timers' do run correctly.  As you can see in the video, the ball hits the target and starts the animation, it also starts a timer to turn on a light 5 seconds later.  The light comes on at the same time on both machines, but animation is way slower on the laptop.

 

Hmmm.. @Fuzzel: Seems like some animations are frame rate dependent??

 

 

Something else. Apparently VPX was again used in the design of a real pinball table. 

Attached Files

•  002-tokyo-perfect-drift_visualPinball.jpg   351.91KB   15 downloads

Edited by toxie, 17 January 2019 - 09:54 PM.

[fuzzel]

Yes seems so. I haven't touched the light sequence as far as I know but I can check that when I find some time. Pretty busy these days...

[jpsalas]

@toxie: I think it is a good idea to set the transmit to 0 for all backdrop lights.

[toxie]

@fuzzel: Yeah, i can understand that.. Same for me..  :/

 

@JP: Anything else, especially regarding this weird 'if lights are put too far to the left' issue? Could you point to one specific table of yours and what i should modify there to show that issue? Thanks!!

[jpsalas]

@fuzzel: Yeah, i can understand that.. Same for me..  :/

 

@JP: Anything else, especially regarding this weird 'if lights are put too far to the left' issue? Could you point to one specific table of yours and what i should modify there to show that issue? Thanks!!

 

This weekend I'll send you a table with an example.

[LonelyClooney]

Hi guys, I'm trying to use a primitive as playfield (20.25" x 46", or 514.35mm x 1168.4mm).

After import (XSize = YSize = ZSize = 200) I have to change Table Width and Height to 1029 x 2337 Units so the playfield fits the mesh.

 

Are the VP Units not taken into account (or calculated in the wrong place) when using a Mesh?

 

As I would expect the result to be:

20.25 x 2.54 / 0.53975 = 953

46 x 2.54 / 0.53975 = 2165

instead of

20.25 x 2.54 / 0.5 = 1029

46 x 2.54 / 0.5 = 2337

 

I know that I can estimate the correct size by using Scale 185.27, but how about implementing a new check box giving us the option to convert Mesh sizes automatically to VP Units (probably with the option to double the size)? We wouldn't break old tables but new ones could use correct dimensions (e.g. a 1-1/16" Star Pin is exactly 1-1/16" tall in Blender).

 

Also it would be nice if there would be no reflections of the playfield over cutouts, or at least on playfield areas where the opacity is 0.

 

cheers

[jpsalas]

@fuzzel: Yeah, i can understand that.. Same for me..  :/

 

@JP: Anything else, especially regarding this weird 'if lights are put too far to the left' issue? Could you point to one specific table of yours and what i should modify there to show that issue? Thanks!!

 

Here you have an easy table and you can see how the lights on the backdrop are displayed. They are "bulb" type of lights, just to create some illumination effect on the backgrop.

 

 

You'll notice that:

- All the lights are the same. I always use the modulate on those lights set to 1, but to show better the error they are at 0,9

- The lights on the right look fine but the closer they get to the left the more distorted they get

- The lights at the bottom don't blend with the table. I know all the objects on the backdrop are drawn on top of the table, but I was hoping the lights should just lit up the table if they are too close the the table (this has been always like this, it is not a new "bug")

 

As xenonph said the change in the lights happened during the 10.5 beta, and he wrote the specific revision when the change occurred. I do not have those revisions, but I have 10.4 where the lights work as they should.

Edited by jpsalas, 19 January 2019 - 07:47 AM.

[kiwi]

I'm not sure because until now I have not given much attention, I thought it was my fault,

it seems that sometimes the changes I make in the panels properties of objects are not accepted, I have to do them a second time.

[jpsalas]

I'm not sure because until now I have not given much attention, I thought it was my fault,

it seems that sometimes the changes I make in the panels properties of objects are not accepted, I have to do them a second time.

 

Yes, this happens to me too. One of the things that always must be done when doing a table is to rename all the lights, switches & targets. I found out that sometimes if I rename a light, then click/select the next light and rename it, then the last light did not got renamed. If I click on a light, rename it, then click the playfield and then click the next light to rename it, then the first one gets rename it right.

 

Ok, confused? I'll explained a little better:

 

Click light, rename it, click next light, rename it, click next light, rename it.... Some of the lights will not be renamed.

Click light, rename it, click playfield, click light, rename it, click playfield, click light, rename it.... it use to work 100%. So clicking on the playfield between selection use to commit the changes. I guess the changes get commited when de-selecting the object. But sometimes it doesn't work when selecting another object.

 

A long time ago, before VPX,  we could rename or change parameter in an object and it was updated at once. Later, still a long time ago, we had to press enter to commit the changes. Now in VPX you click on the playfield to commit the changes

 

I haven't reported this before since I use the Windows 10 LTSC version, and I'm not sure if it is always 100% compatible with everything But it is nice to to have Windows 10 without all the extra garbage

Edited by jpsalas, 20 January 2019 - 08:28 AM.

[fuzzel]

Hmm that is strange. I tried to reproduce this but everytime when I select a light rename it then click on the next light rename it and so on, all lights have their new names. That must be some strange Win32 GUI behavior that effects some machines and not all...hmm

[jpsalas]

Hmm that is strange. I tried to reproduce this but everytime when I select a light rename it then click on the next light rename it and so on, all lights have their new names. That must be some strange Win32 GUI behavior that effects some machines and not all...hmm

 

This is one of the reasons I have never reported. There are usually about 64 lights in a vpinmame table, and maybe only 2 or 3 lights do not get renamed. So it is a very difficult bug to reproduce. And this happened to me in the Windows 7 computer too, but I don't use it much for VP since it is the work computer But I wanted to tell Kiwi, that this not only happens to him. Also in my computer VPX crashes a lot, but mostly are only ntdll.dll in the crash so it doesn't help you at all. For ex. like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:77391E0B
Attempt to write to 0x00000014
Thread ID: 0x1910 [6416]

Call stack
==========
77391E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x2EDFE060 0x02CA4DC0 0x00000000 0x00000001)
7738FF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x2edfe0d8)
7738FE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x2EDFE0D8 0x02C60A50 0x750E6D20 0x0019cfc4)

 

or like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:777B1E0B
Attempt to write to 0x00000014
Thread ID: 0xBAC [2988]

Call stack
==========
777B1E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x0884C160 0x02FD3460 0x00000000 0x00000001)
777AFF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x0884c1d8)
777AFE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x0884C1D8 0x02F8E9A0 0x76D16D20 0x0019cfc4)

[fuzzel]

I'm putting up a problem I've seen for quite a while with VP.  Timing of Light Sequences and (with their addition) primitive animations do not play the same on different PC's.  My Cab is an AMD processor and my laptop in an Intel processor.  They both have nvidia graphics cards.  Here are some videos I captured to show the difference.   The cab and laptop vids are to show how much faster my cab shows light sequences than my laptop.  The TimingTest vids show the difference in animation speeds.  That one is also important because it shows that 'timers' do run correctly.  As you can see in the video, the ball hits the target and starts the animation, it also starts a timer to turn on a light 5 seconds later.  The light comes on at the same time on both machines, but animation is way slower on the laptop.

 

Looking to see how this can be solved. 

 

http://gofile.me/2820O/c9SkZOpxG

 

Thanks

-Mike

I suppose you use Win10 on your laptop and what OS is running the cab?

 

Hmm that is strange. I tried to reproduce this but everytime when I select a light rename it then click on the next light rename it and so on, all lights have their new names. That must be some strange Win32 GUI behavior that effects some machines and not all...hmm

 

This is one of the reasons I have never reported. There are usually about 64 lights in a vpinmame table, and maybe only 2 or 3 lights do not get renamed. So it is a very difficult bug to reproduce. And this happened to me in the Windows 7 computer too, but I don't use it much for VP since it is the work computer But I wanted to tell Kiwi, that this not only happens to him. Also in my computer VPX crashes a lot, but mostly are only ntdll.dll in the crash so it doesn't help you at all. For ex. like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:77391E0B
Attempt to write to 0x00000014
Thread ID: 0x1910 [6416]

Call stack
==========
77391E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x2EDFE060 0x02CA4DC0 0x00000000 0x00000001)
7738FF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x2edfe0d8)
7738FE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x2EDFE0D8 0x02C60A50 0x750E6D20 0x0019cfc4)

 

or like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:777B1E0B
Attempt to write to 0x00000014
Thread ID: 0xBAC [2988]

Call stack
==========
777B1E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x0884C160 0x02FD3460 0x00000000 0x00000001)
777AFF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x0884c1d8)
777AFE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x0884C1D8 0x02F8E9A0 0x76D16D20 0x0019cfc4)

 

Does the crash happens while you are in the editor and select an element? The call stack isn't much of a help but maybe I can try to check VPX with another tool if we have some race conditions or other hard to find corruptions that are responsible for these crashes.

[jpsalas]

 

I'm putting up a problem I've seen for quite a while with VP.  Timing of Light Sequences and (with their addition) primitive animations do not play the same on different PC's.  My Cab is an AMD processor and my laptop in an Intel processor.  They both have nvidia graphics cards.  Here are some videos I captured to show the difference.   The cab and laptop vids are to show how much faster my cab shows light sequences than my laptop.  The TimingTest vids show the difference in animation speeds.  That one is also important because it shows that 'timers' do run correctly.  As you can see in the video, the ball hits the target and starts the animation, it also starts a timer to turn on a light 5 seconds later.  The light comes on at the same time on both machines, but animation is way slower on the laptop.

 

Looking to see how this can be solved. 

 

http://gofile.me/2820O/c9SkZOpxG

 

Thanks

-Mike

I suppose you use Win10 on your laptop and what OS is running the cab?

 

Hmm that is strange. I tried to reproduce this but everytime when I select a light rename it then click on the next light rename it and so on, all lights have their new names. That must be some strange Win32 GUI behavior that effects some machines and not all...hmm

 

This is one of the reasons I have never reported. There are usually about 64 lights in a vpinmame table, and maybe only 2 or 3 lights do not get renamed. So it is a very difficult bug to reproduce. And this happened to me in the Windows 7 computer too, but I don't use it much for VP since it is the work computer But I wanted to tell Kiwi, that this not only happens to him. Also in my computer VPX crashes a lot, but mostly are only ntdll.dll in the crash so it doesn't help you at all. For ex. like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:77391E0B
Attempt to write to 0x00000014
Thread ID: 0x1910 [6416]

Call stack
==========
77391E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x2EDFE060 0x02CA4DC0 0x00000000 0x00000001)
7738FF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x2edfe0d8)
7738FE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x2EDFE0D8 0x02C60A50 0x750E6D20 0x0019cfc4)

 

or like this one:

 

Crash report VPX rev3592
============
Process: VPinballX.exe
Reason: 0xC0000005 - EXCEPTION_ACCESS_VIOLATION at 0023:777B1E0B
Attempt to write to 0x00000014
Thread ID: 0xBAC [2988]

Call stack
==========
777B1E0B ntdll.dll LdrRemoveLoadAsDataTable + 0x61B (0x0884C160 0x02FD3460 0x00000000 0x00000001)
777AFF16 ntdll.dll RtlEnterCriticalSection + 0x126 (0x005063B2 0x00000000 0x005064EA 0x0884c1d8)
777AFE39 ntdll.dll RtlEnterCriticalSection + 0x49 (0x0884C1D8 0x02F8E9A0 0x76D16D20 0x0019cfc4)

 

Does the crash happens while you are in the editor and select an element? The call stack isn't much of a help but maybe I can try to check VPX with another tool if we have some race conditions or other hard to find corruptions that are responsible for these crashes.

 

 

Most of these crashes happens when I quit VPX. Mostly when I have copied something from another table.