1622 replies to this topic

[hlr53]

 

I think most users will use only 1 system. Users with older systems may have to use DX9. I use only DX11 with BAM. Some may use DX11 without BAM (I have to see how that launches?)

 
That's been my thinking as well.  For the TPA DX9/11 choice, it seems like they're the same game either way, so it's a function of your system, not a playing preference at time of launch.
 
We can explore it further if this becomes a big problem for anyone, but hopefully the one game-one system mapping will be workable for most people.
 
 

Personally, as long as I can navigate to the main menu in PBA and use my cab buttons to move about, I'm good. I have 4 extra cab buttons installed for navigating like arrow keys. If you could kludge together a partial manual setup we would certainly welcome it. 
A LOT of man hours have been spent trying to keep up with their menus.

 
Clearly "external launcher" isn't on their radar.  Or if it *is* on their radar, they hate the idea so much that they're actively trying to make it impossible.  You could easily believe the latter given how ridiculously hard they make it, but Hanlon's razor is usually right in these situations.
 
LMAO - I don't think they are mutually exclusive. Conspiracy vs Stupidity.
 
Anyway... I gave it another try with remapping keys in their UI, and maybe that's the way to go.  Try going to the TPA Controls > Keyboard/Mouse settings (I'm talking about the Pinball Arcade UI, not the PinballY settings), and map the menu commands like so:
 
Menu Select:  1    (pin cab start button)
Menu Back:  2   (pin cab extra ball button - if you have one; use one of your extra buttons if not)*
Menu Left:  Left Shift  (pin cab left flipper button)
Menu Right:  Right Shift  (pin cab right flipper button)
Menu Up:  Left Ctrl (pin cab left magnasave)
Menu Down:  Right Ctrl  (pin cab right magnasave)
 
Those settings don't seem to create any interference during play, and they let you navigate all of the TPA menus with just the basic pin cab buttons.  The up/down arrows are the only ones that are a little weird, because you have to translate left/right magnasave in your brain to up/down.
 
It's a pain to do the manual navigation every time, and seems especially outrageous since you just selected the same game in another UI!!!, but they make it so hard to keep automated key scripts working that this might be the lesser of two hassles.
 
* Why not Escape = pin cab Exit button?  Because PinballY monitors Escape and would override "menu back" to mean "terminate the whole game".
  

 
I'll try to play around with it today. I have to finish wiring Zeb's controller (try to hook up a common return this time - dumbass!). I'm on the keyboard this morning.
 
The last thing I didn't try through PBY in the past was launching the DX11 version direct without going through FCM If I went directly to the folder C:\Program Files (x86)\Steam\steamapps\common\PinballArcade\PinballArcade11.exe it loaded fine. So, in my infinite wisdom I made that link the executable in PBY and had process to monitor PinballArcade11. Thought that would be a piece-o-cake. Au contraire. This is the error I got:
 

 
Tried various config settings to no avail.
 
FCM is broken again because PBA just did an update and noEx has to change whatever he changes at his end. One of these days he's gonna get sick of doing this or PBA will break it completely.
 
PBY error trapped this OK. As a matter of fact, I fired up PBY and tried loading the DX9 version first thing and I received the Technical Error launching dialog. I'm like WTF is happening now?!! Oh, Steam is downloading the PBA update.

Edited by hlr53, 18 September 2018 - 08:46 PM.

[hlr53]

A19-32 Real DMD no longer working on Future Pinball inside PBY. Works OK launched outside PBY via Fploader.

 

Searching for real DMD device DLL

+ Found the DLL in the PinballY folder: C:\PinballY\DmdDevice.dll

+ found DMD interface DLL: C:\PinballY\DmdDevice.dll

+ retrieving file version info for DLL, to check for special handling

+ Version Info data: version=1.7.1.0, product name="Universal DmdDevice.dll for Visual PinMAME", comments="Universal DmdDevice.dll for Visual PinMAME for all displays, inclusively frame-by-frame coloring support.", copyright="Copyright © 2018 [email protected]"

+ This appears to be the dmd-extensions version of the DLL, based on the product/copyright strings

+ Based on the version number, this version of the DLL has a bug in PM_GameSettings,

  so we won't call that function; as a result, per-game coloring from your VPinMAME

  settings won't be used during this session.

