490 replies to this topic

[psmiraglia]

@mjr. From a short test it seems like the random firing within pbx may have disappeared, but the craziness when transitioning from dofslave or doflinx to pbx remains. I’ll stick with my solution for now.

Is it possible for you to de-compile the package that DJrobx put together that fixed all this a while back ?

[Outhere]

Well that would explain why mine would not work right after upgrading.... Because I had people coming over I put it back But since then I replaced all the saintsmarts with an LEDwiz , its time to try it again

 

got it, thanks, that worked.  so do I need Cabinet.xml at all?  when I remove it, the auto-configuration seems to handle it and the DOF is working. 

 

Great!

 

I think you can ditch Cabinet.xml now, as long as the only reason you needed it was for the Sainsmart device setup.  You do still need it for the addressable LED strips if you're using those, but I think that's the only thing that requires it now.

 

[mjr]

Is it possible for you to de-compile the package that DJrobx put together that fixed all this a while back ?

 

Are you talking about yet another fix besides the one that he already sent me?  If he's got something else, I'd be happy to try merging it in (but I'm not going to mess with decompiling anything - this is open source, after all).

 

So is the problem only present when switching between programs?  If so, maybe maybe that initialization issue actually was relevant, and maybe there are other problems like it still lurking.

Edited by mjr, 02 March 2018 - 05:06 AM.

[Outhere]

Did you try plugging the hub into a 2.0 usb?

 

QuoteProbably a longshot but did you try switching usb ports to see if there is any change in the timing? Not all usb ports are created equal .

Cant do that. I have all 3 boards and DMD on an ESD protected usb hub and want to keep it that way. This should be a SW fix.

Edited by Outhere, 02 March 2018 - 05:19 PM.

[Outhere]

After doing the upgrade (DOF R3++ and DOFLinx 6.22) the plugin that I'm trying to use causes all my Solenoids to fire when I go into pinballx.... Before the Solenoids would fire once an a while but now They're firing as soon as it goes into pinballx and continue firing as long as I'm in pinballx With that plug in turn on...

http://www.vpforums....=39750&p=401066

-

UpDate

This problem only seems to affect my 2nd Ledwiz

I moved the 2nd LEDwiz to a 2.0 USB port and now I am back to the Solenoids fire once in a while attract mode...

Visual pinball is working

FX2 now works correctly when you run the 1st game the solenoids are firing....

The upgrade made fx3  work a lot better

 

Well that would explain why mine would not work right after upgrading.... Because I had people coming over I put it back But since then I replaced all the saintsmarts with an LEDwiz , its time to try it again

 

got it, thanks, that worked.  so do I need Cabinet.xml at all?  when I remove it, the auto-configuration seems to handle it and the DOF is working. 

 

Great!

 

I think you can ditch Cabinet.xml now, as long as the only reason you needed it was for the Sainsmart device setup.  You do still need it for the addressable LED strips if you're using those, but I think that's the only thing that requires it now.

 

 

[tttttwii]

Perfect solution! Thanks mjr!

 

How I did it: I deleted my old DOF folder in plugins and used your installer. As I am using LEDWiz, so I changed the interval with the DOF global config tool to 10ms. I plugged also my LEDWiz to an USB2.0 port.

 

Now everything is running fine. The flipper lag, which I had sometime in the past disappeared.

 

Thank you! Very good solution!

Edited by tttttwii, 04 March 2018 - 02:53 PM.

[TerryRed]

My report back....

 

I was starting to see some fluctuations of RGB lights not dimming correctly,etc... and the rare occasional spike of outputs.

 

Changing  the interval with the DOF global config tool to 10ms fixed that problem...smooth sailing again.

 

Thanks again mjr!

[fakingdeath]

Thank you mjr and ddh69 for some incredible software!

Okay I've tried so many things..

Everything is working, vp, pbx 2.65,dof R++, doflinx 6.22, latest fx3, latest b2s

Except: the pbx plugin. The log states (and configure button from plugin manager) that dof not found,make sure com object is registered.

If I run the register com onject exe I get a 100 error and then run as administrator is says successful but still have the issue in pbx plugin manager. If I try to manually register the dll via command line it says something along the lines of entry point not found.

This has been baffling me for 2 weeks. Thanks in advance for advice.

Edited by fakingdeath, 05 March 2018 - 02:01 AM.

[Outhere]

Update

Did more testing when I loaded the latest version of pinballx it put the old version of the LEDwiz.dLL back in pinballx Plugin folder and that happened to be when I was doing the last testing and I didn't realize that....
When I put the new ledwiz.DLL in the pulgin's folder under pinballx the plugin sees my 2 LEDwiz's backwards... Another words if I Want To use the 1st LEDwhiz with the plug in I have to set it for number 2

The one called LED plugin

 

 plugin.jpg   64.91KB   3 downloads

Edited by Outhere, 05 March 2018 - 02:48 AM.

[mjr]

Update

Did more testing when I loaded the latest version of pinballx it put the old version of the LEDwiz.dLL back in pinballx Plugin folder and that happened to be when I was doing the last testing and I didn't realize that....
When I put the new ledwiz.DLL in the pulgin's folder under pinballx the plugin sees my 2 LEDwiz's backwards... Another words if I Want To use the 1st LEDwhiz with the plug in I have to set it for number 2

 

Hmm... I'm not certain about this, but I don't think you can use the DOF plugin and another LedWiz plugin at the same time.  If the "LED Plugin" accesses the LedWiz, you're going to have two programs simultaneously trying to send commands to the LedWiz, which is going to cause all kinds of havoc.  If "LED Plugin" is actually for something different (say, addressable LED strips) and doesn't talk to the LedWiz at all, ignore this.

[Outhere]

The plugin LED is for when you're an attraction mode in pinballx...
But for some reason the NEW .DLL is seeing the 2 LEDwiz's Backwards

[mjr]

The plugin LED is for when you're an attraction mode in pinballx...
But for some reason the NEW .DLL is seeing the 2 LEDwiz's Backwards

 

Let's just make sure we're on the same page on a couple of items here, just in case I'm making some wrong assumptions about what you're talking about...

 

1.  Is the "New DLL" we're talking about the one you can download from my page, here?  

 

http://mjrnet.org/pi...ll-updates.html

 

2.  You're aware that this has absolutely nothing to do with DOF R3++, right?  DOF R3++ doesn't use any ledwiz.dll, new, old, or otherwise.  You don't need any particular version installed for DOF R3++'s sake, because you don't need the file at all for DOF R3++'s sake.  So one perfectly good workaround here, if the "role reversal" is bugging you, is to go back to your old happy working ledwiz.dll.

 

3.  Therefore, you want the new DLL for some reason other than DOF, right?  The only reason you'd need the new ledwiz.dll for non-DOF programs is if you have a Pinscape unit in your system.  The factory ledwiz.dll has some incompatibilities with Pinscape thanks to its dual joystick/keyboard interface; the new DLL's function is mostly to clear up those incompatibilities.  You might still want (but not need) the new DLL even for a real LedWiz because it tries to work around the USB hardware defects on the real LedWiz units, and has a more efficient multi-threaded architecture, but those are bonus features, not reasons you would actually need it.  If you run into any third-party software compatibility trade-offs with it (such as what you seem to be running in to), the bonus features might not be worth the hassle and you might want to revert to the factory DLL.

 

Okay then, assuming we're talking about the same things so far and you still want the new ledwiz.dll:  I hate to play the tech support run-around game, but I suspect that the source of your "role reversal" problem is the PBX LED plugin.  The DLL just reports the native hardware unit number reported by the LedWiz itself.  At a guess, the "reversal" suggests to me that the plugin is incorrectly making assumptions about the order of devices reported and isn't checking the hardware ID as it should - that is, it's not letting you assign "LedWiz unit #1" and "unit #2" but rather "first unit" and "second unit".  So you might want to contact the LED Plugin authors and ask them if that's indeed what they're doing.

 

Or, you could just work around it by reversing the order in your setup.  But it probably would be better to fix the plugin, if that is indeed the source of the problem, since they really shouldn't be assuming things about the order of devices showing up in the list - they should be tying the config to the hardware unit IDs, because that's the only numbering system that's guaranteed to be stable over time.

 

If want to pursue this further, could I ask that you start a new thread for it?  Because it's going off-topic for DOF R3++.  I don't muddy the waters too much for people coming to the thread later.

[coreduo0099]

 

After lots of frustration, I swapped back to my 6.11 DirectOutput folder by simply renaming both (swapping the active one) .. All works great (my PROC tables too).  Figuring all MUST be fixed, I just did another clean DOFLinx/DOF R3++/DOFConfig as Terry did.

Still that same error about Extensions.dll not loading with Vpinball.  Super Bizarre.

 

I'm thinking there is some dependency for Extensions.dll that my system has a problem with. (e.g. some .Net version or something I need as a Pre-requisite?) The file is installed by your msi, so it must be correct.  Is Vpinball the only setup that leverages Extensions.dll or do FX2 and FX2 backglasses do as well?

 

The Extensions.dll dependency is directly in the main DirectOutput.dll, so it gets hit in every possible way of loading DOF.  Whatever's going on is down in the bowels of Windows or .Net.  DOF isn't doing anything unusual here; it just uses the standard C# dependency management, so I think what's tripping things up is one of the weird internal rules in Windows or .Net for resolving DLL paths.  There must be something about the system environment when VP is running that changes the way DLL paths are resolved vs when those other programs are running.  The only weirdness I can think of is the unusual way that B2S loads DOF, which is via that Windows desktop shortcut link in the Visual Pinball\Tables\Plugins folder.  Maybe something having that shortcut in the mix is screwing up the path resolution. 

 

The only other similar case I've run into turned out to be that issue with space characters in the path that I mentioned, but that doesn't seem to be the issue on your machine.  Maybe if you post of your relevant directory paths something will jump out - VP, VP tables, B2S, DOF.  Or maybe not; I would never have guessed that the space character would cause problems, so maybe there's some other thing I'd never guess, like maybe you're not allowed to use the letter "D" in paths some of the time with .Net or something bizarre and stupid like that...

One other thing you might want to try, speaking of the bowels of .Net: there's a tool called GACUTIL that you can run in a CMD window.

 

C:\>  GACUTIL /L

 

That lists all of the DLLs in the .Net "Global Assembly Cache", which is a temp folder .Net creates and populates with copies of DLLs used in C# and other .Net programs.  .Net loads DLLs preferentially from that temp cache even when other copies exist on the system, which can sometimes cause problems with updates, since .Net can sometimes ignore new versions you install and run old versions from the cache instead.  So you might try running GACUTIL /L and see if you spot Extensions.dll or any of the other DirectOutput DLLs in the list.  If so, you can remove them with GACUTIL /U <dll name>. 

 

I don't expect that's what's going on in your case, but given that you've ruled out everything else I can think of, it might be worth a shot.

 

Well, I got a chance to work on my system again this weekend.  Uninstalled just about everything and re-installed (no spaces in paths, but I think that was a wild goose chase).  Manually reviewed/scrubbed registry to be sure all paths associated with pinball apps looked good.  Tested with my 6.11 setup and everything worked perfect with DOF with both ledwiz and pinscape.  Meaning:

-VPX with DMDEXT 3rd display with color roms. e.g. AC/DC

-VPX with PUP and DMDEXT.  e.g. Attack from Mars

-FX3 (non-cabinet mode) with backglass and mirror DMDEXT re-displaying playfield DMD onto 3rd monitor

-FX2 Cabinet mode

-PBA (non-TBA) with backglass and mirror DMDEXT re-displaying playfield DMD onto 3rd monitor

-FP with videos e.g. Terry's awesome Aliens Legacy

-VP9

-VP9 PM5

-PROC Games

-UDMD Games

 

All Launched with PinballX

 

Created Fresh 6.22 and same behavior as before. https://ibb.co/c1enTH

no entry for Extensions using gacutil /l

 

However, this time I happened to start with testing AC/DC and found the following:

(Tested with no PinballX involved, no DOFLinx running in background to minimize variables)

-Launch VPX + AC/DC = NO DOF

-hit q to quit, then F5 to play = DOF

-hit q to quit, then F5 to play = DOF !!!

-close AC/DC, open Rollergames =DOF !!!

Quit VPX

-Launch VPX + Roller Games = NO DOF

-hit q to quit, then F5 to play = NO DOF

Quit VPX

-Launch VPX + AC/DC = NO DOF

-hit q to quit, then F5 to play = DOF !!!

-close AC/DC, open Rollergames =DOF !!!

 

So, some difference between launching AC/DC first and other games like rollergames and whatever I tested last time...

 

I decided to move Extensions.dll file from DirectOutput to my VPX Folder

Now VPX games all have DOF working perfect again first time like with my 6.11 setup!

 

Does this provide any hints as to why I'm apparently the only one with this behavior based on the above?

Edited by coreduo0099, 06 March 2018 - 05:49 AM.

[Slydog43]

I have not tested that much, but on my cab, I have DOF working with VPX perfectly (straight VPX & pinballX).  I tried to update to latest DOF3++, but I get no activiity from VPX after the update.  Not sure what to try as I want to get DOFLinx working again on my cab.  I had it working a while back.

Edited by Slydog43, 06 March 2018 - 02:54 PM.

[nw54]

Hi,

I'm building a new cab, and did an install of DOF R3++ (mjr 20180218) using MSI with a PACLED64 (Zebs EZ Install). Devices aren't working as expected.  After install I performed a test running a VP table directly, running a table using Pinballx, and using DirectOuputConfigTester.  Only 2 devices appear to work - the shaker motor and the selenoid for the right flipper (almost not noticeable).  The shaker motor runs with ball launch and for some bumpers or ramps.  DirectOutputConfigTester - Pulsing selenoid 2, 8, & 46 triggers the right flipper selenoid (almost didn't notice it).  Pulsing selenoid 22 and switch 45  triggers the shaker motor.  

 

I have the following environment (VERY vanilla) and have verified and performed the following:

 

1. Win 10, VP 9.9.3, Pinballx, PACLED64 (Zebs EZ Install), Zebs Plunger

2. Verified all dll & exe files unblocked.

3. Verified table scripts were modified to set Controller = CreateObject (B2s.Server")

4. Global search to verify only 1 copy of B2SBackglassServer.dll

5. Verified shortcut in plugins pointed to C:\DirectOutput

6. Verfied B2STableSettings.xml contained <ArePluginsOn>1</ArePluginsOn>

7. From Backglass verified Plugin settingss - DirectOutput (V:3.1.6623.21194 Active & no exceptions)

8. Verified DOF Config settings were set to Zebs install port settings (per install instructions) and redownloaded new directoutputconfig20

9.Tested PACLED64 on different USB ports and with older USB bus - no impact

10. Updated B2S.Server to 1.3.0.2 - no impact

11. Tried using supplied GlobalConfig_B2SServer from Examples - no impact

12. Using GlobalConfigEditor, changed LedWiz def Interval from 1ms to 10ms - no impact

 

Below is DirectOuput.log from Visual Pinball\Tables:

 

DirectOutput Version 3.1.6623.21194, built 2018.02.18 11:46

MJR Grander Unified DOF R3++ edition feat. Djrobx, Rambo3, and Freezy

DOF created by SwissLizard | https://github.com/mjrgh/DirectOutput

2018.03.06 14:58:44.824 DirectOutput Logger initialized

2018.03.06 14:58:44.794 Global config filename is "C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml"

2018.03.06 14:58:44.824 Global config loaded from: C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml

2018.03.06 14:58:44.824 Loading Pinball parts

2018.03.06 14:58:44.825 Loading cabinet

2018.03.06 14:58:44.825 No cabinet config file loaded. Will use AutoConfig.

2018.03.06 14:58:44.825 Cabinet auto configuration started

2018.03.06 14:58:45.058 Detected and added PacLed64 Id 1 with name PacLed64 1

2018.03.06 14:58:45.058 Added LedwizEquivalent Nr. 20 with name PacLed64 1 Equivalent 1 for PacLed64 with Id 1

2018.03.06 14:58:45.059 PacDriveSingleton.PacUIOGetIdList: i=0, numdevices=1, DeviceType=PacLED64

2018.03.06 14:58:45.060 PhilipsHueAutoConfigurator.AutoConfig started...note, actual connection detection will happen asynchronously, and device disabled if not succesfull (check further down in the log)

2018.03.06 14:58:45.327 FT245RBitbangControllerAutoConfigurator.AutoConfig.. Detected FT245RBitbangController[0], name=FT245RBitbangController 0, serial #ZBPLNGOP01

2018.03.06 14:58:45.327 Detected and added FT245RBitbangController Id 0 with name FT245RBitbangController 0

2018.03.06 14:58:45.327 Added LedwizEquivalent Nr. 40 with name FT245RBitbangController 0 Equivalent 1 for PacUIO with Id 0

2018.03.06 14:58:45.327 Cabinet auto configuration finished

2018.03.06 14:58:45.328 Cabinet loaded

2018.03.06 14:58:45.328 Loading table config

2018.03.06 14:58:45.330 Warning: No table config file found. Will try to load config from LedControl file(s).

2018.03.06 14:58:45.331 Will try to load configs from DirectOutput.ini or LedControl.ini file(s) for RomName ckpt_a17

2018.03.06 14:58:45.339 Loading LedControl file C:\DirectOutput\Config\directoutputconfig20.ini

2018.03.06 14:58:45.362 Min DOF Version is 0.8 for file directoutputconfig20.ini

2018.03.06 14:58:45.774 1 directoutputconfig.ini or ledcontrol.ini files loaded.

2018.03.06 14:58:45.776 Config for RomName ckpt_a17 exists in LedControl data. Updating cabinet and config.

2018.03.06 14:58:45.797 Table config loading finished: romname=ckpt_a17, tablename=Checkpoint

2018.03.06 14:58:45.798 Pinball parts loaded

2018.03.06 14:58:45.798 Starting processes

2018.03.06 14:58:45.798 Initializing cabinet

2018.03.06 14:58:45.798 Debug: Initializing output controllers

2018.03.06 14:58:45.800 PacLed64 Id:1 initialized and updater thread started.

2018.03.06 14:58:45.802 FT245RBitbangController FT245RBitbangController 0 with serial number ZBPLNGOP01 has been initialized and the updater thread has been started.

2018.03.06 14:58:45.802 Debug: Output controllers initialized

2018.03.06 14:58:45.807 Cabinet initialized

2018.03.06 14:58:45.811 Loading shape definition file: C:\DIRECTOUTPUT\DirectOutputShapes.xml

2018.03.06 14:58:45.817 Connection to FTDI chip ZBPLNGOP01 established.

2018.03.06 14:58:45.859 Framework initialized.

2018.03.06 14:58:45.859 Have fun!

2018.03.06 15:00:55.151 Finishing framework

2018.03.06 15:00:55.153 Finishing cabinet

2018.03.06 15:00:55.154 Debug: Finishing output controllers

2018.03.06 15:00:56.169 PacLed64 Id:1 finished and updater thread stopped.

2018.03.06 15:00:56.288 Connection to FTDI chip ZBPLNGOP01 closed.

2018.03.06 15:00:56.288 FT245RBitbangController FT245RBitbangController 0 with serial number ZBPLNGOP01 has been finished and the updater thread has been terminated.

2018.03.06 15:00:56.288 Debug: Output controllers finished

2018.03.06 15:00:56.288 Cabinet finished

2018.03.06 15:00:56.288 DirectOutput framework finished.

2018.03.06 15:00:56.288 Bye and thanks for using!

  

 

Thanks to mjr and all the others for your great contributions.  If there is anything you'd like me to try to get this to work, let me know.

[mjr]

I decided to move Extensions.dll file from DirectOutput to my VPX Folder

Now VPX games all have DOF working perfect again first time like with my 6.11 setup!

 

Does this provide any hints as to why I'm apparently the only one with this behavior based on the above?

 

Interesting.  I still don't have a clear idea of what's going on, but this at least seems to confirm that it's something about the way C#/.Net is searching for the DLL.  

 

What exactly are all the paths you're using?  VP, B2S, tables, PBX, and DOF?  Maybe there's some pattern to the path names that I could spot if I could see the exact names.

 

I notice that in the error box screenshot you posted, there's that verbiage at the bottom about enabling assembly binding logging:

 

WRN: Assembly binding logging is turned OFF.  To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog](DWORD) to 1.

 

They're actually only telling you part of the story - it looks like there are several other variables you have to set, all under the the same key (HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion):

 

   ForceLog  DWORD = 1

   LogFailures  DWORD = 1

   LogResourceBinds  DWORD = 1

   EnableLog   DWORD = 1

   LogPath  String - set to a folder path on your disk (C:\LOGS\ or wherever you want them - be sure it ends with a "\")

 

So maybe you could try this: turn that logging on, move Extensions.dll back to where it started, run one of the failure scenarios again, and then look at the log it creates.  That might shed some light on what's going wrong.

Edited by mjr, 07 March 2018 - 04:34 AM.

[mjr]

I'm building a new cab, and did an install of DOF R3++ (mjr 20180218) using MSI with a PACLED64 (Zebs EZ Install). Devices aren't working as expected.  

 

[From the log]

 

2018.03.06 14:58:45.327 FT245RBitbangControllerAutoConfigurator.AutoConfig.. Detected FT245RBitbangController[0], name=FT245RBitbangController 0, serial #ZBPLNGOP01

2018.03.06 14:58:45.327 Detected and added FT245RBitbangController Id 0 with name FT245RBitbangController 0

 

That part with the "FT245RBitbangController" looks like it might be at least part of the problem.  FT245RBitbangController is DOF's user-friendly way of saying that you have a SainSmart relay board.  You didn't mention having a SainSmart relay board, so it might be news to you that you have one!  Or at least, that DOF thinks you have one.  Just a wild guess, but based on the serial number reported, I'm thinking that this is not actually a SainSmart relay board, but is in fact a "ZeB's PLuNGer", which you said you do have.

 

So I think what's going on is this: DOF is incorrectly thinking that your plunger is a SainSmart board.  It's sending commands to that device to turn things on and off.  Some of those commands might have been intended for your PacLed, but in any case they're probably not intelligible to the plunger. 

 

I'm not sure if that alone would screw up everything on your PacLed, so there might be something else going on as well, but the rest of your log makes it look like DOF thinks everything is working great.  So hopefully this is the whole problem.

 

I'm going to have to look at the SainSmart auto-detect code and figure out how to fix this.  Evidently that code is just blindly assuming that anything with an FT245R chip is a SainSmart, which is clearly a faulty assumption.  What I don't know is what other information is available to distinguish SainSmarts from everything else.  I could easily add a check for the serial number pattern that excludes the pattern we see here for Zeb's plunger, but that seems a little hack-ish and likely to break again down the road if Zeb ever changes his serial number pattern, plus there are probably lots of other things using FT245R chips that will cause this same problem if we can't reliably identify SainSmarts specifically.

 

If anyone has any specific knowledge of how SainSmart's identify on USB, let me know - it would be good to add a specific and reliable test for them.

Edited by mjr, 07 March 2018 - 05:08 AM.

[mjr]

nw54, here's a build with just a simple check for the ZBPLNG... serial number prefix, to make it suppress Zeb's plungers in the FT245R auto-detection.  Give it a try and see if that helps with the PacLed problems.

 

http://mjrnet.org/pi...jr-20180306.zip

http://mjrnet.org/pi...jr-20180306.msi

 

I also added the "description" string reported by the device to the log.  It would be helpful if you could tell me what that says for the Zeb's plunger, whether or not the build helps with the PacLed problem.  That part is just to gather data on how best to distinguish the various FT245R devices.

 

If anyone has an actual SainSmart and wants to try this build, it would also be great to know what the "description" says for that device.  I'm hoping that SainSmart puts something there that would help identify them, like maybe include the word "SainSmart".

Edited by mjr, 07 March 2018 - 05:38 AM.

[coreduo0099]

 

I decided to move Extensions.dll file from DirectOutput to my VPX Folder

Now VPX games all have DOF working perfect again first time like with my 6.11 setup!

 

Does this provide any hints as to why I'm apparently the only one with this behavior based on the above?

 

Interesting.  I still don't have a clear idea of what's going on, but this at least seems to confirm that it's something about the way C#/.Net is searching for the DLL.  

 

What exactly are all the paths you're using?  VP, B2S, tables, PBX, and DOF?  Maybe there's some pattern to the path names that I could spot if I could see the exact names.

 

VP9, VP9PM5, VPX:

E:\Emulator\Pinball_emu

Tables, BS2

E:\Emulator\Pinball_emu\Tables

DOF

E:\Emulator\Pinball_emu\DirectOutput

PBX (although I've tested without it just in VPX)

E:\Emulator\Pinball_emu\PinballX

 

For working tables I have Extensions in

E:\Emulator\Pinball_emu\DirectOutput\Extensions.dll

(and for VP to work, also a 2nd copy in) E:\Emulator\Pinball_emu\Extensions.dll

 

So maybe you could try this: turn that logging on, move Extensions.dll back to where it started, run one of the failure scenarios again, and then look at the log it creates.  That might shed some light on what's going wrong.

 

Couldn't get log files to generate based on:

https://ibb.co/mNV1oS

https://ibb.co/msnQF7

 

 

 

 

[mjr]

>What exactly are all the paths you're using?  

[ various E:\ paths]

 

Huh, nothing obvious, except that you're so flagrantly tempting fate by using a drive other than C:.  Or maybe those "_" characters are as bad as space characters.

 

 

 

Couldn't get log files to generate based on:

https://ibb.co/mNV1oS

https://ibb.co/msnQF7

 

Grrr, awful Microsoft black box.  There must be some other step you have to do that no one documents - maybe you have to install some .Net debug version or something, or at least reboot Windows.  Well, it was worth a shot; it would be awfully interesting to know what those supposed logs would have to say, but I guess .Net doesn't give up its secrets that easily.