4027 replies to this topic

[wiesshund]

Guys with the "hang problem" - can you take a look at https://www.vpforums...=44135&p=504813

 

As you see, for me, there where a change between 166 and 167. Admit that the commit/change to the code, just doesn't make sense. But, nevertheless, testing these two versions should just take a couple of minutes.

Wiesshund provided the versions two posts above the link.

 

Hmm, and that commit that buggered it up for you was something to do with openGL
which would have to do with merging VPX-VR with VPX (I imagine so that the forks dont keep drifting totally appart)

The strange thing is

1) if not running a VR compile, why would the openGL even come into play

2) why would it run and hang, rather than not run at all
3) why only on some systems? anyone with a real GPU is going to have a higher OpenGL version and more OpenGL capabilities than my laptop

 

Keep in mind, i dont really understand the source code that i am looking at.

 

Probably dumb to ask, but...
Are any of you affected by this issue running a debug build so you can get the extended logging info from it?

keep taskman on your backglass and as soon as you see an orphaned VPX appear
snip the log, and maybe something useful in it?
maybe not, but worth a try?

[BrandonLaw]

I'll grab the debug version, but this is the FIRST time I've experienced anything of this sort and I've been a beta-boy for a long while now.  Almost a 4a ritual to see what's new at VP Git.

 

EDIT:

 

So...reporting back.

 

I've never used the 64bit ver.  Decided what the hell...gave it a go fired right up on 279 64bit but gave some controller errors of course, but was curious and it panned out.

 

Installed debug 32bit...fired right up.  

 

Went BACK to 279 32bit.  Now it fires right up.   

 

The fk?

Edited by BrandonLaw, 07 September 2022 - 09:05 AM.

[Gravy]

Crash on start bug seems to be the same as what's happening to a few people at https://github.com/v...nball/issues/80

I know that at least one of these guys (Joshua, "TalOfAruk" on Github ) seemed to start experiencing the issue around the same time as setting up a plunger kit from virtuapin and I'm wondering if the plunger setup software is the common thread amongst other users with the problem? Does that software remain resident even when VPX is not running maybe?

[toxie]

Okay, thanks for the confirmation, guys, so the problem is in general, not just double clicking tables.

 

Now the next testing step, please:

Does the same happen when you run the debug x86 build? (apart from BrandonLaw where this magically fixed things )

The problem I had (controller error) was fixed by changing to the 32 bit build but the only thing that shows up on the table is the 3d elements with no texture graphics at all except for the drop targets and the standup targets behind them. The backdrop graphics don't show either. I don't know what the last beta build I used was, wasn't long ago, but it worked very well. I just run VP and load tables from the editor. I have enough older builds that I can still get my table to work correctly

Could you try resetting the video preferences, please? Cause this error i never heard of.

As for 32bit vs 64bit: Thats expected :/ . If one uses B2S (or other controllers), then the same bit-variant must also be installed, otherwise you get that controller error.

Hmm, and that commit that buggered it up for you was something to do with openGL

which would have to do with merging VPX-VR with VPX (I imagine so that the forks dont keep drifting totally appart)

The strange thing is

1) if not running a VR compile, why would the openGL even come into play

2) why would it run and hang, rather than not run at all
3) why only on some systems? anyone with a real GPU is going to have a higher OpenGL version and more OpenGL capabilities than my laptop

Quick explanation for the VPX vs VPVR stuff: So far, both projects are still separate, and GL won't be triggered in VPX ever.

BUT: what we did is, to touch A LOT of the codebase to be able to at one point have both codebases inside of one (to avoid merging things/improvements from one to the other all the time), and even potentially (this one is not decided yet if it makes even sense!) to ship both within the same .exe.

So while reconstructing both projects rendering core, it might well be that something got broken/flawed.  :/

Are any of you affected by this issue running a debug build so you can get the extended logging info from it?

keep taskman on your backglass and as soon as you see an orphaned VPX appear
snip the log, and maybe something useful in it?
maybe not, but worth a try?

 

Thanks for pointing out logging!! I totally forgot that i included something like that with 10.7.0!

So..

 

For all people with the hang-problem:

Please create a file named 'Profile.txt' in the same directory as VPX.

When testing, make sure its empty before starting VPX.

If VPX then hangs, then kill the task and look into that txt file.

Edited by toxie, 07 September 2022 - 10:28 AM.

[Thalamus]

I'll grab the debug version, but this is the FIRST time I've experienced anything of this sort and I've been a beta-boy for a long while now.  Almost a 4a ritual to see what's new at VP Git.

 

EDIT:

 

So...reporting back.

 

I've never used the 64bit ver.  Decided what the hell...gave it a go fired right up on 279 64bit but gave some controller errors of course, but was curious and it panned out.

 

Installed debug 32bit...fired right up.  

 

Went BACK to 279 32bit.  Now it fires right up.   

 

The fk?

