nomdeplume

...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).

There's also a speed indicator on the steerpoint page which can be cycled between IAS/TAS/GS.

The easiest way I think would be to create an overhead mark point at your current location, then set your nav to mark point mode and make that your active steerpoint. Then you can just watch the distance tick up. Unless flying that exact distance is really important, you can also just do a time calculation, i.e. work out how long you need to maintain your current speed for in order to cover the specified distance. Won't be quite as accurate but for following ATC directions should suffice.

I think command are more likely to give you a hard time for recklessly endangering yourself, your wingman and your airframes by trying to dogfight with enemy aircraft in your ground attack plane. :P There's CAP and SEAD flights in that mission which you can release using the radio (F10 'Other' submenu). But, congrats. It's pretty good fun bringing a wounded jet home. Almost worth getting yourself shot up for! :D

If you do want to enter it/change it, it's done through the TGP's CTRL page. i.e. set the TGP to A/G mode, then use the CTRL OSB at the top left. On the left side of the screen are two codes, one is for search (LSS) and the other is the code it emits (not sure what that's labeled as, but should be pretty obvious). The search code is used when the TGP is in laser search mode, and needs to correspond to the code being transmitted by whoever it is that's designating the target for you. If it's JTAC, they'll tell you the code they're using, but it's probably always 1688 (the default) so you won't need to change it. In MP flights you can be more creative. If you change the code your own designator emits with, you'll also need to change the code the bombs your guide on. That's done through the DSMS inventory page. In the real world, the code is physically selected on the bomb and can't be changed by the pilot. In the sim the DSMS inventory settings serve that purpose, so if you prefer to play realistically you should restrict yourself from making any changes unless you're on the ground (i.e. pretend the ground crew are doing it). I don't know what real life procedure is, but I guess at a minimum the bombs loaded on each aircraft in a flight would be configured with a different code if there's any chance they'll both want to engage simultaneously.

Caribbean Airlines flight BW-523 (a Boeing 737-800) carrying 157 passengers and 6 crew overshot the runway when it landed at Cheddi Jagan airport in Georgetown, Guyana. The front part of the plane broke off. No fatalities, but one broken leg and various other injuries. See link for more & video: http://www.abc.net.au/news/2011-07-31/plane-crashes-in-guyana/2817690