490 replies to this topic

[ashleyb]

Check this file

2020.09.07 23:14:26.861 Warning: File E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini does not contain data.
2020.09.07 23:14:26.861 Warning: No version section found in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.
2020.09.07 23:14:26.861 Warning: Could not find color definition section in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.

Ah thanks Outthere, mines empty, is there a way to generate that file? Or could you point me in the direction of what to put in there?

[Outhere]

 

Check this file

2020.09.07 23:14:26.861 Warning: File E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini does not contain data.
2020.09.07 23:14:26.861 Warning: No version section found in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.
2020.09.07 23:14:26.861 Warning: Could not find color definition section in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.

Ah thanks Outthere, mines empty, is there a way to generate that file? Or could you point me in the direction of what to put in there?

 

Make sure you only Select hardware you have on the  - DOF Web site
That files come with the Dowmload from the DOF Web site -- http://configtool.vp...e.com/login.php

 

[ashleyb]

Check this file

2020.09.07 23:14:26.861 Warning: File E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini does not contain data.
2020.09.07 23:14:26.861 Warning: No version section found in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.
2020.09.07 23:14:26.861 Warning: Could not find color definition section in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.

Ah thanks Outthere, mines empty, is there a way to generate that file? Or could you point me in the direction of what to put in there?

Make sure you only Select hardware you have on the  - DOF Web site
That files come with the Dowmload from the DOF Web site -- http://configtool.vp...e.com/login.php

Thanks Outhere, deleted the empty file so the only one in the folder is directoutputconfig30 that Dof config creates and all working. Totally overlooked that error, thanks Outhere, really appreciated.

Edited by ashleyb, 09 September 2020 - 10:01 PM.

[ashleyb]

 

 

Check this file

2020.09.07 23:14:26.861 Warning: File E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini does not contain data.
2020.09.07 23:14:26.861 Warning: No version section found in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.
2020.09.07 23:14:26.861 Warning: Could not find color definition section in file E:\PINBALL\DIRECTOUTPUT\config\directoutputconfig.ini.

Ah thanks Outthere, mines empty, is there a way to generate that file? Or could you point me in the direction of what to put in there?

 

Make sure you only Select hardware you have on the  - DOF Web site
That files come with the Dowmload from the DOF Web site -- http://configtool.vp...e.com/login.php

 

Hi Outthere,  everything working great in VPX now, but when I launch pinballx I get no LEDS in either Pinballx or VP.  I've tried both 64 bit (which I had installed) and 32 bit versions of PBX which I still have installed as that seemed to solve PBX issues for some.

 

I've included the directoutput pinballx log which seems to show the directoutput.dll isn't registered, but it's working for VPX and I can see the reg entry which all looks correct.  I'm also running everything as admin.

 

20.09.10 09:33:25.458 DirectOutput PinballX Plugin, version 3.1.7527.20768, built 2020.08.10 11:32

20.09.10 09:33:25.460 Loading plugin config

20.09.10 09:33:25.476 Plugin config loaded

20.09.10 09:33:25.476 Initializing plugin

20.09.10 09:33:25.477 Loading PBX config data

20.09.10 09:33:25.489 PBX config data loaded

20.09.10 09:33:25.489 Initializing DOF

20.09.10 09:33:25.494 Init failed: Could not create a instance of the DirectOutput framework. Retrieving the COM class factory for component with CLSID {A23BFDBC-9A8A-46C0-8672-60F23D54FFB6} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

20.09.10 09:33:25.496 . Stack:    at PinballX.DOFManager.Load()

   at PinballX.DOFManager.Init()

   at PinballX.Plugin.Initialize(IntPtr InfoPtr)

 

Again, any help appreciated.  Thanks.

[Outhere]

@ashleyb   Try this
Make a copy of the file GlobalConfig_b2SServer.xml, and renamed it GlobalConfig_PinballX.xml. Needed for Pinball X addressable LED effects.

[ashleyb]

@ashleyb   Try this
Make a copy of the file GlobalConfig_b2SServer.xml, and renamed it GlobalConfig_PinballX.xml. Needed for Pinball X addressable LED effects.

