nomdeplume

No, altitude doesn't affect aircraft waypoints normally, the waypoint altitude will just adjust to terrain level if it's too low (plus it wouldn't restrict its movement over water, which is altitude 0). It appears the mission editor applies ground vehicle rules to the helicopter waypoints if they're set to start from ground. Probably a trick to limit initial placement which erroneously is then applied to subsequent waypoints.

The animated cloud background is the default. If you select a different theme in the options section (I think it's under Misc) you'll get a static picture, and one of them is the scene you describe.

I think if you're using scripts in conditions they need return the value, so something like: return Unit.getByName("name of aircraft"):getfuel() < 0.15 might do the trick. You can't actually tell the AI to refuel. The "Refuelling" enroute task if for tankers (to provide fuel). So, you have to wait until the AI itself decides it's low on fuel and needs more, but I don't know at what level they decide they're low. You'd have to experiment a bunch. I think the best strategy would be to have your trigger push a "switch waypoint" task to a waypoint that's near the tanker, and possibly has a "follow unit (tanker)" task attached, so they'll stick close to the tanker. Then when the AI decides it needs fuel, it's already close by and should be able to rejoin and tank quickly and easily. Then have another switch condition trigger with the fuel state > 0.99 or something, which switches them back to their mission waypoint. Yep - tonnes of messing about with fragile systems to get something fairly basic to work properly, but that's par for the course with DCS. :)

You could try disabling UPNP support on your router so the game doesn't try to activate it. Although, have you tried running the server without the manual port forwarding? If it just works then that might actually be the easiest solution to get it forwarding where and when needed. This post is pretty old but contains the configuration to disable UPNP in the server, so you could try setting that in your network.cfg to see if that's the cause. Although, that error: Call error get_server_info:?:0: attempt to index global 'mission' (a nil value). seems like the most troubling bit and is probably the reason the server is not starting. This would suggest to me the environment initialisation scripts are not working. (Is there a mission selected?)

I think this is intended. There are two different radios and two different frequency ranges covered. 145 is not a covered frequency. The main radio covers both ranges, the auxiliary radio only the UHF range.

If its main task is 'Nothing' then it won't have any actual combat tasks set. The AI will only do what it's told to do. As Wrecking Crew suggests, set the aircraft's task to CAP or Fighter Sweep (I think CAP would probably be better). You could delete the default CAP task and add 'Search and engage in zone' task(s) to cover the region(s) of interest to give yourself more control over exactly where it will engage. If the group's ROE is set to RETURN FIRE or HOLD FIRE, then it won't engage any targets. Once the ROE is changed to WEAPONS FREE, then it will engage targets that are valid for its tasking. So, you need to have some kind of combat task assigned before WEAPONS FREE will do anything. There is also an option that controls what units the group will engage, but I can't remember its exact name. The default setting is "Only designated" which is why you need appropriate enroute tasks running to actually select targets. You can also change it to "priority designated" amongst others which might allow them to engage targets that fall outside of their actual tasking, but I'd be reluctant to use it due to the possibility of them traipsing off to the other side of the map.

AI will hit the tanker when they're low on fuel, but they tend to be very stupid about it and will try to fly it on full afterburner and ending up running out of fuel before they get there. Of course, AI is terrible at joining up so even if they get to the vicinity of the tanker they often run out of fuel while trying to get into position. Also, the M-2000C can't refuel in a turn (doesn't align its probe with the basket properly) so if the track isn't super long it can take them ages to complete a refuel; and if it is super long then the tanker will potentially be a very long way from the aircraft when it needs to refuel. Not sure if other aircraft have this problem. Boom refuellers seems okay even in turns. There is a function unit:getFuel() which returns the percentage of fuel the unit has (0.0 to 1.0, or above 1.0 if they have external tanks). So you could potentially use that to determine if a flight is getting low on fuel, and then command it to follow a tanker (perhaps with afterburner use disabled) until its fuel level reaches (or is close to) 1.0 and then send it back to its normal tasking. Would take some finagling to make it work reliably, but it might be kind of cool - having a few AI fighters trailing a tanker would add a bit of atmosphere for when players refuel. I pretty much never use the default tasks outside of very simple test missions specifically due to this. Search and engage in zone or the Search and engage enroute task with a range limit help to prevent the AI going all over the map.

Not all betas are created equal! It should be pretty obvious to anyone that's got the F-5E that it was made available way later in its dev cycle than the M-2000C. The reason they don't release the training missions already is because a) people will get upset if they change how something is implemented after they've already done a training mission on it and b) people will get upset if a training mission breaks because of changes in the module and c) the person maintaining the training missions gets upset if they have to do significant rework because something changed in the module.

I guess my joke was somehow too subtle? :huh: (Edit: at least one person got it! :D) It's on page 119 of the manual, under the Magic II heading. It doesn't specify the G-limitations though. Here's the full section: Sniped!

When you use the new "Takeoff from ground" or "Takeoff from ground hot" starting positions for helicopters, the placement of the first waypoint is restricted to flat terrain (similar to FARPs). That's reasonable, but all subsequent waypoints inherit this limitation once placed, so you cannot drag waypoints over water or slopes. Also: it would be really nice to have the "Uncontrolled" option available for ground starts, so we can parked helicopters that sit around until they're explicitly started. I'm not sure if that's a wishlist or a bug, hopefully the latter though. Reproduction: place any helicopter in the mission editor. set the initial waypoint type to "Takeoff from ground". add a second waypoint anywhere (water and hilly terrain is permitted when placing the waypoint). switch to waypoint edit mode, then try to drag the waypoint over water or hills: the editor will refuse to allow the waypoint to move anywhere that is not 'flat' terrain. Expected behaviour: in step 4, the waypoint should be able to be placed anywhere, as for the other helicopter starting options.

Just to check the obvious, you are changing the port forwarding on the router when you test the server, and vice versa? (Though you could probably avoid doing that by using a different port on one of your machines.)

Seemed like an interesting idea so I knocked a little script together and made a simple test mission where you need to keep below 30 metres. I put some comments in the triggers to explain roughly how it works, up to you if you want to have a look or not. One practical issue you'll run into is that trees are only cosmetic, but setting the minimum altitude high enough that players can fly over them (~30-40 metres) means that it's trivial to keep below that altitude. Still, it's kind of fun to taunt the Vulcans by popping up above the threshold and dipping back down before they can aim at you. Fun but dangerous... :D My immediate thought was to add some trigger zones you had to fly through and time the player - a race where the maximum altitude is enforced by deadly weapons. AGL-Test.miz

Well, auto-collective is a made-up thing Polychop put into the sim to make it easier for a single pilot to use the missile system. So turning it off if you have a player in the left seat maybe makes some sense. Could just be a bug though.

Yeah, they should probably mention it in the Magic II section. Near the top of page 119 would be ideal.

It sounds like you'd be better off using the mission scripting system to check the player's altitude rather than data from the cockpit instruments. What happens if the player turns off their radar altimeter, or if it's damaged?

Just did a quick test and the MiG-21 definitely shows as 21 with a hat. How do you know there were no search radars "near" the S symbol? EWR and the like have massive ranges.

Just some more info... Starting coordinates are slightly off by design, within 10 km of your real position. You often don't need more precision for this, especially for air-to-air missions. Coordinates at the top left of the map screen are for the mouse cursor, you'll see them changing as you move the mouse around. This makes it easy to get the coordinates for any location on the map. The longitude being cut off from the info panel on the map view is annoying, yep, been like that for quite some time. You can just put the mouse over your aircraft position and read the coordinates from the top left. Or, use the info bar in the external view if they're enabled, as Rlaxoxo suggests. Also, if you're regularly starting from the same few positions, you can have a cheat-sheet with those coordinates. This is probably closer to real-life procedures where they'd have the parking spot coordinates for their aircraft. Hopefully mission designers will consider adding this information to the briefing. Another strategy is to taxi to a specific spot at the airbase with known coordinates, park there for a moment and then update your aircraft position. This should result in slightly reduced accuracy than you'd get if you did a full alignment with the correct position, but I don't think it means a difference in the sim at the moment. The airport charts that come with the game have several positions marked on the map along with their coordinates, which you can use for this purpose.

What seems to work for the red axis indicators is to clear the controls so you no longer have any conflicts, then exit DCS completely, then start it up again and go into the controls menu. You should then be able to configure it as normal. Seems like it won't remove the red markers indicating a conflict until you restart the game.

INS isn't powered when the QRA switch is used, see here:

If you click on an airport in the F10 map it'll show the ATC frequencies (amongst other things) in the lower left corner...

"Caged" just means the missile seeker is in a fixed position (typically boresighted) and unable to move. "Uncaged" means the seeker is free to rotate to track a target. In the F-5E, you acquire the target when the missile is caged, by flying your aircraft to put your target in the seeker's boresighted position (the gunsight symbology assists with this). Once you hear the tone change indicating the missile has locked a target, you can either fire with the seeker still caged (it'll uncage automatically), or hold the uncage button to allow the seeker to roam about and track the target. The benefit of uncaging the seeker is that you don't have to keep the target directly in the (fairly small) position where the caged/boresighted seeker can see it. The most common use is to allow you to pull some lead on the target before firing, which reduces the amount of manoeuvring the missile has to do upon launch, allowing it to use that energy to increase the pK. Another use is to deliberately aim above the target when it's flying very low, so the missile's initial trajectory takes it up, and it comes back down to engage the target. This can help to avoid the missile flying an intercept course directly into the terrain. On the other hand, fiddling with the uncage button while manoeuvring your jet in combat increases the likelihood you'll make a mistake and miss an opportunity to fire, so often it's best just to fire when you first get the lock in the caged position. The above is basically a loose and possibly misremembered summary of this thread: Aim9P To cage or uncage

