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!)

Hi All, I wanted to let everyone building a sim-pit know about a new application I'm developing. It's called DCS Integrator and the intention is to provide a completely application driven integration option between DCS World (any aircraft with a clickable cockpit) and microcontroller boards. For those who want to go further, there are also base classes that can be extended for custom controls. It's still a work-in-progress but you can keep up with development at http://www.dcsintegrator.co.uk I'm hoping to have a release available for public consumption soon. Best regards, Oliver

I'm working on an integration application, and noticed that one of the clickable elements in the Ka-50 has, what I believe is, an anomaly in the argument values. elements["EMERGENCY-BRAKE ENGINE-RIGHT-PTR"] Has two different values: 555 and 55 where I believe they should both be 555. Thought I'd mention it! Oliver

Hi All, I've tried to find this on the forums, but the only references I can find say that the in-game console is "disabled in public builds". From that, is it the case that it simply isn't available to non-privileged types (i.e. general users) or is it just disabled by default? i.e. Is there any way to enable the in-game console? I'm building a piece of integration software and I'm assuming that being able to access the console will save me a lot of grief (trial & error). It seems odd if this *isn't* available as an option to switch on, since the DCS Manual (found on steam) has a section on triggers where it makes heavy reference to use of the in-game console. I tried using DCSWitchcraft, but I get an error (env is 'nil') at startup, so I gave up on that. Cheers, Ol

Many thanks ;-) If I ever manage to complete the Huey campaign (and at the present rate, the gazelle, DCS 2 and cold fusion will all have been accomplished!) maybe I'll meet some of you guys online :)

Dear Gazelle Developers, I've been lurking on here for a while now, and I'm terrifically excited by the prospect of the SA342 being available in DCS, so many thanks for building what is looking to be a superb add-on. I am one of those who will be happy to pay for the module if you go down that road. In the interest of complete authenticity, I thought I should mention a recent safety notice from Airbus Helicopters that concerns the SA342 (military models L, L1, M, M1, Ma). It appears that some non-approved seatbelts have been fitted by unqualified engineers and this should be rectified asap. I just thought I should let you know to make sure that your seatbelt model uses genuine Aerospatiale/Eurocopter/Airbus parts ;-) Keep up the great work and put me on the distribution list for the release announcement please!