2087 replies to this topic

[DJRobX]

 

Strange, nothing changed in the latest revisions that could explain that behavior. Can you check if you have installed the proper Visual Studio redistributable package, you need 2008 and 2010?

 

 

GTXJoe had problems running VP as administrator in Test13.  

 

Your builds have the project setting which triggers UAC automatically, so now he effectively has this problem all the time.  

[gtxjoe]

I have not run into this problem again on my pincab, only on my work laptop which probably has some user account restrictions even though I have an admin account.  Don't worry about this unless others encounter the issue.

[StevOz]

OK deleting the registry keys and setting it back to non admin, no compatability modes then running the first time at the default settings, then switching to my monitor resolution in windowed mode seems to have fixed it. I do notice the alpha ramps blink on occasion, along with the occasional bumper cap vanishing and the ball going black sometimes.

[mukuste]

 

 

Strange, nothing changed in the latest revisions that could explain that behavior. Can you check if you have installed the proper Visual Studio redistributable package, you need 2008 and 2010?

 

 

GTXJoe had problems running VP as administrator in Test13.  

 

Your builds have the project setting which triggers UAC automatically, so now he effectively has this problem all the time.  

 

 

Those weird behaviors are generally due to VP picking up the wrong typelib. VP always tries to register its typelib at startup. (The code is in vbatest.cpp somewhere, IIRC.) It used to be that it tried to do this system-wide, which is why it needed to be run as admin at least the first time. I then changed it to register it only for the current user a couple of weeks ago, which allows it to be run as non-admin now.

 

Now it seems that, weirdly enough, sometimes when running as admin it will pick up the old typelib which leads to undefined behavior. In your Start Menu you should have a program called OLE-COM Object Viewer, you can run that and check under Type Libraries > Visual Pinball which one is registered. What I did to fix this was to completely unregister the old VP typelib from my system, but you need to do this from the command line AFAIK.

 

I think, but haven't had time to test this, that the proper fix within VP would be to check whether it is running as admin, in which case the old system-wide register function should be called, or otherwise just use the user-specific one which it uses currently. I might try this at some point, unless someone else gets around to it first. For now the best step would be to disable this UAC setting in the VS project since it's generally not needed for most people.

 

This whole COM business is still mostly a mystery to me, there are layers upon layers of complexity in this whole system and I never quite know what it does internally.

[DJRobX]

For now the best step would be to disable this UAC setting in the VS project since it's generally not needed for most people.

 

 

 

Sadly it seems people do still need to run as administrator - there are tables that write high scores to files, that fail if VP isn't run as administrator.   

 

See this post for an example.   I saw a few people complaining about it on and off, but it took me a while to correlate this to the fact that your build didn't trigger UAC the same way as the official builds.  

Edited by DJRobX, 06 April 2014 - 02:34 PM.

[naboodiver]

@naboodiver:

 

