skypickle

I recently started the ARGO campaign and am enjoying it. Howevewr, half way through a mission, real life interrupted my adventure. I thought I would end the mission, save the track file and come back to it later. However, when I replayed the track file, the helo didnt take off. I could see the controls indicator move but the bird was grounded. This only happens in this campaign- is it a bug ?

I found out in another thread that you have to throttle down. Then it works no matter where you land in the open space surrounded by people.

I recently started the ARGO campaign and am enjoying it. Howevewr, half way through a mission, real life interrupted my adventure. I thought I would end the mission, save the track file and come back to it later. However, when I replayed the track file, the helo didnt take off. I could see the controls indicator move but the bird was grounded. This only happens in this campaign- is it a bug ?

Press ‘direct’ after you’ve selected wpt

The minute I readjust the Crosshair it loses lock. Lmc then has to be disengaged and reengaged. Is this a bug?

just some code. Although I know how to do simple things with an arduino, writing 'game controller code' must be different , right? First, did you use encoders or pots for your dials? How many did you get per teensy? Second , when you read the data from the pin for a particular dial, for example, what do you do with it? It's not like you are going to process the input and activate an output pin on the arduino. How do you assign that value to a variable which the pc will recognize as an axis? Maybe I could see a snippet of code? Finally, I can only find teensy 4.1, teensy 2 and teensy LC boards.

yep, had to throttle down. thanks.

yup, their code does not work with my monitor config. ED says: if v ~= nil then if v.width ~= total_w or v.height ~= total_h then ULX = v.x ULY = v.y SZX = v.width SZY = v.height local aspect = SZX/SZY -- Thanks Asto (https://forum.dcs.world/profile/127293-asto/) local control_pos_offset = {(ULX + SZX / 2 - total_w / 2) / total_w * total_aspect * 2, -(ULY + SZY / 2 - total_h / 2) / total_h * 2} weap_control_pos = {0.8 * aspect + control_pos_offset[1], -0.75 + control_pos_offset[2]} compass_pos = {-0.82 * aspect + control_pos_offset[1], -0.7 + control_pos_offset[2] * 2} -- Kudos to you (https://forum.dcs.world/topic/295236-george-interface-with-3-monitors/?do=findComment&comment=4922420) weap_control_size = weap_control_size * v.height / total_h compass_size = compass_size * v.height / total_h end end but for me this is needed: if v ~= nil then if v.width ~= total_w or v.height ~= total_h then ULX = v.x ULY = v.y SZX = v.width SZY = v.height local aspect = SZX/SZY local offsetX = (ULX + SZX / 2 - total_w / 2) / total_w * total_aspect * 2 local offsetY = -(ULY + SZY / 2 - total_h / 2) / total_h * 2 local padding = math.min(total_aspect, aspect) * 0.2 compass_pos = { -math.min(total_aspect, aspect) + offsetX + padding, -1 + offsetY * 2 + padding} weap_control_pos = { math.min(total_aspect, aspect) + offsetX - padding, -1 + offsetY * 2 + padding } compass_size = compass_size * v.height / total_h weap_control_size = weap_control_size * v.height / total_h end end

@Raisuli thank you for your explanation. I am about to fall into the diy controller rabbit hole and am pondering the different controller options: 1)Arduino 2)teensy 3)Adafruit feather. I like the fact that teensy plays nicely w usb but sourcing a teensy has become a problem as most places are low/out of stock due to the chip shortage. Do you use a teensy 2? 3.2? 4.1? Is your available for perusal so I can see what I am about to get myself into?

I guess icould use an encoder. With 12 digital inputs on an arduino. that would only give me 6 encoders per arduino. Then i could use the 6 analog inputs with potetiometers which gives me another 6 dial controls. But I am confused about how to talk to the pc and make the arduino look like a HID. This video makes it look complicated. https://www.youtube.com/watch?v=RoG_-9lAnSI This suggests that an arduino is a serial device and to make appear as a usb device requires extra work https://learn.sparkfun.com/tutorials/usb-serial-driver-quick-install-/all Obviously you have many arduinos talking to your pc and they are appearring as usb peripherals. What does your arduino code look like?

@Karon I am just starting down the diy controller rabbit hole. I would like to start with something simple-a box with 12 dials for all the analog things like lights in the aircraft I fly. It seems the arduino leonardo can do this. Why did you choose it over a teensy? From what I have read, you cant have more than 1 leonardo per pc due to usb id limitations. But it seems you have a bunch of them all working at once. Also, where did you get your pots, knobs, etc.? Your setup is not only impressive in scope but also in imagination.