Thanks Outhere, already have that file.

I figured out unchecking running pinballx as admin made it all work. For some reason the directoutputcomobject.dll (I think thats what its called from memory) doesnt seem to be registered for the admin user, even though I ran the registercomobject.exe as admin. I even tried to manually register the dll from a command prompt running as admin using the regsvr32 command, but that didnt work. Checked the registry key and the path is correct in there also. So all working now apart from pinballx not being able to shutdown pinsound tracks and the occasional backglass when exiting a table because its not running as admin I guess.

Edited by ashleyb, 10 September 2020 - 05:38 PM.

[Outhere]

@ashleyb   Try this
Make a copy of the file GlobalConfig_b2SServer.xml, and renamed it GlobalConfig_PinballX.xml. Needed for Pinball X addressable LED effects.

Thanks Outhere, already have that file.
I figured out unchecking running pinballx as admin made it all work. For some reason the directoutputcomobject.dll (I think thats what its called from memory) doesnt seem to be registered for the admin user, even though I ran the registercomobject.exe as admin. I even tried to manually register the dll from a command prompt running as admin using the regsvr32 command, but that didnt work. Checked the registry key and the path is correct in there also. So all working now apart from pinballx not being able to shutdown pinsound tracks and the occasional backglass when exiting a table because its not running as admin I guess.

You really shouldn't have to run anything as as admin
 

[ashleyb]

@ashleyb   Try this
Make a copy of the file GlobalConfig_b2SServer.xml, and renamed it GlobalConfig_PinballX.xml. Needed for Pinball X addressable LED effects.

Thanks Outhere, already have that file.
I figured out unchecking running pinballx as admin made it all work. For some reason the directoutputcomobject.dll (I think thats what its called from memory) doesnt seem to be registered for the admin user, even though I ran the registercomobject.exe as admin. I even tried to manually register the dll from a command prompt running as admin using the regsvr32 command, but that didnt work. Checked the registry key and the path is correct in there also. So all working now apart from pinballx not being able to shutdown pinsound tracks and the occasional backglass when exiting a table because its not running as admin I guess.

You really shouldn't have to run anything as as admin

Oh really, I thought it was standard practice to set vpx and pinballx to run as admin. I’ve seen that mentioned a lot in the forums?

[mjr]

Oh really, I thought it was standard practice to set vpx and pinballx to run as admin. I’ve seen that mentioned a lot in the forums?

 

Yes, it's constantly mentioned in the forums, and the #1 reason it's constantly mentioned in the forums is that... it's constantly mentioned in the forums!  It's the Internet misinformation echo chamber effect.

 

There *used to be* some cases where it was actually necessary to run things in Admin mode, but it was never a good practice.  Microsoft designed Admin mode for trusted system software that needs to modify the system, not for routine application use, and very much not for games.  Admin mode should be avoided except for the trusted system software where it's legitimately needed, because it compromises system security and creates inter-operability issues between components.  Most of the old cases where you needed Admin mode for pinball software (and again, they're OLD cases at this point) were due to bugs in different components of the software.  The developers of most of the components have figured out and removed most of those bugs, and I don't think there are any legitimate excuses to use Admin mode any more.  Any setup guides or FAQs telling you to use Admin mode for everything are generally either outdated or are just repeating echo-chamber advice they read somewhere else.  There might still be some special cases where Admin mode is actually needed for some reason, but those should be examined closely to see if they're really true or just a misunderstanding based on outdated advice; Admin mode is not needed for any of the mainstream virtual pinball ecosystem software at this point.

 

See "Should I use 'Run as Administrator' for everything?" here: http://mjrnet.org/pi...hp?sid=software

Edited by mjr, 10 September 2020 - 07:31 PM.

[ashleyb]

Oh really, I thought it was standard practice to set vpx and pinballx to run as admin. I’ve seen that mentioned a lot in the forums?

 
Yes, it's constantly mentioned in the forums, and the #1 reason it's constantly mentioned in the forums is that... it's constantly mentioned in the forums!  It's the Internet misinformation echo chamber effect.
 
