490 replies to this topic

[DKong]

Thanks guys. VPX was running as Admin, so I unchecked that in properties and now DOF and exiting seems to be working in and outside of Pinup Popper. I'm hoping the Admin thing was the culprit and I won't see this issue again.

 

@Nailbuster,

Your comment about some table throwing an error has me thinking about any possible VPX tables I might have issue with, now that VPX is not running as Admin anymore. Do you or anyone else know which tables might have issue with running as non Admin?

[mjr]

IIRC,  there were even some table scripts in vpx that accessed and wrote to the registry in script and would error out if VPX wasn't running as admin... everyones solution to that was... run vpx as admin

 

Yeah, unfortunately, "try running it as Admin" has become a generic troubleshooting step that everyone lumps in with the usual bunch of random things to try:  reboot Windows, check for blocked DLLs, make a small blood sacrifice to Microsoft.  All are about equally effective in most cases, so I think on the whole it's usually better to go with the blood sacrifice and avoid the risk of screwing things up by checking random Admin boxes. 

 

 

Your comment about some table throwing an error has me thinking about any possible VPX tables I might have issue with, now that VPX is not running as Admin anymore. Do you or anyone else know which tables might have issue with running as non Admin?

 

I'm sure no such list exists, but if you ever run into one, I'd say treat it as a bug in the table, not a reason to switch your whole system to Admin mode.  Report it to the table author (unless you can just fix the script yourself).

[boslaw]

Weird problem with R3++ - everything is working well in my setup except the ACDC table. When I load that table, I get no DOF. I get full DOF with all of my other tables. ACDC worked fine before I upgraded to R3++. I saw some other posts in this thread about ACDC but they didn't seem relevant to my issue.

[Outhere]

Go to the DOF website and make sure the correct rom is selected for the ACDC table... Then download new files

[DDH69]

I'm seeking a favour from mjr or someone who can properly update the wonderful R3++ code thread.

 

I have am currently working to get the PinControl 1 board working with DOFLinx.  While working on this I have found what I believe to be an original bug in DOF for the PinControl 1 device.  I have worked through the current version of R3++ source and found what I believe it to be.  Having said that I am not capable of rebuilding the DOF solution properly so am asking if smeone would make the change, let me test it, and if it all works make a release with the fix in.

 

I currently have a test PinControl 1 board setup and can test this immediately.

 

The symptom I've identified is that out of the 10 outputs, output #8 does not update properly.  I believe this has been missed for a long time since outputs 8, 9 and 10 are dedicated for RGB strips.  This means that most people would see a few odd colour changes and probably dismiss it or not be able to reproduce it.  The section of code where I believe the fault to be is below;

 

                for (int i = 0; i < 7; i++)
                {
                    if (OldValues == null || OldValues[i] != OutputValues[i])
                    {
                        Port.Write("{0},{1}{2}#".Build(i + 1, (OutputValues[i] == 0 ? 2 : 1), (OutputValues[i] != 0 && i == 0 ? ",0,0," + OutputValues[i].ToString() : "")));


                    }
                }

                bool ColorChanged = false;
                bool IsBlack = true;
                for (int i = 7; i < 10; i++)
                {
                    if (OldValues == null || OldValues[i] != OutputValues[i])
                    {
                        ColorChanged = true;
                    };
                    if (OutputValues[i] != 0) IsBlack = false;
                }

 The particular line is (with my change);

for (int i = 7; i < 10; i++)

It was;

for (int i = 8; i < 10; i++)

It looks like output #8, array position 7, was never being tested in the second update checking loop.

 

I have attached both the old and proposed PinControl.cs files to this message.

 

I hope someone can assist me with this.

Attached Files

•  PinControl Bug.zip   2.73KB   1 downloads

[mjr]

It looks like output #8, array position 7, was never being tested in the second update checking loop.

 

Good catch - I think you're exactly right about that.  I just built a test copy for you with the fix:

 

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

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

 

Let me know if that works for you.  If so I'll check it into my github fork and make this build current on my R3++ page.

[DDH69]