If you go for 64bit VP, that does regular VP almost require ? Pinmame - do you have that in 64bit ? That is your controller error. You don't want 64bit, if you at all like to play SAM/Stern tables, at91jit isn't working and either is db2s. It is however very stable, for editing !! That is to me its main use.

 

fk explained I guess

[BrandonLaw]

 

I'll grab the debug version, but this is the FIRST time I've experienced anything of this sort and I've been a beta-boy for a long while now.  Almost a 4a ritual to see what's new at VP Git.

 

EDIT:

 

So...reporting back.

 

I've never used the 64bit ver.  Decided what the hell...gave it a go fired right up on 279 64bit but gave some controller errors of course, but was curious and it panned out.

 

Installed debug 32bit...fired right up.  

 

Went BACK to 279 32bit.  Now it fires right up.   

 

The fk?

If you go for 64bit VP, that does regular VP almost require ? Pinmame - do you have that in 64bit ? That is your controller error. You don't want 64bit, if you at all like to play SAM/Stern tables, at91jit isn't working and either is db2s. It is however very stable, for editing !! That is to me its main use.

 

fk explained I guess

 

Ha..yep I'm aware.  Just wasn't going through the rigamarole to setup a 'test' environment for 64bit.  App opened and that's all I needed to see

 

Further testing...app window only opens/shows about 50 percent of the time.  Sometimes it won't open twice from being ended in task manager and others it will open twice in a row.  Not sure what's up with this particular build. 

 

 

EDIT:

 

I fired up an empty Profile.txt fully ready to copy/pasta that sucker and seriously wth as the Debug .exe fires up every single time.  I don't know what planet I'm on any longer.

 

Best I could do for anyone is I created a dump file of the orphaned (non-Debug) .exe.  Here's the link if you feel like sifting through it....

 

:::DUMP FILE:::

Edited by BrandonLaw, 07 September 2022 - 01:17 PM.

[Outhere]

I double clicking the EXE
When VPX hangs the 'Profile.txt' is Empty

With Debug version it fires up every single time

[rxd]

Just installed the latest version and when I start Haunted House to test it out the flippers are invisible.

They work but aren't visible at all....

[Thalamus]

@toxie : again back to my 166 vs 167 test ... ran without counting a few 167 - hang. Killed it off and created Profile.txt

 

Ran 60 successful open vpx without anything else than being efficient. Doubleclick the exe and close it. After 60 attempts - 2 minutes. Very bored.

 

After the 19th attempt on 167 it hang, actually, I believe that is a new record for successful starts for me on that version. After it hangs, I'm able to start a new copy of 167, no problem, but, the old one is there dormant. Killing of the process - looking at Profile.txt - doesn't give much of information I guess.

 

Trace from Wed Sep  7 21:30:20 2022

0.000 : OnInitialUpdate

Trace from Wed Sep  7 21:30:24 2022

0.000 : OnInitialUpdate

Trace from Wed Sep  7 21:30:27 2022

0.000 : OnInitialUpdate

Trace from Wed Sep  7 21:30:29 2022

 

... they are all like this - nothing different from success or the hanged one.

 

- I don't see anyone else doing a good, proper test, just referring to the latest which is absolutely useless for figuring out where it all began.

 

JUST for giggles. I decided to run the test all over again - 60 successful 166, hang on the 2 attempt at 167. So, at least for me, there is a CLEAR change between them !!

[Outhere]

I Also noticed this the other day when I was troubleshooting a game the DOF controllers in VP Does Not Turn off the DOF on solid state games


DOF For most EM (Pre solid state) and original tables ( DOF controllers in VP work Correctly )
PlaySoundAt SoundFXDOF("fx_flipperup", 101, DOFOn, DOFFlippers)


But


DOF For solid state games Ignores the DOF controllers in VP
PlaySound SoundFX("fx_flipperup",DOFFlippers)