No, I use the TM Warthog, the throttle off position activates (and holds down) a DirectX button (as far as the game/any software is concerned). I'm a little confused about this part, particularly the "push and hold the start button ... before hitting the start button". :) The whole thing with having to move the throttle into the off position before the game will recognise it's in the off position is just par for the course. You might be able to avoid that with the 'sync controls at startup' option or whatever it's called, but when I tried that it didn't seem to make things appreciably easier. Basically, DCS doesn't scan for button states at startup so doesn't know the button is down until it receives a button press event. So, I just plonk the throttles into the off position when I first get in the cockpit as part of my standard routine, same with resetting the zoom to normal level. Your lines seem to be functionally the same as the existing ones, so I'm not sure why/how you're avoiding having to let DCS know your throttles are already in the off position.

^ I think the bindings I use are called: Throttle (Left) - OFF/IDLE Throttle (Right) - OFF/IDLE There are also separate OFF and IDLE bindings, but the OFF/IDLE are obviously intended for switches (i.e. the 'button' is held down).

If you keep having problems, I would suggest posting a track of you trying it, preferably from an air-start to keep the track as short as possible. You might also find it useful to just watch the weapon fall (F6) after you release it - it might then be obvious if it's overflying the target and never picking up the laser spot, for example.

Haven't tried it, but sounds like you just need to add the labels file to the mission file. The .miz file is actually a normal ZIP file with specific files inside. So you can open it in any program that understands ZIP files, e.g. 7-zip, WinRAR, etc. Or, you can rename it to end with .zip and use Windows Explorer to access its contents, then rename it back to .miz when you're done. I guess just try copying the labels.lua into the root of the mission archive?