490 replies to this topic

[mjr]

I do run pinballx in admin mode so i changed properties and had pinballx start without admin and log shows same errors. Everything else runs as user.

 

Aw, seemed so close!

 

 

What I do find interesting is that prior to the msi install, the log always stopped at "...check to make sure directoutput.com object is registered"

 

Yeah, the problem seems to be in that COM object registry lookup - .Net fails to find it on some machines (such as yours, apparently) even though the object to all appearances is properly registered.  That seems to be the common thread for other people reporting the problem.

 

One other suggestion I came across was to try to load the COM object by GUID rather than by name.  That bypasses one layer of registry lookups, at least, so it supposedly clears it up for some people.  I just tried adding that (direct GUID lookup) as a fallback when the name lookup fails.  Here's a new build with that in place:

 

http://mjrnet.org/pi...r-20180308b.msi

http://mjrnet.org/pi...r-20180308b.zip

 

Hopefully that'll clear it up for you, but the way these .Net things go, it'll probably just bring us to another layer to peel back...

Edited by mjr, 09 March 2018 - 04:26 AM.

[fakingdeath]

After msi install of above release.

Init failed: Could not create instance of DirectOutput framework ... failed due to error 80040154

Break time lol

[Outhere]

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

is to go back to your old happy working ledwiz.dll. -- That's what I did after I figured out what it was doing

But for the time being I quit using that plugin

 

 

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.

 

Edited by Outhere, 26 March 2018 - 05:52 PM.

[mjr]

After msi install of above release.
Init failed: Could not create instance of DirectOutput framework ... failed due to error 80040154

 

Gah!  

 

