No replies to this topic

[tgx]

I have read a lot of posts and watched a lot of videos about DOF recently to help me with an original VPX project I have been working on.

DOF is probably one of the more confusing and over-explained parts of Virtual Pinball that still remains nebulous for many. Me being one of those.

 

Worse, there are many starting points where you can begin. YouTube, websites, forums, FB you name it all have people attempting to explain it.

Even the legendary JPSalas (thank you for all your input) finds it a challenge so what do us mere mortals do?

I will toss my two cents in since I exhausted nearly 5 days of my life deciphering it for my use case. I am coming at this from a slightly different

perspective, that of someone coding an original table, so if you want to just add DOF to your rig, or learn how to munge it to work with PinballFX, FP,

DOFLinx etc, this is not the post for you. Nothing to see here. IF you are a VPX table creator, or would be table creator, I hope you may find this post

useful and not take you 5 days to get started. So let’s go!

 

Getting your ‘original’ table to work with DOF.

 

You need a few things before you start.

Your VP setup must have a working B2S setup. You don’t need to have a b2s backglass but the b2s Server must work.

Use a table that has a b2s backglass to ensure the DOF plugin is loaded after you install and register DOF.

Just right click on the backglass and check that 'activate plugins' is checked and that the plugin is visible under ‘Plugin Settings’.

 

VPX Table Scripting

 

You will need the following code in your script somewhere prior to Table_Init:

Option Explicit

Randomize

LoadEM ‘Yes you need this, you don’t have a rom and nothing DOF will happen without it.


On Error Resume Next

ExecuteGlobal GetTextFile(“core.vbs”)

If Err Then MsgBox “Could not open core.vbs!”

On Error Goto 0


On Error Resume Next

ExecuteGlobal GetTextFile(“controller.vbs”)

If Err Then MsgBox “Controller.vbs is required to run this table.”

On Error Goto 0


Dim Controller

Dim B2SOn:B2SOn = TRUE

Const B2STableName=”your table name” ‘this will also be the name of your ‘fake rom’

Const cGameName=”your table name” ‘this will also be the name of your ‘fake rom’


You should also close the B2S Server when the table exits with something like this.

Sub Table1_Exit

If B2SOn Then Controller.Stop

End Sub

Let’s talk about online DOF Configtool.

 

For someone starting out programming DOF, it’s a bit overkill. The tool is really designed for someone who is wanting

to populate their gaming system with every known table config in existence, and maybe, upload a config once you are

an ‘expert’. It is not entry level friendly and not much use at all to learn about DOF programming. What do those codes

even mean? Well if you want to decipher it you’ll spend a lot of time digging and you’ll end up at github in the DOF docs,

http://directoutput....o/DirectOutput/ which are good, but not the quickest read for just wanting to turn on an LED

with your fancy new LEDWiz using a table script in VPX.

 

If in your cabinet configuration you have multiple devices, like LEDWIZ, then you will have multiple directoutputconfig.ini files

created by the online DOF Confgurator, one for each device. Make sure you go through the ‘My Account’ tab FIRST in the

configurator, so you can tell it what devices you have. After you set up your devices under My Account, just go to Port Assignments

and click Generate Config. For initial tests it doesn’t matter a whole lot what all of those settings are that you see. Save and

extract the files into your C:\DirectOutput\Config directory.

 

You will find a number of files when you extract them. The ini files are where the magic happens but

you are going to need a cabinet.xml file as well to even get going. You can read more about it here:

http://directoutput....nfig_configfile

I manually built mine using the one found under the ‘C:\DirectOutput\config\examples’ and the link above. This file defines

the devices in your rig. You would think you would get a basic one from the Online Configurator since it knows which devices

you have, but sadly no. Keep in mind the files output from the Online Configurator are going to be huge with a lot of stuff inside.

Don’t get intimidated the first time you open one. It’s a lot of fluff that you as a coder of a new table don’t need. I lopped all of

the table configurations out of my directoutputconfig.ini files (around 1800 lines in each one) and stripped it to only contain my

new table. The same with other sections that I didn’t need. I kept an original for reference in case I might want to explore other

table configs.

 

Let’s talk about the directoutputconfig.ini files.

 

The first one assigned is directoutputconfig.ini. You may see a directoutputconfigX.ini for each device after the first one.

Interestingly if you have a PinOne, in my case at least, it was assigned directoutputconfig11.ini. No idea why. FYI, there is no

directoutputconfig1.ini created by the configurator. The file for device 1 is directoutputconfig.ini.

 

Why is the directoutput file numbering important?

When you make a DOF call you want to communicate with the correct device, the devices are enumerated with those files

and the cabinet.xml. That’s how you end up with directouputconfig.ini = LEDWIZ1, direcoutputconfig2.ini = LEDWIZ2 and so on.

 

