mahuja

On a mp server where it's stated to be on auto, I've had this problem during the day but george works perfectly as normal at night.

For the poll itself, I imagine the question attracts one side more than the other, and forum goers are already less casual, so the yes/no ratio doesn't seem like it'll be useful. Selecting on a dependent variable (times two) and all that. ---- I set up a 'daily basket' mission which I played every day, taking an F-18 up to refuel (and a bit more). It took me a bit short of a month to reliably refuel in usually only one go. Now I'm somehow better at refueling than formation flying, and the skill really doesn't perish for me. The F-14 has the added challenge that it doesn't fly straight. I trim it out, but adding a couple knots to approach the basket brings it enough out of trim so it swings up. Also having the same problem switching F-16 to F-15. I've crept forward slightly into the red for a moment and maintained contact. The 'box' shrinks a lot near the top.

This sounds like a rare problem, which I've encountered twice in about a decade. Unzip the mission file, or track file, and open the 'mission' file. It's a lua file, and at the end it would normally say ["failures"] = { }, -- end of ["failures"] I'm gonna guess this has been filled with lots of random failures. This then affects a multiplayer mission.

I have a set of 4 missions reproducing it. Scenario A: One A-10C, vanilla CAS, guns only, waypoints brings it near a column of 6 BMP-1s. One F-16C, escort, on WP1 it gets an escort task on the A10 with an end at escortee's WP5. WP2 is off to the side. Outcome: The F-16 sticks to the A-10 as best as it can, even joining in being AAA target. As the A10 reaches its exit waypoint, it continues to its WP2. Scenario B: Scenario A, but the A-10C is given an attack group task on its WP1, roughly colocated with F-16 WP1. Outcome: No difference. Scenario As previous, but A-10 is now tasked with "Ground attack" and given a bomb load. WP1 gives it a bombing task. Outcome: F-16 runs off to its "after-mission" WP2 as soon as the A-10 hits WP1. Once the attack is completed, the F-16 flies max speed to rejoin, but it got fairly far away. Scenario As C, but the F-16 now has a new (inserted) waypoint 2 past the target area, and the escort task is followed by a "switch waypoint" task to the after-mission waypoint. Outcome: When the A-10 hits WP1 (and instruction to hit the bombing target) the F-16 zooms ahead to WP2, staying ahead of the A-10 in a manner which would keep it protected. When the bombs are dropped, the F-16 returns to the A-10. When the A-10 exits, the F-16 continues to WP3 (old WP2) as intended. Conclusion: This already exists, but is undocumented and only obvious to codeheads. (I have not tested interactions with further tasks on the while-escortee-is-busy waypoints.) If anything, it's the stick-too-close behavior of A and B I have an issue with. There's no obvious way for this forum post editor to turn off auto-discorrect. Escort issue reproduction.zip

Quite frankly, I'd like to see it preceded by more night content for existing night-capable modules.

The default seems to have changed from always-christmastree to christmastree only over friendly airfields. A big improvement for sure... but... I have a need to have a few specific units be always-christmastree for a few mission ideas.

The elephant in the room is the autists who want everything to be correct. You know, the ones who get (proverbial or otherwise) aneurysms when they see a screenshot of a plane with a bomb it never carried, or a TPOD it never carried in that spot, or with a screen interface it shouldn't have, or... And frankly, I'd rather have those people make my sims than the opposite type. I think these statements are correct. - You'd never see a v1/v3 on a carrier - You'd never see a v2/v4 with a canadian or australian skin (probably) - USMC hornets, should they operate off of a USAF-supplied airfield, may use v1/v3, but would not bring them to a carrier. - USN hornets would only operate from carriers in a combat zone. There is a strong case to have irons, LGBs and JDAMs in separate submenus in the loadout screens. That's a separate thread though. As is the performance issues in the reload screen, which annoy me far more than a couple mostly-cosmetic entries in the bomb list.

Here's my observations: If you start with a HMD designation, your TGT point will be in the right direction, but typically wrong distance. AFAICT this does not happen with AGR measurements. With no AGR, it's a question of where it would get the distance data from; unlike the A-10C it doesn't have a terrain database to look up in. (AFAIK the A-10Cs terrain database was added primarily to provide terrain warnings.) Then when you switch to the TGP, your TGP will default to being slaved to the TGT - a point that is now in midair before the target. (Or belowground behind it). As you move laterally, it will have the appearance of drifting, but it's really the incorrect point in the first place. Slewing it doesn't fix the incorrect distance. (Maybe it should?) Switching to AREA track allows you to have the TGP track the correct target. Upon switching, I'm seeing the TGP target coordinates suddenly showing the correct target altitude (and presumably coords) as I switch to AREA. At this point I can TDC Depress to update the TGT point to the correct position... ... for a split second. Then the TGT point is set back to the incorrect, midair position. In one test case, the TGT distance went from 3.5 to 4.0 for a split second, then back to 3.5. That's probably a bug.

If you start with a HMD designation, your TGT point will be in the right direction, but typically wrong distance. AFAICT this does not happen with AGR measurements. With no AGR, it's a question of where it would get the distance data from; unlike the A-10C it doesn't have a terrain database to look up in. (AFAIK the A-10Cs terrain database was added primarily to provide terrain warnings.) Then when you switch to the TGP, your TGP will default to being slaved to the TGT - a point that is now in midair before the target. Or belowground behind it. As you move laterally, it will have the appearance of drifting, but it's really the incorrect point in the first place. Slewing it doesn't fix the incorrect distance. (Maybe it should.) Switching to AREA track allows you to have the TGP track the correct target. Upon switching, I'm seeing the TGP target coordinates suddenly showing the correct target altitude (and presumably coords) as I switch to AREA. At this point I can press the TDC Depress to update the TGT point to the correct position... ... for a split second. Then the TGT point is set back to the incorrect, midair position. In one test case, the TGT distance went from 3.5 to 4.0 for a split second, then back to 3.5. That's probably a bug.

There's another variable you should play with, and that's the fog of war setting. Going by your table above, ??? would be jtac with the f10 map friendlies only setting.

While I agree for the simple case... (they love their pods for a reason) 1, you may not be carrying a tpod. Whether an issue of limited availability, or because you need the hardpoints for the extra missile or fuel/bombs. 2, I'd like to remind people of this optional-in-dcs thing called weather. If the weather, or weather in combination with air defenses, prohibits tpod usage, A-G radar targeting is still available. 3, If you're at low altitude the tpod has greater range error when you can't use LRF. At that point, the radar may give better range information. At that point, using the tpod to cue the radar rather than the other way around may be viable.

M9 pdf, page 6 FRAGO, says the primary mission is "Destroy SAM and AAA in Anvil, engage targets of opportunity." This is exactly what it said in M8. The rest of the fields in the table is different, but I am doubting the reliability of the rest of the table as a result.

TACAN should not rely on your INS in the first place, so how you aligned your INS should be completely irrelevant. One thing to watch for is if you have turned it off in the volume controls panel.

Vanilla DCS lua. No dependencies. local checkid = 74023650; local function handler (self, event) if event.id ~= 8 or event.initiator.id_ ~= checkid then return false end trigger.action.setUserFlag(1,true); world.removeEventHandler(self); end world.addEventHandler {onEvent = handler} The trigger action can be whatever you want, I just used the flag for scoring and followed up with other triggers.

No, there is a pair of covers on the stick itself which has separate controls. That caught me out as well.