nomdeplume

As you say, there's lots to learn, so learning how to use the MFCDs I don't think makes much sense. Learn how to use the different things that can be displayed on them, i.e. TAD, DSMS, TGP, etc. Any decent discussion of navigation should include the TAD, for example. The MFCDs themselves are pretty simple. You don't manually release individual countermeasures, instead the system is designed to run 'programs', i.e. predefined sequences of chaff/flare ejection. You can execute the currently selected program by using the 'HOTAS CMS FWD (aka UP) SHORT', and stop it prematurely using 'HOTAS CMS BACK (aka DOWN) SHORT'. But, I'd suggest reading about the CMS to properly understand its workings and how to program the sequences (if you so desire).

Maybe he forgot? I'd guess he's not finished starting up though, e.g. the ejection seat is apparently not armed yet (I thought they were meant to do that first thing in case they have to make a rapid exit during the startup procedure). May just be personal preference. Keeping the APU running and generator enabled gives you a backup power source if you suddenly need to shut down the engines. You're unlikely to encounter such a situation within the sim though, as far as I know... random engine fire at startup?

You'll only get the Sidewinder seeker indicator if you have Sidewinders... maybe in the earlier you case you accidentally switched into air-to-air mode (by holding the master mode button) and you weren't carrying Sidewinders in that particular mission? You'll still get the gun aiming reticule, assuming you're carrying the gun. :D

The AI will jettison and punch out if they run out of fuel, so maybe that's what happened.

You can also directly slave the TGP (and only the TGP) to your current steerpoint using the China Hat Aft Long command. Note that when slaved (via either method), as soon as you slew the TGP or command an area/point track it'll become unslaved. Easy/realistic avionics mode makes no difference, it's part of the mission setup. Different mission designers will do different things, so there's no universal solution. In the quick mission, I think target groups are marked with smoke, so just acquire them visually.

...and having the helo take off again. :) Actually I don't think angled terrain would be a problem if you they only landed at places that were pre-designated, the mission editor could just restrict you from placing the 'invisifarp' on angled terrain, like it does now with FARPs. Personally, I want the ability to switch waypoints for ground units before the ability to have helos land/takeoff on command. But both would be nice!

