33 replies to this topic

[Sindbad]

The script snippet has been implemented into Vector VP10. Thanks for sharing!

[Sindbad]

I added it also to the Buck Rogers VP10, I hope other authors will do also.

[mjr]

This is a great idea - I'd love to see this become the standard as time goes on.

 

In my tweaks to Aladdin's Castle, I ran into a couple of other items that would be really useful to externalize into an options file.  That got me thinking in terms of generalizing the cController.txt idea so that it could handle any set of options.

 

I came up with a little script that I think accomplishes this.  It lets you define an arbitrary set of constant names and their default values.  For each name, it looks to see if the name is defined in an external options file.  If so, the script defines the constant using the value in the options file.  If the constant isn't defined in the options file, we use the default value that you define in the script.

 

As with cController.txt, the idea is that this option file is a single file shared among all tables.  The user only has to define the option settings once, and they'll automatically work for all tables that use the options loader.

 

Here's what I came up with:

Sub LoadOptions(vars)
    Dim fname, FileSys, fp, txt, i, fileVars
    set fileVars = CreateObject("Scripting.Dictionary")
    fname = UserDirectory & "options.txt"
    Set FileSys = CreateObject("Scripting.FileSystemObject")
    If FileSys.FileExists(fname) then 
        Dim re : set re = New RegExp : re.Pattern = "(\w+)\s*=\s*("".*""|\d+)"
        Set fp = FileSys.GetFile(fname).OpenAsTextStream(1,0)
        While Not fp.AtEndOfStream
            txt = trim(fp.ReadLine)
            Dim matches : set matches = re.Execute(txt)
            if matches.Count then
                Dim m : set m = matches.Item(0)
               fileVars(m.SubMatches(0)) = m.SubMatches(1)
            end if
        Wend
    fp.Close
    End If
    for i = 0 to ubound(vars) step 2
        dim var : var = vars(i)
        dim val : if VarType(fileVars(var)) <> vbEmpty then val = fileVars(var) else val = vars(i+1)
        ExecuteGlobal "const " & var & "=" & val
    next
End Sub

 

Put a call to this routine near the top of the script, with an array of constants to be defined and their default values:

LoadOptions Array("XXX", 1, "YYY", 2, "ZZZ", """foo""")

Here's how this works.  The LoadOptions first looks for a file called Visual Pinball\User\options.txt.  If the file exists, the script reads each line from the file, parses it as a VARNAME = VALUE line, and stashes the resulting VARNAME and VALUE in a hash table.  After finishing with the file, the function then goes through the "vars" argument array and defines each variable as a script constant, by executing a CONST VARNAME = VALUE statement in the global scripting context.  If the variable was defined in the options file, we define the value from the options file; if not, we define the default value from the "vars" array.  

 

I think this design has all of the properties we'd want from such a mechanism:

 

- It's zero hassle for users who don't want to know about it.  No error messages ever pop up if the file doesn't exist.  The script simply uses the default values if no options file exists.

 

- It's infinitely extensible.  Every table can add whatever options it wants.  If the option is unique to the table, that's fine, but the main point is to share option settings that apply to many tables.

 

- There's no problem if a table adds new options that aren't listed in the user's option file.  The table simply gets its default values in this case.

 

- There's no danger of naming conflicts from adding new options.  If a user adds a bunch of options to the options file that a table doesn't need, the table ignores them.  Each table only gets the option names loaded that it specifically lists in the name/default array when it calls LoadOptions.

 

- It's efficient for scripting, since the options are all defined as CONST items.  (I'm not sure if the VB Script engine used in VP actually makes use of constants for run-time efficiency, but it could in principle, and it could in future versions.  At any rate, CONST should be as good as any other way of defining these values, if not better.)

 

Table builders, let me know what you think!  It'd be great to see at least the cController.txt mechanism get widely adopted, but I think it would be a little better still if something truly general could get traction.

Edited by mjr, 10 August 2015 - 09:22 PM.

[mjr]

A little improvement, for backwards compatibility with cController.txt.  If cController.txt exists, this grabs the value of CONST cController from that file first.  That way anyone who set up their system for cController.txt will still have that setting work without having to know anything about options.txt.  You can also define cController in options.txt by adding a line of the form "cController = N".  If you do, that will override any cController.txt setting.

 

LoadOptions Array("cController", 1, "XXX", 1, "YYY", 2, "ZZZ", """test""")
Sub LoadOptions(vars)
    Dim fname, FileSys, fp, txt, i, fileVars
    set fileVars = CreateObject("Scripting.Dictionary")
    Set FileSys = CreateObject("Scripting.FileSystemObject")
    fname = UserDirectory & "cController.txt"
    if FileSys.FileExists(fname) then
        Set fp = FileSys.GetFile(fname).OpenAsTextStream(1,0)
        if not fp.AtEndOfStream then
            txt = trim(fp.ReadLine)
            fileVars("cController") = CInt(txt)
        end if
        fp.Close
    End If
    fname = UserDirectory & "options.txt"
    If FileSys.FileExists(fname) then 
        Dim re : set re = New RegExp : re.Pattern = "(\w+)\s*=\s*("".*""|\d+)"
        Set fp = FileSys.GetFile(fname).OpenAsTextStream(1,0)
        While Not fp.AtEndOfStream
            txt = trim(fp.ReadLine)
            Dim matches : set matches = re.Execute(txt)
            if matches.Count then
                Dim m : set m = matches.Item(0)
                fileVars(m.SubMatches(0)) = m.SubMatches(1)
            end if
        Wend
        fp.Close
    end if
    for i = 0 to ubound(vars)-1 step 2
        dim var : var = vars(i)
        dim val : if VarType(fileVars(var)) <> vbEmpty then val = fileVars(var) else val = vars(i+1)
        ExecuteGlobal "const " & var & "=" & val
    next