There *used to be* some cases where it was actually necessary to run things in Admin mode, but it was never a good practice.  Microsoft designed Admin mode for trusted system software that needs to modify the system, not for routine application use, and very much not for games.  Admin mode should be avoided except for the trusted system software where it's legitimately needed, because it compromises system security and creates inter-operability issues between components.  Most of the old cases where you needed Admin mode for pinball software (and again, they're OLD cases at this point) were due to bugs in different components of the software.  The developers of most of the components have figured out and removed most of those bugs, and I don't think there are any legitimate excuses to use Admin mode any more.  Any setup guides or FAQs telling you to use Admin mode for everything are generally either outdated or are just repeating echo-chamber advice they read somewhere else.  There might still be some special cases where Admin mode is actually needed for some reason, but those should be examined closely to see if they're really true or just a misunderstanding based on outdated advice; Admin mode is not needed for any of the mainstream virtual pinball ecosystem software at this point.
 
See "Should I use 'Run as Administrator' for everything?" here: http://mjrnet.org/pi...hp?sid=software

Oh really, I thought it was standard practice to set vpx and pinballx to run as admin. I’ve seen that mentioned a lot in the forums?

 
Yes, it's constantly mentioned in the forums, and the #1 reason it's constantly mentioned in the forums is that... it's constantly mentioned in the forums!  It's the Internet misinformation echo chamber effect.
 
There *used to be* some cases where it was actually necessary to run things in Admin mode, but it was never a good practice.  Microsoft designed Admin mode for trusted system software that needs to modify the system, not for routine application use, and very much not for games.  Admin mode should be avoided except for the trusted system software where it's legitimately needed, because it compromises system security and creates inter-operability issues between components.  Most of the old cases where you needed Admin mode for pinball software (and again, they're OLD cases at this point) were due to bugs in different components of the software.  The developers of most of the components have figured out and removed most of those bugs, and I don't think there are any legitimate excuses to use Admin mode any more.  Any setup guides or FAQs telling you to use Admin mode for everything are generally either outdated or are just repeating echo-chamber advice they read somewhere else.  There might still be some special cases where Admin mode is actually needed for some reason, but those should be examined closely to see if they're really true or just a misunderstanding based on outdated advice; Admin mode is not needed for any of the mainstream virtual pinball ecosystem software at this point.
 
See "Should I use 'Run as Administrator' for everything?" here: http://mjrnet.org/pi...hp?sid=software

In that case I may unadmin mode my components and it should make my LEDs work easier if it works.

BTW - your pinscape s/w is fantastic, use it for nudge and recently bought an oakmicros plunger kit which works really well. Thanks for the advice and s/w

[Outhere]

ashleyb - Don't forget about this

User Account Control (UAC)
http://mjrnet.org/pi...2xx&sid=windows
 UAC.jpg   65.49KB   4 downloads

Edited by Outhere, 10 September 2020 - 07:49 PM.

[ashleyb]

ashleyb - Don't forget about this
User Account Control (UAC)
http://mjrnet.org/pi...2xx&sid=windows
UAC.jpg

Thanks Outhere, will check that as I think UAC is off.

[ashleyb]

Oh really, I thought it was standard practice to set vpx and pinballx to run as admin. I’ve seen that mentioned a lot in the forums?

 
Yes, it's constantly mentioned in the forums, and the #1 reason it's constantly mentioned in the forums is that... it's constantly mentioned in the forums!  It's the Internet misinformation echo chamber effect.
 
There *used to be* some cases where it was actually necessary to run things in Admin mode, but it was never a good practice.  Microsoft designed Admin mode for trusted system software that needs to modify the system, not for routine application use, and very much not for games.  Admin mode should be avoided except for the trusted system software where it's legitimately needed, because it compromises system security and creates inter-operability issues between components.  Most of the old cases where you needed Admin mode for pinball software (and again, they're OLD cases at this point) were due to bugs in different components of the software.  The developers of most of the components have figured out and removed most of those bugs, and I don't think there are any legitimate excuses to use Admin mode any more.  Any setup guides or FAQs telling you to use Admin mode for everything are generally either outdated or are just repeating echo-chamber advice they read somewhere else.  There might still be some special cases where Admin mode is actually needed for some reason, but those should be examined closely to see if they're really true or just a misunderstanding based on outdated advice; Admin mode is not needed for any of the mainstream virtual pinball ecosystem software at this point.
 