+ Based on the version number, this version of the DLL has a bug that crashes

  the process if we try to close and later reopen the DLL session.  As a result,

  we'll leave the session open permanently once opened.  This may result in the

  DLL's virtual DMD window remaining visible even if you explicitly disable the

  real DMD feature in the options.  Close PinballY and restart it to get rid of

  the extra window.+ Checking if dmd-extensions virtual DMD mode is enabled

+ Loading DmdDevice.ini from DLL folder (C:\PinballY\DmdDevice.ini)

+ DmdDevice.ini not found or load failed; assuming default settings (with virtual dmd enabled)

+ It looks like virtual dmd mode is enabled in the dmd-extensions DLL.  Your

  PinballY real DMD setting is "Always On", so we're going to use the DLL

  anyway.  Note that you'll see two simulated DMDs on the screen - one from

  the DLL, and another from PinballY's built-in DMD window.  If you want to

  get rid of the one from the DLL, change its virtual dmd setting to disabled

  in the DLL's DmdDevice.ini file.

+ dmddevice.dll successfully loaded

+ It looks like virtual dmd mode is enabled in the dmd-extensions DLL.  Your

  PinballY real DMD setting is "Always On", so we're going to use the DLL

  anyway.  Note that you'll see two simulated DMDs on the screen - one from

  the DLL, and another from PinballY's built-in DMD window.  If you want to

  get rid of the one from the DLL, change its virtual dmd setting to disabled

  in the DLL's DmdDevice.ini file.

 

Detecting and configuring real DMD device

+ It looks like virtual dmd mode is enabled in the dmd-extensions DLL.  Your

  PinballY real DMD setting is "Always On", so we're going to use the DLL

  anyway.  Note that you'll see two simulated DMDs on the screen - one from

  the DLL, and another from PinballY's built-in DMD window.  If you want to

  get rid of the one from the DLL, change its virtual dmd setting to disabled

  in the DLL's DmdDevice.ini file.

 

DOF: shutting down DOF client

 

Saturday, September 8, 2018, 3:36:21 PM: PinballY session ending

[mjr]

 

A19-32 Real DMD no longer working on Future Pinball inside PBY. Works OK launched outside PBY via Fploader.

 

+ Based on the version number, this version of the DLL has a bug that crashes

  the process if we try to close and later reopen the DLL session.  As a result,

  we'll leave the session open permanently once opened.  

 

It's that bit about leaving the DMD connection open due to the bug in the DLL.  The USB driver for the DMD only allows single-process access, so PBY keeping its session open locks out everyone else.  If you download my fixed version of the DLL, PBY will be able to close the session when launching a game.  See the "Real DMD DLL update alert!" section on the PinballY page:  

 

http://mjrnet.org/pi...hp#dmddeviceDLL

[mjr]

The last thing I didn't try through PBY in the past was launching the DX11 version direct without going through FCM If I went directly to the folder C:\Program Files (x86)\Steam\steamapps\common\PinballArcade\PinballArcade11.exe it loaded fine. So, in my infinite wisdom I made that link the executable in PBY and had process to monitor PinballArcade11. Thought that would be a piece-o-cake. Au contraire. This is the error I got:

 

Weird that it lets you launch it directly from the Windows desktop but not from PBY - they really should be pretty equivalent means of launching. 

 

If you do a little searching around on the web for PinballArcade11.exe, it looks like there are some tricks for getting Steam to launch the DX11 version.  The suggestion I've seen in a few places is to change the *Steam* options (not PBY, not Pinball Arcade, but Steam itself):

 

Steam > game list > Pinball Arcade > right click > properties > general > set launch options :  <full path>\PinballArcade11.exe %command%

 

Then you can change PinballY launch options back to the basic [Steam] launch for -appid whatever it is, since the change above supposedly tells Steam to always start the DX11 version.

[hlr53]

 

The last thing I didn't try through PBY in the past was launching the DX11 version direct without going through FCM If I went directly to the folder C:\Program Files (x86)\Steam\steamapps\common\PinballArcade\PinballArcade11.exe it loaded fine. So, in my infinite wisdom I made that link the executable in PBY and had process to monitor PinballArcade11. Thought that would be a piece-o-cake. Au contraire. This is the error I got:

 

