Loophole

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.

Mate, I am *desperately* waiting for the next open beta! I want to get my hands on that FCR! I will also let you know how the power lever is behaving!

So, for the last few versions I have started to get an issue with the Power Levers when in the CPG cockpit: I have "Power: Both" bound to an analogue axis for AH-64D CP/G There is no other axis bound to that function for AH-64D CP/G There are no DirectX button binds for any of the Power Lever actions There are no axis binds or DirectX button binds for any of the Power Lever actions for AH-64D Pilot. The axis input shows as smooth and non-jittery under Tune Combo Axis, so I don't think there is any real noise. When the Power Lever axis is at 100%, the lever is stable and in the "Fly" position. If I position the Power Lever axis anywhere between 100% and 0%, the lever position in the cockpit jitters by maybe 10-20%, and always towards the FLY position from where I have the lever actually set. If I pull the Power Lever axis back to 0%, the Power Lever position jumps immediately up to the FLY position and stays there. It is acting as if some other binding is trying to push the lever to 100%, but as I said, there does not appear to be any other binding for that axis. Furthermore, if I remove the CPG binding, then go to the pilot position and re-bind the same axis in the same way for the pilot's Power Levers, they work fine and smoothly - the problem seems to be unique to the CPG position. I wonder if George-as-pilot might be trying to push the levers up to 100% when they shouldn't be allowed to? If while CPG I hand control over to George-as-pilot, he certainly does push the power levers back up to FLY immediately (but then I'd expect him to do that) My CPG axis bindings, just for reference...

It would be nice to see these issues resolved. A while ago I made a fun mission that involved tracking down and disabling a train, then landing troops to recover cargo from the undamaged carriages, but in the end had to shelve it because of the multiplayer issues with trains. (I tried switching the train for a truck convoy, but those idiots kept getting stuck on bridges or jamming on other AI vehicles).

The tooltip for the Improved Spotting Dot setting in the UI just says "$improvedSpottingDot_tooltip". That could probably be improved - maybe expanded to describe how the Improved Spotting Dot actually behaves? Thanks!

Oh yeah! As of DCS Open Beta 2.9.0.46801 George now trims the controls before handing them back to you! Hallelujah! It didn't make it into the release notes, but it did get fixed!

I recently spent some time learning the Mi-24, and guess what? Petrovich as pilot trims the controls before handing them back to you - so the Mi-24 works perfectly in that regard! So all that needs to be done for the Apache is exactly whatever was implemented for the Mi-24!