Thanks mjr.  I've given it a quick run on the test PinControl1 setup on my development machine and the problem is resolved.

 

I've got to go to work now, but tonight will load it on my cabinet for a quick regression test using LEDWiz, Pinscape and Teensy.  As far as I can see its good to go as is, but will report back any issues found on regression.

 

Thanks again.

[mjr]

Thanks mjr.  I've given it a quick run on the test PinControl1 setup on my development machine and the problem is resolved.

 

I've got to go to work now, but tonight will load it on my cabinet for a quick regression test using LEDWiz, Pinscape and Teensy.  As far as I can see its good to go as is, but will report back any issues found on regression.

 

Perfect - thanks.  This build is pretty much identical to the last release build (other than your fix, of course!), so I don't expect any new issues, but it's always good to do a little testing to make sure.

[DDH69]

Perfect - thanks.  This build is pretty much identical to the last release build (other than your fix, of course!), so I don't expect any new issues, but it's always good to do a little testing to make sure.

 

And as expected, no issues using it in the cabinet.  Sadly I had to play a good 30 minutes of pinball to verify this 

[mjr]

 

Perfect - thanks.  This build is pretty much identical to the last release build (other than your fix, of course!), so I don't expect any new issues, but it's always good to do a little testing to make sure.

 

And as expected, no issues using it in the cabinet.  Sadly I had to play a good 30 minutes of pinball to verify this 

 

Sorry you had to go through that!   But glad to hear it - I'll update everything to the fixed version.

[boslaw]

Go to the DOF website and make sure the correct rom is selected for the ACDC table... Then download new files

 

I've done that - no change. It's the only table that was affected by upgrading to R3++. 

[mjr]

 

Go to the DOF website and make sure the correct rom is selected for the ACDC table... Then download new files

 

I've done that - no change. It's the only table that was affected by upgrading to R3++. 

 

I have no guess as to why one table would be affected - that doesn't sound like anything I've run into before.  Have you tried looking at the log?

[mjr]

New testing version!

 

I've posted a new, experimental DOF R3++ release.  The big change in this version is repackaging to reduce the number of loose DLLs.  I'm hoping that this will fix the dreaded "space in the filename" and "can't install on D:/E:" problems. 

 

Where to find it:

 

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

 

Look for the "Experimental 9/2018 edition" links.

 

What's new in this version:

 

This is the same as the current stable R3++ release, except that it repackages each of the DOF plugin and COM object assemblies into monolithic DLLs using a C# tool known as Fody/Costura.  I'm pretty sure that all of the weird problems that many people have run into with path/folder names and drive letters trace to the C#/.Net DLL loading mechanism, which gets involved because DOF is structured into a bunch of separate C# and native DLL components that all have to get loaded for DOF to work.  This is a common problem in the C# and .Net worlds, which is why the Fody/Costura tool is widely used.  It's designed to fix these sorts of deployment headaches by turning collections of components (like DOF) into monolithic applications or DLLs that Windows can load more reliably.

 

I also tried to fix some build errors in the ProPinball bridge, so I'm hoping that will be un-broken now, but that's purely speculative since I don't have a ProPinball setup to test that with.

 

Who should try it:

 

First off, those who don't mind risking their stable setup on a testing version!  I actually don't think it's all that risky, since the only thing that's changed is the DLL repackaging described above, and that's all done using a well-known and widely used C# tool (Fody/Costura) that appears to just work.  I've deployed it on two of my machines and everything has been perfectly smooth.  But even so, the "don't fix it if it ain't broken" rule is always worth considering.

 

With that in mind:

 

(1) If you've run into any path/drive problems with past DOF versions, it would be great if you could give this a try and see if it fixes them.  You probably worked around those problems by changing the path name or drive letter, so the thing that would be really helpful here would be if you could tempt fate by going back to the OLD drive letter or path name that gave you problems in past versions - those "E:\Direct   Output" type folder names with spaces or non-C: drive letters.

 

