lesthegrngo

https://grabcad.com/library/a10c-knobs-for-dcs-world-based-cockpits-1 https://grabcad.com/library/a10c-knobs-solidworks-files-1 https://grabcad.com/library/a10c-knobs-2 Les

https://grabcad.com/library/miscellaneous-3d-files-for-a10c-cockpit-parts-for-dcs-world-1 Les

https://grabcad.com/library/virpil-mongoos-t-50-cm2-base-1

Right, that makes sense - I see the individual .lua files for the different input devices Thanks again Les

Yep, all good now. I used the line {down = device_commands.Button_9, up = device_commands.Button_9,cockpit_device_id = devices.AHCP, value_down = 1.0, value_up = 0.0, name = _('JTRS switch Toggle'), category = _('Armament HUD Control Panel')} and after I remembered to put a comma at the end it works perfectly Now, one thing that I couldn't understand was that I deleted the original callout line for the JTRS, but it still displays in the controls option. I'm not worried as you simply ignore it, but why does it still show? Cheers

Got it, thanks - let me give it a go, the good thing was I that was able to at least grasp the concept Cheers Les

Yes please, I was looking through the 'How to Edit Control Bindings Files' to see if I could do it, but am currently trying to work out where to find the 'cockpit_device_id' pertaining to the (as you correctly point out) the JTRS I would like to learn how to modify the files as well, because although I do heavily use DCS Bios, I also have a number of Bodnar boards as I think that they are better for switches ***EDIT*** from the clickabledata.lua file I believe it to be 'device = devices.AHCP, action = {device_commands.Button_9,device_commands.Button_9}' so I think would be written as {down = device_commands.Button_9, cockpit_device_id = devices.AHCP, value_down = 1.0, name = _('JTRS switch ON/OFF'), category = _('AHCP')} Have I got that right? Thanks for the help Les

Hi all, looking for some guidance here to set this up. On my A10C armament panel there are a number of two and three position switches. I have managed to make all the three position switches work fine, other than start synchronisation - more later. For the three position toggle switches the switch logic I am using is as follows as an example GUN/PAC Arm JOY_BYN20 (so button 20 energised) GUN/PAC Train JOY_BTN_20_OFF JOY_BTN_22_OFF (no button energised) GUN/PAC Gunpac Arm JOY_BTN_22 (button 22 energised) Works fine, except if the switch is in the incorrect position at startup I have to move the switch to get it to register and synch However when it comes to the two position switches, I can get them to work like this JSTRS On/Off JOY_BTN_34 JOY_BTN_34_OFF. That works great, as long as the toggle switch is in the correct position when you start the game. Despite only one position being energised, if the game starts with the toggle switch in the wrong position, the switch logic becomes reversed. Now, I can make it all work by presetting the switches in the correct positions before start, but that seems to defeat the object. If I just use either JOY_BTN_34 or JOY_BTH_34_OFF, in game each time you throw the switch it will only move the switch once every two throws, ie either when the switch is energised, or when de-energised. So am I using it correctly? The object is to only have to use one button for a two position switch, which in Racing sim games for H pattern gears and things is acheived by checking a ;hold button for gear' box, that means when no button is pressed it defaults to a 'neutral' or zero state Cheers Les

I know that this is essentially finished, but I'm always spotting little bits that I'm not 100% happy with. It would need either improvement or a complete replacement, with some that would require a lot of work, and others that are not so much. Today it was the turn of the armament panel, one of the easier ones. I've modified the switches for better feel, plus added painted 3D printed covers to the relevant ones to match the ones in game. Additionally, rather than use a nano to drive them, I'm using some spare bodnar board pins I need to replace the M2 allen head bolts with countersunk ones to neaten it up ***Edit*** The GUN/PAC has two ARM settings..... Doh! Off to redo the fascia Cheers Les