See "Should I use 'Run as Administrator' for everything?" here: http://mjrnet.org/pi...hp?sid=software

Unadmined all of my s/w components and everything running great now. In fact, it could be my imagination, but everything seems to run snappier now. Thanks @outthere and @mjr for the help and advice.

[arejst]

Is the Wemos mini pro code a part of the main build now?

 

I had problems when upgrading to the latest DOF version and had to revert to an older .ddl I had.

Edited by arejst, 06 October 2020 - 05:34 PM.

[mjr]

Is the Wemos mini pro code a part of the main build now?

 

I had problems when upgrading to the latest DOF version and had to revert to an older .ddl I had.

 

Yes, it should be in there.  You have to set some global config variables to override the default timing for it.  Check with the author (Vroonsh) if you're not sure how to do that.

[pitty]

Hello, not sure if i'm in the right section.

 

I bought a Teensy 4.0 thinking it was an upgrade over the 3.2.

 

Does anyone have any info about getting Teensy 4.0 to work with DOF? or could point me in the right direction please?

 

Or should i just ditch the Teensy 4.0 and buy a 3.2 version?

[mjr]

Hello, not sure if i'm in the right section.

 

I bought a Teensy 4.0 thinking it was an upgrade over the 3.2.

 

Does anyone have any info about getting Teensy 4.0 to work with DOF? or could point me in the right direction please?

 

Or should i just ditch the Teensy 4.0 and buy a 3.2 version?

 

I assume you're talking about using it to run SwissLizard's light strip controller software?  I'm really not sure one way or the other, but my guess is that you do need the exact Teensy version that he specifies in his documentation.  The "version" naming for the Teensy's is a bit misleading in that each version is completely different equipment with a different CPU chip.  They versions all have some things in common, but the external hardware interfaces are different from version to version.  I don't know for sure if SL's setup depends on the 3.2's unique features, but it wouldn't surprise me if that's the case.

[Outhere]

Hello, not sure if i'm in the right section.

 

I bought a Teensy 4.0 thinking it was an upgrade over the 3.2.

 

Does anyone have any info about getting Teensy 4.0 to work with DOF? or could point me in the right direction please?

 

Or should i just ditch the Teensy 4.0 and buy a 3.2 version?

If you have to re-buy  See - Pinball Addressable LEDs (PAL)
https://www.vpforums...topic=43173&hl=

Edited by Outhere, 12 October 2020 - 01:31 PM.

[pitty]

 

Hello, not sure if i'm in the right section.

 

I bought a Teensy 4.0 thinking it was an upgrade over the 3.2.

 

Does anyone have any info about getting Teensy 4.0 to work with DOF? or could point me in the right direction please?

 

Or should i just ditch the Teensy 4.0 and buy a 3.2 version?

 

I assume you're talking about using it to run SwissLizard's light strip controller software?  I'm really not sure one way or the other, but my guess is that you do need the exact Teensy version that he specifies in his documentation.  The "version" naming for the Teensy's is a bit misleading in that each version is completely different equipment with a different CPU chip.  They versions all have some things in common, but the external hardware interfaces are different from version to version.  I don't know for sure if SL's setup depends on the 3.2's unique features, but it wouldn't surprise me if that's the case.

 

Yes i was talking about swisslizards github teensystripcontroller - i managed to install a pull request that supports the teensy 4.0 and the firmware is working ok (i think) on the Teensy4.0

 

But i get this DOF error in logs:

Warning: Output controller type TeensyStripController not found during deserialization of data.

 

 

 

2020.10.12 00:17:40.475 DirectOutput Logger initialized

