nomdeplume

Most likely it's this bug: https://forums.eagle.ru/showthread.php?t=157613 External sounds only play the first mission you run. If you start a new mission, external sounds are broken. If you completely exit the game between missions it should work properly.

They've always been able to take damage, and seem to drain quite fast. You have only a few seconds to switch the crossfeed on before the affected engine flames out. But when you repaired the leak would remain, so when you asked to refuel the refueling would never complete (the fuel would be leaking as fast as it was being added). So, hopefully that changelog entry means that's fixed.

Probably means damage to fuel tanks will actually be repaired now when you request the ground crew to repair the aircraft.

Yep you're right, it seems to be bugged - probably from the localisation changes. The actual code written to the .miz file is: ["conditions"] = { [1] = "return(c_predicate(getValueDictByKey(\"\")) )", }, -- end of ["conditions"]The call to getValueDictByKey() is passed an empty string, so this fails to do anything useful. The localisation dictionary doesn't contain anything that looks like my predicate code, anyway. A normal condition (e.g. flag is true) just has the function directly in there: [2] = "return(c_flag_is_true(1) )",so my guess is it's erroneously writing out a dictionary lookup for the string rather than embedding the code directly.

Strange... I'll do some more testing after work, I do a lot of scripting in the game but almost never use the lua predicates - tend to just use 'standalone' scripts and use flags to trigger actions via the triggers list. You could try making it as simple as possible: return true and see if that works as expected (you should get the text message right after the mission starts).

What's it doing or not doing? Are you getting any errors, either in-game popups or in dcs.log? I'm pretty sure the lua predicate is expected to always return true or false. You're only returning true if the condition is met, and nothing if it isn't, which might be interpreted as nil or just as an error. So you could try: if timer.getAbsTime() - timer.getTime0() > 20 then return true else return false endor more succinctly: return timer.getAbsTime() - timer.getTime0() > 20 Also, I think the calculation you're doing is the same as the model time, so timer.getTime() would return the same value, or you could just use a "Time more (20)" trigger condition.

Oh actually, I believe you're right - they did add this. They still won't refuel in some cases though; I don't think they care about external fuel tanks and need to be less than a certain amount before they'll refuel. So yeah, ignore that - perform task Refuel should be fine, especially if you're activating it after they're reasonably low.

Did you try to rearm after the repair? There is a bug where leaks in fuel tanks aren't fixed by a repair; so when you refuel it never completes and that blocks any further ground crew tasks. Edit: one of the reports.

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.

Pretty sure he meant they either fly true altitude or AGL (if you tick the AGL box). Not that AGL was a synonym for true altitude; I'm 99.999999% confident Frederf knows the difference.

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.