490 replies to this topic

[mjr]

Dofslave is a self contained dof build. My dof works fine otherwise. The path for this particular case is the pro pinball path in the steam directory. Almost positive the dofslave version has the older ledwiz.dll version in it. (The Logs don’t detect a Ledwiz and the zebs board I am using requires it )

I tried compiling a new on using freezys git, but my level of understanding this is still pretty basic

 

I'm sure you're right that it's self-contained, as it has the Costura DLL embedder stuff in it, but shouldn't it be self-contained using the DOF of the version it's built with?  So if you're rebuilding the whole thing, shouldn't you be picking up the DOF version of the VS solution it's being built against?  Unless Freezy embedded an old snapshot of the DOF DLLs in there, but I don't see them, and there wouldn't be much point of incorporating it into the DOF build anyway if it was just going to use an old snapshot.  He does have the ledwiz.dll bundled into the Costura/Fody tree, but I don't think that should matter, as a  modern DOF would never even load that DLL.

[electricmagma]

I think I understand what youre saying. I think the last time freezy compiled it, was 2017. My particular issue is that the regular ledwiz doesnt work with zebs stuff. Therefore dofslave doesnt detect a ledwiz device.

When I run the dofslave bundled with your version I get errors about missing pinball bridge etc. The old version works but because there are no ledwiz devices detected, nothing fires.

I think the reason I asked the question was because the original dofslave was 8mb. Then since your unified, the file size has changed with each release

I wish I knew more about taking the newer version of dof and compiling it to an exe. Ive tried, maybe Ill keep at it until I figure it out, I think I was more curious as to if I was on the right track

Edited by electricmagma, 15 October 2019 - 12:23 AM.

[mjr]

I wish I knew more about taking the newer version of dof and compiling it to an exe. Ive tried, maybe Ill keep at it until I figure it out, I think I was more curious as to if I was on the right track

 

You should be able to just load the solution (.sln) file in Visual Studio, then hit Build > Build Solution.  But like I said, I haven't been paying any attention to the DOF bridge/slave part of it - it might not build properly any more.  If not, if you can't figure out what's wrong, you might want to get in touch with Freezy and see if he can bring it up to date.  I'd certainly be happy to integrate any necessary changes back into my tree if there are in fact any changes needed.

[electricmagma]

Awesome. Thanks! I’ve reached out to freezy. I haven’t had any luck building the solution. Ends up being extremely small and then complains about missing stuff when run.

Appreciate the help.

T

[Runner]

Going through Nailbuster's and TerryRed's videos to update my cabinet to Pinupplayer and Pinuppopper but one step is holding me back at this point.

 

I'm wondering if you've seen this before.

 

I cannot install DOF R3 using the MSI installer I downloaded from this link http://mjrnet.org/pi...ll-updates.html. I start it and select the drive and path (C:\DirectOutput) and then as it tries to start I get this error:

 

The system cannot open the device or file specified.

 

Retry doesn't help so I have to click on cancel and then I get this error:

 

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755.

 

I tried writing the path, I tried selecting the path using the browse button, I tried a different drive.  I turned OFF my Windows 10 virus realtime protection.

 

Running as admin did not resolve the issue.

 

UAC is turned off.

 

I also re-downloaded the MSI package multiple times without effect.

 

I had previously installed DOF R2 fine.

 

This is the only thing preventing me from moving on with the Pinup upgrade.

 

Any ideas?

[mjr]

UAC is turned off.

 

I think that's the problem.  Turning off UAC changes the way Windows handles a bunch of registry information, which screws up installers.  (And don't just turn it on for the install and then turn it back off.  You really need to leave UAC enabled at all times.)

[Runner]

 

UAC is turned off.

 

I think that's the problem.  Turning off UAC changes the way Windows handles a bunch of registry information, which screws up installers.  (And don't just turn it on for the install and then turn it back off.  You really need to leave UAC enabled at all times.)

 

 

Hi Mjr,

 

Just turned it back ON and restarted the computer but I'm still getting the same errors.

[Runner]

 

 

UAC is turned off.

 

I think that's the problem.  Turning off UAC changes the way Windows handles a bunch of registry information, which screws up installers.  (And don't just turn it on for the install and then turn it back off.  You really need to leave UAC enabled at all times.)

 

 

Hi Mjr,

 

Just turned it back ON and restarted the computer but I'm still getting the same errors.

 

 

Strange, well I created a new admin profile in Windows 10 and was able to install the msi fine using that profile.  Problem resolved.

[mjr]

Strange, well I created a new admin profile in Windows 10 and was able to install the msi fine using that profile.  Problem resolved.

 