I went into the image manager, there are five different pf_XX textures. For all five of them, I clicked on the transparency color and set it to pure black (make sure it's really RGB 0,0,0). This fixed it for me.

 

I tested this on Test13, if it doesn't work in the latest revision then there must have been some change inbetween which messed with it.

 

Mukuste:   Finally got around to trying your suggested change...  You are the man.    Worked like a charm.    Thanks for the guidance .    I was concentrating on the lights rather than the playfield image.    I need to broaden my thought process.

Edited by naboodiver, 06 April 2014 - 02:44 PM.

[mukuste]

 

For now the best step would be to disable this UAC setting in the VS project since it's generally not needed for most people.

 

 

 

Sadly it seems people do still need to run as administrator - there are tables that write high scores to files, that fail if VP isn't run as administrator.   

 

See this post for an example.   I saw a few people complaining about it on and off, but it took me a while to correlate this to the fact that your build didn't trigger UAC the same way as the official builds.  

 

Yeah, that seems to be the only reason to still have it on currently. As far as I know, putting your tables somewhere within your user directory will fix that? Since you don't need admin rights to write there. Alternatively, I guess you could change the Security settings on the folder which the table is trying to write to so that everyone has write access there.

Edited by mukuste, 06 April 2014 - 03:46 PM.

[DJRobX]

 

Yeah, that seems to be the only reason to still have it on currently. As far as I know, putting your tables somewhere within your user directory will fix that? Since you don't need admin rights to write there. Alternatively, I guess you could change the Security settings on the folder which the table is trying to write to so that everyone has write access there.

 

 

Right, although I think since the aim of this version is to be backwards compatible, following the old method (UAC compile setting + global COM registration) is probably going to generate the least amount of headaches for people who are just trying to substitute in a new version of vpinball.exe and get up and running.  

 

In VP10 we should remove it though, and instead give table authors a specific place to put RW data, that defaults somewhere in the user directory, to follow the limited security model correctly. 

Edited by DJRobX, 06 April 2014 - 06:31 PM.

[ClarkKent]

There is still a display bug on the left insanity falls ramp in White Water (segmented, distorted texture).

Attached Files

•  bug.png   175.48KB   13 downloads

[dyopp21]

Following up (from this thread http://www.vpforums....topic=26917&hl=) concerning double target hits.  Would there be any way to fix the inability to hit two targets simultaneously in the upcoming release of VP, or is this something that will have to be implemented by the author when a table is created?

 

I realize this is a small nuisance, but I think it is still ultimately worth pursuing. 

[slashbot]

I found a bug with the latest vp version of junkyard
All the lights are white




Sent from my iPad using Tapatalk HD

[boiydiego]

als je wil kan je bijmij zien welk de instellingen zijn , heb dat ook gehad op tafelmenu ru verzetten.

Edited by boiydiego, 07 April 2014 - 08:40 PM.

[fuzzel]

I found a bug with the latest vp version of junkyard
All the lights are white




Sent from my iPad using Tapatalk HD

Hmm can't reproduce that. JY works as expected with rev980 on my cab!

[fuzzel]

There is still a display bug on the left insanity falls ramp in White Water (segmented, distorted texture).

This is the depth ordering problem. This ramp is done with two ramps of the same height. On some ramp parts you see the z-fighting problem. To fix this select all ramps with the plastics image and raise the top and bottom height bei 0.1 and the segments are gone.

[mfuegemann]

Hi slashbot,

 

I am not able to reproduce the behaviour, described by You. But looking over the options and table details, I got an idea to bypass the current DX9 errors on this table.

You may want to check out the new DX9 version of JY.

 

Regards

Michael

[DJRobX]

 

This is the depth ordering problem. This ramp is done with two ramps of the same height. On some ramp parts you see the z-fighting problem. To fix this select all ramps with the plastics image and raise the top and bottom height bei 0.1 and the segments are gone.

 

 

Only 25 ramps!   Ugh, LOL. 

 

1054, 1055, 1056, 1057, 975, 974, 973, 972 971, 970, 485, 328, 327, 326,  325, 324, 323, 322, 321, 320, 319, 317, 306, 305, 304   

 

If the depth bias adjustment helped, you could at least select them all and just plug in a number, but it doesn't seem to work for this case. 

[mukuste]

 

 

This is the depth ordering problem. This ramp is done with two ramps of the same height. On some ramp parts you see the z-fighting problem. To fix this select all ramps with the plastics image and raise the top and bottom height bei 0.1 and the segments are gone.

 

 

Only 25 ramps!   Ugh, LOL. 

 

1054, 1055, 1056, 1057, 975, 974, 973, 972 971, 970, 485, 328, 327, 326,  325, 324, 323, 322, 321, 320, 319, 317, 306, 305, 304   

 

If the depth bias adjustment helped, you could at least select them all and just plug in a number, but it doesn't seem to work for this case. 

 

 

That's because these two ramps are genuinely at the same depth and therefore have Z fighting. The depth bias parameter only affects the depth sorting order for transparent objects, not the Z buffer (and therefore doesn't affect the solid ramp at all since it isn't depth sorted in the first place). So to be precise, this one is actually not the depth sorting issue, just good old Z fighting.

[Rincewind]

A bit late to the party... had a break with  VP....awesome gonna try this out! One thing, do I just copy/replace the installation files over?

Edited by Rincewind, 09 April 2014 - 10:21 AM.

[Slydog43]

just place the new exe in your visual pinball install directory.  Leave the old one (9.2.1 I hope) and you can run either one the 9.2.1 or the DX9 version (build 980).  Both versions are light years ahead of the old versions.

[unclewilly]

Bump.

How's progress going on this.
Looking forward to the mesh ball.

Thanks for all you devs hard work.

Where's toxie been? Haven't heard much from him on the forum lately