y2kiah

Have you actually checked the output values sent to SIOC server from export.lua, or are you assuming they match the on-screen representation? It sounds like you are describing two problems, a delay and also skipping every 3rd or 4th blink? If the problem is performance then the symptom might be a delay, but that doesn't explain a pattern of skipping. You could test for where the delay is being introduced. Are you setting the tcp_nodelay option on the socket in your script?

There you go again raising the bar. NICE WORK!!!! as always. This is something I'm going to have to do soon, for the A-10 though... Are you sure it's EGI and not EGT for "exhaust gas temperature"? The photo is blurry but I believe that is a "T" there. Some questions - what do you plan to make your bezels from? Aluminum? Plastic? What type? Just wondering what your material choice is and why. Seems like ABS or PVC might be a good choice because of its good machining properties and finish quality. Do you plan to light your gauges? I don't see it (yet) in your model, but if so, will it be with an external flood light, or a ring inside the frame?

Yes some commands require a value, which is why I named the function TwoPositionSwitch_NCC_noparam The idea being that you create another function like TwoPositionSwitch_NCC_param where you do pass parameters

Button set Thanks! I do know which switches I'll be using. Luckily, most switches available out there use standard panel mount cutouts. Most heavy-duty toggles use a 5/32" diameter hole for panel mounting. Pots with a 1/4" shaft usually use a 3/8" hole. Rotary encoders and mini-toggle switches use a 1/4" hole. For panel mounted pushbuttons, I'm not sure about a standard size so I'm just going with what I've got. This went over my head, or under it, or to the side. In any case, it missed my head. Sleep is for wimps :) .. No I've just been good about working on it when I have some free time, rather than get distracted and do something else. I figure I better get as much done as I can while the motivation is with me. No plan yet for the mag needle. What does it do, point to either the +, - or middle? I have a suspicion that DCS will automatically have the compass synced for the area you are flying, so there won't be a need for it to work. In that case I'll just put a printed card in there or something, for looks. But, you never know, it's always possible to implement later on. On another note, a couple of you have expressed interest in getting a set of FMS buttons. I started working on the CAM for the button set. As you can see below, I will cut out all of the buttons required in the cockpit in one shot, then paint, then engrave. The buttons are 9.6x9.6mm to fit in a 10mm cutout, and will be made from acrylic. If you use a 6mm tact switch for each one, there will be room between each switch for a small LED to provide back-lighting to the buttons. There are 5 panels with these buttons; the CDU, two MFDs, EWMU, upfront EW, and the upfront panel below the HUD. 153 buttons total. If anyone else is interested in the full set, PM me. Here is a render of the cutout pattern.

can you post those two .lua files and your export.lua file? I'll see if I can find anything

True, though micros are dedicated devices and likewise usually run dedicated code. My plan for abstraction is to have a generic system run on the micro that can parse commands, debounce inputs, basically handle all of the basic input polling and output stuff. The PC will be responsible for passing messages to enable pins and begin polling, or set up for output, etc. So when building the pit, if I add a new switch all I'm going to have to do is wire up the pin and add one line to my setup script on the PC - nothing to change on the micro side. I think this will strike the best balance for my purposes.

I guess I have a lot to say on this topic, I agree with both of you because both your points are completely valid. I have embedded Lua in my own graphics engine, written in C++. Lua is considered to be one of the faster script environments, hence its widespread use in games. When comparing native vs. script in a vacuum, sure native will run faster. In practice, the lines are blurred a little because: #1, A significant portion of the sim's logic is already written in Lua, so adding a few more lines of your own code probably isn't going to have a drastic overall impact on performance. #2, typically the overall performance of a simulation loop has very little to do with the performance of individual routines, and a LOT to do with the slowest routines (a.k.a. bottleneck). You can make great strides improving the performance of certain function, cut its processing time in half, only to find out that you haven't improved the frame rate at all - your bottleneck is somewhere else. In a game, very often your CPU bottleneck is in the graphics area. It's unclear to many people, that even with modern GPUs doing our vertex and pixel processing, there is significant overhead on the CPU to send data to the GPU each frame. If you take out the part of your loop that renders graphics, you could probably run the AI logic, physics, and all other CPU tasks at hundreds of frames per second. Throw in graphics, sound, etc and you're quickly down to 30 and below :-) #3, for anything that you should need to do for a home cockpit besides displaying more screens with graphics, if you are significantly affecting performance, you are doing something very wrong. If you've done things right, you should only have to poll a buffer (TCP, serial, or whatever) once per frame. If something exists in the buffer, parse it and process it. Let's say your sim is running at 30 fps. If you can flip more than one switch in 1/30th of a second, please please make a video, because you're a superhero. My point is, most frames you will be processing ZERO commands, otherwise ONE or TWO commands at the most. If you absolutely must, you can always give yourself a time budget (say 2 or 3ms), and yield your process once you've exceeded that budget. Next frame, pick up where you left off. This can be effective in preventing frame rate stutter. #4, just get it working, cuz I want to see videos!! edit: I forgot to conclude. I'd say whatever you can get away with writing in script (Lua), do it because the time saved and ease of maintenance far outweighs the performance impact. If you have a certain thing with significant processing overhead, it's time to start thinking about coding that thing in native code, or on its own microprocessor. Just be ready to recompile/reflash every time the smallest detail changes.