I saw the post about landing next to the Apaches. I tried all the orientations and distances from the Apaches.. I also tried landing real close to the C130 and at all 4 quadrants. But the only thing that worked was landing ON the C130 Although I got the message for the Greeks to board the chopper, I also failed the mission for damaging the aircraft (even tho I landed like a butterfly)

same here. Where do I have to park? I tried all around the c130 and the Greeks wont get out of the plane.

what do you folks like for potentiometers? With the numerous dials and sliders in an aircraftfor lights, I need to build something. Since radio shack closed, I have no easy access to hardware and have to order online. What electrical specifications are required? Which pots have the smoothest and damped feel?

I just noticed you use the variables, padding and offsetX , but I neglected to add them because I was focussed on the ' highliughted lines' I saw early in this thread. When I included the entire fix in your post from Friday at 9:47, it works. Please forgive my sloppiness. This is what I now see

This solution does not work with the following monitor config: monitor config --4096 x 3240 4096 screen with a 1920 screen below it _ = function(p) return p; end; name = _('Camera + 2 MFCDsLG'); Description = '2 MFCDs on the bottom and camera on the top' Viewports = { Center = { x = 0; y = 0; width = 4096; height = 2160; viewDx = 0; viewDy = 0; aspect = 4096 / 2160; } } LEFT_MFCD = { x = 20; y = 2160 + 240; width = 810; height = 810; } RIGHT_MFCD = { x = 1080; y = 2160 + 240; width = 810; height = 810; } GUI = { x = 0; y = 0; width = 4096; height = 2160; } UIMainView = GUI GU_MAIN_VIEWPORT = Viewports.Center The 'george' window is offscreen somewhere. Please note that monitor one which is off to the left is for browsing pdf files , websites and other flight instructions, etc while in DCS which plays on monitor 2 The MFDs properly render A10 MFDs.

When all monitors are lined up, the location (0,0) is at the top left. So for example in this array monitor 1: 3840 x 1600 monitor 2: 4096 x 2160 monitor 3: 1920 x 1080 So to use monitor 2 as the DCS game window I specify monitor config to be _ = function(p) return p; end; name = _('Camera + 2 MFCDsLG-Hh'); Description = '2 MFCDs on the bottom and camera on the top' Viewports = { Center = { x = 3840; y = 0; width = 4096; height = 2160; viewDx = 0; viewDy = 0; aspect = 4096 / 2160; } } LEFT_MFCD = { x = 3840 + 4096+20; y = 1080 + 240; width = 810; height = 810; } RIGHT_MFCD = { x = 3840 + 4096 + 1080; y = 1080 + 240; width = 810; height = 810; } GUI = { x = 3840; y = 0; width = 4096; height = 2160; } UIMainView = GUI GU_MAIN_VIEWPORT = Viewports.Center but this gives me the weird result on monitor 2:And when DCS is in focus, monitor 1 is black - I cannot read any browser I might have pulled up there. However when I specify this display config: I can start counting my monitor config from the top left of monitor 2 and this config file: _ = function(p) return p; end; name = _('Camera + 2 MFCDsLG'); Description = '2 MFCDs on the bottom and camera on the top' Viewports = { Center = { x = 0; y = 0; width = 4096; height = 2160; viewDx = 0; viewDy = 0; aspect = 4096 / 2160; } } LEFT_MFCD = { x = 20; y = 2160 + 240; width = 810; height = 810; } RIGHT_MFCD = { x = 1080; y = 2160 + 240; width = 810; height = 810; } GUI = { x = 0; y = 0; width = 4096; height = 2160; } UIMainView = GUI GU_MAIN_VIEWPORT = Viewports.Center I get the main DCS game window on monitor 2 and the MFDs on monitor 3. The number of pixels rendered in this arrangement is 4096 x 3420=14,008,320 So it seems DCS sets (0,0) to the corner of the largest monitor. I realize I could shift monitor 3 all the way to the right in the display settings then I could make a monitor config with fewer total pixels for 2 and 3. (4096 +1920 x 2160 = 12,994,560) But that would confound me having to move my mouse to the right to get to monitor 1 when it is physically located to the left.

@Jayhawk1971 you mean to tell me casmo made two videos about acquisition sources?

i think i understand now why there is even the architecture of sight and acq. Because there are two people in the aircraft. Each person has his own eyepiece,and his own MFDs. Each person also has access to weapons. However there is only one pnvis and one TADS. So the first generation of this system probably was a way for the either the pilot or cpg to share these devices which became labeled acquisition sources. Because each person has his own eyepiece, his own the ability to store his own 'mark points' , and use his own MFDs, a way was needed to give that person a label for the function that could serve this info yet be able to couple to a location on the ground derived from either the TADS(which is shared) or his stored mark points or just use the location of his head. Somewhere in the evolution of this system, someone imagined that using the location of the person's gaze (as measured by his head position) could also be a useful piece of information. So head position was added to TADS as an 'acquisition source'. FCR will provide yet another way to get ground location data. Linked battle space data will be another acquisition source ( I think this was added to the AH-64E) In summary I would define an acquisition source as any gizmo that provides ground location data. I would define 'sight' as any gizmo that passes that info to the pilot and the weapon he has selected. So a sight would be the eyepiece thingy with its weapons interface or an MFD showing the TSD or the TEDAC.

