Interfacing with your custom bridge equipment; Part 2

I don't want to derail this discussion - sure for those of you with the space and budget to build "proper" bridge setups, DMX looks like a good option.

But while you say "we want more from the interface than just a red alert light", there are a whole load of us for whom that would be all we wanted. I'm reasonably tech savvy, though coding is one of my weaker areas. Not too handy with power tools but I can follow instructions with a soldering iron. I don't have much spare cash or the space for any bridge that won't fit in a suitcase. Building a bridge for me, as I suspect for many Artemis players,means rearranging chairs and tables in front of the TV. For us, a cheap, sub $50 way to get a red light to flash when Red Alert is triggered would be the pinnacle of cool simulation experience.

I know I'm in the minority in this thread, but I suspect a significant proportion of the player base who would never consider themselves in the market for LBE building might consider this within their grasp.

So while you're working on the DMX solution for the big boys (and best of luck to
you all,having seen what marvels the flight sim crowd have come up with, I can't wait to see your work) can you consider an option for us budget boys? I know the argument regarding all the different hardware types available and you can't support them all , but frankly if someone posted saying "Buy kit X and do Y to get a working Red Alert light for $30, I think you'd see a lot of semi-casual Artemisers going out and buying kit X.

Thanks for taking the time to read.

Regards

Dr V

I think ThomasGanshorn has the right idea - I don't think the Artemis executable should directly implement DMX or any specific protocol. I see two things that can be done to make this work for many scenarios.

1. Have an option to start an exe with parameters or call a bat file or something when certain key events occur (E.g., RedAlertOn=C:\turnonredalert.bat, RedAlertOff=C:\turnoffredalert.bat). Don't worry about having too many of these - these are for people who have just a few special things they want to have happen; the more "casual" bridge-builders.

2. Have an API for getting status of many, MANY variables via HTTP. Basically, return an XML or JSON string based upon queries, allowing more complex controllers to keep polling things and run their own commands/triggers. I'm sure an application could be built that would act as a DMX controller. E.g., they'd run a "GET /status?target=artemis&details=basic&format=json" and get back something like:
{
name: "Artemis",
frontShields: 75,
rearShields: 90,
shields: true,
impulse: 100,
warp: 0,
redAlert: true,
heading: 173
}

You could pass different values for the details parameter to get more information, such as engineering details, comms, etc.

There might be "better" ways to do this, such as using a push-notification system, but the two options above don't seem like they'd involve too much additional planning, yet would open up many possibilities for the builders out there!

+1

I like the sound of an HTTP API.

Although I've been pushing/supporting the DMX system for additional external outputs, I'm definitely FOR having an interface that will allow all of us to have another screen or computer or whatever display various variables to the players like weapon stores, special shields displays or whatever. It sounds like a web/http interface to the server machine gets this job done quite nicely. If that's through an API, I'm not sure.

I know Thom is reluctant to include support for the Arduino, but I think (admittedly, I'm speaking from my formidable two weeks' experience with my Arduino) that there's a lot of really, REALLY cool things you could do with a few of them if they can interface with the game. For example,here's something I've put together over the past couple of days. It's just a mockup, but it wouldn't be all that difficult to hook it into an simple API like JamesAllen was proposing (at least, I think; I'm still new to the Arduino scene).

Also, if I'm not mistaken, Arduino units can talk to DXS devices, so supporting the Arduino is killing two birds with one stone.

Arduino is just serial stuff though, in fact if serial was used for everything then you wouldnt be restricted to arduinos either. Pretty much all the cheap mcu dev boards support serial in some fashion


Just gimme a breakdown of the network protocol that Artemis uses, I'll be able to hook up anything then :)

Thom has been working on a DMX interface for custom control/display linking. Check out the thread at this link.

I just signed onto the forums for the first time, we're starting a bridge build here. I'd like to eventually have custom consoles for all of the stations and use LEDs and other displays to show torpedo loading status, etc.

I like the idea of an interface where you can "pull" game state. Once this functionality is in place then everyone can write their own software to talk to whatever hardware they want to use. Artemis can *officially* support a few protocols like DMX512 but then those of us with other requirements can develop our own drivers and such.

Scott

X-plane does a nice job of this by setting up an interface that transmits and receives data. It is then up to the user to interface to it. It's pretty simple and years ago I was able to easily write a few Java based instruments. I'm sure that provided such an interface that the user community could quickly come up with the required interfaces to things like DMX or just other PCs.

Here's some info on X-Plane on Srduino/Teensy

http://www.pjrc.com/teensy/td_flightsim.html

Let me jump in and say I like the HTTP API. This is a common method to provide maximum flexibility for custom equipment to use an established protocol to pull status data and react. With a small api published and even Arduino can pull such data and act on it. Plus if the custom equipment has it's own software it could then run parallel on the server or on another system dedicated to the control of more formidable setups.
That said.. Dump the status data every time it changes to a known configurable file and then either a process daemon can pick it up or it can be published by an http daemon so the data can be picked up by another network device.