nomdeplume

Works consistent for me, but I have found you need to make their ROE 'weapons free' - even with 'return fire' they won't execute a fire at point. So your best bet is to make the friendlies invisible (so they won't be automatically engaged) and have them set to hold fire or return fire (so they won't open up). You can always make them visible again with a trigger later if you want them to get mowed down if the player takes too long to respond. Attached is your test mission with the 'fire at' point moved closer to the insurgent position (so they can actually fire at it), and a repeating trigger to have them fire in relatively short bursts. It never disables (so they'll keep firing at that point in bursts until they run out of ammo), but you could stop it at any time by disabling flags 50, 51 and 55. The timing kind of sucks but you can play around with it. I think for it to work well in this particular situation you'd need a few different 'fire at' points to better follow the progress of the friendlies. It might also be nice to split the insurgents into multiple groups and have them firing at different positions so the aim point isn't so obvious. Also the triggers I've put it indicate when they've activated - you'll see it takes a few seconds from the AI 'fire at point' task being activated until they actually start firing at that point. They cease fire as soon as soon as the stop flag is set, though. Just something to factor in when you're playing with the timings. I've randomised the start time to be from 5-25 seconds from when the start flag (#50) is set - to make the bursts a little less predictable. testbed.miz

The target point is just too far away. I set it to ~ 200 metres from the group and they started firing immediately. I think infantry can engage up to about 300 metres when you are using fire at point. RPGs have a longer range but don't seem so keen to take advantage of it. I set up a repeating trigger to enable the AI 'fire at point' task, and then set a flag that stops that task after about 15 seconds. It usually takes them a few seconds to start shooting, so that gives a few seconds of tracers and then you can pause for 20-30 seconds before repeating. That allows a small group to keep putting out fire for a long period to enable the player to spot the tracers.

I knew at least one person wouldn't bother reading the whole post before responding to it. Although, I am impressed it took this long! :)

The only way to automatically advance to the next waypoint is by flying over it, so yes, it would've been the player manually selecting the next waypoint, then using china hat fwd long to slave all to the spi, then locking the Maverick and firing. Bear in mind you can advance to the next waypoint using the waypoint rocker switch on the UFC regardless of what the SOI is, so if you have that bound to a convenient key/button then you don't have to take your hands off the controls in order to do this. The MAV may well have been SOI, as the mark points would have been set up earlier (probably using the TGP). Once they've been created you don't need the TGP again.

As far as campaigns go, anything > 50 is a success (move to next stage of campaign). But keep in mind there's two numbers reported these days, and I can't quite remember what they're labeled as. 'Score' and 'Result' or something like that? One of them is your personal 'score', which I think is calculated in the same or similar manner to in MP, i.e. based on the number of units you (personally) kill of various types. So if you're taking a supporting role in a mission and don't shoot many things, you'll have a low score; but it doesn't really mean anything. The 'result' is the score assigned by the mission designer, which can be based on completely arbitrary rules. Generally they'll have something to do with whatever the mission briefing tells you your mission is. This is the one that matters for campaign missions.

Are they set as ROE -> HOLD FIRE by any chance? I think they'll 'fire at point' if you set them to RETURN FIRE, but HOLD FIRE really does what it says on the box...

Have a look at the warning lights panel. Any new (unacknowledged) warnings will be blinking. You can silence them with the master caution button on the UFC. If by 'APU switch' you mean the APU generator switch on the same panel as the battery switch, then the first warning you're hearing is that the APU generator is enabled but not running/active (because the APU hasn't been started). Also don't forget to enable the inverter when you're powering the jet up. This is required for power to some of the engage gauges.

The built-in tasks don't allow you to assign targets outside of the group's main tasking. So you can't assign a CAS flight air targets (except for helos). Aircraft with non-CAP/sweep missions will only attack other aircraft if they are attacked first. So for example if you give some F16s a CAS tasking and some MiG-29s approach them, they'll ignore the enemy aircraft until the Migs attack the F16s. I think they respond when they're locked up on radar, but that pretty much always means the aggressor gets the first shot. This makes it not very useful for CAP type activity, since it guarantees they'll start out any combat action on the back foot. Similarly if you set a group's task to Ground Attack, you don't get any options in the ME to have them engage particular ground groups or units or within a zone. So you can't e.g. have some F-15Es come in and do a bombing run at a particular point (using the 'bombing' task), then circle around and intelligently engage any survivors (using an 'engage within zone' task, for example).

