itn

Thanks Lord Vader. I assume and expect you'll come into a good solution. Even though there's some discussion here, I don't think this is a very complex question. My two cents, also replying to some of the posters above: The loadout selection is simply a game mechanic, and far removed from any "realistic" way jets are loaded. This is just a fact and not a criticism of any kind, this is a game and some things cannot be "realistic". As such, in my opinion it's best to simply follow good principles of system/interface design, mainly the principle of least surprise, which in this context means this: You have a jet with all the pod power switches (station power + L/R HDPT) on. You add a pod. You expect to have all the power switches on, pod added, pod has power. Instead of, the unexpected: You have a jet with all the pod power switches on. You add a pod. One or more of the power switches are now switched off. You now have a pod with no power on; even though you started from a situation with the power switch on, and simply tried to add the pod. Or, the objectively outright wrong: You have a jet with all the pod power switches on. You add a pod. You have a pod, and all the power switches on, but the pod has no power. This would be a bug. Br, itn

INS drifts regardless of the initial alignment type. It’s also modelled in DCS F-16C, even if in a simplistic manner. However, we get an INS re-work in today’s patch, so some of the DCS-specific details are bound to change.

Pressing COM1/2 and ENTR does not switch between ”preset/frequency modes”. ENTR without inputting a preset/freq switches to the last used channel, and can be used for pogoing to another channel and back easily. Preset channels and manual frequencies can be switched into in the exact same way (COM1/2, preset/freq, ENTR). There’s no ”mode” to change per se. If you really wish to cycle through the presets with selector switch, you can, but it’s faster to just enter the preset number and press enter.

Hi, Using current DCS 2.9.3.51704. Pylon weight is not included in the Loadout/re-arm menu Gross Weight. Tested with Viper, Hornet and RAZBAM F-15E so I assume it's a generic issue, not with individual modules. And at least for Viper, pylon weight is excluded both for pylon-only and weapon+pylon configuration, so in essence pylons are not counted in re-arm menu at all. Steps to reproduce: Create a mission with plane on ground. Use Viper or another plane with removable pylons. Note the total Gross Weight in Mission Editor. Run the mission, enter cockpit and open Loadout/re-arm menu. Note the GW differs from the weight in Mission Editor. Remove or add pylons. Note the Gross Weight does not change. Expected results: Re-arm menu Gross Weight should change when adding or removing pylons. Attached a track, even if it might be useless for a bug like this. Loadout menu gross weight pylons.trk

To both of the questions: No, not possible. As far as I know, not possible on the real jet either, but I might be wrong. Also, you didn't ask but no TACAN indications on the HUD either. So it's quite a bit different than, for example, the Hornet. I assume this is an Air Force / Navy difference, where the AF just hasn't had the need for it, at least not enough to spend resources to add them.

Just to clarify, are you talking about a feature in the Mission Editor, such as an advanced waypoint action? Or did you refer to the same old scripting ways we're currently doing manually or with the excellent MANTIS/Skynet scripts? I could not see any new features like this in current DCS which is why I'm asking.

