Loophole

The aircraft are Blue coalition, but dynamic spawn - which means the precise country can sometimes be a bit odd (I think DCS just picks the lowest-numbered country in the coalition?). However, the mission we are using is "Raiders_696CW_Sinai_Foothold_Updated_20250629", and checking in the mission editor: it has just "Combined Joint Task Force Blue" as the only 'country' in Blue coalition. "Unrestricted SatNav" is set "on" but not enforced by the mission. My game settings have "Unrestricted SatNav" set "on", and "use my settings" enabled. If I set up the same situation on Caucus map, the jet starts with POS/INS and an IFA countdown showing in the HSI, but within 20 seconds or so it switches to display POS/AINS - presumably simulating picking up satellites. I get the same behaviour with a similar new mission set on Sinai - so it doesn't seem to be map-related, but something odd in that specific mission. That being the case, I don't think the GPS issue is related to this thread, and probably not resolvable unless I can make a mission that re-creates the issue on demand. The other weird behaviour might similarly be mission-specific; will have to investigate further.

I'm not sure if this is a related issue, but it does exhibit as an FPM-offset in the HUD: I'm flying a multiplayer mission on the Sinai map, using dynamic-spawn slots, and the F/A-18 nav system keeps failing in unusual ways (system failures are not enabled in the mission!). Characteristics are: - Typically fails after 1-2 sorties in same aircraft - FPM offset completely off the HUD (pinned to the edge, flashing) regardless of heading. - TGP position drifts even when ground stabilised. - HSI shows incorrect position for A/C - HSI -> DATA -> A/C page shows position constantly drifting while parked on the ground - POS/AINS not available when IFA selected, even though date set to 2022 - Doing a full GND INS align stops the HSI -> DATA -> A/C page drift, but position shown is still incorrect (out by 1-2 degrees N & E). - Only solution seems to be to get a new aircraft. - (No mods installed). Sadly I have not been able to identify a simple reproduction for this, but I typically encounter this every couple of hours of flying in the mission If this is unrelated, then please ignore and I'll try and gather enough information to log this as a separate issue, as its being very persistent and really started degrading my F/A-18 experience at the moment!

I'm encountering this in a Sinai-map mission; set in 2022, but no POS/AINS; only POS/INS. Also encountering many INS and nav-system issues in the mission, with the F/A-18, but they might be unrelated.

I agree with this. I fly the Apache a lot, but always from the front seat. George is currently little better than a glorified autopilot for me; I would really like to be able to rely on him to try and save our bacon when coming under fire. Maybe with a press-and-hold keybind to "maintain course" to suppress his evasive behaviours when you *really* want to get that shot away See also these posts on the same topic:

I agree with this. I fly the Apache a lot, but always from the front seat. George is currently little better than a glorified autopilot for me; I would really like to be able to rely on him to try and save our bacon when coming under fire. Maybe with a press-and-hold keybind to "maintain course" to suppress his evasive behaviours when you *really* want to get that shot away See also these posts on the same topic:

For me the binding was RCTRL+RSHIFT+K, not RAlt.

I was having problems with GBU-24 loadouts on my F/A-18, and tracked the issue down to a misunderstanding of what the "Copy to all of same type of weapon" button does on the Fuse Settings panel in the Loadout screen. Note: You only get this button when changing fuse settings for a laser-guided bomb. My assumption was that the button applied ALL of the weapon settings on that panel to all of the other weapons of that type. Turns out it does not - it only applied the laser code, not - for example - the fuse choice. As a result I ended up with multiple fuse types, which the F/A-18 stores system doesn't like (displays ADV-LOAD on the MFD, and bombs won't drop). I can suggest two possible changes that could improve this: Change the button text to be a bit more explicit; E.g. "Same code for all this weapon type". Change the button function to apply all settings (which would then make it a useful button to have on all the fusing panels)

I agree, its a very nice tool. I think a neat enhancement down the track would be dynamic sharing of routes. I'm imagining somebody playing in - say - a ground commander slot being able to sketch out a flightplan, save it as e.g. "ALPHA-01", then be able to tell a pair of players "load flightplan ALPHA-01". I imagine that to achieve this there would need to be some sort of special pool of flight plans that are saved on the server rather than privately on each client. They'd need to be coalition-specific too.

Please please please tell me more about Dynamic Slots! How will they work? What will they do? What colour will they be? Mission developers the world over need answers, to bring them hope!

Power Lever jittering for the CPG still occurs in the current version: 2.9.5.55918

Same for me. update_screenspace_diplacement is the right name for the method - if you do a search of all the Lua scripts in DCS you'll find its defined in ViewportHandling.lua with that misspelled name. I found that putting in the call with corrected spelling resulted in no export at all for me - I'm assuming the scripts fail because they can't find the method. I didn't test your full process, though; I only tested putting the call into the "initxxx" lua's. Oddly, early on in my testing the "TV on the HUD" thing happened to me, but in all my subsequent tests it hasn't happened again; just the full-screen grid, even with TV up on the DSCG. One thing I did notice is that the grid itself (but not the horizon line) is a texture, not drawn lines - which in itself makes no difference, but does explain how it come to exist when the draw_grid and draw_ppi_grid methods in radar_page.lua never get called by anyone. I've put a post about this in the Bugs sub-forum, so hopefully Heatblur will notice and put it on their to-do list, if it isn't there already.

I think the method name you meant to use is update_screenspace_diplacement - with the typo in the name?