That one looks like it might be a 32/64 bit problem.  The suggested solution seems to be to build explicitly for x86 rather than "all platforms".  (This is a whole separate .Net nightmare, apparently - one of the original points of .Net was platform independence, but at some point Microsoft decided their whole approach was poorly thought out, and they started telling developers to build for specific targets after all.  DOF never got the memo - it's been using the once forward-thinking, now old-fashioned "All Platforms" build targets.)

 

I went through and changed everything to explicit x86 targeting.  That doesn't seem to have destabilized anything on my machine, so maybe it's worth a try to see if you're having the dreaded 32/64 bit clash issue.  The odd thing is that this hasn't been a problem for me, but I'm on Win 8.1, so maybe it's a Win 10 issue.

 

http://mjrnet.org/pi...r-20180308c.msi

http://mjrnet.org/pi...r-20180308c.zip

 

Let's see what exciting new COM error code this one turns up for you...

[fakingdeath]

Actually the same error. Used the msi linked above version c from yesterday

 

Edited by fakingdeath, 09 March 2018 - 05:20 PM.

[mjr]

Actually the same error. Used the msi linked above version c from yesterday

 

Huh... I can't find much else about this error, other than that the DLL is simply not registered.  Let's check your registry and see what's there...  open up RegEdit and search for the class key (the prefix A23BFDBC should be enough to find it).  You're on 64-bit Win 10, right? It should show up under

 

HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{A23BFDBC-9A8A-46C0-8672-60F23D54FFB6}

 

If you find it, check what's under it, especially the subkey InprocServer32 - there should be a "CodeBase" value pointing to DirectOutputComObject.dll file with the correct path.  

 

You might also search your Windows directory and see if you have a copy of mscoree.dll installed.  That's the .Net component that loads C# DLLs.  There might be some problem with that, or the version of .Net you have installed, or something along those lines.

[fakingdeath]

I know very little about registries but I did find it and the path to dll is correct. The only thing that looks weird to me is the "class" where is says directoutputcom.comobject

 

I've attached a snippit for you to glance at.

 

 

Also a directory search turned up that I do in fact have the mscoree.dll installed.

 

All my research has also indicated that it's a 32bit vs x64/x86 issue in the build but we've tried that. So I'm especially baffled

Edited by fakingdeath, 09 March 2018 - 08:16 PM.

[mjr]

I know very little about registries but I did find it and the path to dll is correct. The only thing that looks weird to me is the "class" where is says directoutputcom.comobject

 

Yeah, that all looks right.  DirectOutputCom.ComObject is even (weirdly) the right string.

 

I really don't know what else to look at.  It seems like everything within DOF is doing what it should, but it's still not working - something down in the bowels of COM is going wrong and COM isn't playing coy with the diagnostics.  I think the is point where tech support tells you that you need to reinstall Windows and unplug your cable modem for thirty minutes.

The DOF target .Net framework version number is 4.5.2, so maybe you need to explicitly install that version if you don't already have it.  (You can have multiple .Net versions installed at once, so you can just add it to your existing setup - you don't have to remove or replace anything that's already there.)

[fakingdeath]

Yeah I'm running 4.7.1 so when I get home I'll give 4.5.2 a go and see what happens.

[mjr]

Yeah I'm running 4.7.1 so when I get home I'll give 4.5.2 a go and see what happens.

 

Okay, sounds good.  I've definitely a couple of cases in the past where installing a particular .Net version was necessary.  This doesn't seem like it fits that profile, but then again it's not clear what profile it fits since it's giving us so little information.

[fakingdeath]

I'm going to give up on the plugin. Windows 10 ltsb with pre-installed 4.7.1 blocks previous versions of .net to be installed and since it was preloaded you cannot remove it to install the earlier version. News to me but the installer even took me to an online page from Microsoft stating the resolution to my issue was to do nothing as the newest version was installed...

[nw54]

mjr,

With power supply back online I installed 20180307.msi.  Things are working good so far.  Thanks.

[coreduo0099]

 

2018.03.07 23:56:59.607    Pre-loading DLL Extensions.dll from file:\E:\Emulator\Pinball_emu\DirectOutput\Extensions.dll

 

Then I decided to remove Extensions.dll from my DirectOutput folder and it still worked the first time.  however the log states this:

 

 

however since DOF worked and i had removed it from my DirectOutput directory, that is impossible. It should have been:

2018.03.07 23:56:59.607    Pre-loading DLL Extensions.dll from file:\E:\Emulator\Pinball_emu\Extensions.dll

 

Oops - yeah, I logged what it was attempting, but not the results.  And I think that "file:\" prefix from C# was actually screwing things up anyway, so this might not have had the intended effect.  I've posted another round that fixes those - this one reports the results of each load so we can see if it's actually doing what it's supposed to.

 

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

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

 

 

to test, I also then removed Extensions.dll from my VPX folder and DOF never functions with the backglass and I get the Extensions.dll not found message like before, (which I should since it does not exist anywhere)

 

I just realized that you've been posting pictures of the error box and I don't know exactly where that error box is coming from.  Is that the B2S plugin status message, or is it coming from somewhere else?  Does it appear spontaneously when you run, or are you going looking for it in the B2S right-click settings?  The location and timing of its appearance might be important - I might be looking in the wrong place for where the failed DLL load is happening.

Hi, just getting back here after my system got hosed.  And my backup boot ssd drive. 

At least one of my crappy backups worked and I could still mount my drives.. ugggg.

 

So, as long as I had a big mess, I figured I might as well do a fresh W10 install and keep the cabinet machine as clean as possible.

I set it up with all the files up to your 3/7 build, (not the 3/8 in your last post) and used my old directory structure on E:/ and had the same results.

I then uninstalled VPinballX, PinballX, your DirectOutput, Pinup, then re-installed them all on C: with only one directory change which was C:\Visual_Pinball instead of C:\Visual Pinball and....

Ta Da!

It worked with ACDC first time.  So, it sure seems like there is a hardcoded Path somewhere that does not like my path structure that worked for years up thru 6.11.

I'll keep testing and try to keep everything on E except DirectOutput and see if that works next. 

 

Also my FX3 install used to have DOF, it is still the same version and now it does not detect the table changes... I'll have to upgrade it to the Jurrasic Park version I guess and see what happens...

(it sees the FX3 launch and admin privileges are OK, but it won't show backglass or detect table changes in the UI like it did before.. Maybe something between 6.2 beta or 6.20 and 6.22 changed???

 

Thanks again for the assistance and hopefully I nail down which of these apps can't be anywhere other than C.

[mjr]

So, as long as I had a big mess, I figured I might as well do a fresh W10 install and keep the cabinet machine as clean as possible.

 

 

I set it up with all the files up to your 3/7 build, (not the 3/8 in your last post) and used my old directory structure on E:/ and had the same results.

I then uninstalled VPinballX, PinballX, your DirectOutput, Pinup, then re-installed them all on C: with only one directory change which was C:\Visual_Pinball instead of C:\Visual Pinball and....

Ta Da!

It worked with ACDC first time.  So, it sure seems like there is a hardcoded Path somewhere that does not like my path structure that worked for years up thru 6.11.

I'll keep testing and try to keep everything on E except DirectOutput and see if that works next. 

 

Well, very interesting.  I don't know why the paths would be so brittle, but it fits with the weird way it's working on some machines and not others.  I can't see anything in the DOF source itself with any hard-coded C: paths.  Maybe PinballX has introduced something on their side.

I'm glad you were able to find a solution.  Let me know what you find if you experiment more with moving stuff around - it would definitely be good to know where that C: dependency is coming from.

[fakingdeath]

Coredyo0099: ...it sees the FX3 launch and admin privileges are OK, but it won't show backglass or detect table changes in the UI like it did before.. Maybe something between 6.2 beta or 6.20 and 6.22 changed???

You're referring to doflinx but yes doflinx 6.22 supports the most recent fx3 update as of now but will not work with previous updates. Every update ddh69 has to modify code, silly zen...

[DDH69]

@coreduo0099 -  Any DOF R3++ stuff keep in this thread, if you've got DOF up and running but not FX3 / DOFLinx, start up a thread in the support forum so we can stay on track in this thread.    No problem helping, just don't wish to take this thread off topic.

[xantari]

@mjr I looked at the source and do not see MinUpdateIntervalMs setting in the source that swisslizard added over at V P U in the Knocker DOF thread. I asked him if he could be kind enough to upload the updates to the master github repository or to add a branch with the stuff so we could get it merged into Rambo3's sources and your sources.

[mjr]

@mjr I looked at the source and do not see MinUpdateIntervalMs setting in the source that swisslizard added over at V P U in the Knocker DOF thread. I asked him if he could be kind enough to upload the updates to the master github repository or to add a branch with the stuff so we could get it merged into Rambo3's sources and your sources.

 

Which source are you looking at?  It should be there in both the LedWiz and PacLed.  Or are you talking about something else?

 

https://github.com/m...ut/LW/LedWiz.cs

 

https://github.com/m...Pac/PacLed64.cs

[xantari]

Hmm, github search didn’t find it. Guess we are good to go

[senseless]

I'm going to give up on the plugin. Windows 10 ltsb with pre-installed 4.7.1 blocks previous versions of .net to be installed and since it was preloaded you cannot remove it to install the earlier version. News to me but the installer even took me to an online page from Microsoft stating the resolution to my issue was to do nothing as the newest version was installed...

Did you try to register the com object again (use admin rights)?

Verstuurd vanaf mijn SM-G930F met Tapatalk