Oh, you know what's probably going on?  You probably have the "owner" for C:\ set to SYSTEM, so you were running into permission errors when you tried to create C:\DirectOutput from the regular user account.

 

But now you've created C:\DirectOutput under a different administrator account, so you might run into similar problems when you try to write into the folder from your user account (e.g., when you're trying to update .ini files).

 

To head off future problems, you should probably do this:

 

- Log back into the new admin account you created

- Right-click on the C:\DirectOutput folder on the desktop

- Select Properties from the conext menu

- Go to the Security tab

- Click the Advanced button

- At the top where it says "Owner: xxx", click the "change" link

- Type your regular user account name into the box

- Click Check Names, make sure it expands into a valid name (DOMAIN\username)

- Click OK

 

That'll change the owner of the folder back to your regular user account so that you have all necessary permissions on the folder.

[Runner]

 

Strange, well I created a new admin profile in Windows 10 and was able to install the msi fine using that profile.  Problem resolved.

 

Oh, you know what's probably going on?  You probably have the "owner" for C:\ set to SYSTEM, so you were running into permission errors when you tried to create C:\DirectOutput from the regular user account.

 

But now you've created C:\DirectOutput under a different administrator account, so you might run into similar problems when you try to write into the folder from your user account (e.g., when you're trying to update .ini files).

 

To head off future problems, you should probably do this:

 

- Log back into the new admin account you created

- Right-click on the C:\DirectOutput folder on the desktop

- Select Properties from the conext menu

- Go to the Security tab

- Click the Advanced button

- At the top where it says "Owner: xxx", click the "change" link

- Type your regular user account name into the box

- Click Check Names, make sure it expands into a valid name (DOMAIN\username)

- Click OK

 

That'll change the owner of the folder back to your regular user account so that you have all necessary permissions on the folder.

 

 

The owner is TrustedInstaller.  I've changed ownership of external ntfs drives but never changed the ownership of the c drive in all my years.  This is interesting.

[mjr]

The owner is TrustedInstaller.  I've changed ownership of external ntfs drives but never changed the ownership of the c drive in all my years.  This is interesting.

 

I'd leave the root C:\ drive as it is, and just change the owner of C:\DirectOutput.  

 

I've run into this a couple of times, and I'm not sure what the pattern is.  It must be the options that were selected when the drive was initially formatted.  Microsoft has been trying to encourage people to stop putting random stuff in the root folders, and setting the ownership to special system accounts is part of that.  It doesn't exactly lock it down if you have an admin account, but it at least makes you jump through a bunch of hoops like this.

[LynnInDenver]

Microsoft has been trying to encourage people to stop putting random stuff in the root folders, and setting the ownership to special system accounts is part of that.  It doesn't exactly lock it down if you have an admin account, but it at least makes you jump through a bunch of hoops like this.

 

 

As near as I can tell, the ideal that Microsoft is aiming for is to put the main program - and only the main program and unchanging support files - into "Program Files" or "Program Files (x86)", and anything that may or will change needs to be into User Documents if on C:, or onto another drive entirely. I expect that the only reason they're just putting up a bunch of hoops instead of breaking it outright is that they already have a tough enough time convincing businesses they need to replace the OS regularly without going out and completely breaking old software to "properly" force that to happen.

[Runner]

Thanks everyone!

[xantari]

I recently updated to DOF R3++ latest version a few days ago. I just noticed that it broke my LEDBlinky lighting of buttons when it launches Virtual Pinball.

 

The buttons light properly for a few seconds, then completely turn off.

 

I’ve discovered this is due to DOF R3++ update from my ancient version from 2017.

 

It seems DOF R3++ is much smarter about it’s auto-setup, and is now detecting both my PacLed64 (controls all my DOF toys) and my Ultimate IO (which controls all my buttons and button lights).

 

Previously it was not detecting my Ultimate IO from what I can tell from the Log files.

 

The issue is that it appears to reset the Ultimate IO during auto-configuration, so it in essence interupts LEDBlinky’s lightup work (which works for a few seconds until DOF R3++ clears it out).

 

My guess is that I need a Cabinet.xml to specify DOF R3++ to only look at my PacLed64 device and stop touching my Ultimate IO device, but i’m not sure how to do that.

 

I don't even have the Ultimate IO device configured in DOF Config tool, but i'm guessing that since an Ultimate IO is really a PacLed64 with some extra outputs that it is detecting it the same way as a Pacled64.

 

Is it sufficient to just define the output controllers, or when you go into cabinet.xml mode I am going to have to define everything (all toys, etc). Or can I just define the controller and none of the other XML tags?

 

Would I then turn off the Autoconfiguration flag in the Global_B2sConfig file?

 