Disregard, I misread your previous post. Your very first post seems correct in all aspects but the time it takes for GPS to sync (which we already discussed). At least with AI units (using an AI unit's STN as #2) It seems there are no ill effects with powering up GPS and MIDS LVT at the same time. Datalink apparently works the same and you see the #2 as blue on DL. Will test with humans later, but so far I can confirm the only ill effect is the GPS time off on DLNK page, and that one seems cosmetic.

I’m not seeing it. Might test some more. Post a track? True, also why I mentioned the 2 minutes, as it’s longer than what was mentioned. Granted, I haven’t tested extensively what happens if you switch LVT on after 60 secs but before ”GPS” text is shown on TIME page.

On my tests it takes two minutes from switching GPS on to seeing ”GPS SYSTEM” on TIME page. Where did it take you three minutes? Or did you perhaps look at the jet time, which will likely jump ahead a minute or so when GPS time is synced? Look at the mission time on F10 or info bar instead. I’m just curious if there are differences in different locations or such, and does it take longer in some conditions. I tested in Caucasus and Syria SP and MP. Sounds like as a consequence of switching MIDS LVT on too early, you have to fiddle with the DED pages, just like the workaround with the bug since previous patch? If you wait for the GPS time to sync first, you don’t have to do anything on the DED pages.

You can use air-to-ground modes in NAV master mode.

Delta TOS has been implemented and does work in Open Beta. @Nessie not sure what you mean with ME failing badly? I know it does work for a route where route start point is "Fix Time" (TOT) and rest is with speed. The calculated TOS is in waypoints. Haven't tried how it copes with having some additional steerpoints with Fix Times in the route.

To add to this: If using metric throughout, the bug seems not to manifest. ME doesn’t allow fractional values for altitude (whole meters/feet only) and there’d be no unit conversion, so the issue just does not happen. Problem is with rounding and/or unit conversions.

Nice, thanks.

Not the same bug per description, even though similar and maybe same root cause. Maybe that ”minimum 30m AGL” in the other thread is not even considered a bug. My report is about a MSL waypoint having +30m added on group copy. Because ”0 AGL” is not possible, I have to enter target waypoint in MSL. Now if I copy the group, and happen to have AGL waypoints on route, the MSL waypoint gets +30m. And to be accurate, the one you linked was reported in January 2019.

I believe this is the same or at least related to this: Using DCS 2.9.2.49940. When copying a group with AGL waypoints in it, MSL waypoints get additional 30m (~98ft) added to them. Steps to reproduce: 1. Add group with an AGL waypoint or two, and MSL waypoint. 2. Copy-paste the group in place, so the waypoints line up 3. See the copied group's last (MSL) waypoint, which is now 30 meters (~98 ft) higher than the original. In addition, even in the original group, editing the last waypoint from AGL to MSL is weird and it won't save the new altitude until you first switch it to MSL, then switch selected waypoint to other and back, then enter the new altitude (now in MSL). Without switching waypoint there and back, it won't allow you to change it. Attached is a sample miz where I copied the group. See Aerial-2's last waypoint. ME-AGL-MSL-add30m.miz

Using current DCS OB 2.9.2.49940 Mission Editor displayed waypoint altitudes change when switching waypoints. It's frustrating error with hopefully a simple and quick fix. The values change by +-1 feet per my testing. I'm using imperial values and have not tested if similar problems exist when using metric in-game. A sample mission attached. In the mission I have two groups, with waypoints 0 and 1 set to same altitude. Aerial-1 has waypoints 0 and 1 both at 6000 feet Aerial-2 has waypoints 0 and 1 both at 300 feet Steps to reproduce: Select Aerial-1: Altitude is shown 6000 feet as set in the mission. Switch to waypoint 1: Altitude 6001 is shown Switch back to waypoint 0 and still 6001 is shown. Same thing with Aerial-2 at 300 feet, except for that group the errorenous value is 299 feet. Values in mission file are saved in meters. The values values in mission file do not change if you save the mission after switching and seeing the wrong altitude values displayed. I guess this is a simple rounding error in the display logic. The values in meters are 1828.8 (6000 ft) and 91.44 (300 feet). 1828.8 ~ 1829 which gives us 6000.656 ~ 6001 feet 91.44 ~ 91 which gives us 298.556 ~ 299 feet. It's a frustrating error when going over dozens of carefully set waypoints, and no matter how hard you check and fix the values, they always seem to change. ME-altitudes.miz

Yeah, no. ED has changed their stance back and forth on having 2 or 4 HARMs. What we have is simply a 4 HARM capability and no additional "carry only" restrictions available. "Payload Restrictions" allows you to restrict per station, but no restrictions on firing them if you got them.

Where? How? I see nothing in ME payloads/restrictions or in the "..." (Aircraft Additional Properties). Sure, you can disable HARMs altogether from those stations, but nothing about carry-only HARMs.

With stored heading alignment it's the opposite: you must not enter coordinates (meaning you should not press ENTR at all on any of the three lines). Nevertheless it's good practice to check that the coordinates match to the position on Ctrl-Y infobar / F10 map. Again, not pressing ENTR, just checking visually.

That's a big track. It's always better to do as short as possible a track where you can reproduce the issue. Nevertheless, I watched the start and unless you fixed it later in the track by doing a new INS alignment, I found an issue: You're using the wrong procedure for INS normal alignment. When using the normal (NORM) alignment, you must enter or verify (with ENTR) the current position within 2 minutes of moving the INS knob to NORM. So the correct process is: Switch INS knob to NORM. Within 2 minutes: Enter correct LAT LNG and SALT. If they're already correct, as they usually are, just press ENTR on all those three lines, verifying the current values. Wait for about 8 minutes for align to complete. Alignment is complete when status is /10 and RDY is flashing. Switch INS knob to NAV. What I saw in your track was as follows. This is as accurate as I remember as I only watched it once. In any case the problem was clear and you could briefly see the borked alignment status on DED: Switched INS knob to NORM. Waited for the alignment to go to /10. Verified the coordinates with ENTR. Verifying the coordinates after 2 minutes into the alignment process resets the alignment and it starts from zero. You can see the time and status resetting on DED. Switched INS knob to NAV. Last INS status I saw on the DED was something like 0.1/96 so completely borked. Hope this helps. See DCS F-16C Early Access Guide p. 172 for more information.

I think axis controls are not included in the search. What you're looking for is "RDR CURSOR Switch" (Y and X axis, respectively) in Axis Assign list. For the slew axis: Depress is under "ENABLE Switch - Depress": The physical slewable+depressable switch is called the "(RDR) CURSOR/ENABLE switch" for example in the DCS F-16C EA manual.

Cursor Zero. You can find it at least on the following pages: FCR (FCR A-G modes), HSD (A-G master mode) and on TGP (TGP A-G mode). TMS Aft works on TGP, but you didn’t have one. Easiest is to switch to A-G and use CZ on HSD. Unless you had FCR on A-G mode (e.g. GM) in which case you’d just use CZ on FCR i asked Lord Vader above about not having CZ on HSD in NAV mode but no reply so far. As I understood from the explanation given earlier, in the linked thread, cursor deltas are per mode. But seeing that you can reset delta seen in NAV by going into A-G and using CZ, I’m not sure I understand it fully or that it’s consistent. In any case as you can have delta in NAV, it would make sense to have CZ on HSD in NAV mode too. Regardless, CZ is your friend now more than ever. TMS Aft is an additional control in some contexts, but CZ is more prevalent.

This might be about the cursor delta. In October I put in (an erroneous) bug report about steerpoint offsets. It ended up being not a bug, but the longish discussion helped with understanding delta and CZ in different modes. See the linked thread if you're unsure about cursor delta and CZ logic. It will be more clear once you "use it" a few times. I'm not an expert but just guessing on the discussion in this thread: In @IR.Clutch's HTS case I think you simply get cursor delta when designating with HTS. That delta stays until you remove it by using CZ (or TMS Aft on TGP). In @SickSidewinder9's case I suppose fastest way to reset the delta is to switch back to A-G master mode and use CZ on FCR, TGP or HSD. In NAV mode, HSD does not have CZ button nor A-G ghost cursor. I wonder if these should be available also in NAV mode? They would be useful, but that doesn't mean the real jet has them. @Lord Vader care to check/comment on that?

Seeing that you have TGP page readily available on right MFD, switch to that and try TMS Aft or CZ (if "CZ" shown). If it doesn't work, try switching steerpoint back and forth (sometimes needed with edited steerpoints of fresh markpoints).

That's unlikely to be the reason. I did mention earlier the thing about shaking the plane with stick, but I also mentioned you don't get to /10 and flashing ALIGN/RDY if the alignment fails because of movement. I find it quite unlikely that your stick jitter is the reason. In practice, on a level ground etc., you can throw the stick around quite mightily and run the FLCS BIT without affecting the INS alignment. There's absolutely nothing to work with here (no tracks, no video, you didn't even mention if you removed the mods already or not), so I'll just say great if it works for you now well enough.