Welcome To The Dof Config Tool

[arngrim]

ok guys, my accesses are back

 

beware the configtool site has changed!

 

there is a redirection so the old url still works, the new url is this one:

 

http://configtool.vpuniverse.com/

 

if you use the api, the ledcontrol_pull functionality, you need to change the url on the ledcontrol_pull.vbs to this one:

 

sVersionUrl = "http://configtool.vp...?query=version"

sDownloadUrl = "http://configtool.vp...tconfig&apikey=" & param_apikey

 

or it won't work anymore

 

Cheers

[swisslizard]

Hi guys

A small remark regarding the 48 resp. 49 value in the configs.

The configs do always use a value range of 0-48 if decimal values are use or #00 - #ff if hex values are used. Internally all those values are converted to a value range of 0-255. So a decimal 48 in the config well be 255 internally and there is nothing above 255.

49 does only become important when data is sent to a ledwiz. Thats where DOF uses a conversion table to convert its unternal 0-255 value range to the 0-49 value range of the ledwiz. Before DOF R2 thT coversion table only had a target range of 0-49, since R2 this table covers a range of 0-49.

For this reason it is perfectly ok that configs use only 0-48. The abstraction layers of DOF make the values in the configs invisible to the output controller. This is one of the main reasons why DOF can easily talk to different types of output controllers. All output controller accept the internal value range of 0-255 and do only work with a more limited value range (if needed) within their own domain.