I've *almost* been able to get the DSCG export working. I can get the radar and the Maverick TV display to export to a viewport, but when I do that I *also* get the radar grid-lines (only) displayed full-screen across my entire view! Have not found why that is or how to stop it happening, which is frustrating because otherwise the export works really nicely! What I did was add the lines: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("F4E_DSCG", "RIGHT_MFCD") at the end of the two files: F-4E\Cockpit\Scripts\DSCG\indicator\init.lua F-4E\Cockpit\Scripts\DSCG\Indicator\DSCG_Pilot\init_bake.lua ("F4E_DSCG" being my custom viewport defined in monitorconfig, of course) It would be really nice if this could be enabled!

I've *almost* been able to get the DSCG export working. I can get the radar and the Maverick TV display to export to a viewport, but when I do that I *also* get the radar grid-lines (only) displayed full-screen across my entire view! Have not found why that is or how to stop it happening, which is annoying because otherwise the export works really nicely! What I did was add the lines: dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("F4E_DSCG", "RIGHT_MFCD") at the end of the two files: F-4E\Cockpit\Scripts\DSCG\indicator\ init.lua F-4E\Cockpit\Scripts\DSCG\Indicator\DSCG_Pilot\init_bake.lua ("F4E_DSCG" being my custom viewport defined in monitorconfig, of course)

The "Toggle Body" binding works fine, but the "Hide" binding shows, and the "Show" binding hides.

Ok, had to go and watch a darned YouTube video to discover the secret - Press & hold the Jester UI button for a long press. Was that mentioned in the manual somewhere?

I cannot figure out how to get rid of the radial menu. I've tried all the keybinds I can think of, but nothing seems to work. Please; what am I missing?

Just as an FYI to anyone (like me) coming upon this topic at a later date - I was struggling with the same problem, but it wasn't the "auto handover" setting that was causing the issue; I was using the Instant Action "Runway Start" mission as a place to get my keybinds in order; that has "simplified AI" set in the mission parameters, and that also seems to prevent use of the CPG sight.

I have to say I was also a little confused as to what I now had installed, as the folder is still named DCS Open Beta. After reading through some of the other threads I gather that it doesn't matter whether you are Open Beta or Stable; both update to the same version, and in the future they will do something about standardising the folder name. (but right now we can just carry on with whatever "branch" we were on, as they are both the same.

Bug is still present in Feb 2024 - encountered while trying to STORE a target selected using the TADS from about 4km away. The stored position was consistently several hundred meters west of the targeted spot (ownship heading roughly 180 at the time). This is in the latest Open Beta build at the time.

I couldn't find any other mention of the issue; my apologies if this is a re-post! I have noticed that the IAT function of the TADS - similar to many other optical targeting systems implemented in DCS, will only lock on to a live vehicle target. If the target is dead, it will no longer lock on (providing a cheaty way to determine if that dark blob is a live target or not). It also won't lock on to an arbitrary spot, even if that spot provides a nice contrast-y image (e.g. a house or a parked vehicle that is just a map object). Presumably this is all a limitation of the implementation; its simply checking if the TADS LOS is looking at a live unit in the unit list, not actually analysing the image. Simulating IAT "properly" would clearly be impractical, but given the effort put into so many other details in the sim it seems like perhaps some more work needs to be done on this mechanism, to bring it a bit closer to realistic behaviour? I'm thinking: - Lock on to vehicles regardless of whether they are alive or dead. - Lock on to any map object. - Lock on to arbitrary locations on the ground. If you wanted to get really clever you could do a quick & dirty analysis of the image rendered on the TADS (or other sight - I imagine this logic could eventually be ported to all optical sensor systems) to see if it has enough contrast to plausibly allow image tracking, but the cost-benefit of doing that is probably not worth it.

The recent patch notes mentioned "FLIR. Moon looks more natural in FLIR devices.". While the moon's surface does indeed look awesome when closely examined in the AH-64D TADS, somebody seems to have put it in a box! See the attached image: It looks fine in normal TV mode, so I'm guessing its the new thermal texture isn't quite right?

Ok, I re-did the test using my "normal" DCS configuration rather than the windowed setup I use for mission editing. I just used my standard control bindings in this case, as the previous test that I videoed seems to have eliminated "other bindings" as a potential source of the issue. This time the TRK file saved just fine - see attached. Let me know if there are any other tests or data you would like from me. POWERLEVER.trk When I replayed the Trk file it clearly reproduced the "jittering" I am seeing.

I've captured a video showing both the physical actuation of the control, and the in-game response. For this I used a windowed copy of DCS, and explicitly cleared ALL bindings for all my HOTAS devices, then only bound the one axis to Power Lever (both); initially for just CPG, and then after confirming the issue still replicated I also bound it for the Pilot then captured this video. I was using the standard Instant-Action "Ready for Takeoff" mission, and running the Multi-Threaded open beta. I was not able to save a TRK file of the mission - when I tried to save it at the end it reported an error that it couldn't read the LastMission.trk file, and after checking in the reported folder I confirmed that the file did not exist - don't know what was going on there. I thought I would upload the video for you first, before trying to re-capture a TRK file. It will be interesting to see if a TRK captures the control jittering. Video file is here: https://www.dropbox.com/s/4ih0qyv3avuz7ru/VID_20231221_152649.mp4?dl=1 I forgot to attach the Config files I used in the above test, just in case they are relevant. Here they are... Input.zip

@Lord Vader, thank you for releasing the new open beta a day earlier than expected. You didn't need to do it just because I asked, but I appreciate it! Sadly, the Power Lever issue seems to still be evident in the new open beta. George has also developed some piloting issues, but I'll start a new thread for that if nobody else has mentioned it yet.