I'm not sure if there is a list, but from what I understand from the A10C stuff I had to do recently, you can try and make the devices you want in the following way. You need to go do DCS (or DCS Openbeta) > Mods > aircraft > (aircraft type, in my case A-10C) > Scripts > (devicename, in this case CMSC) > indicator The CMSC_init.lua file needs this adding (if it is not already there) for example, making sure you include the callout in the .lua code you will use, in this case "CMSC_SCREEN" dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("A_10C_CMSC_SCREEN", "CMSC_SCREEN") You can then add code like this to your .lua file (mine are in DCS > Config > MonitorSetup CMSC_SCREEN = { x = 3700; y = 100; width = 199; height = 57; } Obviously the actual numbers you use will depend on the screen setup you have. Cheers Les

Try this, this is just for Takeoff, Cold & Dark to follow Les DCS A10C takeoff switch positions.rtf

Nothing? OK, I'll be back after a couple of boring hours! Not sure the best way to list it though, so will get the switch positions first then work out the best way Les

Great, thanks for this! I'm one of those people who need to see a working example of things to help get my head around where everything fits together, so this helps a load. Cheers Les

Thanks Can you give an example sketch for a switch just to show the full syntax? I know it would help me see how it all fits together Cheers Les

All, I'm looking into the switch polling as a separate issue, but one thing that struck me was that I don't know the switch position configuration that should be set prior to starting a 'flight', for example when you go to instant action > cold and dark. Is there a list that shows what positions the switches (or at least the important ones) should be in for the various start configurations? I can start DCS and go through and log each switch position manually without connecting my hardware but I'm hoping that this is already done to save me a boring hour or so! Cheers Les

Just got back from business travel so my mind is a bit slow - the "1" in the code below is the pin selection? I read the SendDcsBiosMessage ("CDU_V", "1"); // This tells DCS that CDU button V has been pressed. SendDcsBiosMessage ("CDU_V", "0"); // This tells DCS that CDU button V has been released. where "1" meant switch on and "0" was switch off in a digital sense, so I think I was confusing myself Les

Would you need a #define pin x statement? Les

All, I followed Maciekish's instructions and inserted the following code into my Mega Warning Light Panel sketch #define DCSBIOS_DEFER_RS485_PROCESSING #define DCSBIOS_INCOMING_DATA_BUFFER_SIZE 512 This was in front of the #include <DcsBios.h> callout I can report that the sketch now works correctly using RS485, where previously it would only display half the panel at any one time. I had a minor issue with another sketch using this but I think that it is probably more something particular to my setup rather than a problem with Maciekish's code So, if you are experiencing issues with an RS485 sketch stuttering or slowing down, this looks like it is worth a try Cheers Les

All, just a note, you need to check the individual instruments in your installation of DCS or DCS Openbeta to make sure that the respective init.lua files are appended with the correct lines to make sue it works - my installation of DCS Openbeta did not have them so I had to copy them across You need to go do DCS (or DCS Openbeta) > Mods > aircraft > (aircraft type, in my case A-10C) > Scripts > (devicename, in this case CMSC) > indicator The CMSC_init.lua file needs this adding for example, making sure you include the callout in the code above, in this case "CMSC_SCREEN" dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("A_10C_CMSC_SCREEN", "CMSC_SCREEN") Sorry for not making a note of that before Les

As you are only pressing one button, therefore it is not having to process tons of information at the same time, I am pretty confident it should be OK - I am certain that Vinc or No1SonUK can confirm Les

Do you mean you are worried about my method giving delays? If so no need to worry as it is instantaneous, only one or two buttons ever get pressed at once another way to deal with it is to use a Bodnar BBI-64 , I used it before changing to the Mega version (for packaging reasons) and it is a really good solution as long as you are ok with all the spaghetti cheers Les