The space/D:/E: problems were definitely not universal - they didn't affect any of my machines, for example - so this will be a much more conclusive test if you personally experienced one of the path name problems in the past.  If you've never experienced the problem, your machine might simply never have had it in the first place.  The real test will be if it works on a few machines that were known to have the space/D:/E: problems earlier.

 

(2) If you've tried to use the ProPinball bridge in DOF R3++ and found that it was broken, it would be helpful if you could try this one and see if it's fixed now.

(3) PinballY 64-bit users.  The next PBY release will make DOF work in the 64-bit version.  That wasn't working before because DOF's COM object only gets registered in 32-bit mode, so a 64-bit program has to do some extra work to load it, but that extra work depends on the COM object exposing a COM type library, which it didn't do before.  This version adds that to enable 64-bit callers.

Fewer files!

 

You might notice that some of the loose DLL files formerly included in the DOF folder are missing.  That's intentional, and highly desirable.  Those are now embedded in each of the "main" DLLs as needed, rather than being installed as separate files. 

Edited by mjr, 05 September 2018 - 05:02 AM.

[boslaw]

 

 

Go to the DOF website and make sure the correct rom is selected for the ACDC table... Then download new files

 

I've done that - no change. It's the only table that was affected by upgrading to R3++. 

 

I have no guess as to why one table would be affected - that doesn't sound like anything I've run into before.  Have you tried looking at the log?

 

redownloaded my rom and re-saved DofConfig again and this time it took. Strange that something affected only that one table but glad that it's working again.

[mjr]

redownloaded my rom and re-saved DofConfig again and this time it took. Strange that something affected only that one table but glad that it's working again.

 

Great - maybe it was just a problem overwriting the .ini file on the earlier attempt, or something like that.

[vinw]

Friends , i am trying by first time run DOF in VPX .. i have installed DOF R3++ , VPX in WIN 10 RS4, I did all Dof config files in configtool , i have created a directoutput directory in C ... tables/ plugins created shortcut to directoutput . . My ledwiz is a ledwizclone with Arduino . I have tested ledwizclone com ledtester program and my solenoids all works, but when I run vpx game nothing happens, ,my ledwizclone don't works with the game. My B2S plugin is active and say DOF is active.. I see log dofconfig ledwiz equivalent is created number 4 , looks all ok... I dont know more what do .. (win10 RS4 all dlls files dont have unblock check button , looks all ok)

[NailBuster]

Hey MJR... thought you'd be the best to ask about this since you might come across it with PBY.  

 

I use a scripting engine to support DOF via comobject.  works fine, but issues come up with systems as I have to deal with calling dof.finish then launch emulator/game and on return having to wait a bit before trying to init DOF again.  B2s seems to linger a bit and keeps the DOF connection open. 

 

On some systems you can crash the DOF interface if I try and send a DOF event right after calling dof INIT.  its like DOF init isn't ready to receive events right after the INIT call.  if i wait till dof it fully initialized (like waiting for the start button to visibly pulse) then I can safely send new DOF events to it.

 

so a couple of ideas to solve this...  have a comobj method that will allow to determine the 'state' of DOF and skip if its not ready.  that should at least stop the exceptions.

 

another idea, is to make sure comobj.INIT doesn't return until DOF is complete and can accept new events.

 

another 'great' idea is that DOF allows multiple connections and won't unload until last connection is 'finished'.  Would be great if upon returning from VPX that I could just keep the DOF comobject open and just call dof.refresh and start sending events without the need to .finish DOF and .init (waiting for DOF).

 

unless you know of a better way to deal with DOF and launching emulators that use dof.

 

I use javascript engine in Popper and it just looks like this:

 

DOFObject = new ActiveXObject("DirectOutput.ComObject");

DOFObject.Init("B2SServer","","pinupmenu");   

[mjr]

