ohall

Hi All, For anyone who knows the internal guts of DCS multiplayer sessions and the Export.lua environment... Is there any way to get a unique ID for a particular multiplayer session/server from within the Export.lua? I'm hoping there might be something like a LoGetSelfData() type method that pertains to the multiplayer world rather than the particular user aircraft. I've got (I think!) a cool idea if such a thing exists... Thanks to anyone how might be able to advise. (B/229) Penguin

Arduino Library Available Just a quick note: As well as a very minor update to DCSI to allow users to specify the location of aircraft config files (hopefully this will work with the DCS 1.5 beta, though I've not tested it yet) I've also posted an alpha release of the Arduino library which includes support for a number of simple input/output devices and also supports an RS485 bus for multiple boards. All available from www.dcsintegrator.co.uk

I'm writing unit tests right now ;) ... well, not *right* now... I can't multi-task.

We are talking about the same end goal, but we're getting there by slightly different routes. What you're saying: A program would auto-generate Arduino code for upload. This is definitely doable but, without a lot of work/dependencies, would still require you to load the generated code into the arduino ide and compile/upload up a new version if anything changes. What I'm saying: The "standard" arduino code (providing you're using the "built in" primitive controls) is loaded up to each arduino board once, though the code doesn't "know" at this stage what controls are connect to the various pins. DCSI then talks to the board at startup and tells the board which types of controls are attached where. If you change/add a new control, just restart the DCSI config and the new control should be functional. Gadroc's pointed out that there are potential issues with this approach (memory management) so it's not a panacea, but I'm hoping to be able to manage that with suitable checks and balances. Keep your fingers crossed for me ;)

Hi Gadroc, I realise that the two are separate entities, though it doesn't really change the points I was making. I think there might be some misunderstanding of my (somewhat proposed) solution too. So, to "decouple": DCS-BIOS exports out all cockpit data, regardless of what's actually required. I'm just commenting that, given that the previous discussion was somewhat biased towards data rates/volumes, this design decision isn't as "frugal" as it could be. DCS-BIOS currently doesn't indicate the start of a new session and which aircraft is in play - sure, it could be extended to do so. But at present it doesn't and I haven't seen any movement in that direction. Any consumer of the DCS-BIOS data stream has to be told (by something else) how to interpret that data. Don't get me wrong, I know none of this is insurmountable - I'm just trying to find a solution to (what I see as) a limitation. DCS-BIOS Arduino Library: Assumes a static/single-type cockpit. Each control is bound to a specific aircraft's clickable cockpit element. I've clearly not explained my angle on what I think is a "better" design properly either. I'm not proposing putting any decision logic on DCS processing loop - in fact, quite the reverse. When a session starts, I take a reference to a lua table that lists the items required for export for that particular aircraft (and nothing else). Only those items are exported, and only when the value changes. After the initial "I am aircraft type: xyz" message, there's no more information in the updates than "device, argument, value" - so it's fairly system agnostic. DCS Integrator (or whatever consumes *those* packets) can sit anywhere on the network - it doesn't have to be on the DCS machine. The practical reality is that DCS Integrator is still in the womb and may be still-born - so this may all be moot anyway! All the best, Ol

Hi Ian, Thanks for the reply. Is it worth creating a specific thread where everyone with a vested interest in this stuff can discuss design ideas? Fundamentally, we appear to have different views on getting data in and out of DCS. As you know, I started off using DCS-BIOS and whilst I think it's a quality piece of work (and I have enjoyed many hours setting up my armament and tuning my ADF using your libraries), there are some basic design principles that I don't agree with. I've stolen this from the storage world, but I'm a firm believer in the adage "the cheapest I/O is the one you don't need to do". DCS-BIOS (to my understanding) is based around a memory mapped block export of everything that changes, regardless of whether the cockpit needs it or not. Although the memory map concept provides a very efficient way of getting the data out, you lose a lot of that efficiency *if* all you want is a subset of the data. Naturally the break-even line moves depending on how complete a cockpit you require. My motivation was to be able to fly different aircraft using a generic set of cockpit controls rather than build a faithful Huey cockpit - I don't have the time, money, space and I might find I'm pushing the tolerance envelope with my wife if I did. DCS-BIOS (again, to my understanding) is currently a one aircraft deal (unless I re-flash all of the Arduinos in between switching aircraft). We did discuss this on GitHub I think, though I believe the issue is that there's currently no way for DCS-BIOS to tell the Arduino to "initialise" at the start of a mission? It's for those reasons (which I appreciate I may have misunderstood, so apologies if I have misrepresented things) that I decided that what I wanted (and thought others might want to) would require dynamic generation of export files, and a configurable mapping model. Managing this in the Export.lua is impractical, so I've gone down a middleware application road. Admittedly, it's another layer between the sim and the hardware, but it provides a layer of abstraction that possibly meets your goal of a single "export" (and control API) - just not the way you've described. Please don't take this as a challenge to DCS-BIOS, as a number of people have said, different requirements need different solutions, and I completely accept that you've been doing this for a long time, and I am still hopping between one hacked piece of code to another so I may find tomorrow that my eyes are opened to some huge over-simplification I'm making... I won't be too proud to admit it if I'm talking nonsense! Sorry - this is the kind of chat that's perhaps better off in a specific thread? All the best, Oliver

