Jump to content

Direct Output Showcase Video


Recommended Posts

  • Content Provider

Hello

 

After having added a lot of new functionality to DOF, I have made a small showcase video to demonstrate what DOF can do.

In this video DOF is controlling 2 LedWiz, 1 PacLed64, 1 PacDrive, 1 custom ledstrip controller and 1 DMX universe. These controllers handle 10 contactors, shaker, 5 RGB flasher, 5 RGBW flashers, 235 RGB leds on strips, 3 lamps, 1 Hellball II and still have a lot of unsed outputs.

 

Now for the fun part:

 

 

It still going to take a bit before the next DOF release is ready, but it is working pretty well already.

 

All the best

 

Tom

Link to comment
Share on other sites

Umm...can you say frikkin unreal! I have 4 ports used on second ledwiz and thought that was it what else can I add...well sheesh!!! I guess I'll be busy adding more stuff! Great work!! Amazing

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

  • Content Provider

I am jealous, my cab is full! :(

When i build my cab, i didn't even expect to put one ledwiz... :D

I tested new functionalities of dof, i like them enough that i said to myself to not upgrade table configs anymore until that dof is released.

but we even haven't finished to upgrade it, i will make exceptions for new tables ;)

Link to comment
Share on other sites

  • 2 weeks later...

The abilities of DOF are great!

 

One concern I suppose I have is something I was discussing in chat today.

 

The current set of "toys" came about very quickly after the implementation of the LEDWiz in cabinets back in 2010.

 

During this time we have experienced a sort of "renaissance" in that people with very little effort can install a fairly complete set of toys in the cabinet and experience force feedback and lighting.  This is accomplished via:

 

Swisslizard's DOF via db2s, DeeGor's config tool, and Arngrim's numerous table configs.

 

 

Why state all the obvious?  Because these components all work together, based on fairly standard set of toys, to create a fairly seamless user experience that reasonably brings cabinets closer to the look and feel of real pinball.

 

DOF is capable of driving many more objects (as is evidenced here).  The config tool can have more entries added to it.  Arngrim can generate table configs with 132 toys instead of 32.  However I have concerns for new users starting up.  Rather than take a, "I got mine, who cares what happens now" approach I'll give my thoughts here.

 

Arngrim's (and my apologies to anyone else who has generated many table configs) are the defacto standard.  Everyone is able in the config tool to make a private table map, but to new users this IS a hurdle.  Unless it is proposed that wiring up 300 LEDs is going to become the new "entry level" for getting lights to work in your cabinet, outputs will be lost.   As the definitions become split, some table events will be mapped to the new LEDs, the disco balls, the laser emitters, the water guns, the confetti cannons, and the seismic floor mats.  Those events will likely no longer be operating the old solenoids or flashers.

 

We have already seen this as the 3 flasher setups have become sparse and as 8 solenoids give way to 10.  Once again, the tools exist to create your own mappings, but in my opinion this is moving the game user into the role of table author.

 

I propose that as a baseline definition for a table, something akin to the following be adopted. 

 

For all output events, a function name and a 3D coordinate be provided.  This way one, it would not matter whether you had an 8 solenoid setup or a 10 or a 20.  You could map the event to the nearest solenoid,  It doesn't matter whether you have a 3, 5, 7, or 250 flasher setup, your event could be mapped to the nearest defined LED|.  Want to better locate your shaker motor sounds?  No problem, add 1 of them to each corner and map your sounds there.  Multiple strobes?  We gotcha covered.

 

You would still have the ability to manually map events to devices as you can now, but you would not sacrifice the ease of entry for a small set of toys that progress, and table definitions, have passed by.

 

Based on what I see in that video, I am going to assume table events are no longer going to map directly to devices anyway but rather to "DOF events" which each can expose multiple physical devices.  This would seem to fit well with a function name and 3D coordinate scheme for the physical device definition.

 

Thanks to the group mentioned for all the hard work and for your consideration.  I hope something like this can be implemented so I don't have to go do it myself ;)

Link to comment
Share on other sites

  • Content Provider

Well, the confetti canon you can add imediately if you want. Smoke machines would also work I think. DOF would support that through DMX. ;)

 

But back to the remarks of Spektre:

I think Spektre is right about the idea of trying to find a config schema which allows for some kind of position based mapping of effects and I'm planning to move into that direction with DOF. With the next release DOF will make a small first step into that direction, since the configs for led strips are already using a position based system to define the parts of the led strip which lights up. Further moves towards position based mappings might be implemented with later DOF releases. Before that can be done, we'll need to find a way how to convert todays configs to a position based system (Redoing all 300+ configs by hand would be a bit to much work I guess) and some kind of database which knows about the positions of the table elements for the various tables will be required as well.

Link to comment
Share on other sites

  • Content Provider

ok more serisously,

 

as discussed on that chat session, me and swisslizard have already the idea to split the playfield area to a matrix for contactors.

 

here is a raw example

 

post-100-0-61205400-1395044952_thumb.jpg

 

So you could define a config for a maximum of 25 contactors, when you have less, you can say contactor 2 will cover 4 cells for example.

 

Then, DOF needs to support this, we need to find a place where we can define the contactor setup of the user, and last but not least, ALL tables needs to be reviewed again...........................

 

That is a lot of work!

 

This is just an idea for the moment and it is not the priority in the sense we are in the middle of implementing working a new version of DOF, and we have almost finalized the changelist, so don't expect that in the coming months.

 

We could use the same for flasher setup.

 

But we really need to be clear with users, that there is a preferred minimum of flashers/contactors to use with that system, to benefit from it the most, we can only recommend, in the end the user do what he wants.

 

For contactors i recommend at least 7 contactors, bumper back can be optional, it is rarely used in fact.

 

For flashers, I recommend at least 5 flashers.

 

Reason is at the time of the pixelmagic site, configs were pretty basic, having 5 to 3 flashers was not a big difference, total ledcontrol.ini file was 33k.

 

But now take latest rev of configtool, combination of my 2 ini files for my 2 ledwiz is about 150k, merging 5 flashers into 3 will be too much in my optinon, and the flasher that is less used is the center flasher, so if we combine outside left and left, outside right and right, you will have plenty of effects on the sides and a limited number on the center.

 

But again, if you want to keep your config or you can't upgrade, i will understand ;)

 

having 2 coordinates for the matrix is enough i think, why would we need 3 coordinates? what does it change if the a toy is recognized close to the playfield or not?

Link to comment
Share on other sites

  • Content Provider

Before that can be done, we'll need to find a way how to convert todays configs to a position based system (Redoing all 300+ configs by hand would be a bit to much work I guess) and some kind of database which knows about the positions of the table elements for the various tables will be required as well.

 

would be great, but I don't see how we can convert the current mappings into a matrix mapping, we would need to do it at least once manually for all the tables  :blink:

Link to comment
Share on other sites

  • Content Provider

We still got a lot of time to think about these things.

 

The next DOF release will concentrate on adding more output controllers and more effect classes. Position based mapping might be a topic for a DOF release 3 (if I'm not to lazy to build it).

 

I also think a two dimensional coordinate system would be OK, but which should still have some 3 value which indicates the part of the cab where the toy is mounted (playfield, playfield side left, playfield side right, backboard, backbock and so on).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...