nomdeplume

Also double-check that you've actually set your SPI to your targeting pod (or whatever you're using to designate your targets). The bombs will programmed with the coordinates of your SPI at the time you release the weapon, regardless of what the SOI is. It should say "TGP" on the bottom left of your HUD -- if it says STPT, then you're dropping the weapon on your current steerpoint, which might be confusing if it happens to be on or near one of your targets.

It will only show in the comms menu if the tanker is currently active, i.e. flying around and executing the "Tanker" task (click the Advanced (Waypoint Actions) button to see the list), which is automatically added when you set the aircraft task to Refueling.

It's mostly driven by what aircraft they can get sufficient information on to be able to model to DCS standards. For the most part, that seems to be dependent on having an operator or manufacturer contract ED for a training simulator, which gives them access to the information. Then if they're lucky, they can get permission to develop a consumer simulation using (some of) that information.

There's no way to do this, the simulation and the main menu/editor interface are actually separate programs.

Just to make sure it's clear, that applies to the "ONCE" trigger types. Basically their conditions are evaluated every time the triggers are run (approx. once a second) until they become true, at which point the actions are executed and the trigger deletes itself. So the "ONCE" refers to "One activation", not "consider these conditions once". 'CONTINUOUS ACTION' triggers don't delete themselves after they run, and continue to be evaluated every second, running their actions whenever the conditions are true. So, they're exactly like "once" triggers, just without the self-deletion aspect. The 'SWITCHED CONDITION' triggers function somewhat like continuous triggers, but have some extra code that prevents them from running their actions again until their conditions evaluate as false, at which point it is 're-armed' and will run its actions if it evaluates as true again. The 'MISSION START' triggers are only run once, i.e. "evaluate these conditions when the mission starts, then forget it ever existed". Yes you are right in thinking that. Hence, if it really matters, you would want to use flags to limit the number of things that can be spawned, or force some things to spawn if there's not enough. Or an alternative approach would be to populate the mission with some activated-at-start groups (i.e. they will always be there) as the core mission elements, and then the random things can be used to add some variation to the mission to keep people on their toes. In the long term it'll probably average out to 50/50, pseudo-random number generators of the type games typically use are pretty good. However it's of course possible to get a random sequence generating even the same number over and over 100 times in a row. Unlikely, but possible if it's truly random. So the short version: the designers of that particular mission aren't relying on any special tricks, but rather the bell curve - most times that mission is run, a 'medium' amount of those groups will be activated. Probably the mission design is such that they felt the edges of the bell curve don't really matter, i.e. the mission would still be fun even if all those random groups spawned, or if none of them did.

If you use the "Set Flag Random Value (Min, Max)" action, then you're guaranteed that the flag's value will be an integer between the minimum and maximum specified, so it's a very easy way to get randomised behaviour without the risk of nothing getting triggered. An alternative (if you're using a bunch of individual flags) is to have a trigger with conditions set to activate if all of the flags are false, to provide a fallback option. However, bear in mind that triggers of type "once" will be evaluating constantly until they become true. So a trigger with a condition of "random 1%" will eventually be activated, it just might take a while. This is why these kinds of conditions are usually protected with a sentinel flag, i.e. each one also has a condition "flag X is false" and when any is activated, "set flag X true" to prevent any of the other triggers from activating. You can also add an or part to the trigger conditions, using "time more than X" or "time since flag more than X" to ensure one of the triggers is activated within a certain time frame, if that's important for your mission.

If I remember right, the / (or \) radio menu option will only work if you've got simplified radios enabled (Gameplay options - "Easy communication"). If you're using realistic radios, you'll need to open the radio comms menu using the appropriate HOTAS MIC Switch button.

^^ Thirded. Or at least, they could regulate their taxi speed (and maybe even their braking rate?) based on the available runway length.

The DCS World modules are installed under the Mods\aircrafts\ folder under the DCS World installation directory.

You could probably just use the 'repair' option - pretty sure that should scan your install and re-download any files that are missing or different from the official ones. Did you re-install the modules? If you uninstall DCS World, it will also uninstall any modules you've installed into it (the modules don't get their own icon in add/remove programs, for example).

^ I just keep replacing it and haven't had any issues reported, seems to be working okay. It's just the updater also 'repairs' the installation so any modified files get replaced by the updater. Have to keep changing the options in graphics.cfg, too. :D

The non-Super version, i.e. everything before the F/A-18E and F/A-18F. The wikipedia page summarises the evolution. The single-seat F/A-18E and two-seat F/A-18F Super Hornets carry over the name and design concept of the original F/A-18, but have been extensively redesigned. The Super Hornet has a new, 25% larger airframe, larger rectangular air intakes, more powerful GE F414 engines based on F/A-18's F404, and upgraded avionics suite.