Weird that it lets you launch it directly from the Windows desktop but not from PBY - they really should be pretty equivalent means of launching. 

 

If you do a little searching around on the web for PinballArcade11.exe, it looks like there are some tricks for getting Steam to launch the DX11 version.  The suggestion I've seen in a few places is to change the *Steam* options (not PBY, not Pinball Arcade, but Steam itself):

 

Steam > game list > Pinball Arcade > right click > properties > general > set launch options :  <full path>\PinballArcade11.exe %command%

 

Then you can change PinballY launch options back to the basic [Steam] launch for -appid whatever it is, since the change above supposedly tells Steam to always start the DX11 version.

 

 

PBA will not launch with  %command% at the end.  I've had it set to launch PinballArcade11.exe with out the %command% but it just launches DX9.

 

I give up for now. I F******* hate FarSight.

[mjr]

PBA will not launch with  %command% at the end.  I've had it set to launch PinballArcade11.exe with out the %command% but it just launches DX9.

I give up for now. I F******* hate FarSight.

 

Oh, well, the advice I saw about that must have been outdated (or just wrong).  Or maybe Farsight saw the posts about it and decided to do something about it.

[hlr53]

 

 

A19-32 Real DMD no longer working on Future Pinball inside PBY. Works OK launched outside PBY via Fploader.

 

+ Based on the version number, this version of the DLL has a bug that crashes

  the process if we try to close and later reopen the DLL session.  As a result,

  we'll leave the session open permanently once opened.  

 

It's that bit about leaving the DMD connection open due to the bug in the DLL.  The USB driver for the DMD only allows single-process access, so PBY keeping its session open locks out everyone else.  If you download my fixed version of the DLL, PBY will be able to close the session when launching a game.  See the "Real DMD DLL update alert!" section on the PinballY page:  

 

http://mjrnet.org/pi...hp#dmddeviceDLL

 

 

That fixed it. Thanks!

 

Also, Zeb's V2 Plunger Kit kit works well with PBY. 

Edited by hlr53, 08 September 2018 - 09:35 PM.

[hlr53]

I would like to run a batch file to start dmdext for FX3 & PBA as an administrator in Run before (1):

 

I don't see a setting to run it as an admin by right clicking on the batch file. I can create a shortcut to it giving the short cut adm rights but PBY won't launch the short cut. 

 

I usually start it manually in Powershell (adm) but that is getting old :-)

[mjr]

I would like to run a batch file to start dmdext for FX3 & PBA as an administrator in Run before (1):

 

I don't see a setting to run it as an admin by right clicking on the batch file. I can create a shortcut to it giving the short cut adm rights but PBY won't launch the short cut. 

 

I usually start it manually in Powershell (adm) but that is getting old :-)

 

Launching as admin is tricky due to Windows security rules.  You either have to *be* an admin process to launch an admin process, or you have to go through a UAC prompt, which isn't much friendlier than doing the whole thing manually.

 

PBY has a good setup for launching the game itself in admin mode, using the "PinballY Admin Mode" program instead of the main program when you first start up and then executing admin-mode.  But I didn't think to apply that to Run Before/Run After.  dmdext with its supervisor-mode memory snooping is definitely a good use case for that.  

 

I think I can add that pretty easily since I already have all the plumbing in place to launch games in Admin mode.  This is just one more thing to launch as Admin.  UI-wise, I'll just add an [ADMIN] flag to the ever-growing Run Before/After flags list.   I'll see if I can get that into the next update.

 

If you want to cobble together a workaround in the meantime, you might try something like this:

 

1.  Create your own private copy of CMD.EXE somewhere in your own folder.  Call it ADMIN-CMD.EXE or something like that.

 

2.  In the Windows desktop, bring up the file properties for your private copy, go to the Compatibility tab, and check the "Run this program as administrator" checkbox

 

3.  Write a .BAT script that contains the dmdext launch and the FX3 launch

 

4.  In the PBY system setup, use your command script as the program executable, like this:  "<path to>\ADMIN-CMD.EXE" /c "<path to>\your script from step3.bat"

 

5.  Set the process name to the FX3 process name as usual

