External Interfaces

edited July 2015 in EmptyEpsilon
Hello,

I just recently discovered EE, and I wanted to know if there were any plans or options for extending the game into external interfaces - As I'm sure you know, Artemis has some basic DMX support which has extended into some very impressive immersive bridge setups. Because of it's open source nature, I think EE has a great potential of extensibility into non-keyboard/mouse interfaces and for doing some neat stuff with DMX or Midi. 

Anything like that on the plan? 

Comments

  • EE currently supports an HTTP server which can query game status. That makes it possible to develop small external applications that talk any protocol you want.

    DMX support would most likely not be that hard. I don't have any DMX hardware right now. But we have tons of Arduinos floating around the office. And we wanted to build some custom hardware anyhow.

    Putting this here for my own reference:  https://github.com/mathertel/DmxSerial
    As that Arduino code will allow us to build DMX acting hardware from just an Arduino.

    Shame DMX is 1 way. As we also want to hook up extra buttons and stuff...
  • Buttons are pretty easy - I've done this with Quintet via Keyboard emulation on a Teensy3. (

    Could EE's http server be extended to receive POST requests to update the game? A JSON encoded request could contain all kinds of information, and I think the latency would be low enough to allow quick response from the game.

    As a request, I'd ask that you make sure you implement true DMX if you're going to do it. One of the big hangups on Artemis has been a weird DMX implementation that means it'll only work with specific hardware.


  • edited July 2015
    sircaster, you might want to check out this issue on Github. It has some more details on the http server
    https://github.com/daid/EmptyEpsilon/issues/13

    (Off topic but....)
    The weird DMX hardware implementation in Artemis is due to the DMX DLL that Thom uses. It only works with Open DMX hardware and not the Pro.
  • The HTTP server can do a lot of things, as it's linked to the scripting engine. It could even create new objects in the world.

    So that also makes it a bit unsafe, which is why it's not enabled by default. You need to trust the clients that connect to it.

    (Script documentation is currently very lacking, sorry, but if you want to do a certain thing with the http scripts, I can point you in the right direction)
  • As for DMX hardware, most likely you need to write a driver-interface per hardware, if I look at this:

    Like I said, it's hard to support without access to the hardware. But let me know what hardware you have, I'll have a look into it.

    Which is most likely the reason why artemis supports that particular type of DMX controller. He has it.
  • I am a hardware guy. (Embedded software developer to be exact) so this is quite up my isle ;-)

    Settings for keybindings are also coming up.
  • I've got the equivalent of the Open DMX USB, which is just a FTDI FT232RL and a RS-485 chip. That's currently what is compatible with Artemis.
  • @kwadroke: If you have that device plugged in, does it show up as a COM port in your device manager?
    (Quick look at the example code seems it just uses it as an serial device, even tough it uses a "special" library to talk to it. Which is most likely just to find the device)

    Also, just looked at the "DMX USB Pro" documentation, and that's quite easy to support I guess.
  • As for keyboard controls. I just added the option to add keybinding to every button and slider in the game. Most likely not perfect yet, but should allow more keyboard interaction if you want that.

    Running the latest code will fill the options.ini with all the possible hotkey settings.
  • Been working on DMX-512 interfacing. Already committed a whole bunch of code for it:

    What it allows, right now is:
    * One or more hardware drivers
    * Select a serial port per driver
    * Map names to channel numbers
    * Map conditions+effects to channels

    For this to work you need a hardware.ini in your installation directory.

    Example hardware.ini:

    There are 3 drivers:
    * DMX512SerialDevice
    Which I know works with the code from: https://github.com/mathertel/DMXSerial
    And I think it will work with the Open DMX USB (but untested)
    * EnttecDMXProDevice
    Which I think will work with the DMX-Pro and DMX-Pro2, the command is pretty easy. But naturally, untested.
    * VirtualOutputDevice
    Can be used for debugging. Will display white squares on the screen for each active channel.

    Each device will by default use 512 channels. But can be configured to use less.
    You also need to supply a serial port. This can be by name (COMxx on windows, ttySxx on linux). Or by pseudo-driver-name, the pesudo-driver names are the same for the same type of hardware. Making it easier to have a general configuration.

    (Pseudo driver names are logged to the console when no hardware is found, but a hardware.ini is found)

    The channel number to name mapping is to have an easier time configuring effects and stuff, and so you don't have to remember "channel 1" is hooked up to the main cabin lighting for example. And when you re-wire things you just have to change 1 value.

    The order of the states in the ini is important. The latest active will be visible on the actual output. So in the example, the "MainCabinLights" is set to 1.0 (full output). Unless there is no ship (HasShip == 0). Then it will glow between 0% and 50% output in 1 second.


    There are no "events" yet. I'll implement those a bit later. So right now you cannot do a flash when you get hit for example. But I have an idea on how I want to implement those.
  • I'll do some openEntec/FTDI testing.. as soon as I get a chance.. 
  • I'm probably just being dense here.. if i have a opendmx device and configure it in serial mode. My light has 7 channels..how do i assign all 7 to a [channels] group?
  • Thanks.. It helps.. I'm guessing though that I need to go get the DMX512Serial libs for linux and add them to my build.. as it is not opening up the device... but it is definitely reading the hardware.ini.. deliberate typos generated errors.
  • No need to get extra libs. But you do need to configure the right serial port name.
  • edited April 2016
    Yeah pointing at /dev/ttyUSB0 which is what the /dev/serial/by-path/.... links to.. but it never gets opened.. Unless I misunderstand the DMX will work on any client or the server correct? Also given that I am using the OpenDMX FTDI chip type of device I should be using the DMX512Serial right?
    HAH! I found it.. I needed to specify simply ttyUSB0 not /dev/ttyUSB0 using the EnttecProDMX driver... now I feel REALLY silly. Any objections to me creating a DMX Hardware Matrix page on the Wiki?

  • (I'll patch up the code so it works with and without /dev/)

    DMX will work on any client/server. (Important IMHO, so you could have a dedicated DMX client)

    No problem in creating a matrix. I think my code will work with any cheap USB2DMX piece of hardware. As those are nothing more then USB2serial with a level converter.
Sign In or Register to comment.