I think proper evasion techniques require you to know what you're evading, i.e. to have visual on it (ideally) so you can see what state the incoming missile is in. No point evading a missile if it's not tracking you, for example. And normally the last-ditch evasive method is to break hard into it when it's a few seconds from impact - and you need to know where it is and how quickly it's closing to arrange that. Getting visual on a missile is pretty tricky on our limited-resolution displays, though. I mean, at least while you still have a chance to do something about it. Although it's probably also noting that in the real world, your wingman would be providing cover and will fix the location of the launch for you so you can concentrate on evading.

The uploader has not made this video available in your country.

He didn't fall asleep, he was still unconcious after being clobbere at 5:13.

Is it an armed humvee? I think that laser/IR pointer is only available for units with large-caliber weapons. You might need to set its engagement mode to 'return fire' to prevent it from shooting at the bad guys, though 1km might be far enough away to keep it out of range.

But it's not magical, it won't do it by default (except maybe for MS Flight Sim?). So unless you're willing to put in the time to learn how to export data from DCS and have the Saitek software put it onto the display, it's not really a selling point. Also, I'm not really convinced of the utility of putting information on the throttle, given that you're not supposed to actually be looking at the throttle...

Hmm... I tried it and went back. :)

I haven't deleted everything for patches most times. Only if I feel like something weird's happening or I'm missing changes that've been made to the control configuration screen will I wipe them. I think those instructions are just the "failsafe" version, i.e. if you follow them then you eliminate every potential problem.

You could keep the 'config' folder under your user directory to preserve your settings. I guess it depends what you're doing the full re-installation for - if you're having problems it's probably better to start clean. Bit of a pain in the short-term, but in the long run it's worth it. If you aren't having any issues then I'd just leave your local user folder alone so you don't lose any settings etc. As a compromise, you could back it up (move it somewhere else) and then you'll have something to refer to if you need to, and/or just copy across parts of it (like the controller configuration).

Thanks for the info, Speed. I guess the trucks aren't needed. I still like to add them though, since it adds authenticity and gives you more things to spot + shoot.

You can use Alt+C to toggle between mouselook (move mouse to look around) and mouse-as-cursor for clicking on things. I don't think you can bind the right mouse button, since you need that to interact with some of the controls (and some of the knobs need mouse wheel up/down).

No, the A-10's autopilot is not route-following. It has 3 modes which hold either your current path (can be useful for long clims to altitude), your altitude and current heading (when you want to keep going straight while you concentrate on other things in the pit), or just your altitude (useful for orbits). No, there's no HUD indication for ILS and there's no automatic landing system. It's a warplane, not an airliner. :D P.S. The speed brakes are controlled via a switch on the throttle, look in the HOTAS section of the controls configuration.

Yes they run out of ammo. They tend to fire at their maximum rate, so to get them firing longer you'd need to have them only fire for a short time (enough to get only a few rounds off) and then have them stop and start again. The problem with that is you'll have to wait for them to 'aim' again so you'll face a minimum 2 minute delay between each set of shots. If you have a few different groups timed properly though you can set up a fairly continuous barrage that lasts a long time. I think they should reload if they have a truck in the same group; for the US forces it's obvious which truck to use, for the others I think the Ural-375 is good, but probably a few others can do it as well. Reloading will take at least a few minutes, though.

It's "Toggle goggles" in the controls configuration, category Sensors.