The "run as administrator" setting in your private CMD.EXE copy should force PBY to launch it in Admin mode.  That will provoke a UAC prompt if you run it from the regular PinballY, but you can avoid that by starting up using PinballY Admin Mode.exe instead.  You'll instead get an in-UI warning prompt from PinballY about the Admin mode elevation, just once per session, the first time you launch an FX3 game using this.  Subsequent launches in the session will accept that you know what you're doing and won't bug you again about it.

 

You can set up automatic system startup launching with the Admin mode version using the "Automatic Administrator mode" startup option.

Just in case it's unclear, "PinballY Admin Mode.exe" is a separate program you'll find in the PinballY folder.  Don't set PinballY.exe itself to run in Admin mode.

[hlr53]

I did 1 - 4 and when trying to launch the table it gave me a system error 740: The requested operation requires elevation. I did set admin-cmd.exe as administrator. Whether running regular or ADM PBY.

 

I also tried powershell.exe but same result.

 

I can wait for next release as this isn't critical.

 

Anyway, thanks for the help.

 

Sorry to be a PITA on these commercial programs. 

Edited by hlr53, 09 September 2018 - 01:17 AM.

[mjr]

I did 1 - 4 and when trying to launch the table it gave me a system error 740: The requested operation requires elevation. I did set admin-cmd.exe as administrator. Whether running regular or ADM PBY.

 

Are you sure you're doing this in the system program, not the Run Before?  That's the error you'd get if you put that in Run Before.  What I'm proposing is that you use that CMD copy as the replacement for the entire game system in the "Program EXE" box.

 

And I misstated the parameters a bit - you'd have to separate the Program EXE and parameters, not put them in a single command line.  So:

 

Program EXE:  <path to>\CMD-ADMIN.EXE

Parameters:     /C "<path to>\your script.bat"

...And then put nothing at all in the Run Before, since the whole before-during-after sequence should be captured in the .BAT file.

[hlr53]

[edit] Sorry, I didn't read the directions better yesterday. I was pretty cooked from many hours of cab plunger/button rewiring, which all works now. I wanted to get to the Sainsmart but ran out of time.

 

If I run a copy of cmd.exe (renamed admin-cmd or whatever) in my system it completely wigs out Windows 10 Pro. It started making a zillion copies of D:\ at the command line prompt and created multiple cmd windows. I had to restart to kill. Not sure what that's about?

 

So, I am trying to run cmd.exe directly out of c:\windows\system32 but I have no idea what parameters to add (and not for the lack of trying) to change the directory to D:\ where I can run fx3.bat. I can go into the cmd window directly and change it but I'm having trouble adding the parameters from PBY (or anywhere else). Needless to say, I have VERY limited batch file experience.

Edited by hlr53, 09 September 2018 - 02:45 PM.

[mjr]

To change to the d: folder:

D:
cd \path\to\wherever

For the endless recursing windows, youre not trying to put the CMD /C in the .bat file itself, are you? That sounds like what must be going on. CMD is the command processor, so you dont want to invoke it from within itself. The .bat file should just contain the commands to execute, one per line.

Edited by mjr, 09 September 2018 - 07:52 PM.

[hlr53]

To change to the d: folder:

D:
cd \path\to\wherever

For the endless recursing windows, youre not trying to put the CMD /C in the .bat file itself, are you? That sounds like what must be going on. CMD is the command processor, so you dont want to invoke it from within itself. The .bat file should just contain the commands to execute, one per line.

 

No, I only ran the cmd.exe copy from the Program EXE: line. It never got to the batch file. No way did I run cmd.exe inside the bat file. I had one line for dmdext.

--------------------------------------------------------------------------------------------------------------------------------------------------------

Anyway,  I cannot get this to work. I can wait for you to add the {ADMIN} flag but this is a good learning experience.

 

In Program EXE: I'm launching c:\windows\system32\cmd.exe 

 

It launches correctly with c:\windows\system32> showing.

 

Where I am getting hung up is trying next to run FX3.bat from my D root directory.

 

All it contains is D:\dmdext mirror --source=pinballfx3 --no-virtual

 

and then I want to change to the C drive and launch FX3 from the Steam directory path (I know no individual tables will launch this way).

 

Do I add parameters behind cmd.exe in the Program EXE: line or do they just go on the Parameters: line to launch the batch file? Exactly what are the parameters? I thought d:\FX3.bat would work or just fx3.bat.

 

I've tried CD and paths and I just cannot get it to work.

