Loophole

I'm so glad you reported this. I thought I was going mad - I could have sworn I had been able to set the background colour, but I went in to do it today and couldn't find the setting. So glad its not creeping dementia after all!!

Done! I also recently stumbled across a reference to this: https://github.com/Dzsek/dcsMissionVariantGen/releases/tag/v1.0 I haven't investigated it, but it sounds like it might be a more general-purpose version of my little utility.

In case it is of any assistance to mission makers and server operators out there, I put together a small utility that automatically removed the Mod requirements from any mission you apply it to. It doesn't remove the mods - just the flags that mark the mission as requiring specific mods - thus allowing non-modded clients to join. See https://www.digitalcombatsimulator.com/en/files/3322208/

I have a question - is this a bug in MIST, or just a DCS oddity that I've been unable to verify? In the implementations for mist.getUnitsByAttribute() and mist.getGroupsByAttribute(), when it is populating the "cEntry" object it has the line: cEntry.categry = att.category is the misspelling of "categry" deliberate here? I can't find anything in the DCS Scripting Engine documentation, nor in the MIST sourcecode (or the MOOSE sourcecode) to confirm or contradict this. The "categry" entry is later checked against the mist.DB data, but I haven't been able to trace whether that data contains "categry" or "category" (I wish DCS had a Lua debugger built in!) If its a deliberate misspelling to match a corresponding spelling in the core DCS scripting engine, it might be an idea to note that in an inline comment - lest some enthusiastic but ill-informed programmer like myself tries to 'correct' it.

I haven't really been entirely happy with the existing trim modes, and had been thinking of ways that might improve the experience. As a result I have come up with an idea for a different algorithm for the "trim" mode for the Apache (and potentially other DCS helicopters, and even other aircraft that have similar trim mechanisms). If you have already tried something like this internally and found it didn't work, that's fine - this is all hypothesis - but if it hasn't been tried, perhaps this approach might work better? The Existing Trim Options Of the current three options: "Instant trim", "Central Position" and "Without springs", I am going to ignore the "without springs" option, as I have no experience with it and expect it works just fine. I have found the other two options to both have certain disadvantages, and I hope this new approach might alleviate both and potentially replace both options. Disadvantages of the current trim options "Instant Trim": Unless you are very quick to re-center your controls, you will get a "bobble", as the system reads your off-center stick position as command input. "Central Position": Eliminates the bobble, but in my experience can eventually kill you, as the algorithm locks out all of your inputs until it sees a "perfect" (0,0) from the controls. If you don't use a significant dead zone then eventually you will hit a circumstance - typically, when trying to arrest a slide into a building while trying to dodge an IR SAM - when your frantic inputs just keep missing that magic (0,0) point and you die. My proposal here - if it actually works as I am hoping it might - would combine the best characteristics of both the existing algorithms - no "bobble", but also never locked out of control. Heuristic-Centering Trim When considering the control inputs there are three factors to consider: Your physical joystick position, The current trimmed control position, and The current joystick (0,0) reference position. The existing algorithms both calculate the Effective Control input at any time as: (current trimmed control position) + (physical joystick position) - (joystick reference (0,0) position) In both existing algorithms, the (joystick reference (0,0) position) is always at physical joystick (0,0). "Central Position" mode ignores all input after a "trim" command until observing (physical joystick position) == physical (0,0) Heuristic-Centering Trim would use the same logic as above, but with two additions: When a "trim" command is issued, the (joystick reference (0,0) position) is set to the current (physical joystick position) The Effective Control input calculation has one added step: If the (physical joystick position) is between the current (joystick reference (0,0) position) and the actual physical joystick (0,0), then set (joystick reference (0,0) position) to (physical joystick position) Calculate Effective Control input the same as before: (current trimmed control position) + (physical joystick position) - (joystick reference (0,0) position) The Player Experience How this will translate into player experience would (I hope) be something like this: You would treat it much the same as either of the existing modes: you press trim, then you re-center your stick and then continue giving control inputs. Initially everything is at physical (0,0). You apply stick (or rudder) inputs, and that translates directly to Effective Control inputs, exactly as you expect. You get the helo flying in trim with the stick at some position - call it (X,Y), and you press & release the "trim" button; your stick is at (X,Y); the Trimmed Control Position is set to (X,Y), AND the (joystick reference (0,0) position) is set to (X,Y). If you don't move the stick, the calculated Effective Control input is unchanged - (X,Y) - and there is no "bobble". As you then relax the stick back to physical (0,0), the (joystick reference (0,0) position) follows your action; Effective control input remains (X,Y) and there is still no "bobble". If - before you reach physical (0,0) - you suddenly find a need to add a little more input, the algorithm detects that and applies it proportionally from wherever (joystick reference (0,0) position) was when you started re-applying input. As you do this, (joystick reference (0,0) position) doesn't change unless you re-trim, or you again start relaxing the stick back to physical (0,0) and pass the current (joystick reference (0,0) position). If conversely you suddenly find the need to apply opposite input, you will experience a slight "deadzone" effect as you move the stick back past physical (0,0), but as soon as you move past physical (0,0) - at which point (joystick reference (0,0) position) hits physical (0,0) - your inputs immediately start applying as Effective Control inputs - you never get permanently locked out. So the slight "deadzone" effect as you move back to (0,0) is the only quirk you would experience, and if you are following the habit of "trim then re-center", I think you would barely ever notice it. On the up side, there should be no "bobble" effect, and you can never be unexpectedly locked out of your controls. I hope this idea is of some interest!