Ok, I have the solution. Unfortunately everyone will have to tailor it to their own monitor setup, but as long as you follow the monitor setup guides that you can find on these forums you should be OK. I recommend using Notepad++ for this Please note that I have had to change the device callouts from previous posts discussing viewports as it seems a lot of them have changed over time. The ones in the code below are all working on my PC today, so I know that they are correct as of writing this. Getting the naming right is important otherwise while the .lua file will be accepted by DCS, it won't show the device. Once you have your monitor setup .lua file defined that suits your particular arrangement, call it HUD_View.lua. In the .lua file remember to change the part where it shows you what the file will be called in the DCS > system > monitors drop down menu. name = _('HUD_View'); You then need to copy and paste the code below into the .lua file below the callouts for the Center, Left MFCD and Right MFCD. Please note that syntax is very important, if you get it wrong, or miss a semi-colon, equals sign or other symbol, the .lua file will not appear in the monitors drop down menu, it is extremely sensitive to this. If your new .lua file does not appear in the monitors list, go through it and try and find the missing or incorrect symbol! A10C_RWR = { x = 3593; y = -41; width = 550; height = 550; } ED_A10C_CDU = { x = 3600; y = 1024; width = 800; height = 500; } UHF_REPEATER = { x = 3650; y = 350; width = 40; height = 40; } A_10C_DIGIT_CLOCK = { x = 3650; y = 250; width = 105; height = 105; } CMSC_SCREEN = { x = 3700; y = 100; width = 199; height = 57; } A_10C_UHF_PRESET_CHANNEL = { x = 3700; y = 200; width = 199; height = 57; } CMSP_SCREEN = { x = 3700; y = 300; width = 199; height = 57; } UHF_FREQUENCY_STATUS = { x = 3700; y = 300; width = 199; height = 57; } Obviously the x, y, width and height numbers will not match your setup - but I believe that they don't have to, unless you want to be able to see them on one of your screens. It seems that the PC will 'display' them even in a position that is not within the limits of your monitors, and to do so will require the DCS program to output the data, which is what we want. Now when you go to the HUD view, those devices are being supported by a data output even if you can't see them, but DCS Bios can now get that data to use for the displays and so forth that you have made. Most of the above are self explanatory, but please note that unless your UHF radio frequency is set to display the repeater output, you will need the UHF_FREQUENCY_STATUS displayed. At the bottom of the .lua file should be the following code UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center I hope that this is easy enough to understand, and that it works for you! Les