Like this the DOF controllers in VP For solid state games works Correctly ( It's looking the 3 Commas and The DOF Added to SoundFX )
PlaySound SoundFXDOF("fx_flipperup", , , DOFFlippers)

Could somebody that has DOF check this to Verify that this is correct
Go in the editor under preference, then under configure keys nudge DOF set some of the DOF controllers to sound only
Then restart vp and see what the results are

Edited by Outhere, 07 September 2022 - 08:55 PM.

[BrandonLaw]

What's a bonus here....when it DOES work...it's SNAPPY as shit.  Debug of course takes a few seconds longer during render for output, but the non-debug is notably quick.

Edited by BrandonLaw, 07 September 2022 - 09:25 PM.

[Thalamus]

So, the newest in this thread. Like any release since 166, hangs on my end. The latest maybe more often than any I can remember. But, well, I'm not going to make a very accurate measurement of this fact. What I did just now however was to download the very latest code (2 days old) from github and compiled the exe myself.

 

This one I ran over 70 times in a row without ANY hangs.

 

What is the difference ? Compile on my machine of course - vc2019, no upx crap which breaks pinmame I should add ...

 

If anyone trusts my exe for not being infected by virus - what about giving this one a try and see if it is any better for you ?

 

YES, the file is much larger than the release that you normally see. This is because it is NOT compressed like the official. Someone is bound to answer that question I guess.

 

https://www.dropbox....nballX.exe?dl=0

Edited by Thalamus, 07 September 2022 - 09:58 PM.

[BrandonLaw]

@Thalamus 

 

downloaded and used.  Opened 20+ times in a row no problem.  Snappy.  Rev 0 lol.

[Thalamus]

Hehe. Yeah. There is something in that build process they do that isn't run on my end, so, the version number is kind of cool

[Outhere]

@Thalamus
Opened 30+ times in a row no problem

[wiesshund]

If you go for 64bit VP, that does regular VP almost require ? Pinmame - do you have that in 64bit ? That is your controller error. You don't want 64bit, if you at all like to play SAM/Stern tables, at91jit isn't working and either is db2s. It is however very stable, for editing !! That is to me its main use.

 

 

 

 

 

 

You can run it.
You need VPX 64 bit
VpinMAME 64bit
B2S Server 64bit
Freezy's 64bit dll
and FlexDMD is already compiled as either/or
 

For the most part, it will run fine, EM tables it is of course as flawless as the 32bit
ROM tables it is mostly fine except where the SAM/Stern tables are concerned.

And even then, it can at times play them, seemingly fine.
But on close inspection you will find that the DMD begins to lag behind the actual table events.
And yes, sometimes it will flat out crash running a stern ROM.

But what i learned from running 64bit for several months
1) there is no benefit to running it, VPX does not need the higher accessible memory at all, it just doesnt use enough, so it runs just the same.
2) unless one understands vpinmame code, and could contribute to improving the at91jit implementation in the 64bit, the whole thing is a pointless endeavor
aside from saying ok neat, it works

 

This is mostly for anyone else popping by or googling by or otherwise looking at the 64bit build and wondering
or grabbing it and then assuming it is broke cause it doesnt work right off the bat.

It does work if the entire VPX installation is 64bit including helper apps
but it is currently pointless to do so aside from curiosity, unless one is going to commit some serious skills to vpinmame development

 

 

If anyone trusts my exe for not being infected by virus - what about giving this one a try and see if it is any better for you ?

 

 

https://www.dropbox....nballX.exe?dl=0

 

If you compiled it, i would trust it

[Gravy]

So, the newest in this thread. Like any release since 166, hangs on my end. The latest maybe more often than any I can remember. But, well, I'm not going to make a very accurate measurement of this fact. What I did just now however was to download the very latest code (2 days old) from github and compiled the exe myself.

 

This one I ran over 70 times in a row without ANY hangs.

 

What is the difference ? Compile on my machine of course - vc2019, no upx crap which breaks pinmame I should add ...

 

If anyone trusts my exe for not being infected by virus - what about giving this one a try and see if it is any better for you ?

 

YES, the file is much larger than the release that you normally see. This is because it is NOT compressed like the official. Someone is bound to answer that question I guess.

 

 

Well now that is interesting, that should give Toxie some clue as to what is happening with the compiling.

[toxie]

Yup, thanks for all the info and testing! This is all very helpful!

 

Does https://github.com/v...ase-win-x86.zip work for you guys?

Or https://github.com/v...facts/353269571 if you have a github account (already has the physics options fix)

Just installed the latest version and when I start Haunted House to test it out the flippers are invisible.

They work but aren't visible at all....

Which version of Haunted House did you test?

Edited by toxie, 08 September 2022 - 05:48 AM.

[toxie]

Guys with the "hang problem" - can you take a look at https://www.vpforums...=44135&p=504813

 

As you see, for me, there where a change between 166 and 167. Admit that the commit/change to the code, just doesn't make sense. But, nevertheless, testing these two versions should just take a couple of minutes.

Wiesshund provided the versions two posts above the link.

I just checked the differences between 166 and 167 again. And these basically boil down to nothing.  :/

I just renamed some functions between the 2 revisions. So what may have still have happened is that there was an update to the compiler under the hood (as we always just use the 'standard' github setup, which usually means latest updates to the compiler applied).

@Thalamus: Which compiler version do you use exactly? (Help -> About -> Version, e.g. for my VS2019 its 16.11.18)

And did you just use the standard VS2019 .sln file? And compile to Release x86? Or Debug x86 (which is the default)?

[Thalamus]

@toxie : I'll have to answer for the exact version when I'm home. Standard vs2019.sln - generated from the bat and this is Release x86 build.

 

Maybe the code change in itself is very insignificant, something else, like upx or whatever small unexpected thing is effected ?

All I know for sure now, is that for my new win10 machine - LGA 1700, 12-Core, 20-Threads, 2.1/4.9GHz, Alder Lake. There IS a difference !

Edited by Thalamus, 08 September 2022 - 07:02 AM.