It's one of the waypoint properties. You need to find the player flight and select it by clicking on it, which will give you properties for the flight on the right hand side of the screen. You can tell if it's the player flight because the skill level for the lead aircraft will be set to 'player'. Below the flight's properties you'll find the waypoint information. You can cycle the waypoint back to the first one (if you selected the flight by clicking on some other waypoint, rather than the aircraft's icon). Once you've got your initial waypoint displaying, you can change its type. For a runway start it'll be listed as "Start from runway", just change it to "Start from ramp" to do a ramp-start. When you change it to "start from ramp" you'll get an additional option to set the parking spot. These are numbered and if you select one, the aircraft's icon will be placed at the position. So you can decide if you want to start on the ramp or in a hangar, and if you want to place yourself close to the active runway or further away.

Yes that's right. You can also use the SEL rocker on the UFC, or you can open the profiles page on the DSMS and use the up/down OSBs to select the profile you want, and then hit the ACT PRO button on the left to activate it. If you're using DMS left/right (with HUD as SOI) or the SEL rocker, bare in mind that if you're in guns mode (a-g or a-a) that'll select different reticules rather than cycle your DSMS profiles. You need to be in CCIP, CCRP or NAV mode for it to cycle profiles. Just something to be aware of if you've just gun in for a guns run and then want to come back around with rockets or bombs or something. Yes, that's exactly right. If you want to drop a specific weapon you can select a DSMS profile and then de-select particular station(s). That way you can still control exactly which munition is used, but still use your preconfigured profiles.

VRinsight panel and AutoHotKey configuration Thanks hassata, AutoHotKey seems to detect them (as joysticks #10 and #11) so I think the future is looking bright. Thanks again! Edit - so after a lot of messing around this is what I've come up with, and it seems to work pretty reliably. The first issue I had was in getting DCS to actually recogonise/respond to the keypresses. I tried a few methods that AHK offers, and found the most reliable was to use SendInput with "key down" commands, pause for a short time, and then send "key up" commands. This seems to be completely reliable, at least for me with Warthog 1.1.0.9. The other issue I encountered was with getting the switches into a state which matches the in-game switches. This isn't a problem for those that have individual mappings (e.g. master arm on, safe, and training can be assigned individual keystrokes), but it's a problem for many of the switches which are only accessible as toggles (e.g. TGP). That means you have to send the same keystroke for "tgp on" as for "tgp off", so it's easy to have your physical switch doing the opposite of the in-game switch. Additionally, it seems AHK will detect a "button down" event for any switch that is currently up as soon as you press any button/flick any switch on the panel. You can also use it to determine the button number of each switch. For example, if you've got one of the switches in the "on" position when you start the AHK script, nothing will happen at first. But when you flip a switch or press a button on that panel, the event for what you just did will be triggered in parallel to the event for the switch that was already in the on position. My solution to that is to assign one of the switches on the panel to toggle whether the script is actively sending keystrokes or not. When it's off, it will still notice button state changes and set up the listeners for when the switch is turned off, but won't actually send the keypresses. That way you just start it up with that off, mash a button on each panel, and then turn it on. I won't post my whole script but here's the gist. Firstly I start with this: #SingleInstance #NoEnv #MaxThreads 1 SendMode Input holdDownTime := 50 pollInterval := 100 sendKeystrokes := 0I'm not sure if the maxthreads thing really helps, but it doesn't hurt. Basically I'm just trying to prevent multiple commands trying to run simultaneously. The holdDownTime is the time (in milliseconds) to hold down the key combination for. This seems to work okay for me, but it's easy to adjust having it as a variable. The pollInterval is the time between checks for when the button is switched off. Finally, sendKeystrokes is the flag which controls whether we're actually sending the keystrokes or not, so it's set to 0 (false) to start with. Each button needs two handlers, one for it being pressed, and one for it being released. The "pressed" handler is a hotkey using the xJoyN syntax. You can find out the joystick number through trial and error by using the test script which is accessible through the AHK helpfile (it's linked in the Joystick section on the 'List of Keys, Mouse Buttons, and Joystick Controls' page). Just change the "JoystickNumber" variable at the start, starting with 1, try a button on your panel, and see if it registers. If not, go to the next number. My panels ended up joystick numbers 10 and 11. This is the script I use to control the sendKeystrokes flag, which is controlled using the bottom-left switch on my Multi Switch panel. ; toggle sendKeystrokes flag 11Joy13:: if sendKeystrokes = 0 { sendKeystrokes := 1 SoundBeep 400, 100 SoundBeep 800, 250 } SetTimer WaitForSendKeystrokesOff, %pollInterval% return WaitForSendKeystrokesOff: if GetKeyState("11Joy13") return SetTimer WaitForSendKeystrokesOff, %pollInterval% if sendKeystrokes { sendKeystrokes := 0 SoundBeep 800, 100 SoundBeep 400, 250 } returnNote that it plays a two-tone indicator when switched on and off; be warned that it's quite loud. You might want to turn your sound down before the first time you try it... The "11Joy13::" bit sets up a hotkey for button 13 on the 11th joystick. This checks the sendKeystrokes flag, and it's not set, enabled it and plays a tone to indicate it's done so. It then sets a timer to call the routine WaitForSendKeystrokesOff at the poll interval defined earlier (100ms is what I use). This just means that every 100ms, that part of the script is run. To detect if it's off, we use the AHK function GetKeyState with the button name. If it returns true then the button/switch is still down/on. So, as long as the switch is in the "up" position (which means the DirectX button is being held down), every 100ms AHK will check that state and then do nothing. Eventually when you turn the switch off, the routine wakes up, checks the status of the button, discovers it's no longer down, and then runs the rest of the code. The first thing it does is disable the timer which calls itself (so it stops polling for the button to be released), and then it toggles the sendKeystrokes flag if necessary, and again plays a tone to indicate it's taken action. So what about actual game actions? These are handled by detecting the switch and then sending the appropriate keystrokes, so as long as the sendKeystrokes flag is set. We then start another timer to monitor for the switch to be turned off, and then send the appropriate keystrokes for that action. So here's an example for the landing gear, which can be assigned separate keystrokes for "raise gear" and "lower gear" in the sim (which means this particular switch can never be desynched): ; landing gear 10Joy26:: if sendKeystrokes { Send {LCtrl down}{g down} Sleep holdDownTime Send {g up}{LCtrl up} } SetTimer WaitForGearDown, %pollInterval% return WaitForGearDown: if GetKeyState("10Joy26") return SetTimer ,, off if sendKeystrokes { Send {LShift down}{g down} Sleep holdDownTime Send {g up}{LShift up} } returnIt's very similar to the script for the sendKeystrokes toggle switch, but instead of just changing an AHK variable, we send some keystrokes. The script for things like the TGP switch which only have a single keybinding are the same as the above example, except they send the same keystrokes in both the up and down positions. That means it can get desynced, e.g. if you usually do a ramp start, your physical TGP switch may be down, but if you do an air start mission one day it'll start on. You can correct that just by turning off the sendKeystrokes flag with the appropriate switch, flipping your physical TGP switch on, and then turning the sendKeystrokes flag back on. My final example is the three-state switch (T4) on the MS panel. I use this for the gun, since I use all 3 modes quite regularly. Here it goes: ; gun arm switch up 11Joy17:: if sendKeystrokes { Send {LAlt down}{a down} Sleep holdDownTime Send {a up}{LAlt up} } SetTimer WaitForGunArmOff, %pollInterval% return ; gun arm switch down 11Joy18:: if sendKeystrokes { Send {LAlt down}{g down} Sleep holdDownTime Send {g up}{LAlt up} } SetTimer WaitForGunArmOff, %pollInterval% return WaitForGunArmOff: if GetKeyState("11Joy17") return if GetKeyState("11Joy18") return SetTimer ,, off if sendKeystrokes { Send {LAlt down}{s down} Sleep holdDownTime Send {s up}{LAlt up} } return This is pretty much identical to the two-state switch examples above. The only differences are a) there's two buttons which both set up the WaitForGunArmOff timer (the three-state switch controls two DirectX buttons, one of which is 'pressed' when the switch is in the up position, the other which is 'pressed' when the switch is in the down position; in the center position, neither button is being 'pressed'); and b) WaitForGunArmOff checks the status of both buttons that invoke it, and only takes action if both have been released. Hope this is clear enough and saves someone else a bit of time trying to implement this. It's a bit of effort but it works well once it's all running. Note that most of the game's controls don't have default keybindings, so you'll have to add them as you go.

Very late to the party... but the answer is yes with a caveat. They are just standard USB controllers, however the switches are presented as a single DirectX button. That means when you move the switch up the button is 'pressed', and when you move it down it's 'released'. That's fine and good, but since you can't assign an action to "button released" in DCS, it means you can't make a single switch e.g. raise the gear when it's up, and lower it when it's down. But, some of the controls in A-10C do work like that, i.e. anything that's on the TM Warthog throttle, such as the APU start switch. However... the particular command that's assigned to the TM Warthog throttle's APU Start/OFF switch can't be assigned to other controllers. Seems like it's a special command just for that controller. So - does anyone know if there's a way to configure DCS to recognise these kind of switches for arbitrary commands? Or - does anyone know of any software that can be used to translate DirectX device inputs into keystrokes? The same kind of functionality that TARGET or SST or CH Control Manager has - but not locked devices from the respective vendor? The buttons and axis controls work just fine, although I haven't found any other functions in A-10C to assign the axis commands to. The encoder rotaries in the middle of the MS panel function as two buttons, i.e. each turn clockwise registers one instantaneous button press, and each turn anti-clockwise registers one instantaneous press of a different button. The "T3" and "T4" buttons on the MS panel are three-state (up, middle, down) - T3 returns to the middle position automatically while T4 will hold in whatever position you move it to. These both are presented as two separate DX buttons, one for "Up" and one for "Down", with the middle position being both buttons off. So, they work like the LASTE mode switch on the TM Warthog throttle. So again the issue is with getting the game to recognise the buttons being released as an event worth reacting to.