I have my CDU set up exactly like that, with a PCB that connects directly to a Mega on the back of it. Here's my code (for the RS485 version) //#define DCSBIOS_DEFAULT_SERIAL #define DCSBIOS_RS485_SLAVE 74 #define TXENABLE_PIN 2 #include <Wire.h> //#define DCSBIOS_IRQ_SERIAL #include <DcsBios.h> DcsBios::Switch2Pos cdu0("CDU_0", 36); DcsBios::Switch2Pos cdu1("CDU_1", 6); DcsBios::Switch2Pos cdu2("CDU_2", 13); DcsBios::Switch2Pos cdu3("CDU_3", 12); DcsBios::Switch2Pos cdu4("CDU_4", 17); DcsBios::Switch2Pos cdu5("CDU_5", 16); DcsBios::Switch2Pos cdu6("CDU_6", 14); DcsBios::Switch2Pos cdu7("CDU_7", 38); DcsBios::Switch2Pos cdu8("CDU_8", 48); DcsBios::Switch2Pos cdu9("CDU_9", 50); DcsBios::Switch2Pos cduA("CDU_A", 10); DcsBios::Switch2Pos cduB("CDU_B", 8); DcsBios::Switch2Pos cduBck("CDU_BCK", 55); DcsBios::Switch3Pos cduBrt("CDU_BRT", 33, 31); DcsBios::Switch2Pos cduC("CDU_C", 4); DcsBios::Switch2Pos cduClr("CDU_CLR", 62); DcsBios::Switch2Pos cduD("CDU_D", 18); DcsBios::Switch3Pos cduData("CDU_DATA", 69, 52); DcsBios::Switch2Pos cduE("CDU_E", 19); DcsBios::Switch2Pos cduF("CDU_F", 20); DcsBios::Switch2Pos cduFa("CDU_FA", 65); DcsBios::Switch2Pos cduFpm("CDU_FPM", 37); DcsBios::Switch2Pos cduG("CDU_G", 11); DcsBios::Switch2Pos cduH("CDU_H", 7); DcsBios::Switch2Pos cduI("CDU_I", 3); DcsBios::Switch2Pos cduJ("CDU_J", 24); DcsBios::Switch2Pos cduK("CDU_K", 26); DcsBios::Switch2Pos cduL("CDU_L", 30); DcsBios::Switch2Pos cduLsk3l("CDU_LSK_3L", 49); DcsBios::Switch2Pos cduLsk3r("CDU_LSK_3R", 29); DcsBios::Switch2Pos cduLsk5l("CDU_LSK_5L", 51); DcsBios::Switch2Pos cduLsk5r("CDU_LSK_5R", 25); DcsBios::Switch2Pos cduLsk7l("CDU_LSK_7L", 47); DcsBios::Switch2Pos cduLsk7r("CDU_LSK_7R", 27); DcsBios::Switch2Pos cduLsk9l("CDU_LSK_9L", 53); DcsBios::Switch2Pos cduLsk9r("CDU_LSK_9R", 23); DcsBios::Switch2Pos cduM("CDU_M", 15); DcsBios::Switch2Pos cduMk("CDU_MK", 44); DcsBios::Switch2Pos cduN("CDU_N", 9); //DcsBios::Switch2Pos cduNa1("CDU_NA1", 56); //DcsBios::Switch2Pos cduNa2("CDU_NA2", 57); DcsBios::Switch2Pos cduNav("CDU_NAV", 43); DcsBios::Switch2Pos cduO("CDU_O", 5); DcsBios::Switch2Pos cduOset("CDU_OSET", 39); DcsBios::Switch2Pos cduP("CDU_P", 22); DcsBios::Switch3Pos cduPg("CDU_PG", 42, 40); DcsBios::Switch2Pos cduPoint("CDU_POINT", 32); DcsBios::Switch2Pos cduPrev("CDU_PREV", 35); DcsBios::Switch2Pos cduQ("CDU_Q", 61); DcsBios::Switch2Pos cduR("CDU_R", 28); DcsBios::Switch2Pos cduS("CDU_S", 46); DcsBios::Switch3Pos cduScroll("CDU_SCROLL", 56, 57); DcsBios::Switch2Pos cduSlash("CDU_SLASH", 34); DcsBios::Switch2Pos cduSpc("CDU_SPC", 59); DcsBios::Switch2Pos cduSys("CDU_SYS", 45); DcsBios::Switch2Pos cduT("CDU_T", 58); DcsBios::Switch2Pos cduU("CDU_U", 60); DcsBios::Switch2Pos cduV("CDU_V", 67); DcsBios::Switch2Pos cduW("CDU_W", 66); DcsBios::Switch2Pos cduWp("CDU_WP", 41); DcsBios::Switch2Pos cduX("CDU_X", 63); DcsBios::Switch2Pos cduY("CDU_Y", 64); DcsBios::Switch2Pos cduZ("CDU_Z", 68); void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } As you can see, apart from the rocker type switches, each individual button is allocated a pin number. You just have to modify that for your array Cheers Les

Yes, I'd seen that too, but was unable to recall where. So the CMSC and CMSP are also affected. It looks like we have some work to do on viewports for all of us who have home cockpits. I'll start researching Les

for info I tried using Helios for the digital clock and UHF radio, I used one of Capt Zeen's predone profiles to make sure I didn't make any errors. It didn't work So, we need to have a workaround. I'm wondering if the cockpit view modified to put the camera viewpoint in front of the HUD would work, as the cockpit would be there just not shown I'll be disappointed if after all the work I have done to replicate the devices would be wasted because there is no output to them...... Les