Adding the ability to create and remove client slots via script would make it much simpler and less problematic to create dynamic campaign-style missions, where airbases and FARPs might change hands over time. Instead of having to pre-set every possible client slot at every possible base, then muck about with mechanisms to selectively block slots, script could simply create and remove slots as required by the mission. It would also simplify missions that need to cater to an unknown and variable number of players, with unknown preferences for specific airframes. Some straight-forward scripting could give a Spectator a menu from which they could select airframe and starting point; script could then generate a slot on-demand, with whatever loadout and flightplan it deemed appropriate.

One feature I would really like to see for the AH-64D IHADSS is the ability to customise the vertical offset of the eyepiece rendering. I know its a weird request - for the majority of people I'm sure the center of the screen is the center of their field of view, but I use a 55" monitor, and for flight-sims I find it best to have it positioned with my eyeline somewhat below the center, as that provides more peripheral vision above the cockpit (where the bad guys are), and less in the cockpit (which I can always look down at using TrackIR when I need to). The default rendering in the Ka-50 and F/A-18, which assumes the eyepiece is centered on the screen, works poorly and feels awkward - the reticle is always ends up slightly above where you are trying to look. The Ka-50 has an excellent configuration setting where you can adjust the vertical offset of the eyepiece - perfect for me! I would love to see this same feature in the AH-64D (and maybe some day in the F/A-18 as well?) (for TrackIR users another cool feature might be to also proportionally offset the eyepiece rendering to the left or right as you pan your view, as physically you are looking towards the edges of your screen. It would be very tricky to tuning right, though!)

Sadly, I tested it from a cold start with the same result - the HMD display still ends up offset. I think the problem is that the logic used to render the HMD display assumes that the center of the screen is the center of the user's eyeline, and where they are looking by default. Probably works perfectly if you leave the cockpit viewpoint in its default configuration, or have a VR headset, but for my setup that doesn't work - I actually have to look up somewhat to look at the center of my screen.

Thanks; I'll test is that helps. If it does, then it *not* helping from a hot start might be a bug.

