itn

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.

Can you clarify this? It should start with current coordinates and normally you would only have to verify them with ENTR. Are you using the correct coordinate system? And how big is the error when navigating? Is there GPS available and enabled on the mission? A track file would be helpful. Stick input and FLCS BIT might shake the plane enough to cause INS alignment to fail. However, when it fails it simply stops and will never get to /10 and flashing RDY. You said you checked it so that shouldn’t be an issue here. With all that being said, you should follow the recommendation and try without mods. It seems some mods cause issues in current versions.

Glad you got it working and happy to help. However, to re-iterate: I haven't seen myself nor seen anyone demonstrate speed having any difference to the release as long as you're otherwise in the parameters (mainly steering in this case). I've dropped them from 1.5M+. If there's a track that shows otherwise, I'd like to see it. What I believe has happened in your case using autopilot, is that speed affects AP steering, and you might or might not end up at the correct steering line. If that's what's happening, then the release is merely a happy accident based on some combination of speed, relative wind and AP steering logic. So the lesson here, based on what I've seen, is not that "release has a speed limit", but that speed can affect autopilot steering, and AP might or might not steer you accurately to the release parameters. If using AP for CCRP, you need to check that the steering line goes through FPM. If it doesn't you need to correct it: Maybe steer manually or switch to HDG mode and adjust from there. The reason why I'm replying is because I think the speed thing is a misconception and hides the actual reason for CCRP troubles for anyone possibly reading this afterwards. If anyone disagrees, please post tracks because I just haven't seen it.

In current OpenBeta there's no such limit. You can pickle GBU-12s at 1.5M+. In May maybe it did or maybe it didn't have such an additional speed limit. Taking control of OP's track you get to about 1.05M with full AB, and can pickle just fine as long as the steering is correct.

It's not the speed, it's the steering. With DCS F-16 and LGBs, you need to line up the steering line and Flight Path Marker to release. In the track with autopilot, it seems to align Target Designator box and the steering line. This takes you off right of the correct line, FPM is to the right of steering line. Line them up like this, and you're good to go:

This is not a good comparison. Those Contact Light's charts are from September 2022. There's also a weight difference of 5000 lbs between the ED reference and CL's charts. While weight might have a linear effect, the FM changes done in the last 15 months do not. For newer in-game data, check out DCS Dogfighters Discord, as that's where CL has published his charts. After some research you might find it harder to say pure rate numbers are "quite off" for the Viper. By "pure rate numbers" I mean STR/ITR, not other aspects such as FLCS behaviour, G onset etc.

Hey, Using current DCS 2.9.1.48335 Open Beta. Unit selection in Unit List is bugged when group is HIDDEN ON MAP. Steps to reproduce: Add group with multiple units Set the group HIDDEN ON MAP Select View unit list Select different unit from Unit List. Note the following: In Vehicle Group display (top right), Unit Name and other values reflect the first unit of the group, instead of the unit selected from Unit List. Modifying unit values, e.g. skill, edits the unit whose name is shown, not the unit selected in Unit List. In practice, first unit of the group is edited. Furthermore, the modication seems to be reflected in Unit List only if HIDDEN ON MAP is toggled.