2020.10.12 00:17:40.476 DirectOutput Version 0.8.5307.1702 as of 2014.07.13 00:56
2020.10.12 00:17:40.476 Global config loaded from: K:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml
2020.10.12 00:17:40.476 Loading Pinball parts
2020.10.12 00:17:40.476 Loading cabinet
2020.10.12 00:17:40.477 Will load cabinet config file: K:\DirectOutput\Config\Cabinet.xml
2020.10.12 00:17:40.543 Warning: Output controller type TeensyStripController not found during deserialization of data.
2020.10.12 00:17:40.573 0 output controller defnitions and 3 toy definitions loaded from cabinet config.
2020.10.12 00:17:40.573 Cabinet config file has AutoConfig feature enabled. Calling AutoConfig.
2020.10.12 00:17:40.574 Cabinet auto configuration started
2020.10.12 00:17:40.648 Cabinet auto configuration finished
2020.10.12 00:17:40.648 Autoconfig complete.
2020.10.12 00:17:40.648 Cabinet config loaded successfully from K:\DirectOutput\Config\Cabinet.xml
2020.10.12 00:17:40.648 Cabinet loaded
2020.10.12 00:17:40.648 Loading table config
2020.10.12 00:17:40.649 Warning: No table config file found. Will try to load config from LedControl file(s).
2020.10.12 00:17:40.649 Will try to load configs from DirectOutput.ini or LedControl.ini file(s) for RomName mm_109c
2020.10.12 00:17:40.651 Loading LedControl file K:\DIRECTOUTPUT\config\directoutputconfig30.ini
2020.10.12 00:17:40.709 EXCEPTION: Table with ShortRomName Galaxie_1971 has already been loaded (Exists more than once in ledcontrol file).
2020.10.12 00:17:40.709 EXCEPTION: Thread:
2020.10.12 00:17:40.711 EXCEPTION: Table with ShortRomName Big_Shot_1974 has already been loaded (Exists more than once in ledcontrol file).
2020.10.12 00:17:40.711 EXCEPTION: Thread:
2020.10.12 00:17:40.744 EXCEPTION: Table with ShortRomName SpotPool_1976 has already been loaded (Exists more than once in ledcontrol file).
2020.10.12 00:17:40.744 EXCEPTION: Thread:
2020.10.12 00:17:40.769 1 directoutputconfig.ini or ledcontrol.ini files loaded.
2020.10.12 00:17:40.770 Config for RomName mm_109c exists in LedControl data. Updating cabinet and config.
2020.10.12 00:17:40.791 Table config loading finished
2020.10.12 00:17:40.791 Pinball parts loaded
2020.10.12 00:17:40.791 Starting processes
2020.10.12 00:17:40.792 Initializing cabinet
2020.10.12 00:17:40.795 Cabinet initialized
2020.10.12 00:17:40.797 Framework initialized.
2020.10.12 00:17:40.797 Have fun!

 

Here's my Cabinet.xml