Before we get into actual code, here is some interesting syntax you will run across. You can use either a number or words to describe the action DOF should take.

DOF 101, 0 = DOF 101, DOFOff
DOF 101, 1 = DOF 101, DOFOn
DOF 101, 2 = DOF 101, DOFPulse ‘DOFPulse would be the equivalent of a quick blink’

Coding directoutputconfig.ini Files

 

You need a directoutputconfig.ini file with an entry for your table under [CONFIG DOF] that begins with your fakerom name

which is the cGameName you define in your VP table script (they must match).Here is an example directoutputconfig.ini:

[CONFIG DOF]

fakerom, E101,E102,E103,E104,E105

In the case of originals you really only need concern yourself with ‘E’ codes. This part took me a long time to sort out

because it was too simple. I kept trying to sort out whatever LEDWIZ configuration app du jour was doing in relation to VP.

Tools like LEDBlinky are a good place to start playing with the hardware but it’s a challenge to mentally link what VP is doing

with DOF and the controller. Good news is, all of that gets done with the ini files. I suffered, you don’t have to.

 

All DirectoutputconfigX.ini files define ports on your device. That’s the E101,E102 etc.

The X in the filename relates to the device number. Directoutputconfig3.ini = eg LEDWIZ3.

Programming inside the files controls active ports by device number X eg. X01 = E101,E201,E301.

You cannot reference E301 inside directouputconfig2.ini because it is the wrong device. You would need to call E301 inside of directouputconfig3.ini

 

Mystery solved.

 

With this knowledge and the correct entries in directoutputconfig.ini, you can program DOF and easily test in VP.

I found the best way to do this was to launch my table, press ‘q’ to pause the table and enter the debugger. Then you can type

DOF commands to your hearts content and document your table for later programming. In our original example above,

we are communicating with E101, which is equal to VP Table script, DOF 101. To turn on whatever is attached to port 1, simply

add in your script or the debugger, “DOF 101,1”. Keep in mind whatever is on that port will stay locked on until you issue DOF 101,0. DOFPulse

can be used to send a quick signal and see a reaction DOF 101,2 or DOF 101, DOFPulse. Also note syntax is important. It won’t take DOF101,1.

 

In the case of a second LEDWIZ, you need to program inside the file directoutputconfig2.ini something like:

fakerom, E201,E202,E203,E204,E205

Then in your VP Table script you would program using DOF 201,1 to turn on port 1 of LEDWIZ-2 and DOF 101, 1 to turn on port 1 of LEDWIZ-1 and so on.

 

Keep in mind you can only access ports that you have defined in the ini files. Calling DOF 106,1 or DOF 206,1 would do nothing in the above examples.

 

In summary, there is one final bit of coding to think about. There are many things you can program inside of the directoutputconfig.ini’s that ‘set’ the behavior of a port. Let’s take this example:

fakerom, E101 Blink fu500 fd600

If this is all that was in your directoutputconfig.ini, first you could ONLY call DOF 101 in your table script as it is the only

DEFINED port. Second, that LED at port 1 would have only 1 behavior. If you called DOF 101, 1 in your table script the

LED would Blink with a turn on speed of 500ms and a turn down speed of 600. That’s it. It is forever a blinking LED. Maybe

that’s what you want, but that isn’t always what we want. Sometimes we want it to blink for awhile and be solid at other times, you may want to have 2 lights come on simultaneously or conditionally.

 

You might have a timer that says, DOF 101, DOFOn, wait DOF 101, DOFOff to simulate a blink so that somewhere else

you can turn it on and have it stay solid. You have to make the call whether programming is done in table script or in

directoutputconfig.ini where it makes sense. More timers in a table = more performance hits so there’s that to consider.

There is a lot of programming that can occur in the directoutputconfig.ini files. I refer you back to the github documents for more information.

 

I also recommend the post by arngrim as a good read, which contains information on DOF with sound effects, some of that

post has been duplicated and edited at the head of this post for readability and introduction to the subject: https://www.vpforums...showtopic=34429

 

Here is another good read but the naming is problematic so you may think it is focused on installation, but it has a lot of good coding information: https://www.vpforums...&showfile=15750

 

If you are having issues with your config files, run them through the "C:\DirectOutput\DirectOutputConfigTester.exe" application. you can also call the DOF Frontend at that point and get insights into

your installation. It's good for making sure things are working before you get too heavy into table scripting. The config tester will want a rom name, use your cGameName as a 'fake rom'.

Be sure to set up your Global Configuration first using the GlobalConfigEditor found in the same location. You just need to point it at your DOF .ini files and the cabinet.xml file you created.

If the DOF tools aren't working for you, then the table code won't either. Consult the github docs to troubleshoot your installation.

Edited by tgx, 20 June 2024 - 08:45 PM.