nomdeplume

Does the DSMS allow you to configure ripple drops for the LGBs? I was also under the impression LGBs are usually released with more energy than required to hit the aim point (i.e. if left to go ballistic, they'll overshoot the target). Maybe this doesn't apply to CCIP releases, though?

I think you might need to review your startup process? The HUD won't be fully functional until various systems have finished booting up. At the very least you'll need the CICU and IFFCC on, and your DSMS profiles loaded. There might be other stuff required for full functionality, e.g. the EGI aligned and activated for the TVV.

The triggered 'switch waypoint' crash is a known bug. You can only safely use 'switch waypoint' as a waypoint action, not as a triggered command. For your case, I would just set a "stop condition" for the orbit task so it stops when a particular flag is set. Then, have the radio trigger set that flag. The B1 will then stop its orbit task and progress to the next waypoint. JTAC is pretty fiddly. Make sure you're using a unit with a 'large calibre' weapon (armed HMMWV is commonly used) and it has a clear line-of-sight to the target.

Don't get too hung up on ping times. We regularly have people with pings in the 300-500ms range and there's no issues. I think the weirdness is more dependent on the reliability of the path between the client and the server; I watched some warping all over the place despite having a very constant and relatively low ping. Personally, I don't think the ping time is a useful metric. It might matter more if you're doing PvP, of course. Stability definitely seems to be mission-related. I think there's certain events that can cause a server crash if they occur in a particular way; but trying to pin down the exact circumstances is difficult. The most recent crash I had didn't even produce a .crash logfile; as far as I could tell, it occurred after a tank exploded on a bridge (it was stuck there with several other units due to the pathfinding 'issues' :D). The bridge then exploded and immediately it happened - no more server. Actually reproducing this one is difficult, since obviously the game doesn't crash every time you blow something up that happens to be on a bridge. And of course there's the possibility that the crash was caused by something else happening elsewhere and had nothing at all to do with the events I happened to be watching! Generally I just try to avoid running complex missions - although it's hard to define what 'complex' is. 'The Playground' which is usually active on the AEF's server has triggers to set the ROE of various groups and to spawn additional tankers, but it's pretty much rock solid (at least on the server). I've seen it running for over 8 hours without issue. It automatically restarts the mission if all the clients leave, so that was 8 hours of continuous use by a variety of clients that were coming and going, using both aircraft, without any problems (aside from the scenario not really having 8 hours' worth of content...).

True, but we may have just gotten lucky there - it was originally planned/expected to be the A-10A. Only time will tell if that was a one off or if modernised versions of aircraft will be the norm. Also, the Ka-50 isn't exactly cutting-edge technology.

The menu is for items relating to the AI; the wingman/flight menus refer to additional AI-controlled aircraft that are part of your flight (i.e. aircraft group in the mission editor). So in a multiplayer mission, this menu wouldn't be available since you don't have any AI wingmen. [it is possible to have AI wingman in multiplayer missions, but very rarely done.] If you want to talk to your human wingmen, use Teamspeak or Ventrillo or Skype or something like that. Or the in-game text chat, if you're desperate.

What are you expecting to do with the UHF radio? From the mission briefing, it would appear that whoever is hosting the mission will need to use the "F10 Other" options in the radio menu to interact with other flights. Note that these options essentially just set a flag that the scripts can use to determine which option you selected; they don't really use the radio per se. These options can be accessed from any of the comms menus. The other one you might want to interact with is the AWACS, but he's on 124 MHz AM.

Masking is based on configuration of the stores, rather than any kind of detection as to whether or not the view is actually obstructed. IRL I believe there's multiple masking profiles; in the sim, there's only one. So, I think the masking behaviour is based on a "worst case" scenario. It's just a limitation of the pod that you'll need to learn to work around. 20-30 degrees off the nose doesn't sound too bad though, unless you're at a fairly low altitude. If you're seeing masking which seems completely unreasonable you could pause it and post a series of screenshots showing the TGP's view as well as external views - I think you'd need to provide pretty compelling evidence that the masking is too aggressive.

China Hat Aft Long is "slave TGP to STPT". What you describe sounds like the correct function of this control, although it shouldn't "erase" your SPI; but I'm not sure what you mean by that. It might reset your SPI to the STPT if the TGP is currently your SPI, but I'm not sure. Details, details... China Hat Fwd Long is "slave all sensors to current SPI". If your TGP is the current SPI it won't have any effect on the TGP, naturally. It will also only slave/slew the Maverick seeker if the Maverick seeker is currently displayed on one of your MFCDs. If it's not being displayed, then the seeker will be in standby mode and not available for manipulation.

TCP would make things far worse, because if a packet is dropped the entire stream will hang until the drop is detected and the packet is re-sent (TCP guarantees in-order delivery of all packets, has built-in retries etc., which is outside of the application's control). There's a reason almost no real-time apps (games, voip, streaming video etc.) use TCP. You could still measure packet loss with UDP though, especially in a game where you're expecting each client to send you packets at specific intervals. In the simplest case, you could just include a "sequence number" in each packet the client sends, and if the server is expecting packet #10000 from a client and instead receives #10001, it knows one was lost. This would also treat packets that arrive out-of-order as 'lost', but that's probably desirable (no sense updating a game object with old information). I actually think it would be very helpful for diagnosing issues and determining where problems are if the server did collect metrics on player connection quality and reported them in the player list screen. Currently it just performs a ping test periodically and reports the time, but it could 'easily' be extended to provide some actually useful information: - keep results of the last e.g. 5 pings and display the average (mean) value and the amount it varied by so you can estimate jitter. So instead of just showing the ping is 50 ms or 300 ms, it could show "65±12" or "302±132" - which would give you a better idea of just how crap the connection to the client is; - count the number of packets successfully received and not received over the same interval and report it as a percentage of packet loss - or simply a count of the # of packets lost. That way you could see at a glance if someone's connection is terrible, and if everyone has a terrible connection then it implies something is up on the server side of things (maybe saturated bandwidth or just a crappy link). Whereas if everyone is showing low jitter and 0 packets being lost but there's still weird stuff going on, it'd point to issues with the code. Don't forget the game also has a track replay feature. It's a little bit different to multiplayer, but it still deals with the basic concept of transferring events that occurred in one instance of the simulation to another instance. It doesn't rely on the unreliable internet, but still routinely fails to play back an accurate record of the events that occurred in the game. So, assuming the netcode is as good as it could reasonably be and that any issues are because of the big bad internet is premature, IMO, when we already have proof that the game can't be relied on to recreate events even when using a lossless transport medium with practically unlimited bandwidth (local HDD).

There's two game modes, "game" and "simulation" (or "real"). Each has a completely different separate set of control bindings, so you may have your controls configured properly in one mode but not the other. In the Options menu, go to the "Gameplay" tab and make sure your settings are as desired (i.e. both Game Flight Mode and Game Avionics Mode are disabled if you want to play in simulation/real mode), and then make sure the "Use these options for all missions" option (at the bottom right) is enabled. This will make sure your settings override whatever was specified in the mission itself, and you'll get consistent behaviour across all missions.

I'm not worried about the warping, that's expected and I don't see any way around that. What I think could be improved would be the events that never occurred for any player somehow making it into the server's view of the world. That guy sitting on the ramp next to me starting his jet never slid 10 metres to his left and into me. There's no way his client actually sent data to the server saying it was sliding sideways across the tarmac; nor did the guy taking off have his client send information to the server that it was now balancing delicately on its tail. So either the server received data that the client didn't actually send and should've ignored it (checksums?) but didn't; or it did reject the bad info and the server tried to predict the actions and came up with something which was not only manifestly not what the client did, but also physically impossible for the client to do.

There could definitely be some improvements made server-side e.g. rejecting impossible updates from clients. It's pretty common for planes and helos to be twitching around the place in physically impossible ways. Even if we assume the network connection is terrible, planes should at least behave like planes. I replayed a track (recorded by the server) to take screenshots, and when one of the guys was positioning on the runway for takeoff he suddenly juts 90 degrees up and stands on his tail. After a few seconds of that, the aircraft suddenly reverts back to normal position. My personal favourite though was starting up on the ramp and having the guy next to me slide sideways into my plane and explode, leaving half his wing on the ground next to me and a message saying I'd killed him... before warping back to his original position (still dead, though). Even a fairly permissive filter should be able to stop those kinds of impossible events from happening.

Had a look at the Maverick tutorial videos here?

We'd probably need an example mission, since it's hard to describe everything that might be relevant. The 'attack group' command is a triggered task? Have you verified the trigger is firing? Can the Ka-50's detect the blue vehicles? You might want to try putting yourself in an aircraft that has LoS and radio set to the same frequency as the AI flight so you can hear them call out contacts in order to verify they're aware of them. Maybe there's also a conflict between the orbit and attack group command? Maybe for a test have the orbit command be halted before you fire the attack group?

The A-10's throttles have a "hump" between the OFF position and the IDLE position (which is just forward of the OFF position). In order for the throttle to be moved from OFF to IDLE, it needs to be pulled/lifted up in order to get over the hump. Similarly to get to the OFF position, it needs to be lifted up from the IDLE position and moved down. The ThrustMaster Warthog HOTAS has this functionality built-in to the throttles: in the OFF position, each throttle activates a DirectX button. When lifted up over the hump and moved to the idle position, this "button" stops being pressed down. The game detects and moves the in-game throttle to match. If you have a regular HOTAS, you only have the linear axis for the throttle motion (from IDLE to full), without an OFF position. Since the distinction between the two values is important (IDLE means the engine is running, and initiates the auto-start sequence if it's not - OFF shuts the engine down) the sim needs to provide this functionality even if your physical controller doesn't. It does this by maintaining the state of the in-game throttles, and rejecting inputs which are invalid for the state it's in. So when you start a new mission on the ramp, the in-game throttles are initially in the OFF position. Hence, movement of your HOTAS throttle is ignored until you use the key commands to tell the game to move the virtual throttle from OFF to IDLE - since it's not possible for the throttle to be moved when it's in the OFF position. Additionally, in order to prevent weird/undefined behaviour from occurring, the game will only allow you to use the keystrokes to move from OFF to IDLE if your HOTAS throttle is in the IDLE position. This is because the real throttle control cannot go from OFF to e.g. max thrust - it's only possible to transition to/from the OFF position from/to the IDLE position.

Yah, I wouldn't bother with the patch unless you're only one version behind. Since you're two versions behind, I'd just download the full 1.1.1.1 version from the download page, uninstall your existing one, and do a new install. Your controller configuration and other settings are stored in your profile (on Vista/Win7 in C:\Users\username\Saved Games\DCS Warthog) so you won't lose any of those customisations. Note that the full installation is four separate files, that all need to be downloaded to the same directory. You then run the first one (the .exe) to start the installer. Each file has several mirrors available. There's also a torrent at the bottom of the download page which will allow you to download all the files using a bittorrent client, which also performs an integrity check to make sure your downloaded files are complete and without errors.

The main worm is that it saves all your aircraft settings, including the DSMS profiles. If you change your weapons loadout, it will still try to load the DSMS profiles, and if the weapons you actually have don't match the saved loadout then weird things will happen. You can fix that by opening the .miz file (it's just a zip archive) and deleting the DSMS settings.

"I tried the F10 thing but nothing came up" - do you mean nothing happened when you pressed F10? If so check your options to make sure you have access to the map view enabled. If you did get the map but didn't see the frequency, did you click on one of the airdromes to select it? "Is it possible to set the ATC frequency automatically in the briefing" - not sure what you mean? There's no way to automatically add the frequency to the briefing, I normally put a FREQUENCIES section near the top of the task and include ATC/FARP frequencies that will be required for the mission.

That's the standard way of doing it, and yes it's a pain. The addition of "OR" clauses in trigger conditions at least reduces the volume of triggers you need. Yes. The given reason IIRC is that Russian guided CAS procedures (FAC/JTAC type) is quite different to how the US does it.

Aircraft can and will run out of fuel. You cannot make an AI aircraft land and take off again. Only players can do that. There is a "switch waypoint" in the advanced waypoints properties. So, if you want the loop to begin at waypoint 2 for example, set up the additional waypoints and then add a "switch to waypoint" command at the end of the loop. Once the aircraft reaches that waypoint, it will then head to the waypoint you told it to switch to. You can use conditions to prevent the "switch to waypoint" command from being executed after a certain amount of time or some other event occurs (in combination with user flags and triggers). There's also an "orbit" task which will have the aircraft fly either a circling pattern at its current waypoint, or a racetrack pattern between the waypoint you put the orbit task on and its next waypoint. This can easily be set to last for a certain duration, so it's nice to use for those cases. If you need the aircraft to fly a more complicated pattern then 'switch waypoint' is the mechanism to use. There is a "refuel" task which you can make an AI perform in order to refuel from a tanker (in-flight refueling), however it's only available for aircraft actually capable of in-flight refueling. The AWACS aircraft have enough fuel to stay airborne for several hours though, so you should be okay for most missions. If you really need to, you could add a second AWACS flight to take off at an hour or two into the mission in order to relieve the previous one.

Pretty sure the required vehicles are listed in the GUI manual, too. One thing I noticed which is slightly unexpected is that the required vehicles are determined by the units' coalition (i.e. BLUE or RED), not the nationality. For example if you have a coop A-10 (US) and Ka-50 (Russian) mission with your team being on BLUE, then your Ka-50s will require the US service vehicles at the FARP, even though their country is set to Russia. On the other hand if your side is set as RED, then everyone will require the Russian service vehicles at their base, even though the A-10s are set to country US. Hopefully that makes sense. So basically in the data Speed posted, RUSSIAN_FARP means "Red" and WESTERN_FARP means "Blue".

Unless the page selections (etc.) are stored on circuits that are near (or in) the MFCD, so a loss of the MFCD implies a loss of the system that controls the MFCD.

The only other thing you'll need to play around with is the slew control, using the mini-stick thing on the throttle. If you've tried to use it for anything, you'll know it's not all that precise. You'll also likely want to adjust the curves for the pitch/roll axis, but that's also personal preference. I find it a lot easier to fly formation and that with a decent curve on it, but then I might just be incompetent. For mouselook, you also use the mouse to activate various switches in the cockpit, and even with the TM Warthog you'll still need to click on things (unless you're good at memorising key combinations for controls you rarely use). You can toggle between mouselook and mouse-for-clicking with Alt+C (IIRC, I use TrackIR :D) so you can leave it on until you need to click something. The one "downside" of the TM Warthog is that it doesn't have a twist axis for rudder control, and takeoffs and landings using the keyboard rudder controls are pretty awkward. There is a spare axis (where the throttle friction wheel is on the real throttle), but I imagine it'd be pretty weird to use that for rudder.

Is the FAC task a "Perform task" one or an "enroute task"? If it's "Perform task" then the processing of the commands stops until the command is completed. Which means, the callsign and frequency would not be set. So, I'd try moving those options up, i.e. assign the group a callsign and frequency before asking it to provide FAC services. I don't understand the second part, "can you stop the afac from call details until you ask".