[mjr]

hlr53 - let's try something a little different vis-a-vis this dmdext/Admin mode fiasco.

 

Here's the root of my new thinking:  I think it's a bug that dmd-ext wants you to run in Admin mode. 

 

I'm pretty sure it shouldn't be necessary in most cases, with the possible exception of certain types of enterprise environment where the IT department has deployed group policy settings that restrict user accounts more than the Windows defaults.  Hopefully your pin cab is not managed by a corporate IT department.  Freezy might have a different perspective on this, but I believe the reason he's demanding Admin mode is that he's thinking that the debugging APIs he's using to hack into TPA/FX3's process address space are privileged.  The thing is that they're normally not - except maybe in the corporate settings I spoke of.  On a normal Windows machine, in ordinary user mode, you can normally fire up a user-mode debugger on any user-mode process without any special privileges and without any special relationship between debugger and "debuggee".  (A user-mode process can't debug an Admin process, though; hopefully you're not trying to run FX3 itself in Admin mode.)

 

So:  I've compiled up a test version of dmdext.exe for you that removes the Admin requirement.  It happily runs with Admin mode, but if Admin mode isn't enabled, it will instead try to enable the debug privileges in user mode.  This works nicely for me with TPA, so I'm hoping it will work nicely for you with FX3.  Give it a try and see.

 

Steps:

 

- Download this:  http://mjrnet.org/pi...in-20180910.zip

 

- Replace your existing dmdext.exe with the one there

 

- Go back to your old settings, with launching your FX3 dmdext script in Run Before and the normal Steam launch in the Program EXE/Parameters/Process fields.  Remove all of the Admin mode business from every step and do everything in ordinary user mode.

 

Let me know if that works for you.  If it does, I'll contact Freezy and propose making this standard.

Edited by mjr, 10 September 2018 - 11:29 PM.

[hlr53]

Thanks MJR,
I scarfed the file. My cab is off today but I will try after work tomorrow afternoon. I don't recall ever doing any admin stuff with FX2 or 3. I believe I have UAC turned off on the cab due to all the hoop jumping in PBX over the past years. My home mesh system that go into multiple routers first is pretty buttoned up against hackers. My #1 son (chronologically) set it up and has a ton of Cisco certs.

Edited by hlr53, 11 September 2018 - 12:42 AM.

[TerryRed]

hlr53 - let's try something a little different vis-a-vis this dmdext/Admin mode fiasco.

 

Here's the root of my new thinking:  I think it's a bug that dmd-ext wants you to run in Admin mode. 

 

I'm pretty sure it shouldn't be necessary in most cases, with the possible exception of certain types of enterprise environment where the IT department has deployed group policy settings that restrict user accounts more than the Windows defaults.  Hopefully your pin cab is not managed by a corporate IT department.  Freezy might have a different perspective on this, but I believe the reason he's demanding Admin mode is that he's thinking that the debugging APIs he's using to hack into TPA/FX3's process address space are privileged.  The thing is that they're normally not - except maybe in the corporate settings I spoke of.  On a normal Windows machine, in ordinary user mode, you can normally fire up a user-mode debugger on any user-mode process without any special privileges and without any special relationship between debugger and "debuggee".  (A user-mode process can't debug an Admin process, though; hopefully you're not trying to run FX3 itself in Admin mode.)

 

So:  I've compiled up a test version of dmdext.exe for you that removes the Admin requirement.  It happily runs with Admin mode, but if Admin mode isn't enabled, it will instead try to enable the debug privileges in user mode.  This works nicely for me with TPA, so I'm hoping it will work nicely for you with FX3.  Give it a try and see.

 

Steps:

 

- Download this:  http://mjrnet.org/pi...in-20180910.zip

 

- Replace your existing dmdext.exe with the one there

 

- Go back to your old settings, with launching your FX3 dmdext script in Run Before and the normal Steam launch in the Program EXE/Parameters/Process fields.  Remove all of the Admin mode business from every step and do everything in ordinary user mode.

 

Let me know if that works for you.  If it does, I'll contact Freezy and propose making this standard.

 

No change mjr. I get the same results with your version of dmdext as I do with freezy's file. (with or without using Popper)

 

 

 

