Jump to content

ColonelPanic42

Members
  • Posts

    23
  • Joined

  • Last visited

Everything posted by ColonelPanic42

  1. Sorry, apparently email notifications weren't enabled so I never saw this until now. The original post (this was originally filed as a bug, but we were asked to refile as a feature request) had the track file showing the problem:
  2. Please add either a waypoint task option for unlimited fuel similar to the existing invulnerability/invisibility options, or a checkbox in the loadout so it can be done per flight member (so player aircraft in mixed groups don't also need unlimited fuel). There are global options for enabling unlimited fuel (both at the mission level and in the game settings), but it can't be done per-aircraft group or per aircraft. AI aircraft don't always do a good job conserving their fuel (alternating air brake and afterburner, for example), and in long running missions that can be a problem. One potential corner case: the manual says the existing unlimited fuel option causes the aircraft to always be at 100%, including the affects that has on aircraft weight. For this it would be better to have the option maintain whatever fuel level the aircraft spawned with, since 100% fuel weight can be too much for some aircraft to take off with some loads.
  3. time more broken.trk demonstrates the issue. A single aircraft is in an orbit and is supposed to continue to its next waypoint five minutes after mission start. The flight instead orbits forever.
  4. 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 .
  5. 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 (2.7.2.7910.1), 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
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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?
  16. 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.
  17. 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
  18. 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 :)
  19. I've attached a mission and track that demos an AI aircraft taking off, ascending toward a waypoint specified in AGL, and then turning toward another waypoint. It seems that in attempt to maintain exact radar altitude the AI commands huge pitch oscillations that bleed speed until they reach 18.5 AoA, at which point they seem to be unable to recover. The exact same flight plan with the waypoint specified as MSL (the altitude MSL is the same in both cases; it's the radar altitude specification that seems to affect the AI). I suspect this could be because the buildings the AI is flying over is causing many sudden changes in their radar altitude. If allowed to use afterburner the AI is able to recover. Somewhat related to https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/bugs-and-problems-ai/ai-ad/7121294-ai-stuck-at-high-aoa-after-making-sharp-turn-if-afterburner-is-restricted, but the circumstances that get the AI into this bad state are different. agl oscillation.miz agl oscillation.trk
  20. The attached mission is a simplification of the desired flight plan: take off, ascend to a hold point, loiter until a push time, then push to the objective (objective omitted in this demo). Both pilots are AI. The AI wingman isn't able to follow the flight lead through the first turn, and it seems that the AI lead will not climb toward the hold point unless the wingman is joined. Once the wingman joins they do begin to climb, but not in time to reach the altitude of the hold point, so instead they do most of the climb in a high speed circle. If you remove the wingman so it is only a single AI aircraft they begin their climb as expected. A "None" formation option here would be a suitable fix for me, because I don't care if the two are in formation until they push from their loiter point. The hold point is where I expect them to join up. bad wingman follow climb.trk climb.miz
  21. AI pilots occasionally get themselves into high AoA conditions that they cannot recover from without afterburner (if disabled or in an aircraft without AB, they're stuck unless a waypoint commands a descent). The exact circumstances are tough to nail down. A similar mission to the one attached where the AI starts in flight does not seem to have the same issue because the AI makes a wide sweeping turn instead. It does appear that the problem is that the AI refuses to nose down to reduce AoA which would allow them to recover because it would result in a short term descent away from their desired altitude. It's also worth noting that if I move the waypoint a small amount they don't manage to get themselves stuck at the high AoA condition. It's not clear to me if this is a single pathological case or if this was just bad luck, but this flight plan is a reduced version of something I had actually planned (I expected the AI to take off from the opposite runway). I've observed similar (though not identical) behavior for aircraft turning after completing a Bombing task, and it usually results in them crashing because they cannot gain altitude. Mission and track file attached. no ab recovery demo.miz takeoff sharp turn.trk
  22. Could we get a task option or a different task type for the other behavior? Unfortunately the follow task has the same behavior. I could not find a way to create a close escort mission that protected the bomber during its attack. Workarounds seem to be: Use Search Then Engage and plan the same route for both groups. This has the large downside of the escort potentially leaving the objective area before the bomber if the bomber needs to make multiple passes to complete its objectives. Use Search Then Engage for all waypoints up to the IP, and then use Search Then Engage in Area on the target area, stopping based on a flag set when the bombers complete their tasks. I suppose this works (untested), but it seems like there should be a simpler answer. Should I report this elsewhere if it's a feature request rather than a bug?
  23. Attached a demo mission and track file. The northern group shows the desired behavior: the escort aircraft stays with the bomber through the entire flight plan. That bomber has no tasks, so it works as expected. The southern group shows the problem. When the bomber begins its attack task the escort wanders off until the attack is complete, at which point it rejoins. Would love to see a fix for this. The workarounds are pretty clunky. broken escort.trk escort.miz
×
×
  • Create New...