Jump to content


  • Content Count

  • Joined

  • Last visited

About Loophole

  • Rank
  • Birthday 04/14/1961

Personal Information

  • Flight Simulators
    Falcon 4 Allied Force
    IL-2 Sturmovik 1946
    DCS World
    Wings of Prey
  • Location
  • Website
  1. So is there some magic trick to getting this to work? Because my kneeboard is still uselessly docked to the bottom-right, half off my main monitor, with no way to move or resize it. No clickable buttons or anything different?
  2. This is definitely a PITA. After reading the above (good) advice regarding deadzones, it still took me 10 minutes of fiddling to get the Grid mode to work. What I finally had to do was: 1. Add a small (2 unit) deadzone to the TDC slew axes in the DCS Axis Tune. 2. UNBIND my MouseX and MouseY from the TDC (even though I wasn't touching the mouse while selecting a grid) That did the trick - and I wasn't using the mouse anyway, but apparently it was generating inputs while sitting on the desk? Anyway, I think what would really help is for DCS to have a built-in "deadzone" behaviour wh
  3. Thank you for that information, @shagrat ; that should really go into the mission editor manual somewhere - or better still be displayable as a legend on the mission editor map.
  4. Might the issue also be affecting the catapault crews? My multiplayer group was running a dawn mission with the Supercarrier and was encountering similar issues with approach control as described here. However we were also finding the catapault crews became erratic, sometimes responding to players, and at other times ignoring them. Often it seemed they would respond only to one of the players on the deck, and ignore the others. The ATC also became erratic, sometimes completely ignoring players, or only responding to "ball" calls.
  5. With four GBU-31(V)2/B on board, I have the JDAM MSN page up on the left MFD, and locate my target (a runway) with the FLIR page on the right MFD and designate it. I drop the first JDAM, and instead of the FLIR remaining pointing at the target (as I would have expected), it reverts back to snowplow - losing the target completely and making multiple individual drops down the runway impractical. Is this a bug, or am I simply doing something wrong?
  6. mikemadmax20, I have a similar problem - the default Controls Indicator position is off-screen of my multi-monitor setup. To move the indicator position, I have to edit the ControlsIndicator_page.lua file in each aircraft's mod folder in the DCS installation - and the customisation has to be re-done after each update, as DCS replaces the edited files. The file is in a consistent location for each aircraft - mods\aircraft\[aircraft-name]\Cockpit\Scripts\ControlsIndicator. The file itself can differ a bit from aircraft to aircraft, but the required change seems to always be the same
  7. Thanks! I seem to recall I did try the "turn it off and on again" tactic and I think it did help. Maybe this is realistic for the Hornet TGP :-)
  8. I've been practising with the targeting pod a bit recently, but am encountering some weird and inconsistent behaviour; I can't figure out the pattern to it and I'm hoping some of you wise folks can set me straight... The targeting pod seems to have three modes; sometimes four; which you can switch between using the Sensor Control Switch. The modes are: OPR / ATRK - Area Track OPR / PTRK - Point Track (useful for moving targets) OPR - Neither ATRK or PTRK, but still ground-stabilised OPR - Neither ATRK or PTRK, and not ground-stabilised. Only happens sometimes? Most of the
  9. Because of the new way the MFD viewports are being handled, it seems to no longer be possible to redirect them to a custom viewport - they can only be displayed in "LEFT_MFCD" and "RIGHT_MFCD". This is a problem when you are flying multiple aircraft that use LEFT_MFCD and RIGHT_MFCD, but have displays that need to be in different locations or of different sizes. The most obvious culprit here is the Su-25T, which has a 4:3 aspect ratio RIGHT_MFCD. All of the previous non-FC3 aircraft could be configured to look for a custom aircraft-specific viewport, and fall back to using LEFT_MFCD an
  10. The EHSI is already coded to look for a viewport named "EHSI", so you just need to define one of that name in your MonitorConfig file. The DED and RWR can be exported, but you need to add the necessary lines to the DED_init.lua in Mods\aircraft\F-16C\Cockpit\Scripts\Displays\DED\indicator\, and to the RWR_ALR56_init.lua in Mods\aircraft\F-16C\Cockpit\Scripts\EWS\RWR\indicator\ The lines added are the normal ones; e.g. for the DED: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") update_screenspace_diplacement(1, true, 0) try_find_assigned_viewport(
  11. Thank you, Rik. If the programmers need anything tested on a "failing" system, just let me know - I'm happy to assist.
  12. Both the successful and the failing examples send an 85-byte block structured as per the above example. So: the data sent by the failing request looks to be basically correct; possibly it is compressing or encrypting incorrectly at the WebGui end due to some bug in the javascript, or incorrectly decompressing/decrypting at the Dedicated Server end due to a bug in the server logic.
  13. It looks like the data sent in the erroring request is a JSON structure containing two encrypted or compressed name-value pairs: e.g. {"ct":"0zO+husJE8oGJkvPRmrjixGE6o3XowL522XOJr8+mn8=","iv":"Q6J4kce9IeNLeB2DrcaViA=="}
  14. It could be an error in the javascript at the WebGui end - with it not formulating the data packed correctly for the second request, but sadly the javascript has been obfuscated, making debugging it client-side very difficult.
  15. FYI: "The HyperText Transfer Protocol (HTTP) 422 Unprocessable Entity response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions." Which I think is telling us that the issue is at the Dedicated Server end - it got the message, understood it, but could not process it. That might be related to the packet being smaller (107 bytes) than the successful example (171 bytes).
  • Create New...