I thank you all for the chorus of help.

Casmo's video: I am probably wrong but have labeled some of the parts. Could someone confirm my identification of parts?

@AvroLanc thank for trying to explain what seems to be a confusing topic. Most of the videos use these words differently. You stated: "If you removed the ACQ SOURCE concept from the whole helicopter, you could still go out and shoot up targets all day long with your 3 SIGHTS (HMD/TADS/FCR), just like the Hind or a fancy Huey. BUT….it’ll be much harder to know where to look, and more time consuming and extra effort to search and point with those 3 SIGHTS. " Typically, in the A10, the sights we use have 'their own 'brains'. The TGP can 'remember what it locked on to. And it can be locked onto what it sees or the current waypoint. The maverick can remember what it locked on to independently. The TAD can show me the SPI as well as data from the link and all the other aircraft in my net. The HMCS can show me the TGP video, where the TGP is looking, the SPI, as well as data from the link from other aircraft. I can point my weapon to a SPI generated with TADS , HMCS, TGP Your comment: 'the confusion is that a SIGHT can also be an ACQ source. ' is right on. Perhaps I need to make a list of three columns: 1st column - display device ( and how it is selected). These are the articulated borg-like thing on the pilot's helmet next to the eyeball, the same thing that is in front of the CPG eyeball, the TEDAC, the MFDs 2nd column - sight (and how it is selected and manipulated - moved, zoomed, to which acquisition sources can it be 'slaved' to extract position data), The sights I can use are an MFD showing the TSD, an MFD showing video, the TEDAC. 3rd column - acquisition source (and how it is moved, zoomed as well as where its data can be saved). Pushing the ACQ button on the MFD gives me a list of acquisition sources When I do this, then I start to see many combinations that can exist but dont make sense Conceivably I could make a chain like this pilot eyeball-> pilot'shelmet sight ->gunner sight -> TADS.. So what's the acquisition source in that example? or CPG eyeball -> CPG helmet sight -> Pilot helmet sight -> TADS -> waypoint? add PNVIS, FCR in there and the soup gets murkier. And where does the TEDAC fit in? is it just a display or does it have it's own sighting system? Somewhere I read that the TEDAC has its own computer and sighting with the TEDAC is better than with the helmet. @PlainSight when you press 'slave' what are you slaving to?always the acquisition source? If that's the case, what are you slaving to the acquisition source- the display next to your eyeball, the TEDAC, the PNVIS, the video on the MFD? How do you pick 1)what you are slaving and 2)what you are slaving it to

I watched this and read the manual. Initially I thought an acquisition source was the gadget used to find the target. But then I read in the The manual, 'the cued line of sight reticle indicates the location of the selected acquisition source'. So an acquisition source is a location? Why dont they just say target? I know there are different ways to get the location of the target-for example, it could be the TADS, it could be the cursor (CAQ button), it could be fixed, it could be the pilot's helmet sight (if you are the CPG), it could be the gunner's helmet sight (if you are the pilot) or it could the cryptic tech labeled '7skr' or '?00'. So that's why I thought the acquisition source was the gadget identifying the target. But the confusion arises because they say the acquisition source can be the pilot's or CPG's sight. So is an acquisition source really just a sight? And when I used the sight select switch (HMD,TADS, FCR) am I not just designating which tool I am using to identify the target? Can someone clearly and simply explain why there is an 'extra layer' in between me and the target? Why isn't the sight select switch enough? In the A10 we have SOI (which is the tech used to 'sight' the target) and SPI (the actual target in the sight). If the acquisition source is like a SPI, then it should be a location (as the quote I pulled from the manual indicates). But then why should there be a button on the MFD that allows me to set the acquisition source to a tool ( a sight) when it is a location?

@Avenger31 Unfortunately I do not have the F16. But if I fly the huey first, it makes no difference. even with this line added to the lua file (just before the KA-50 statement) like so: elseif obj.Name == "AH-64D_BLK_II" then dataTable.name = "UH-1H" elseif obj.Name == "Ka-50" then or this line: elseif obj.Name == "AH-64D_BLK_II" then dataTable.rpm = string.format("%.2f", 5000) I get this error on quitting DCS.

After shutdown, despite turning off battery and APU, MFDs reain on. Also note throttle settings do not zero.