Jump to content


  • Posts

  • Joined

  • Last visited

About ColonelPanic42

  • Birthday 03/09/1991

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In ai fail rejoin behavior.trk there are two groups of F-15s flying from Gudata to Kutaisi. The fourth member of the second group continuously overshoots their join with the rest of the group, which prevents the group from speeding up or climbing due to .
  2. The "runway start" option does not currently work when the mission is run in multiplayer (local or dedicated). Instead of spawning on the runway, aircraft spawn on the taxiway (or sometimes in a parking space), and depending on the aircraft sometimes in a location where they're intersecting a building so they blow up on server start. In this example the A-50 kills itself as soon as it tries to move. I'm pretty sure this did before the most recent update (, but I could be remembering wrong. I attached a track file, but note that even the track will not replay the bug in the mission editor. The mission must be loaded in multiplayer for the bug to show. The attached example uses Syria but the bug is also present for Caucasus, so presumably is unrelated to the map. multiplayer runway takeoff.trkmultiplayer runway takeoff.miz
  3. F-14s can carry TALDs which are fit for SEAD missions, but the F-14 is not allowed to be assigned to that mission type in the ME (and attempting to do so will cause the group to switch airframes). I've attached screenshots showing the full list of airframes that are allowed to use this mission type. The result of this is that F-14s cannot use the Escort enroute task to defend against SAMs, which only groups assigned to SEAD may do.
  4. Any luck? Any more info I can provide? We're quite interested in getting a fix for this because not being able to predict the path that the escorted group takes (or how long they'll take to finish their attack) means that we currently rely on just setting the escorts on a path through the target area. If the attacker is quick, the escorts loiter in a dangerous area and don't escort the attacker out of the area. If the attacker is slow, the escorts might leave before the attacker is done, leaving them unprotected.
  5. The goal here is to have a flight of F-14s launch their decoys and use them as cover while they approach to bomb the target. AI skill is set to ace, and the SAM starts in red alert mode. I've set up an Attack Group task on the target (aiui this does not require the target to be visible to the AI, but I have a Kiowa AFAC to spot the target just in case) set to auto weapon, group attack. Expend all ordnance is not an option when "auto" is selected. I expect the AI to fire their decoys and then continue with the rest of their weapons. Instead they fire their decoys and go home. I also tried using multiple Attack Group tasks, the first with Guided for the decoys and the second with Bombs for the bombs, but that didn't work either (they would loiter until their decoys were dead and then go home). If I try to force them into the target area by placing another waypoint on top of the SAM, they loiter until their decoys are dead and then move to the target, at which point they get killed because their decoys are no longer protecting them. The attached track dead_with_decoys shows the F-14 behavior. The problem is not unique to the F-14 or decoys. dead_with_harm_and_bombs shows the F/A-18 loaded with 2x HARM and 4x Mk83 doing the same thing. Interestingly it's better (but still not what I expect) when the second weapon is not a bomb. dead_with_harm_and_jsow has the HARM fire, but the hornet keeps pushing to the target after launching (good!). After the HARM hits, the hornet fires a JSOW, loiters until that one hits, then fires another. I'm not sure if it waits for the HARM because it's waiting for the HARM or because it's not yet in range for the JSOW. It should not be waiting for the HARM, the HARM is there to suppress the site and the JSOW is supposed to kill it. dead_with_decoys.trk dead_with_harm_and_jsow.trk dead_with_harm_and_bombs.trk
  6. This railroad is missing a connection (as is the smaller road that's supposed to go beneath the highway) near Tishreen Lake in Syria (37 S BV 304 497). This prevents connecting Aleppo and Damascus by rail. This does seem to be complete IRL: https://earth.google.com/web/@35.65424842,36.02085321,136.79718617a,604.71390451d,35y,0.00000331h,0.62922038t,0r
  7. Based on a precise reading of the manual, I think it's a misleading name rather than a behavior bug: "Same as the Search Then Engage Enroute Task, but with an added restriction of a user-defined target area." It's not "search the zone and engage the targets", it's "search the route and filter by the zone". Would be nice to have an option for the behavior I expected. https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/dcs-wishlist-aa/7149996-task-for-attacking-aircraft-on-the-ground
  8. Looks like this is actually a bug in the search then engage in zone task. https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/bugs-and-problems-ai/ai-ad/7150830-search-then-engage-in-zone-does-not-search
  9. The attached miz and track show that the Search Then Engage in Zone task does not actually perform a search. There are three flights in the mission. The leftmost has a single Search Then Engage in Zone waypoint with the target area over the airfield. This flight RTBs the moment they hit their IP, without ever searching the target area. The second is the same as the first but also includes a flyover point over the airfield. They fly to the airfield, then back off and begin their attack run. The third is the same as the first but the search task has a duration of 15 minutes. They do not wait and RTB when they hit their IP the same as the first. I don't know if this is a behavior bug or a documentation bug. I expected the first flight to behave correctly. If the behavior is correct, I'd suggest renaming the task to "Engage Already Spotted Targets in Zone" or something similar, since the unit will not search the area as the name implies. oca_strike.trk oca_strike.miz
  10. There doesn't appear to be a way to task AI aircraft to attack enemy aircraft on the ground. CAS search then engage will not attack planes, CAP search then engage will not attack things on the ground and will not use air to ground weapons, fighter sweep does not work, CAP does not work, CAS does not work. Bombing appears to be the only option, but that has its own issues. The target location must be set in advanced (if the target begins to taxi it will not be hit) and with groups of AI fighters there is no way to have them split up tasks among themselves, so attacking 8 grounded planes will take 8 passes or more. I've attached a miz showing how I'd like this to be configured (though I don't think CAS is the correct task type, it should probably be ground attack or maybe a new "OCA strike") and a track file showing what they do instead: RTB the moment the reach their IP. oca_strike.miz oca_strike.trk
  11. Just to be clear up front, everything in the sim is behaving correctly here :) The problem is that the way the ME displays speeds for waypoints with a TOT when the previous waypoint has a departure time different from its arrival time confuses people. I've attached a mission (and track file) that includes two flights. The first travels a longer distance from waypoint 0 to waypoint 1 and is set to arrive (based on speed, not a fixed TOT) at waypoint 1 at T+0:10:00 and waypoint 2 at T+0:15:00. The second flight has the same waypoints 1 and 2 but shifted south a bit. Waypoint 0 is much closer to waypoint 1, but it should arrive at waypoint 2 at the same time. This is accomplished by creating an orbit task on waypoint 1 that ends at T+0:10:00 so the two flights each depart waypoint 1 at the same time and arrive at waypoint 2 at the same time. For the second flight, the travel speed between waypoints 1 and 2 is shown as 175kts because it is calculating that speed based on the arrival time of waypoint 1, not the departure time. In any case, the speed shown is just a hint to the designer because the flight will obey waypoint 2's TOT regardless of how the speed is set (because the orbit might end 180 degrees out of phase, the jet ended up going 660kt to get there on time). While everything is behaving correctly, this is confusing to anyone trying to debug the mission. If such a flight plan exists in a mission that's being used to demonstrate an AI flying behavior issue, the bug is usually dismissed because of the seemingly low travel speed, which the AI is not expected to handle. Perhaps instead, where the previous waypoint has an orbit action, the departure time of the waypoint could be used. There are a lot of other end conditions or actions that could cause waypoint 2 to be pushed, and for those cases it might be best to just say "unknown" or "trigger dependent" for the speed instead of the misleading speed based on the previous waypoints arrival time? Open to other ideas :) post hold waypoint speed.trk me speed after hold.miz
  12. Spreading the waypoints out does give the wingman more time to catch up, but that's not the behavior I'm looking for. They're on the way to their rendezvous point, so I don't actually want them waiting for their wingman at this point. Still, the workaround is a good idea, so thanks! I think I can also improve things by slowing them down a bit, since I think the wingman is at MIL trying to catch up and just barely closing. I probably should have filed this as a feature request instead. Are you able to move it or do I need to repost?
  13. Yeah, that matches what I'd observed. I agree that this isn't high priority, but it does seem to demonstrate a real (if a fairly avoidable) issue with the AI's flying. If they find themselves stuck at high AoA while flying in a straight line they should pitch down enough to recover if that won't run them into the ground or override AB restrictions if needed. I appreciate them trying to save gas, but the gas isn't worth much if they can't get anywhere :) If I can come up with a demo that shows this happening on the attack task (where the mission creator has no control over the distances the AI chooses) I'll post an update. I've definitely seen it happen, but it's tougher to reproduce.
  14. Done, thanks! https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/dcs-wishlist-aa/7121311-options-for-alternate-ai-escort-behavior
  15. https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/bugs-and-problems-ai/ai-ad/250183-task-follow-and-escort-temporarily-aborted is the expected behavior for the Escort task, but it doesn't appear that there is a way to task the AI to perform a close escort mission while the escorted AI performs their strike. Could we get a new task type added (for both Escort and SEAD mission types) or some new options for the existing task to provide the behavior expected in that report? I'm not sure if the alternate behavior for the AI should have them follow the escorted group exactly (including altitude changes during dive bombing, for example), or if they should follow but maintain their altitude. An option to specify the maximum distance from their escorted group could be sufficient. As can be seen in the track/miz I uploaded in the other post, the escorts currently wander very far from the unit they are escorting; far enough that they will not be able to intervene in time if an enemy interceptor approaches. Another option would be the ability to set a custom loiter position while the bombers complete their tasks. If I could position the loiter over the target, or between the target and the expected enemy approach, that would solve a lot of problems. It seems that currently they just loiter back toward the previous waypoint, which is exactly the wrong direction to go :)
  • Create New...