End Sub

[hmueck]

any ideas what variables to save in the options.txt? i think there should be a standard set of options, or every table would use its own settings, which wouldnt make sense.
idea: name for the highscore post-it note on em tables
idea: prefered rom language if available

[arngrim]

great idea mjr, as possible option
dmd hidden
dmd position

[hmueck]

dmd hidden? doesn't that depend on the type of table or something?

and don't cabinet users set their dmd position with setdmd.exe? hm, okay, new tables could set the position automatically...

[mjr]

any ideas what variables to save in the options.txt? i think there should be a standard set of options, or every table would use its own settings, which wouldnt make sense.

 

Definitely!  The main point of this would be that options affecting multiple tables would be shared, so that users wouldn't have to edit the file every time they install a new table.  So it would be key for table builders to use standard names for options that they share with other tables.  

 

That said, another important aspect of this is extensibility, so we don't want a pre-determined set of options that can never grow.

 

It would probably be a good idea to have an editable master list of options somewhere - maybe a dedicated thread here would do the trick.  That way table builders would have a reference point for finding existing options that serve their needs, but could add to the list whenever they come up with something new.

 

The ones I ran into with Aladdin were:

 

- cabHasAccelerometer: 0 or 1: Does the cabinet have an accelerometer and physical plumb bob?  If so, you want the "T" key to just map to the tilt switch without doing a fake nudge.  (For MAME tables this is usually handled with the core.vbs scripts, but EM tables usually have their own custom code for this, so they need handling for it.)

 

- cabHasChimes: 0 or 1: Does the cabinet have DOF chimes?  If so, the table fires DOF events for scoring chimes and suppresses the digital audio versions of the chimes.  I always like to turn off the digital audio for a particular sound effect when there's a real DOF device present that does the same thing, but I don't think that chimes are very common even in otherwise well-equipped DOF cabinets, so I didn't want to turn off the scoring sound effects just because DOF is present.

 

There are probably a few other fine-grained DOF questions along the lines of the chimes that would be worth adding, like whether there's a real knocker or a mechanical bell (the kind that Fire! and a number of EM machines used).

[arngrim]

yeah i thought that as well, constant if you use a knocker, but also a gear for mech movements, shaker for shaker movements, etc

[mjr]

yeah i thought that as well, constant if you use a knocker, but also a gear for mech movements, shaker for shaker movements, etc

 

Good ideas - those would be great to break out separately too.  I didn't think of those since I have both in my cab.  Maybe a fan as well.  For that matter, maybe whether or not you have contactors - some people use DOF just for flashers.

 

 

dmd hidden
dmd position

 

Could a VP script actually do anything with those?  I thought those were all external, in the VPM / B2S / UVP configuration, and VP had no control over them.

Edited by mjr, 11 August 2015 - 09:11 PM.

[arngrim]

vp script has the last word in terms of vpm registry, you can force the table with the script to hide the dmd or to position it

 

here for hide the dmd, i don't have an example for the positioning next to me

 

With Controller

.GameName = cGameName

If Err Then MsgBox "Can't start Game" & vbNewLine & Err.Description : Exit Sub

.SplashInfoLine = cCredits

.HandleMechanics = 0

.ShowDMDOnly = 1

.ShowFrame = False

.ShowTitle = False

.Run

.Hidden=0

If Err Then MsgBox Err.Description

End With

 

for the break out, activating the toys or not is properly if you setup your configtool toy configuration properly

 

we speak for shutting the sounds, if we have xyz toy, that it auto shuts the xyz tagged sound or something.

 

so here's my idea, i can setup the configtool toys with a certain category and when you generate new ini, i can create an output file that has the constants filled if you have the respective toys, constants that could be used with the xyz tagged sound to say ignore it

 

the biggest problem, first that is document properly and with a great visibility and second that all authors would need to follow the way to tag their sounds respectively with the constants related to the toys

 

if you see what i mean

[mjr]

so here's my idea, i can setup the configtool toys with a certain category and when you generate new ini, i can create an output file that has the constants filled if you have the respective toys, constants that could be used with the xyz tagged sound to say ignore it

 

That would be good in principle, although I'm not sure it would be ideal to add even more complexity to the configuration setup.  Judging by the forum posts, most people find it pretty hard to set up all of the pieces that have to work together as it is - VP, VPM, B2S, DOF, and all of their interacting plugins and config files.

 

It seems like the ideal way to handle this would be to have a way for the VP script to query DOF to ask it directly what toys are available.  I don't think there's any mechanism for data flowing in that direction currently, but it could be added - something like a new B2SGetData, although that would be the wrong name for this since it's more of a metadata query.  B2SQueryDOF, maybe:

 

   cabHasShaker = Controller.B2SQueryDOF("cabHasShaker")

[arngrim]

your solution is more complex than you think, vp would query dof via b2s which is not extendable, it is out of support currently.

 

if it is just to know which toy you have, if you don't have a cabinet.xml where you have hardcoded your toys there (which 99% of the people don't have, including me), DOF has no way to know which toy you have in your config, it just knows you have that number of toys mapped based on your ini, it even doesn't know what is a shaker or a knocker or whatever.

 

the only tool that knows that is the configtool, so we could just say to the users, create your file with constants yourself and place it to user folder, or i can provide that file once you generate new ini files.

[mjr]

your solution is more complex than you think, vp would query dof via b2s which is not extendable, it is out of support currently.

 

I didn't know B2S was orphaned.  That's bad news.  I don't suppose the author ever released the source code?  That's the biggest reason for open-sourcing these things, in my opinion - the authors of these tools *always* get bored of the support work and abandon them, and if they didn't release the source no one can ever fix them.