Have a look at the DCS\Logs\ folder under your user directory, and see if there's an autoupdate.log file there. The contents of that might provide more information as to why it's failing.

That doesn't sound correct to me, so long as the TGP is still slaved to your steerpoint it should move to the new location of markpoint Z. Here's some things to try/verify: Is Mark Z being updated/moved/recreated upon weapon release while it's active? I'd test this by releasing a weapon, verify it's been marked on your TAD, fly a short distance and then release again, and make sure the TAD marker is moving. If you make your steerpoint your SPI and then use china-hat-fwd-long to slave all sensors to the SPI (rather than china-hat-aft-long to slave the TGP to the steerpoint specifically), does the behaviour change at all? It might be worth doing these before you create any markpoints, then repeat them after you've made one or two.

The shortcut for single-player now execute DCS World\bin\DCS_updater.exe - if you change it to directly run DCS World\bin\Launcher.exe it should bypass the update check and simply launch the game. You can always force an update by using the "Update DCS World" shortcut in the Start menu (which runs the DCS_updater.exe with 'update' as a parameter, presumably to force it to check for updates - normally it only checks once per day or something).

I run it on my server just fine as a regular user (non-admin, UAC disabled). The game is installed in C:\Games (i.e. not under Program Files). I use a different account for installing/updating it.

It's the name of Valve's digital distribution service. So if you've read somewhere that the game is available on Steam or something like that, that's what it's referring to - http://store.steampowered.com/ If that's not what you're talking about, more information would be required. :)

I don't know exactly what you'll need; but presumably its video card needs to support at least enough of DirectX to allow the game to create its render window and render the UI. You can disable the rendering of the actual 3D environment, so on-board graphics are fine. I just don't know how 'low' you can get away with. For what it's worth, my dedicated server appears to be using this MSI motherboard which has Intel HD graphics, and 'dxdiag' reports that it has 3D and 2D acceleration. I certainly wouldn't want to try to play the game on it, but it works perfectly for a dedicated server. I'm running Windows Server 2008 R2 SP1 as the operating system, and the game's set to run in 1024x768 windowed mode (with the render3d option disabled). The CPU is an i7 @ 3.4 GHz. The game doesn't take much advantage of multiple cores, so the faster the CPU the better off you'll be. To be safe, I'd probably check with the provider if the system's onboard graphics supports DirectX accelerated 3D - if it does, you should be absolutely fine, as the calls to create the window and render the UI will work, and as before, the actual graphics performance is pretty much irrelevant. Or alternatively, just ask them what motherboard they use and look up the chipset and capabilities online. Before I committed to renting this server, I did check if adding a dedicated video card was an option (and it was), so I had a fallback plan in case the onboard wasn't sufficient. So, you might want to consider asking that as well.

You are aware that ED stands for Eagle Dynamics right? It's not just some guy named Ed who makes flight sims...

I haven't tried it in DCS World, but just to confirm: how are you changing the volume? It used to turnable by using the mouse scroll wheel while the cursor is over the knob. On a related note... are the tooltips/panel labels for the UHF and VHF radios correct yet? :)

Right, gotcha. Thanks! :thumbup:

Is there any difference between that mod and setting: disable_events = true,in the server's Config\network.cfg (in the user profile directory, i.e. Saved Games\DCS\Config)? This is all I've done to remove the multiplayer messages about kills and takeoffs/landings.

You'd be better off asking such questions in the Mission Builders' Corner. The 'unit alive' and 'group alive' conditions will be false for client aircraft until it's been spawned, so you can use either one to check whether anyone is in those slots. However you'll need to be careful with this, since if the mission is automatically resumed when someone connects, these conditions will pretty much instantly evaluate as false. So, you might need to delay the check until some time (e.g. "time more" or use triggers to detect when one of the aircraft on the other side becomes airborne), or alternatively invert it - spawn the AI aircraft by default, but deactivate them if someone spawns on the other side. That might result in unexpected things occurring if e.g. someone spawns on the other side while the AI jets are in the middle of a dogfight, but depending on the mission setup it might be okay.

The "Prepare mission" option just puts you into the jet normally, but when you exit the mission it saves 'all' of the jet's settings, e.g. waypoints, DSMS config, HUD options, TAD configuration, and so on. These are then automatically loaded when you fly the mission the next time. If you change your loadout from the one in the stored DSMS settings, you'll get weird problems.

Plane crashes into housing complex, six dead An Indonesian military aircraft has crashed into a housing complex in the capital, Jakarta, killing six of the seven crew members on board. This article says the aircraft was a Fokker 27. WP also says that another one of these operated by the Indonesian military crashed in 2009, killing all 24 on board.