For dmdext's new memory grabber method to work correctly, it requires BOTH Pinball FX3.exe and dmdext.exe Run as Admin!   (I did lots of testing to help out DJRobX when he was helping with the 1.71 updates)

 

 

 

Usiing Freezy's new memory grabber method for Fx3 with dmdext.exe when both files are NOT Run as Admin:

 

- it works the "first" time it's run fine (freezy DMD works). When you exit out of FX3, dmdext will NOT auto-close itself out like it normally does (this will be the cause of many problems). So you need to manually close it (which is NOT normal). After that it will NOT work at all ever after that unless you completely reboot your system. (and there wasn't any leftover dmdext process still running)

 

- it works if you Run both dmdext.exe and Pinball FX3.exe as Admin, but you still need to manually close out dmdext.....BUT.... this is a problem for anyone who uses Pinup Player for my Aliens FX3 PuP-Pack or my FX3 SSF PuP-Packs (for Surround Sound Feedback for all FX3 tables...a big deal for SSF guys). This is because dmdext not auto-closing out properly (when Run as Admin) doesn't allow the Pinup Player com object to close out. As a result the PuP-Pack will stay running until it is manually closed out which is messy and can cause problems.

 

 

 

Using the --fx3-legacy parameter:

 

If dmdext uses the --fx3-legacy parameter and does NOT run dmdext and FX3 as Admin... then dmdext will close out properly when exiting a table, and so does the PuP com object, and so the PuP-Packs close out correctly as well.

 

 

 

The bottom line is when dmdext (and FX3) is not Run as Admin with the new memory grabber method...nothing works and is messy! If you do Run them as Admin, then it never closes out, and as a result makes it messy for other programs that work with it like PuP.

 

 

So currently, for anyone using PuP-Packs (Aliens and SSF) with dmdext 1.71, I currently recommend for them to use the --fx3-legacy flag which works fine....BUT that will be an issue in the future when the Williams tables come out...as the new grabber method seem to get pixel perfect dots...but the old method doesn't (I think).

 

 

This is the Aliens FX3 PuP-Pack:

 

https://youtu.be/A1tNlyc9qY4

 

 

...and this is FX3 SSF and how it works with my FX3 SSF PuP-Packs.

 

https://youtu.be/UW9tn7_47k0

 

 

PuP-Packs and PuP are front-end independent and don't require Popper to run. (Popper is a front-end that makes use of Pinup Player)

Edited by TerryRed, 11 September 2018 - 07:37 AM.

[hlr53]

 

PuP-Packs and PuP are front-end independent and don't require Popper to run. (Popper is a front-end that makes use of Pinup Player)

 

 

 

Did not know that. Cool.

[mjr]

Usiing Freezy's new memory grabber method for Fx3 with dmdext.exe when both files are NOT Run as Admin:

 

TerryRed - I saw that you filed this as an issue against dmdext on github.  You should consider everything with this having to do with Admin mode to be a bug.  You shouldn't have to run either FX3 or dmdext in Admin mode.

 

(The underlying problem you're having with dmdext not quitting is some threading issue in dmdext that isn't clear to me.  Hopefully freezy will figure it out.  The problem where nothing works after one run is probably that the USB resources aren't being properly released when you manually kill the process, which leaves the device inaccessible to subsequent processes.  If freezy can figure out the underlying threading problems, the "won't work again" problem should fall out naturally from that.  Don't keep hitting your head against the brick wall of Admin mode looking for solutions here - the internal threading problems in dmdext are what need to get fixed.)

 

 

 

hlr53 - if you could still try it out on your system, it would be good to test on a different machine.  I don't have FX3 to test with, but like I said, I can test with PBA and that works nicely with no admin mode for any piece of this.

 

You should skip the batch file you're using and call dmdext.exe directly from the Run Before, with something like this:

 

   [NOWAIT] "d:\path to\dmdext.exe"  mirror --source=pinballfx3  --whatever-other-options-are-in-the-batch-file

Edited by mjr, 11 September 2018 - 05:31 PM.

[mjr]

TerryRed - you might give this update a try: 

 

http://mjrnet.org/pi...in-20180911.zip

 

I noticed that the dmdext memory grabbers are never closing their handles to the target process.  That could leave things in a weird state when you manually kill the dmdext process.  This version at least closes those handles properly.

Edited by mjr, 11 September 2018 - 06:06 PM.