That's feasible, though the death of many a project is scope creep, so I'm going to focus on DCS World for now. I know nothing about X-plane and don't want to dilute the effort at this point. That's exactly what DCS Integrator does, though... ... rather than generate code, the Arduino code generates object models (e.g. a button or LED) dynamically and then configures anything that is control specific (such as the range of an encoder or potentiometer). As you say, there's a bunch of "well known" controls which are provided by default, and then more complex stuff would need a bit of programming-fu to realise (though all the coms is encapsulated in the generic base classes).

Hi Gadroc, You've got me thinking now - do you have any example data for what a decent simpit might have in terms of volume of controls/data points to represent? My perspective has been very much towards the Huey with limited/unsophisticated controls whereas I expect the A10 is far more involved. I just wondered what a good sized cockpit might require? Cheers, Ol

Hi Gadroc, Thanks for the tips - I'm certainly at the early end of the process so I appreciate the heads up on the various things that may bite me as configs grow. I have to admit I don't have any experience with your stuff, as I had understood Helios was geared towards glass cockpit stuff, and I hadn't seen EOS until just now. My hope (and it's just that at the moment) is to ameliorate some of these issues by only transmitting information that matters to the cockpit, and has changed since the last update, rather than have DCS dump the entire cockpit constantly. My testing is currently at 115200 baud with a value update message length of 63 bits (including stop bits). I know I won't get anywhere near (or require!) the theoretical limit of 1828 updates/sec - once I get the code complete I'll start pushing the limits and see where things break down! I've written the firmware for a DMX lighting controller which has some fairly precise timing constraints at 250k baud, and a few other RS485 master/slave devices, though never using Arduino before, so without getting down and dirty with the interrupts I'm not sure how it'll turn out! I noticed you've gone low-level on with EOS - was that because the Arduino libs block? I'm developing everything on a few Nano's at the moment - memory wise I can't see the device hosting more than a handful of devices due to the limit on pins, and each device instance is pretty lightweight - It's a good point though and I'll build a test to see how many devices I can instantiate before it keels over! All the very best & thanks again for the advice, Ol

Not really a "release", but something to play with - go to downloads @ www.dcsintegrator.co.uk All the best, Ol

This looks amazing!!!

Hi Warhog, What you're suggesting is certainly the ideal for community developed projects, though that ideal doesn't always work out in practice. I won't make any bones about it, I have some thoughts on how I may be able to monetise the work I'm doing, with a central ethos that the platform is free for hobby use, though not in any commercial activity - so opening up the "platform" project to a collaborative effort isn't part of the plan. Ian's work is very impressive, and I did try out DCS-BIOS and even made a number of contributions to the GitHub repository, but with my pull request still sitting dormant after 8 months - to be frank - I got tired of waiting. That experience was really what lead me to consider my initial proof of concept - reading in DCS aircraft files to avoid the process of having to build aircraft definition files for DCS-BIOS - and having passed that milestone fairly easily, I thought I might as well carry on. I completely understand your point of view, and it is a chunk of work which I hope others will pitch in on (e.g. developing reference code for platforms other than Ardui-**spit!**-no ;) All the best, Oliver

I'm really not sure yet - and I don't want to fall in the Eagle Dynamics mold of promising something and then not delivering ;-) I haven't set up the installer yet, but I may get that done fairly soon, and then I'll be able to make Alphas available on the site. you won't be able to do much until I get the Arduino* library/reference code up to scratch (it's currently very much hacked together) but you will be able to play with e Windows application, and IMPORTANTLY, I'm keen to know if there are any issues loading various aircraft definitions. ED (or 3rd party devs) don't appear to follow a consistent approach in the LUA files that define the gauges and clickable cockpits so I've had a couple of failures in loading aircraft info. I've got all of my installed aircraft working now (Ka-50, UH-1H, Mi-8MTV2, TF-51D, Su-25T**) but that doesn't mean the others will work without a few more tweaks! * Hardware-wise, the Arduino is just the easiest platform to prototype on. Once I get the significant things squared away, I'll look at other MCU options (or others can come up with ideas once I publish the DCSI<->board protocol) ** The Su-25T doesn't have a clickable cockpit so that's severely limited to stuff like altitude, heading, lat & long.

it's encouraging when other people are thinking along the same lines :) DCS Integrator is a C#/.Net/WPF application too and handles all the coms natively, so no need for other utilities/tools to route the data etc. I also read/modify/update (or create if it doesn't exist) the Export.lua hooks too, so I'm trying to get to a stage where a user doesn't need to know any of the dirty details of lua scripts in DCS (unless they have to, or create a custom output script... which is another "output device" on my hit list!)