I was hoping that the JHMCS alignment procedure would actually enable me to align the JHMCS with the HUD. For me the JHMCS display has always been offset above the HUD, which just makes it awkward to use. The reason for the offset is because my default cockpit view is set to suit my monitor and desk setup, so the centre of the HUD / horizon line is actually about 1/3 of the way up the screen, not in the middle (its a big screen). The JHMCS assumes the middle of the screen is the point you are looking at; in my case it is not. (see attached Zip file for screenshots, if this is not clear). The Ka-50 module actually has a setting to vertically offset its helmet monocle, so it *can* be adjusted to suit my setup. I had hoped this new alignment procedure would achieve the same thing in-game for the F/A-18. (I've only tested re-aligning from a hot start; if the alignment actually has an effect when done from a cold start, then there is still hope!) The attached Zip has screenshots showing me conducting the alignment procedure, with "before" and "after" views of the JHMCS display - there is no noticeable difference between them. FA-18-Alignment.zip

I've found that on a hot start you still have to run the JHMCS Bit tests in order to get the HMD page to become available.

The AI logic for air-to-air tanking might benefit from this relatively small change. At present the AI will cancel your clearance to connect after some arbitrary period of time if you have not successfully connected. Often this will be at the point when you are just 2-3m from connecting to the basket. Air-to-air refuelling is a difficult task and developing the skill in not made easier by the AI cancelling your clearance just as you are about to achieve a successful connect. My suggestion is that the logic be enhanced such that while the player has clearance and is within 100-200m of the tanker, their clearance is *never* cancelled and any timeout counter towards cancellation is not incremented. This change might also help reduce the number of AI tankers downed by frustrated players.

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?

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 when a grid cell is selected on the MFD - ignore any minor cursor movements, and only "cancel" the selection if the cursor moves a significant amount (e.g. more then 2-3 pixels) - assuming that 'cancel on move' behaviour is even intentional; it seems strange, really.

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.

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.

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?

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: E.g. for the F/A-18, I just change one line - at around line 54 of the file, to be: base.init_pos = {0,0.5} -- was {0,-(1 - 2.0*size_x)} The A-10C is similar, but the line is in a slightly different location. Look for the "base.init_pos" line in the file for your aircraft. The numbers you require depend on your screen layout. {0,0.5} puts the indicator half way down the LH edge of my main monitor. If you have difficulty with this, and have a specific aircraft you need adjusted, let me know and I can post a suitably-adjusted file for you.

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 :-)

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 time the targeting pod cycles OPR (stabilised) | ATRK | PTRK as I expect, but sometimes it drops one or the other option and sometimes the OPR mode refuses to ground-stabilise. E.g. it will cycle OPR (not stabilised) | PTRK, but won't enter ATRK or ground-stabilised OPR-only mode. I have not been able to identify any pattern to this. I have not had it happen to me in a local mission - everything works exactly as expected. I have only encountered these issues when connecting to a dedicated server - but then 95% of my flying is done connected to a multiplayer server, so that isn't a statistically valid observation. Can anyone offer any suggestions as to what is going on here? Thanks!

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 and RIGHT_MFCD if a custom viewport was not defined. That approach no longer works with the new mechanism implemented for the F-16C: Under the previous system, this would have worked: --ViewportHandling dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") update_screenspace_diplacement(1, true, 0) try_find_assigned_viewport("LEFT_MFCD_F16", "LEFT_MFCD") On a side issue, if you change the "USE_LCD_MFD" setting, then the above *kind* of works - the custom exports *do* appear, but totally fuzzed-out and unusable, and the standard LEFT_MFCD and RIGHT_MFCD viewports are also still displayed as well. It would be great if they adopted a standard of including the calls to check for both an aircraft-specific viewport, and (where appropriate) a generic viewport for every exportable display - would save me a lot of editing after each upgrade! :-)

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("F16_DED") Then you need to add the relevant viewport definitions to your MonitorConfig. Sadly they are doing something weird with the MFDs, and you can't customise the viewports they display to - which is a pain if you fly multiple aircraft with different MFD shapes and locations.

Thank you, Rik. If the programmers need anything tested on a "failing" system, just let me know - I'm happy to assist.

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.

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=="}