nice work on the speadsheet, that will be helpful! regarding your question, I'm not sure of the difference between the clickableaction method and the setcommand method. I think in the end they probably accomplish the same thing, and I doubt there is any difference in performance. I would say use the one you like better. Do clickableaction calls work from an external view?

Oh I know it works standalone, tested yesterday. I meant the SIOC bits are untested, I wanted to help out memento10 with his SIOC issue.

Put the following new function at the end of your ExportSupport.lua file -- Calls non-clickable commands without parameters for two-position switch function TwoPositionSwitch_NCC_noparam(pDevice, pCommandNumber) GetDevice(pDevice):SetCommand(pCommandNumber) end Then, in your siocConfig.lua file, add the switch definition local SIOCNbr = 0 -- insert your correct SIOC button number here for shkval center inputsTable = { ... [sIOCNbr] = {TwoPositionSwitch_NCC_noparam, 8, 92}, ... } just keep in mind that this code is not tested at all I'm taking a leap of faith here that SIOC is actually passing the switch event to the sim machine just like all other events. If it's not coming through, try configuring it as a standard switch with SIOC, instead of as a key emulation type.

I have your answer guys I used the Shkval Center command as my example, the following code will do it local dev = GetDevice(8) -- 8 == SHKVAL dev:SetCommand(92) -- 92 == Keys.iCommandPlaneRadarCenter another example, lock/unlock shkval target, and toggle white/black dev:SetCommand(100) -- 100 == Keys.iCommandPlaneChangeLock dev:SetCommand(846) -- 846 == iCommandPlane_I251_Background_WhiteBlack To find other commands browse SHKVAL_commands.lua, then look at command_defs.lua to find the corresponding command number for other devices besides shkval browse to the appropriate folder and follow the same pattern.

I think that because FSUIPC already defines its own protocol, that integrating SIOC with FSUIPC was a simple matter of translating IOCP messages sent to the IOCP server, into FSUIPC messages sent from the server to the sim software. For DCS, no such protocol exists and instead we have export.lua to work with. You should be able to connect to IOCP server from export.lua and appear as an IOCP client by following the protocol. At that point, all event messages will be forwarded to the script from all other clients. memento10 seems to have found something that he writes about in his thread on this topic: inputEvents['JOY_BTN1'] = JOYSTICK_BUTTON0 while it doesn't mean much by itself, this appears to be proof that all input events are exposed to lua script and not just clickable events. What if it's just a simple matter of doing something like sendInputEvent(inputEvents['KEY_C']) to send a 'C' keypress to DCS? Of course, I made up the function name but there should be something like that available. Wish I was home now so I could find out for sure

Lua will be running within the context of the DCS sim anyway, so it's pointless to have Lua send a keystroke to the OS, to then be handled by DCS. You might as well use the provided APIs to send the command directly. I would be very very surprised if this wasn't somehow possible. Even if ED doesn't publish it in the clickabledata.lua file, there are many other lua files that you can browse through to see if something looks promising. You can also try dumping the metatables to a file to check out all of the functions made available. Sure those particular commands may not be clickable from the virtual cockpit, but shouldn't all sim commands be exposed to Lua in some way? I'll look into this at home when I get a chance, I'm now curious too... SIOC can't generate a remote keystroke, but does SIOC at least generate a TCP message that the virtual keystroke occurred? If so, whatever listening software on the sim computer (in this case export.lua script probably) can listen for those messages and respond with custom code as described above.

Ah, yes of course. Sorry about that