If you want to do sonething good about value ranges it is best if you start using hex numbers (e.g. #C8). With hex numbers you have full control over the whole internal value range of 0-255.

All the best

Tom

[arngrim]

Another update, I created the Controller FRDM-KL25Z, interface created by MJR, he setup the code around as Ledwiz 8, so I restricted the number of Ledwiz in the configtool from 16 to 6 (don't think anybody will ever goes above 6... ), and mapped it to ControllerID 8, so you won't need to change the ID of the controller in a cabinet.xml anymore, if you use another Ledwiz number than the default one for this card.

I have adapted the few users who had their Ledwiz 8 filled to match the FRDM-KL25Z controller, with the same ledwiz number 8, it has just now the right Controller name, the rest is transparent .

[Spektre]

Hmmm that seems a strange way to handle the 48/49 scaling issue, but as long as its known.  So what is the exact mapping between profile values and actual LEDWiz values? INT(49/48*Profile_Value)

[swisslizard]

The decision to stay with 48 as the max allowed config value is quite logical when you look at the way how DOF is built:

• From a tech point of view there is no relation between the values in the configs and the values which are sent to devices. As mentioned earlier, DOF has no 48 or 49 internally. Everything is scaled to a value range of 0-255. Since that 49 thing is only a ledwiz issue, the right place to fix this is the output routine for ledwiz.
• Legacy configs only knew a value range from 0-48. DOF was built to be compatible with the legacy configs. Thats why there is the 0-48 value range in the first place. If that range is ever changed it will for sure not be 0-49, but 0-255 (which is already supported in most places if hex numbers are used (#00-#ff).

[Spektre]

 

The decision to stay with 48 as the max allowed config value is quite logical when you look at the way how DOF is built:

• From a tech point of view there is no relation between the values in the configs and the values which are sent to devices. As mentioned earlier, DOF has no 48 or 49 internally. Everything is scaled to a value range of 0-255. Since that 49 thing is only a ledwiz issue, the right place to fix this is the output routine for ledwiz.
• Legacy configs only knew a value range from 0-48. DOF was built to be compatible with the legacy configs. Thats why there is the 0-48 value range in the first place. If that range is ever changed it will for sure not be 0-49, but 0-255 (which is already supported in most places if hex numbers are used (#00-#ff).

 

 

I suppose everyone could have a different definition of "logical" based on what your goals are.  This one is certainly logical if the goal is to minimize work performed by the developers.

 

• Your comment on the tech point of view is not accurate.  Unless you have added a random number generator to your code base from version 1 when I last looked at it, there is indeed a relation between the value in the configs and the value sent to the device.  If there were no relation, the values in the configuration file would be meaningless.
• The legacy configuration were not designed with the philosophy "Let's make a range from 0-48 as our output."  They were made based on the only device they supported, the LEDWiz, and the values entered were those directly passed to the device.  They were unfortunately made with a bug as the actual values for the LEDWiz are 0-49, not 0-48 and thus the devices were never fully turned on.

Based on this, the solution made obfuscates the problem and leaves us with a solution that neither allows us to directly send a value to the LedWIZ device, nor works as the original legacy files did.

 

That being said the problem is minimal and it is doubtful anyone will notice the issue.  It just seems another kludge added onto the string of kludges that defines Visual Pinball today.

 

I doubt anyone will ever encounter a problem because they tune a toy to a value of "32" in the native LEDWiz tools, then finds the toy misbehaving due to DOF playing with the number in the background.  Just noting it could happen and as such seems illogical to me.

 

For posterity sake if anyone stumbles across this thread in the future troubleshooting, what is the relationship between config file PWM values and DOF output values to the LedWIZ?  Is it a simple INT(49/48)*config_value)).  If 48 config file steps are being mapped onto 49 LEDWiz steps, one value will be missing somewhere.

[arngrim]

most important is the output, not the input, and if the output works as expected, then it's fine, thank you

[Spektre]

I'm not sure I follow you Arngrim.   "If the output works as expected" would mean "If the output does as I expect it to do based on the input."  You don't get one without the other.

 

If someone enters a "32" into their configuration and expected to see a "32" level at the output and instead sees a "33" that is not working as expected.

[swisslizard]

If you feel that using 0-48 is not adequate, then use the 0-255 value range (hex number in following notation like #00-#ff resp. #f00ff or #ff00ff80 for colors). Thats what DOF is really using internally.

 

DOF is not only about the Ledwiz and all other output controllers use a different value range anyway (0-48 is only by convention). For its effects like fading DOF is always using the full value range of 0-255. This means that fading might uses more fadesteps than a Ledwiz can handle naturally (if the fading is slow enough to have plenty of fading steps).

 

When DOF converts values from ini files into its object model it just does some multiplication:

• For colors in 0-48 notation:  Red = (int)(Values[0].ToInteger().Limit(0, 48)* 5.3125);
• For intensity in 0-48 notation: Intensity = (int)(((double)Parts[PartNr].Substring(1).ToInteger().Limit(0, 48)) * 5.3125);
• For intensity in hex notation: Intensity = Parts[PartNr].Substring(2).HexToInt().Limit(0, 255);

On the output side values are converted to the range of the output controller as follows:

• For LedWiz the following conversion table is used:
  

  private static readonly byte[] ByteToLedWizValue = { 0, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 
  3, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 
  10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 12, 12, 12, 12, 12, 13, 13, 13, 13, 13, 13, 14, 14, 14, 
  14, 14, 15, 15, 15, 15, 15, 16, 16, 16, 16, 16, 16, 17, 17, 17, 17, 17, 18, 18, 18, 18, 18, 19, 19, 
  19, 19, 19, 20, 20, 20, 20, 20, 20, 21, 21, 21, 21, 21, 22, 22, 22, 22, 22, 23, 23, 23, 23, 23, 23, 
  24, 24, 24, 24, 24, 25, 25, 25, 25, 25, 26, 26, 26, 26, 26, 26, 27, 27, 27, 27, 27, 28, 28, 28, 28, 
  28, 29, 29, 29, 29, 29, 29, 30, 30, 30, 30, 30, 31, 31, 31, 31, 31, 32, 32, 32, 32, 32, 32, 33, 33, 
  33, 33, 33, 34, 34, 34, 34, 34, 35, 35, 35, 35, 35, 36, 36, 36, 36, 36, 36, 37, 37, 37, 37, 37, 38, 
  38, 38, 38, 38, 39, 39, 39, 39, 39, 39, 40, 40, 40, 40, 40, 41, 41, 41, 41, 41, 42, 42, 42, 42, 42, 
  42, 43, 43, 43, 43, 43, 44, 44, 44, 44, 44, 45, 45, 45, 45, 45, 45, 46, 46, 46, 46, 46, 47, 47, 47, 
  47, 47, 48, 48, 48, 48, 48, 49 };

• DMX, Adressable Ledstrips and Pacled64 dont do any value conversion on the output side, since they are natively using a range of 0-255.
• For controllers which have digital outputs like the FT245RBitbangController resp. Sainsmart or PacDrive all values which are not equal zero are sent as 1, zeros are sent as 0.

DOF doesnt have a clue about output controllers when it is loading the data from the ini files. So there is nothing like sending a specific value from a config to a output. There are some abstraction layers in between. Instead DOF loads the ini files, normalizes all values to its interal value range, builds up the necessary effect stacks and so on. The only place where there is some kind of relation between ini-file and the actual output controller is when DOF tries to map the number of the ini files to one of the ledwiz equivalents (which is either using a ledwiz equivalent from a cabinet config file or a ledwiz equivalent which was generated during auto detection of output controllers).

The whole ini-file loading process is only a (ugly) hack put on top of DOFs logic, so ini files can be used.

 

One more thing to keep in mind is that DOF uses additional mapping curves on most toys which allow to change the value received by the toy before anything is sent to a output controller. As a example, this can be usefull to adjust the brightness of the leds to a brightness curve which does better fit the brightness perception of the human eye. Still need to write some docu on the use of those mapping curves, but they are always used by DOF since R2. In short there are a few predefined curves (http://directoutput.github.io/DirectOutput/class_direct_output_1_1_general_1_1_curve.html#a258edf1501f05c0b5afe7d8aae4ed7a5), but individual curves can be defined as well. These curves can then be applied to toys (check the Sample XMLs in the builtin toys page: http://directoutput.github.io/DirectOutput/toy_builtin.html). If the fading cruve is not defined in the config (e.g. if no cabinet config file exists) the toys use the Linear curve (which doesn't change the values). Also for that reason, you can never tell for sure from the ini file data what is actually sent to a output controller. As a example: My shaker is to strong if run on full steam, so I'm using a curve to limit the values which are sent for the shaker so the port of the output controller to which the shaker is connected can never receive a value above 120.

 

Last but not least, if you feel more comfortable, you can always put 49 into the config, but for DOF it wont have a effect. DOF is checking the values and limits them to the allowed range anyway (so 49 will become 48).

 

Merry Xmas everyone

[Spektre]

Thanks Swisslizard.  This amply documents the mapping used.

 

So, without explicitly defining a brightness curve, the relationship between config files and LEDWiz values are:

 

config file value: [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48]

LEDWiz value:   [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,49]

 

Namely, for constant values, the 48th PWM step is never seen at the LEDWiz.  (The one that was most commonly used prior to version 2 of DOF).

 

This is minutiae, and there certainly haven't been a slew of reported problems using DOF v2.  It's a great piece of code.  But this method does cause the loss of one of the already limited dimming steps available to the LEDWiz, causes inconsistent results with other LEDWiz tools, and changes the behavior of a very used step within the config files form v1 to v2.

 

Thanks for documenting this.

[gigalula]

Haaaaa  Thank you so much Arngrim for the new URL concerning "ledcontrol_pull.vbs". I was a bit lost trying to figured out if that was a problem with "virus software" or "windows update" itself and worst if I was the only one with this issue ...

 

 

[arngrim]

here's a small preview of DOF in PinballX

i mapped the contactors for browsing through tables, but most complex, i scripted in the configtool to have RGB Flippers and undercab like you are launching the table:

to be followed

btw, happy new year!

[gtxjoe]

Cant wait for the DOF plugin.   Ahh, the fire dance lives on!

[randr]

Very nice! The dancing I mean!! And DOF is cool I suppose

[senseless]

That PinballX plug-in looks really cool and is a really nice feature . I'm really happy with the Dof Config Tool in general and would like to thank everyone and arngrim in particular for making this happen. I 'only' have a RGB Bar installed via LedWiz but together with the config tool makes it a great feature to my pincab!

[arngrim]

thank you for the beers :drunk:

[tspeirs]

That looks awesome. I know people are eagerly awaiting a decent plugin over on my site. What I provided is only basic.

 

PS: Just send you some beers.

 

Cheers.

Tom.

[arngrim]

thank you Tom

so you are extending the plugin?

we have an issue, probably you already heard it from swisslizard, we need to be able to do a proper matching between the tag rom and the dof ini files, or between an external file, that i can provide from the configtool,that would contain the table rom association, to the dof ini files.

because right now not all the roms are working with it, because the dof plugin, tries to make the matching from pinmamehi but the real source to look into id the one is the one i update every week

would be great if you can extend the plugin, let me know or swisslizard if you have questions

[tspeirs]

I don't plan to do much more with what I did. Id much rather have more professional solutions for PinballX.

 

Sorry, I didn't know about the issue. I will work with Swissizard over on my end when he has time.

 

Cheers.

Tom.

[arngrim]

it's like 30% of the tables can't be personnalized with dof at scrolling at pinballx, in my workcase, the rgb flippers and undercab remain shut just because the matching couldn't be done with what the current plugin framework can deliver, in purpose i made a video where all the tables that i show are recognized, maybe one or 2 after and feedback couldn't work

 

i have to admit this is kind of a showstopper for me and to publish this in the configtool, it must work for every table as long as the rgb flippers and undercabs are mapped in the configtool, it just miss a link in your plugin framework and we are good to go

 

thank you and keep us posted

[swisslizard]

Hi guys

 

I'm one more time completely overloaded with work from my real life projects, which means that I only have little time to work on DOF at the moment

 

Regrading the PBX plugin, I'm planning to change the implementation a bit, to allow for easier mapping of table to romnames.

 

Background:

PBX cant deliver romnames to DOF natively. Since PBX does only use the tablename, but not the romname there has to be some logic to translate the tablename to romname. Since table names are not guranteed to be the same for all users a one to one mapping is not possible. Therefore the tablename has to be compared to a mapping table using some fuzzy text matching, so the ro0mname can be detected even if the table name does not exactly match the name in the mapping table.

 

Plan for implementation:

Since the config tool does already have a list of table/romnames it is likely a goof idea to use this list as a based for the mapping explained above. If Arngrim can add a mapping file to the config files which can be downloaded from the config tool (proposal for format is a bit further down), I could extend DOF resp. the logic for the PBX plugin to load this extra file and use it for the tablname to romname mapping. Like that the system will always have a list of all tables known to the config tool. Since the mapping must using fuzzy matching is will still be possible that some tables cant be matched (e.g. if the table name is completely different from the name in the list), but for the majority of table that approach should work fine.

 

Proposed mapping file format:

If possible I'd like to have a xml file for the table/romname mappings.

<TableNameMappings>
  <Mapping>
    <TableName>Adams Family, The</TableName>
    <RomName>TAF</RomName>
  </Mapping>
  <Mapping>
    <TableName>Attack from Mars</TableName>
    <RomName>afm</RomName>
  </Mapping>
  ....more mappings ......
</TableNameMappings>

[arngrim]

i'll send you a sample file soon, with personalized roms per user so it will be perfect

[tspeirs]

Sorry for the delay. PinballX does actually have an additional field for the PinMAME Rom name that the user chooses its just that its not currently exposed to the plugin system. Its easy for me to add and I will do so for the next release.

 

Cheers.

Tom.

[tspeirs]

Please see version 1.94 uploading now. There are two new fields for plugins (look at sample in plugins folders). Both fields are fo rom names one is the one auto detected by PinemHi after launching the table and the other is the PinMAME ROM specified in the XML. Is this enough for you?

[arngrim]

thank you Tom

 

in fact, we were already checking for another solution, the only problem is it's a pain to fill the xml with the right rom for each table, especially when you never filled it and you have 350 tables

 

i have created the xml that swisslizard asked, i'm waiting for him to see what option he wants, for me it's the same

 

Cheers