Here are the log files of the OLD and new R3++ version: https://drive.google...tNNnWxR8Bu9hjtD

Edited by xantari, 20 January 2020 - 12:10 AM.

[xantari]

So I figured it out. I did have to make a Cabinet.xml to fix my issue with it initializing devices I didn't want it to initialize and start causing problems with LEDBlinky which was trying to interact with that device.

 

To create the Cabinet.xml (not sure this is documented anywhere that I could find). I took ST TNG table and right clicked the backglass image to get into the B2S Config.

 

From there I went to the plugins and double clicked on the Direct Output Feedback plugin.

 

That brought up a window which I could view the cabinet configuration.

 

This then had a button to export cabinet.xml (awesome!).

 

This exported the cabinet.xml file.

 

I then removed all Ultimate IO device settings in the <Toys> section and removed the UIO from the outputcontrollers section.

 

Lastly, there is a bug in the cabinet.xml exporter in that it will NOT output the <Name></Name> field. I had to add that manually otherwise DOF would fail to deserialize that XML file properly.

 

Additionally, there is some sort of issue where by the mouse cursor disappears in the above named B2S Config windows, not sure why that was, but it was real fun trying to figure out where my cursor should be when it was invisible. Was randomly clicking all over the place.

[zebulon]

Most likely both the pacled64 and the pacled64 potion of the ultimate i/o were assigned to the same device id and causing a collision when initialized.  Another possible fix if it is still an issue would be to download the pacled software from Ultimarc and re-assign the device id of one or the other.

 

Kudos on sorting it out!!

[settingsons]

For anyone who wants to get the Steam version of Pro Pinball Ultra working with DOF, there is a new build of the DOFSlave.exe at the link below.  This is the 64-bit version and it now works with Zebsboards.  I had an issue with the my Zebs PNP Lightbar not working with Pro Pinball Ultra, whereas everything else (Visual Pinball, Pinball FX3, etc) worked.   The reason is the previously available and working version of DOFSlave.exe was built by Freezy back in 2017 before I guess Zebs board was recognised.

 

https://www.vpforums...578#entry442621

 

Just to add the DOFSlave.exe bundled in the current R3++ bundle appears to be 32-bit, and I know that back in 2017 Freezy only released a 64-bit version on the VPU forums as Pro Pinball Ultra 64-bit was the only version working with DOF at the time.  Now I don't know if the currently bundled R3++ version works with '32-bit Pro Pinball Ultra' (it might do), but I would say that ideally the R3++ release should contain a 64-bit version of DOFSlave.exe.   I can vouch that it works for me with my Zebs Lightbar which is a kind of Ledwiz clone, and it should work with all the other devices (as mentioned in Zebs post above).

 

Footnote:  I should have posted my original DOFSlave issue in this thread as I can see there were earlier mentions of DOFSlave in here, but Google must be going downhill as it doesn't find those pages at all. Bring back Altavista

Edited by settingsons, 06 February 2020 - 01:10 PM.

[dramaone]

I have a PACLED64, 2 x Sainsmart boards and a pinscape.

All was working. 

 

After adding a WS2811 in dofconfig tool and generating a new file ( which is 20 pacled , 30 WS, 40 sainsmart, 41 sainsmart )

 

When I then add Addressable Led info in my cabinet xml the device order changes resulting in my flippers triggering the wrong sainsmart. 

Flippers triggering the gear motor instead of a solenoid!

PACLED64 stays ok but sainsmarts get mixed up.

 

If i delete the address led info from cabinet file and then swap the sainsmart serial number over, I get back to working as normal.

 

 

 

I have no clue what is going off. 

If I disconnect the sainsmart that runs my shaker, blower and fan, the 1st sainsmart will become active and correct during a game

 

What controls device order ? 

Edited by dramaone, 07 February 2020 - 03:28 PM.

[mjr]

dramaone - I'm afraid I don't use either Sainsmarts or addressables, so I don't have any direct experience here.  But Sainsmarts and addressables both interface to Windows using virtual COM ports, so I'm guessing that DOF is getting confused about which COM port belongs to which device.  From your symptoms it sounds like the commands for one device are getting sent to another device.  I'll also note that DOF does auto-detection for the Sainsmart devices, but not for the addressables, so the big thing that's probably changed in your setup is that you had to add a cabinet config for the addressables, right?  Maybe the solution is to explicitly add the Sainsmart devices to the cabinet config as well - the procedure is here:

 

http://mjrnet.org/pi...p?sid=sainsmart

[zebulon]

Exactly,

 

If you have to create a cabinet config then you might as well list everything and take the autoconfig out of the equation entirely.  No sense in confusing the issue with a half and half solution.  It's better to take full control of the configuration.