During the beta the docs for the new task system included a "land" task for helicopters that would've got them to land at any designated point. Seems to have quietly disappeared, so I guess it was harder than they expected. Bit of a shame, but probably one day it'll turn up. Use a deactivate group action in a trigger (I think it's probably listed as GROUP DEACTIVATE). When deactivated all members of the group will disappear.

Run the game, select the mission editor from the main menu, and then from the last menu option at the top (can't remember what it's called :() select Credits. That'll show the full version. I think Steam should probably be 1.1.0.8. 1.1.0.9 is the latest but updates tend to be released a bit later on Steam. Starting with 1.1.0.9 the startup splash screen shows the full version number (rather than just 1.1.0).

The radar altitude is always* displayed if you're below 5,000 feet, above the data block at the bottom right (e.g. 3120R). The tape only appears (if enabled) below about 1,500 feet. * - assuming your radar altimeter is working and you're not upside down. The only way to determine height AGL is using a radar altimeter or similar, or by having a database that contains elevation information for all the terrain you're going to be flying over. The A-10C does actually have such a database, and if you have the TGP equipped, it'll give a reading in the top right corner. This is presumably calculated by subtracting the terrain elevation at your current position (from the database) from your current barometric altitude. That means if your position isn't accurate, or your barometric altitude isn't accurate, or the stored data isn't accurate, then the readout won't be accurate.

If you're using the HOTAS MIC switch, then accessing a different radio should open up the root menu. e.g. if you contact JTAC with the FM radio, use the UHF switch and you should get the root menu. Otherwise, if you hit \ (backslash) I think it'll either go back to the root or close the menu. If the latter, when you open it again I think it should be at the root.

I was just using that as an example where it's particularly evident, but it's present all the time. The simulation for each player-controlled aircraft is run on the player's own computer, in order to give them a smooth and pleasant flight experience (and to avoid the server having to do complex flight modeling for every player). The client sends its controller state and aircraft position etc. to the server, which relays it to the other clients so they can display that player's aircraft in the 3D world. So, if someone's flying along straight and level and then suddenly roll into a high-G turn, the other players won't see the results until your computer tells the server, and the server passes that on to the other players. That can take several hundred milliseconds. In the meantime, your own computer will be "guessing" where the other player's aircraft is and displaying it at the anticipated position. This is fine in predictable flight, but when maneuvering the predicted position can be off by a noticable amount, and then when your computer receives the actual position of the other player, it has to somehow move the other player from the incorrect predicted position to the correct (as of a few hundred ms ago) current position. I think previously the game just "warped" the aircraft to the new location, which when done continually looks very jittery and weird. Landing a helicopter involves a lot of very small changes to control inputs, and so it's very noticable there. But it's a constant problem due to that time window between a remote player making a control change and your computer knowing about it. From Crunch's post it sounds like they're now smoothly moving the other player aircraft from their anticipated position to their actual position, so the effect is less noticable. Also, it's easier to predict the path of a fixed-wing aircraft than a helicopter, so that would help reduce the effect. I've no idea how this would translate to a RIO type position. Transferring control of the aircraft (so the back-seater can take over flying) would be a technical challenge but solvable. The strange motion from the interpolated flight might cause problems for those prone to suffering motion sickness from video games. Theoretically, if the back seat "owns" the avionics and the front seat "owns" the flight model, everything should be copacetic. But there's obviously overlaps which will complicate the implementation. This is probably all solvable to a reasonable extent, but again it's the point that it'd require quite a lot of resources to do well, for the fairly small proportion of players that will actually want to do multicrewed flights. Especially if you also want to make missions where the backseat actually makes the pilot more effective than two single-crewed aircraft would be.

I haven't had time to experiment, so I gave a particular setting that was forcing a change. It's pretty easy to set up if you really want to find out. My guess is that probably anything that's blowing toward the west will cause a shift, but it might require a minimum speed. The game's ATC is not at all sophisticated. If it's not safe to land you could divert yourself, but the game's certainly not going to. Something for the wishlist, maybe.

The main problems I see with a two-seater are latency/synchronisation and having a detailed enough environment to keep both players occupied. I've never played a game in this series (or others, for that matter) that didn't have other players jerking about in weird ways, especially when taking off or landing in a helo. It's not so bad when it's an external aircraft, but I think it'd make for a very interesting challenge to make it playable without weirdness when another player is controlling your aircraft. Might be okay if ED can rework the network model to allow the two players in a single aircraft to have a direct connection with each other, but even that assumes they're close enough that the latency isn't a problem. The issue with the environment detail is basically down to the discrepancies between real life and a simulated environment. Real life combat ops are very demanding due to the extreme fidelity of real life, and the fluid and dynamic nature of evolving battlefields. Both of these are very difficult to recreate within a simulation. The other issue is that if you do manage to create an environment that's complex enough for a two-seater to actually be better than -- or even on par with -- two single-seaters, it's probably going to be unplayable single-player. I think it's a hard call for ED to spend resources enhancing multiplayer as-is; it's a pretty big move to enhance MP at the expense of single-player. And I don't know if the two-seater fantasy has enough mindshare to actually make it worth developing "two products". Still, maybe some innovative AI and interface solution could be found to keep the single-player workload reasonable.

Is that now reflected in the game? I had a feeling that being able to reset a hung JDAM was corrected in one of the patches, but I'm not sure. Don't make enough of a habit of hanging stores to have committed the reset procedure to memory.

Have a look at WarriorX's guide. Edit: apparently the ability to reset hung JDAMs was fixed in a patch, so skip this post and read EtherealN's below. As a practical note, a hung store won't normally be reset in-flight - the pilot would either jettison it or return to base with it and let the ground crew deal with it. It's very easy to avoid getting a hung store just by employing the weapon properly, so I guess in real life if it does hang it's due to a fault with the some component of the weapon system and you wouldn't risk trying to deploy it knowing there's a fault.

Have a look in the guides section here: http://en.wiki.eagle.ru/wiki/DCS:_A10C_Training_Supplements Particularly the three "JTAC 9-line ..." guides.

If your hard deck zone is far enough from the takeoff point that you can expect/require the player to be above 8,000 feet by the time they reach it, then blaster's solution is the easiest. For that, you'd create a trigger zone (let's call it "HARD DECK AREA") and have a trigger with two conditions: 1. Unit <player> altitude less than 8000 2. Unit <player> inside zone <HARD DECK AREA> Action would be set to a flag to true. You can then have a separate trigger activated by that flag being set that displays/plays the message, and optionally use it as part of the scoring criteria (i.e. no points if that flag is set). If your hard deck area is too close to the airfield, you'll need to have another trigger to set a flag when the player climbs to the minimum altitude, and then add another condition to the above trigger of that flag being true. That way, the deck will only come into effect once they've reached a certain altitude. You'll need to devise a method for determining when the mission is over though so you can avoid triggering the hard deck alert when they go to land. Another option would be to add a custom radio option to allow the player to report that they're ready to begin. You can then check they're at a reasonable altitude and/or within a particular area, and then start checking for the minimum altitude. Then when the player is done, they can use another radio option to report they're finished and you can stop checking the deck that way.

Not quite sure what you're asking... if you want the JTAC to just provide additional targets after the first, you should be able to just add additional FAC tasks, and they'll be run in sequence. If you want the JTAC to actually relocate after the target has been engaged, then you'd probably need to use the HOLD task with a flag as a stop condition. You can then use a trigger to set that flag at the appropriate time, most likely on a GROUP DEAD condition. The JTAC group will then proceed to its next waypoint, and you can set up additional FAC taskings there. It's fairly simple, just add a 'Bombing' task to a waypoint for an AI flight, drag the position to where you want the bombs dropped, and set the options appropriately. If the flight doesn't have the appropriate weapons to carry out the task, it will simply skip the task and carry on. For example, if you give a flight only precision-guided weapons and then add a bombing task set to use iron bombs, it'll ignore it. The AI flights won't always compensate correctly for wind, so if you find they miss your targeted point, just offset the target point by the amount they missed by. Might take a bit of trial and error, but they generally miss in a consistent manner so you can compensate for it. Try setting up a new misson with an AI flight already airborne and give it a bombing task. If you can't get it to work, post the mission file here and we can help you understand how to get it to work.

Not "coming from [090]", you mean "blowing towards [090]" - airfields like Senaki-Kolkhi that can operate in both directions will have you take off and land facing into the wind. Runway 09 is the 'default' for this airfield, so you'll only get directed to 27 if there's an easterly. Not sure how strong it needs to be to force a shift, though. With wind direction 132' at 7 m/s I'm getting directed to runway 27. I normally use this airfield and so I've deliberately set the winds to force a takeoff from 27 in order to mix things up a bit. Note that the wind direction in the mission editor shows the direction the wind is blowing towards, which is opposite of how wind conditions are usually communicated.

This video might also be helpful in terms of visualising what it's about. It's done with MS Flight Sim and shows an external view followed by the pilots' view. http://www.youtube.com/watch?v=Wbe_gfk7Cuc

Also note that 'slave all sensors to SPI' (i.e. china hat fwd long) will only slave the Maverick seeker if it's active, i.e. being displayed on one of your MFCDs. If it's in standby then the seeker won't be slewed. Easiest option is to issue the slave all only after you've got the Maverick set as the SOI and a Maverick weapons profile selected.

Yes, the default will basically engage anything it can detect. This is fine for a simple mission where every unit on the map is involved in the same mission, but doesn't work so well in more complex situations. I nearly always delete the default tasks (the -a ones) in order to provide better control. It may be that the SEAD flight isn't detecting any other targets so they're behaving themselves. If you have one of the really long-range SAMs in the mission they'll probably up that radar and go zooming off across the country to engage it.

The key is that the laser code your bombs guide on is set on the ground and can't be changed in-flight. The designator can have its code changed on-the-fly, so if you want to guide someone else's bombs, you have to set your designator to whatever code their bombs have been set to search for. So if a JTAC wants to guide your weapons onto target, you'd need to give them the correct code to use. Designating for someone else has two purposes though: to help them identify the target, and to actually guide a weapon onto the target. Often the designation will only be for the former, so the pilot will set their targeting system to search for whatever code the JTAC is using to light up the target, and then once they've found it the JTAC can stop lasing it. There'd likely be more back-and-forth on the radio as the pilot confirms that what they're looking at is definitely the correct target. After that, the pilot can engage it on their own, i.e. designate for their own weapon. If the intention is for someone to guide someone else's weapons, then I imagine that'd be sorted out in the mission planning phase, well before the planes took off. While it's always cool, it's really only useful in specific circumstances, so most of the time it happens it's probably part of a pre-planned event.

Yes it's normal and one of the changes, i.e. the system now correctly defaults to DTS-derived altitude data rather than steerpoint-derived. You can change it by using one of the down arrows, or maybe both, I forget the exact procedure unless I'm actually doing it. I think you press the data down and it should highlight the DTS setting, and then use sel up/down to cycle between steerpoint and DTS altitude. Note that this is the altitude used in weapons impact calculations. So if you set it to your steerpoint, then you're telling the weapon system you're engaging a target at that altitude. The normal setting is DTS, whereby the aircraft will determine the altitude itself from its stored terrain elevation data. Edit: see this post (just the first one I found) for more info. For waypoint numbering, yes - in a recent patch the game started appending numbers and automatically incrementing them, and it still seems to be doing it. It doesn't happen all the time though, so it's a bit weird. Hopefully it'll get sorted eventually.

Not sure if this is new in 1.1.0.9, but it used to be the case that the 'day' (green) HUD was brighter than the 'night' (amber) HUD when viewed through NVGs. Now it's the other way around - the green HUD is much more comfortable when flying with NVGs, while the amber one tries to burn your eyes out. Attached are two screenshots from pretty much the exact same moment, with the only difference being the second one has the HUD in night mode. The HUD's set quite dim in both (I had been calibrating it in night mode then accidentally switched it to day and was surprised when it became less intense, not more).