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.

As a workaround, cycle the FLIR to off and back on. It will go through its timeout procedure, but at least you can use it again.

The "X else Y" controls are intended for hotas switches - for example, you push a switch forward, and it registers that as a held button until you move it back.

I get where you're coming from, and I'd kind of like to see some autoupgrade myself, but I just don't see how it's practical. Automatically upgrading or switching would be bad if any of - multiplayer - 'decorative' objects have been placed on it by the mission maker - you want the mission to be plainer, without any extra procedures, obstacles, or other features used by the SC. I'm guessing it will say in the store entry that you will need carrier capable planes separately from the carrier itself.

Notching is about having the same approach speed as the ground. If the missile is a perfect 90 degrees away from your flight path vector, you'll be more still, as far as doppler is concerned, than a tree bending in the wind. (Unless you have exposed props, but DCS doesn't seem to simulate that.) AFAICT, missiles going for chaff is a random chance, though the chances seem greatly increased by notching compared to not, at least in general. Then there's what happens with ground clutter in your cell. Back on topic, I don't remember what missiles an amraam will target from maddog, but I distinctly remember sa-10 (s-300) was among the things it would target. Brute forcing your way into a sa-10 zone is one of the very few reasons it can be legit to load 10 amraams on a hornet that doesn't even have TWS. You'd want to have enough hornets to have more missiles than the site, and THEN have some payload to put on whatever your actual target was.

Hmm... now try walleyes and gbu12. Started in the air, released walleyes, landed, reloaded walleyes+dl13+litening+gbu12s. Dropped walleyes, can't release GBU12s.

In DCS, you can use the NS430 with any plane, including the F-14B, it's just not integrated into the 3d cockpit, and does not control the radios.

I'd think it should at least be turned to the stby position in a hot start.

JDAM and JSOWs are in. You need something to feed you the target position, however, which is mainly from the map, which presumes it's visible there. LGBs are in, but you need something else to designate, and it's up to you to get the bombs into the right area. Laser guided mavericks (AGM-65E) can double as LSTs until you let them off the rail. IR Mavericks (AGM-65F) are in. HARMs are mostly in, except Pre-Briefed mode. We'll probably see AGM-84D (anti-ship) as the next weapon added. If we still don't have the AG radar, it will require something to feed us a target position, we enter it as a waypoint, and fire at it.

Also keep in mind that the HARM can only track on a radar when it emits in the direction of the missile. So if you launch a harm on a tracking radar and make sure it keeps emitting on you while the HARM is on its way, its constant pulses should ensure good guidance and a hit. On the other hand, if you imagine a search radar that takes 5 seconds per rotation... that's one update every 5 seconds. I remember* observing a HARM doing course corrections every 1.0 seconds or so. *human memory and all that

When you're datalinked to a source you should see lower half symbology on your TID, whereas your own radar contacts only show upper half. Set the datalink frequency to the value found in the kneeboard and push the DL switch forward. That's all that should be required. This has nothing to do with voice radios (hear messages, send requests, get answers) but a panel on the RIO right console, near the front.