<!-- This config file will set up two addressable LED strips orange on the right and blue on the left.  Each is 53 long and have the distal LED as the first in the array -->
<Cabinet xmlns:xsi="http://www.w3.org/20...chema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Name>MultiBall</Name> Cabinet Name
  <OutputControllers>
    <TeensyStripController> 
      <Name>TeensyStripController</Name>
      <NumberOfLedsStrip1>144</NumberOfLedsStrip1>  Number of LEDs on the right playfield 
      <NumberOfLedsStrip2>144</NumberOfLedsStrip2>  Number of LEDs on the left playfield
      <NumberOfLedsStrip3>0</NumberOfLedsStrip3>
      <NumberOfLedsStrip4>0</NumberOfLedsStrip4>
      <NumberOfLedsStrip5>0</NumberOfLedsStrip5>
      <NumberOfLedsStrip6>0</NumberOfLedsStrip6>
      <NumberOfLedsStrip7>0</NumberOfLedsStrip7>
      <NumberOfLedsStrip8>0</NumberOfLedsStrip8>
      <ComPortName>COM4</ComPortName> You must look in device manager to see what port Windows assigned for the Teensy USB connection.
    </TeensyStripController>
  </OutputControllers>
  <Toys>
    <LedStrip>
      <Name>PF Right</Name> This is the name that I gave the right playfield strip
      <Width>1</Width> These strips run as one long string as far as the Teensy board is concerned.  If you set the width to anything other than 1 it will give you funny results like the entire strip being LED 1
      <Height>144</Height> This is the length of the right playfield LED array
      <LedStripArrangement>TopDownLeftRight</LedStripArrangement> There are several choices that can be used here like BottomUpLeftRight.  This determines the order of LEDs that the Teensy sends out on its signal path.  If you use TopDown then the furthest LED from the connecting wires will be the first one in the segnal pathway.  I needed this because I wanted my Teensy Board in the back of the machine by the power supplies to make the shorted wiring runs.
      <ColorOrder>GRB</ColorOrder>  You must choose GRB not RBG with these strips to get them to correctly display the colors sent to them
      <FirstLedNumber>1</FirstLedNumber> This is the first strip so it starts with LED 1
      <FadingCurveName>SwissLizardsLedCurve</FadingCurveName> I didn't play with this setting so I can't tell you what this does but I suspect that this sets the protocol that DOF uses for lighting the strips.
      <OutputControllerName>TeensyStripController</OutputControllerName>
    </LedStrip>
    <LedStrip>
      <Name>PF Left</Name> This strip is set up just like the other with exceptions in bold
      <Width>1</Width>
      <Height>144</Height>
      <LedStripArrangement>TopDownLeftRight</LedStripArrangement>
      <ColorOrder>GRB</ColorOrder>
      <FirstLedNumber>1</FirstLedNumber> Since this is the second strip its first LED is the next one after the last LED on the other strip so since my strips are 53 LEDs long it is LED 54.
      <FadingCurveName>SwissLizardsLedCurve</FadingCurveName>
      <OutputControllerName>TeensyStripController</OutputControllerName>
    </LedStrip>
    <LedWizEquivalent>
       <Name>LedWizEquivalent 30</Name> This is the number assigned to the WS2811 controller by the online DOF config tool
      <Outputs>
        <LedWizEquivalentOutput>
          <OutputName>PF Right</OutputName> Name as defined above
          <LedWizEquivalentOutputNumber>1</LedWizEquivalentOutputNumber> This is the port number of the first set of combos set up In the online DOF Config tool so it is port 1
        </LedWizEquivalentOutput> 
        <LedWizEquivalentOutput>
          <OutputName>PF Left</OutputName> Name as defined above
          <LedWizEquivalentOutputNumber>4</LedWizEquivalentOutputNumber> This is the port number of the second set of combos set up in the online DOF config tool so it is port 4
        </LedWizEquivalentOutput>
      </Outputs>
     <LedWizNumber>30</LedWizNumber>
    </LedWizEquivalent> 
  </Toys>
 <AutoConfigEnabled>true</AutoConfigEnabled> This needs to be set to true to work
</Cabinet>

 

Hello, not sure if i'm in the right section.

 

I bought a Teensy 4.0 thinking it was an upgrade over the 3.2.

 

Does anyone have any info about getting Teensy 4.0 to work with DOF? or could point me in the right direction please?

 

Or should i just ditch the Teensy 4.0 and buy a 3.2 version?

If you have re-buy  See - Pinball Addressable LEDs (PAL)
https://www.vpforums...topic=43173&hl=

 

Thanks, i already ordered a teensy 3.2. i will have to resolder the OctoWS2811 onto the teensy 3.2.

 

See above the errors i was getting.

 

Thanks for your help.

 

 

[pitty]

Thanks all i solved my problem.

 

The Teensy4.0 with the Github pull request files was working properly after all.

 

I ran putty and communicated fine with a test signal.

 

So that led me to examine DOF - which i upgraded to latest version 3++.

 

and Dof config tool, I didn't use the Combo1 and Combo 2 as names in my cabinet.xml

 

Also the name

<TeensyStripController>

     <Name>LEDStripController</Name>

 

was different - my old file was named Teensystripcontroller instead of LEDStripcontroller.

 

So all working now, looks amazing, can't wait to get it into the cabinet.