NailBuster - indeed, DOF wasn't designed with concurrency in mind.  None of the feedback stack is; the USB devices that DOF talks to, and their manufacturer DLLs, all have the same issues.  It would be good to re-engineer DOF a bit with an eye toward concurrency, but it'll take some doing.  The basic problem is that DOF runs in-process, so the DOF object you're creating in your process and the DOF object I'm creating in mine are running in their own little worlds thanks to Windows process isolation.  Each object has no idea the other one exists, and the two have no way of coordinating with each other.  I don't mean that they don't expose this at the COM interface level; I mean that DOF internally has no conception of other instances in other processes.  So step one is to add a server that can coordinate all running instances across processes, and step two is to retrofit awareness of that server into the appropriate places in the DOF runtime structure, so that the different instances coordinate with one another and don't step on each other.  Once that's done, there probably are some new capabilities that could be exposed through the COM interface to help launcher programs.

 

Anyway, it's something I've thought about doing at some point.  But it's kind of low on my priority list right now since it really only affects the front ends, and (as you've described) you can mostly work around it with a little heuristic fussing.

Edited by mjr, 12 September 2018 - 06:30 AM.

[wrd1972]

MJR, still have one remaiing DOF issue. The DOF almost never works on the first game played. But if I close the table, restart it the second time, DOF works fine.

So, I am still running a pair of Sainsmart 8-relay boards, and the Zebs Deluxe plunger that has a function based off of the Sainsmart too, thats used for the lighted cab buttons. So thats three Sainsmart boards that need to run, when the table is started.

So when a table starts, most of the time, one of the three boards will activate properly, but not the other two. Or sometimes, all three will activate. And even sometime, none of the the three. Its all freaking random. But close the table, restart the table, all three activate perfectly, and everything is golden. So it just seems like the boards are not activating like they should, when they should. Not sure how that activation process works???

SO I have done the following:

• Removed all AV…problem remains
• Reinstalled DOF 3++…problem remains
• Reinstalled the FTDI driver for the three Sainsmarts…problem remains
• Tried different USB inputs…problem remains
• Tried different USB cables…problem remains

So IMO, the Sainsmarts are not initializing and or activating, when the table starts…the first time. But they do activate the second time?

 

SO I am curious, when 3++ is installed, does it create the "cabinet config", and the "global config". I remember a while back, I had to manually create these files. But now, things tend to set up more automatically. Is that correct? I also know that this issue was not present on DOF2, Does that mean anything. Man really looking forward to putting this issue to bed.

 

Also, still no log. I tried to make a global confi so that we would have an error, but I must still be doing something wrong. Any more ideas?

[mjr]

MJR, still have one remaiing DOF issue. The DOF almost never works on the first game played. But if I close the table, restart it the second time, DOF works fine.

 

Have you tried the latest "experimental" update, from 2018-09-04?  I have no idea what's causing the first-time-doesn't-work problem, but at least a few other mystery problems traced to weird .Net loading issues, and the whole point of the experimental version is to try to eliminate the .Net loading issues for good.

 

If that's still failing, what are you seeing in B2S when you look at the "plugins" status during the initial non-working run?

 

 

SO I am curious, when 3++ is installed, does it create the "cabinet config", and the "global config". I remember a while back, I had to manually create these files. But now, things tend to set up more automatically. Is that correct? I also know that this issue was not present on DOF2, Does that mean anything. Man really looking forward to putting this issue to bed.

 

The cabinet config file with the Sainsmart device list is no longer needed, and in fact, if you have one left over, you should get rid of it.  R3++ has code that scans for Sainsmarts automatically, similar to the way most of the other devices are discovered automatically.

 

So it's possible that your problems are due to leftover device listings in your config files from an earlier version.  Having the explicit listings confuses DOF by creating multiple DOF access objects per device, which can conflict with each other.  You might want to scan through all of your config files and make sure that nothing Sainsmart related is mentioned anyway. 

 

 

Also, still no log. I tried to make a global confi so that we would have an error, but I must still be doing something wrong. Any more ideas?

 

Arg, finding that stuff in DOF is a giant PITA because DOF is terrible at providing diagnostics when anything is wrong.  It just silently ignores you.  All I can tell you is to go through Swiss Lizard's documentation with a fine-toothed comb and make absolutely sure you've got every single detail exactly right in the config files.