Jump to content

meltingSnowdrift

Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by meltingSnowdrift

  1. The problem occurs near the end of the attached track file. Two AI A-10s descended into terrain while apparently trying to make a cluster bomb attack on a group they had been attacking successfully. My DCS version was 2.5.6.59625.1 at the time of the problem. I have no unofficial mods and the only module installed is Combined Arms. A-10 spontaneous crash.trk
  2. I am not fully sure exactly what set of conditions causes this. My mission file and procedure probably contain some unnecessary elements but it was the simplest case I could find in which the bug appears. Procedure to reproduce: Run the attached mission file and select the blue tactical commander slot. In the F10 map view, turn on the option to display all routes. Give the group of ships a route containing a single waypoint. Give the same group pf ships a new route containing a single waypoint. Upon completing this procedure, both the first route and the second route will be displayed on the map at the same time. route display bug demonstrator.miz
  3. In the mission editor and in the F10 map view, the engagement ranges of the LHA-1 Tarawa and the Type 071 amphibious transport dock are far greater than the ranges of any weapons on those ships. This can annoy the player and cause confusion when designing missions and when commanding units in Combined Arms. Why are the displayed ranges like this? If it is intentional, what are these ranges intended to show? If not intentional, can it be corrected?
  4. I have just reproduced the bug again. A track file and logs are attached. As far as I know, my DCS installation is up to date and there are no unofficial mods. The only installed module is combined arms. In case it helps, the relevant flight is the last mission flown before quitting DCS. altitude change 2.trk dcs.log debrief.log
  5. Procedure to reproduce: Create a mission with only a single type 093 submarine (without waypoints) and a tactical commander capable of controlling that submarine. Run that mission. Using the tactical commander's command map, give the submarine a route with a single waypoint and set the submarine's speed slider as high as it can go. Set the submarine's depth slider to approximately 50 feet. The submarine will then dive considerably deeper than 50 feet. After the submarine dives to approximately 120 feet, give the submarine another route with a single waypoint. The submarine will begin to climb and, some time later, will rise above the surface of the water and fly. The results should look like the attached track file. flying submarine.trk
  6. The AGM-84A does not work at all. When launched from an aircraft, it briefly descends normally and then begins increasingly large and fast roll oscillations, resulting in loss of control of the missile followed by the missile crashing into the water. The Kh-31P is able to hit a target, but not in the intended way. Shortly after launch, it ceases to produce thrust and coasts to the target while losing speed. It typically hits the target at subsonic speeds. Attached is a mission file containing only AI units which, when run, should verify both of my claims. ASCM problems.miz
  7. Steps to replicate: Create a mission with an aircraft group flying toward a single waypoint at constant altitude. Include a tactical commander capable of controlling the aircraft. Launch the mission. As tactical commander, assign a new route to the aircraft with exactly one waypoint. Then, change the altitude setting of the aircraft using the altitude slider. After performing the last step, you should find that the aircraft ignores your new altitude setting. I suspect that this problem has the same cause as https://forums.eagle.ru/showthread.php?p=4523018 because both happen when an aircraft group is moving toward the last waypoint of a user-created route. No track or mission files were provided because replication should be trivial.
  8. Steps to reproduce, as far as I understand: Create a mission in which an aircraft group starts out travelling at a constant altitude of 10000 feet toward a single waypoint. Add a tactical commander that can control the aircraft. Start the mission. As tactical commander, add two waypoints for that aircraft group. Preferably, give enough space between the group's current position and the first waypoint as well as between the first and second waypoints for altitude changes to occur gently. Set the altitude setting of the group to approximately 4000 feet using the altitude slider. The following will then happen. It will descend to the new altitude set using the slider while proceeding toward the first waypoint and behave as expected until it passes the first waypoint. Upon passing the first waypoint, the altitude setting of that group, as shown beside the altitude slider, will change by itself to a value near 10000 feet. This change will not be visible until the group is deselected and selected again on the command map, but its effects are immediate. This is not expected behaviour and is presumably not intended. The aircraft group will climb toward its new altitude setting while flying toward your second waypoint as though you had changed that setting to its new value immediately after passing the first waypoint. Attached is a track file demonstrating this issue. altitude target change.trk
  9. A similar issue seems to occur for an AI Harrier instructed to land on the Kuznetsov. Attached is another track file to illustrate this. harrier kuznetsov.trk
  10. A group of 2 Su-33s does not land on the Kuznetsov, instead continuing to fly circles at low altitude near it. This does not occur for single Su-33s. See the attached track file for a demonstration of this issue. su-33 carrier landing problem.trk
  11. The AI F-117 seems to be able to sometimes be unaffected by hits from SA-10 missiles. In some cases, hits will have no effect. In other cases, hits immediately destroy the aircraft. It is not clear to me exactly what is causing this inconsistency. I suspect from some testing that whether a hit has any effect on an F-117 may depend on the direction from which the aircraft is hit. Attached are track files demonstrating both successful destruction of the aircraft and hits, including one case of multiple hits, with no effect. f117_destroyed1.trk f117_destroyed2.trk f117_destroyed3.trk f117_fail1.trk f117_fail2.trk f117_fail3.trk
  12. The bug has been shown to still occur at the end of CA-assigned routes. I have produced 3 different demonstrations of this, for which track files and videos are provided. Demonstration 1 shows a case in which the aircraft had already reached its CA slider altitude before reaching the end of its route. The airspeed target is disobeyed when the aircraft reaches the end of the route. It is not obvious from this case alone that the altitude target is disobeyed. I think this is because the aircraft maintains the altitude it had at when it reached the end of the route. Demonstration 2 shows a similar case which I am not sure is distinct or interesting, but which is included in case it is relevant. Demonstration 3 shows a case in which it is obvious that the altitude slider is disobeyed at the end of a route. When the aircraft reaches the end of the route, it rather dramatically maneuvers to stop descending toward its target altitude. Demonstration 1 video: Demonstration 2 video: Demonstration 3 video: demonstration 3.trk demonstration 2.trk demonstration 1.trk
  13. In the current open beta version at the time of this post, selecting an aircraft (edit: apparently any group containing exactly one unit) on the command map causes its route to become hidden. Exiting and reentering the map view removes this effect. This is true whether or not the "show all routes" option is turned on. The overall effect of this is that, when that option is turned off, it is not possible to see any routes because selecting an aircraft to see its route also immediately hides that route, and when the option is turned on, it is necessary to leave and reenter map view frequently to make visible routes which are hidden whenever aircraft are selected. A workaround is to select an aircraft and then exit and reenter map view; this appears to be the only way to see the route of a selected aircraft, and the only way to see any routes at all when the "show all routes" option is off. Due to the great frequency with which players need to select units both for command and monitoring when playing CA as a commander, this problem makes the experience of playing it considerably frustrating. Edit: this bug appears to only affect groups containing exactly one unit. It appears to affect groups other than aircraft, at least including groups containing exactly one ship
  14. In the latest open beta version at the time of this post, an AI F-14 set to take off from a carrier will get onto the catapult and then sit there permanently without taking off. A relevant track file is attached. In the track file, I used time acceleration to wait a long time after the F-14 got on the catapult to show that it is probably not simply a delay before taking off. F-14 bug.trk
  15. As far as I know, there is currently no way to instruct an aircraft to land on a carrier in Combined Arms: Attempting to place a waypoint over the carrier as though the carrier is an airfield results in the creation of a normal non-landing waypoint. Adding a waypoint for the carrier landing and then switching to that waypoint using a radio item does not work if the aircraft's route has been modified using CA. It appears that waypoints in an original route are entirely forgotten by a group and can no longer be referred to once CA route editing occurs. Using a radio item to set "RTB on out of ammo" for a weapon type not carried by the aircraft has no observed effect. Leaving aircraft groups to orbit until fuel depletion does not work with any useful reliability, frequently creating situations in which aircraft run out of fuel and their pilots are forced to eject on approach. This makes any attempt to command carrier operations in CA quite frustrating and unrealistic. The carrier ends up surrounded by returning aircraft which cannot be told to land and which slowly expend their fuel until (usually) they run out of fuel before they complete the landing they initiate when fuel depletion is imminent. Would it be possible to add a task which causes an aircraft group to land on a specified ship? This task can then be triggered by a radio item, creating a usable way for CA players to instruct carrier-based aircraft to land. Alternately, can some method within CA be created to instruct aircraft to land on carriers?
  16. When the command map is used to change the route of an aircraft group, the aircraft group stops obeying the speed set by the speed slider and the altitude set by the altitude slider. Aircraft in such a state appear to attempt to hold their current altitude while decelerating to stall speed. To make the aircraft group start obeying the speed slider again, the speed slider must be moved. Similarly, to make it obey the altitude slider again, the altitude slider must be moved. Edit: The problem also occurs when an aircraft reaches the last waypoint of its route and begins orbiting. I am assuming the behaviour described here is unintended because I cannot think of a reason for which such behaviour is preferable to aircraft continuing to obey their existing airspeed and altitude slider values when their routes are changed.
  17. Edit: { Just after posting this, I read the latest thread more carefully and realized that it appears to be about the same issue described in different terms. What I have to add to that discussion is that it may not be desirable to entirely prevent the selection of a targeted unit, as selecting it may occasionally be the intended action for purposes such as viewing the targeted unit. } After setting a ground group to target something, there is no obvious way to tell it to stop targeting the targeted unit. Air groups have a "stop attack" button which unsets all the group's targets. Sometimes, clicking on a targeting box selects it, allowing the user to remove that target. More frequently, such a click selects the unit under the box (the targeted unit); when this behaviour occurs, there is no way to unset this target. This is a particularly serious problem for artillery, which as a result of this issue cannot be told to switch targets; artillery groups are instead forced to deplete their ammunition on the first target selected. Why does clicking on a targeted unit behave inconsistently and unpredictably, sometimes selecting the targeted unit and sometimes selecting the targeting box? If there exists a way to reliably tell a ground group to stop targeting something, how is it done? If there does not exist such a way, can something like the "stop attack" button be implemented for ground units?
×
×
  • Create New...