One example would be one of Leo Bodnar's joystick boards. Another example can be found here http://www.pjrc.com/teensy/index.html Don't worry about that too much, no one is born with the knowledge. Best thing to do is when someone mentions something in passing that interests you, find out more about it on your own. I think most people aren't going to explain things in great detail unless they are specifically asked, but there is plenty of information out there already on these subjects. Has nothing to do with the method that I mentioned, it has everything to do with the use of the "toggle" sim command. I didn't suggest he map the switch events to a toggle command. It's a given that if a separate "up" and "down" command exist, that those be used. If only a toggle command exists, Lua can be used to do a set->read loop until the correct setting is reached. The game controller would have to send different events for each toggle switch position, or expose the positions as unique buttons for things to be done right.

You wouldn't send a constant signal to the PC. Whatever micro controller you use to read switch input would have to be programmed to send messages to the PC only when a switch changes position. On the PC side, these events can be handled in software exactly the way keyboard events are handled in win32. If the I/O board is a USB HID client, it will be recognized by your OS as a generic game controller / keyboard type device, and your switch events will appear just like button presses. The more flexible route (but more work involved) is to use Lua on the back end because you have the opportunity to code whatever extra processing you may need before sending input to the sim.

Right console panels I found some time to wrap up the panels on the right console Annunciator panel, kind of boring until it lights up! EGI Panel, for lack of a better term... TACAN Panel ILS Panel Compass Panel... this may actually get some use in the sim due to the Nevada terrain for training, and Crimea region for combat being at different latitudes, provided magnetic errors are actually simulated in DCS. Oxygen panel, who knows if I'll ever use it, or if it's just for looks And now the more or less finished right console. I've also started modeling the center pedestal and instrument panel.

You should be able to display any view on the other 2 monitors, assuming DCS view configuration lets you specify the device. If it doesn't, I guess it wouldn't work. I can't recall DCS allowing for this, so it might not be an option. It's really something that should be supported by the engine, but maybe is not. Don't get me wrong, there would definitely be a performance hit compared to running one screen on one card. If you run 3 cards, each GPU is dedicated to rendering say 1600x1200 pixels for a total of 4800x1200. Compared to one card trying to provide 4800x1200, you should get better performance. So your CPU now becomes a clear bottleneck, having to send data to 3 cards instead of 1. You would benefit a great deal from a fast CPU in this case, but that's true either way.

This idea would never work trying to run and sync with 3 separate instances of the sim on different computers, not for DCS anyway. The problem is not necessarily with syncing aircraft control or positioning, although that would be a major challenge to overcome. The problem is with syncing the environment around you, meaning all AI units. I assume you'd want this solution to work for all facets of the game, not just flying around aimlessly but in combat as well. Unless you can spawn AI units, update their positions and other visual elements from Lua, you're going to have disparate environments on your 3 views and it will be useless. Your best bet is to buy a motherboard with 3 PCIe x16 slots, get 3 video cards, and hook up 1 or 2 monitors each. This is essentially 3 "computers" running different views. You would want a very powerful CPU in this machine though.

it's a work of art! amazing

sweinhart I plan to have a "send all" button somewhere in my pit that will tell my firmware to treat all inputs as changed on the next loop, thereby sending all control positions once. At the start of each mission, I will optionally press this button to sync the sim to physical switches. For air starts, I'll probably run my startup checklists prior to starting the mission to get most switches into their typical in-flight positions, and then I'll just press the "send all" button when the mission starts and go from there. I might also put a "quick start" button next to the "send all" button and a bunch of other useful sim commands. Luckily there are a bunch of blank panels available for this kind of stuff.

Lights Panel I thought this x-ray render of the pit looked pretty cool...

I've decided a 20x2 display might be better, looks like the real panel has 4 sets of 4 characters with space between them. A 20x2 would allow for those spaces.

D'oh! it's always the pcb behind the display that ruins things. 4.8" width is too big, doesn't look like this display will work after all. At first I thought the "display area" was the whole screen space, but now I see there is quite a bit of unused screen space around the edges not included in those dimensions, and overall width is 122mm which would extend far past the left side of the panel.

This is PERFECT! Way to go obotNapalm, rep from me. The size 3.25x0.75" is just about perfect for my cutout (3.25x0.8125), I don't think I'll even need to adjust the cutout size. I'm going to order one of these and start interfacing it with Arduino. Hopefully one of the existing libraries will already work with it.