meltingSnowdrift

Thank you for your explanation of the actual behaviour and your views. I feel less frustrated and lost now. As you did above, I also restate here the main ideas of what I had to say on Discord. Much of the content below is copied directly from my words there; none of it is intended to express new meanings. I propose to make it so that the aircraft obeys the sliders all the time and the sliders never move by themselves. This mainly addresses the kind of thing that happens at step 5. Regarding the kind of thing that happens at step 3, I agree with your ideas. For simplicity, I abandon the "more ambitious response" idea in my original post above. Here is a question I would like to be considered when deciding whether or how to change the behaviour of aircraft groups commanded by the player using Combined Arms. In what situation, if any, would a player be glad that passing a waypoint resets an aircraft group's altitude to what the sliders said when the route was created? I admittedly find it hard to imagine such a situation. I find it easy, meanwhile, to imagine situations in which such an altitude reset, even when it is happens to not be a reset to 0, could confuse and frustrate the player. This is because the latter type of situation has been my daily experience with the game. As always, I mean this respectfully. This question is not meant as a rhetorical question: I am genuinely open to answers to it. Thank you again for your patience in general.

Procedure to reproduce Run the attached mission file. Join the game as a blue tactical commander. Wait until the aircraft have passed waypoint 1 and are in straight and level flight on their way to waypoint 2. Using Combined Arms, give the aircraft group two new waypoints. For testing purposes, these waypoints should be far enough from the group's current position and from each other to easily see the effects of altitude control. (This step will cause the aircraft to descend. Check that this occurs.) Using the sliders in Combined Arms, assign an altitude well clear of the terrain and a speed appropriate for flight at that altitude. Wait until the aircraft pass the first waypoint you added and are on their way to the second waypoint you added. (At this point, the aircraft will descend again.) Expected behaviour In situations like step 5, in which an aircraft group is following a speed and altitude specified by the player using sliders, passing a waypoint placed by the player and moving on to another waypoint placed by the player should not cause that speed and altitude to be abandoned or changed. In situations like step 3, in which an aircraft group following a route created in the mission editor is reassigned a route using Combined Arms, the group should not proceed toward zero altitude and speed. Actual behaviour See the attached track file. After step 3, the aircraft group proceeds toward zero altitude and speed to the extent it is able. Specifically, it descends and begins closely following the terrain as well as losing speed. Consistently with this, the speed and altitude sliders are at zero. After step 5, the same thing occurs as after step 3. Opinions There is no single correct answer regarding what altitude and speed to set when transitioning from a mission editor route to a player-defined route. I have two ideas about how to handle this. The easiest way would be to set the group's target speed and altitude (and the corresponding sliders) to the current speed and altitude of the group's leader as though the player assigned these values using the sliders. This easily ensures that no dramatic and uncommanded changes in altitude and speed occur in response to a player assigning a route. A more ambitious response to this issue would be to allow the player to assign an altitude and speed to the waypoints of a player-created route before assigning that route to an aircraft group. This would make the occurrence of this issue fundamentally impossible. Though the subject of this post can be interpreted as two issues, I choose to report it as one issue because I believe that what happens at step 3 and what happens at step 5 are fundamentally the same phenomenon: altitude and speed are reset when transitioning to a player-assigned waypoint. problem D21.trk 22D21 problem demonstrator.miz

Procedure to reproduce Run the attached mission files. They contain only AI units. The mission file "demonstrator 1" is a simple demonstration of the basic bug. I think it is close to the minimal mission contents needed for this bug to work. The mission file "demonstrator 2" is a more elaborate demonstration showing a full SA-5 missile system engaging in combat while mounted on a group of moving boats. Suspected principles Static land units and non-amphibious vehicles (hereafter "pure land units") must be placed on land. Earlier testing showed that, if an amphibious vehicle is placed on a ship, that vehicle travels with the ship. Placing something on a ship, for our purposes, means that the reference position of a land unit (the centre; the point within the model of the land unit corresponding to the centre of its icon in the mission editor) overlaps with the ship's model. This result led me to suspect that, if a way could be found to place a pure land unit on a ship, that pure land unit would travel with the ship as well. This suspicion was confirmed. In the mission editor, ships and boats can only be placed on the sea. They are only capable of motion if they are not aground. Vessels with shallow draft, such as the speedboat, are capable of motion even when placed extremely close to shore because they need little depth to float and move. In certain locations in the ports depicted in the Caucasus map, the boundary between land and navigable sea is extremely sharp and steep. This causes there to exist a narrow region at that boundary where pure land units can be placed but which can also be occupied by a small part of the model of a speedboat without immobilizing that speedboat. It is thus possible to fulfil the condition for making a land unit travel with the speedboat even when that land unit is not amphibious. Expected behaviour The series of tests leading to the discovery of this bug was conducted with the purpose of finding exactly such a bug. Unusually for my bug reports, there is therefore no expected behaviour differing from the actual behaviour. See the "Opinions" section for further context. Actual behaviour The image below is a representative example of the results of successful use of this bug. When this bug is applied to static land units, they become rigidly attached to the boat in all dimensions. Static land units in this condition are upright relative to the boat. When it is applied to land vehicles, the results can be highly unpredictable. Sometimes, possibly when the land vehicle does not try to move, the result resembles that for static land units except that the land vehicle is highly tilted. Other times, possibly when the land vehicle does try to move, it appears to try to move on an invisible tilted plane rigidly attached to the boat. Under unclear conditions, land vehicles in this condition can also teleport short distances (within visual range), after which they continue to move on a plane rigidly attached to the boat. Sometimes, as shown in the image above, land vehicles become raised into the air while remaining rigidly attached to the boat. This may be possible (as I suspect it was in this case) even if the vehicle does not try to move. Opinions (Unlike the rest of this post, this section expressed my views rather than factual claims. I separate these views into this section to preserve the clarity and professionalism of the bug report.) Though I acknowledge that the behaviour I report is unambiguously a bug, I feel that it may be better to think about it as something more than a problem with the game. It reveals potential in the game that is presently underused and which I suspect would not be hard to fulfil. The direct mounting of originally land-based military equipment, including SAM systems, is a practice with recent precedent[1] in real life. Inspired by this and by experimenting with existing functionality for placing static objects on ships, I began to wonder whether functioning land units could be placed on ships as well. Though it was almost immediately apparent that this could not be accomplished using the current intended behaviour of the game or the mission editor, the possibility captured my imagination. The resulting hours of experimentation produced the results presented here. Treating this behaviour as a pure bug, I expect that it would not be hard to fix: one would merely need to make it impossible for any land unit to rest on a ship. I propose, however, that no more than a little more effort would produce a result much more friendly to the creativity of a mission designer. I specifically propose to allow the placement of pure land units on the decks of at least some ships but to make land units in such a state immobile relative to the ship. By rigidly attaching these land units to their ships, most of the potential for serious misbehaviour described in this report (teleportation, motion along invisible planes) is removed. As demonstrated by the bug and by the ability to place static objects on ships, the fundamental features required for this functionality are already present. It should therefore require little implementation effort, especially compared to the tactical and storytelling possibilities it opens. [1] https://www.thedrive.com/the-war-zone/russian-black-sea-warship-now-equipped-with-ground-based-sam-system demonstrator 2.miz demonstrator 1.miz

Procedure to reproduce Run the attached mission file. It contains only AI units. Look at both types of missiles to check their appearance. Expected behaviour Both types of missile should drop their solid rocket boosters when transitioning to cruising flight. During cruise, boosters should not remain attached to the missiles. The wings of the YJ-62 missiles should be deployed during cruising flight. Actual behaviour Booster separation and wing deployment animations do not occur. See the attached images for the appearances of the missiles during cruising flight. There appears to be no effect on the behaviour of the missiles: they fly and hit targets as expected. I am not sure if this issue affects any other missile types because I have not conducted exhaustive tests. Not all missiles are affected because the ship-launched Tomahawk does not experience this issue. 22F13 ship missile problem.miz

After further experimentation, I think I may have found a more reliable way to reproduce it. Try the attached mission file. When running this mission file, watch the blue ship. At around 3 minutes in-game time, it should start firing SAMs. Approximately 10 seconds later, the bug should start repeatedly occurring. Because the ship is not moving, new SAMs being launched from under the immobile ones collide with the immobile ones, destroying both. 22J19 SAM bug.miz

Steps to reproduce I am not completely sure about how to reproduce this issue. It does not occur very consistently. Similar things have occurred occasionally when using various AI-controlled SAMs, including SAMs launched by ground units, with no clear pattern. The case shown in the attached track file is one of the simplest ways I was able to make it happen. Expected behaviour Missiles launched by the ships should either continue in flight or self-destruct. Their models should be visible. Actual behaviour Sometimes, a missile, when launched, does not begin flight or visually appear, though its label indicates that it is present. Instead, the missile, invisible except for the label, remains stationary in midair, apparently at the location where it was initially created when launched. After some seconds, it self-destructs with a visible explosion. See the attached track file. standard missile 2 in midair.trk

Procedure to reproduce Run the attached mission file. Expected behaviour Missiles explode close enough to the target to damage and probably destroy it. Actual behaviour Missiles explode well before reaching the target. See the attached track file. Possible additional problem It appears to me that the ship fired 5 missiles at the target in quick succession. Is this the intended behaviour? I see no obvious reason to decide that the situation calls for such an unusually high number of missiles to be expended before the first missile arrives. Type 052C problem.miz 052C missiles exploding early.trk

Considering the loadout I used for the tests reported here, they appear to also be incapable of dropping unguided bombs on ships.

Procedure to reproduce Create and run mission files in which an H-6J aircraft attempts in any way to engage any type of ship with any weapons. Alternately, run the attached mission file. In the attached mission file, an H-6J is specifically instructed to engage a Seawise Giant ship while loaded with every type of weapon it can carry. Expected behaviour The aircraft should launch a weapon at the ship for at least some combinations of available weapons and target ship types. When running the attached mission file, the aircraft should eventually launch at least one weapon of some type at the ship. Actual behaviour The aircraft turns toward the ship to conduct an attack run. It continues toward the ship until it nearly overflies the ship. It then turns away from the ship, flies some distance away, and then turns toward the ship again for another attack run without releasing weapons. This process repeats multiple times. See the attached track file. H-6 ship problem.miz H-6J not engaging ship.trk

Upon seeing a change to the Kh-59 in the most recent changelog (2.7.5.10869), I tested it. The problems described here were found. Procedure to reproduce Run the attached mission file. It contains only AI units. Expected behaviour Both missiles hit the buildings at which they were launched. Actual behaviour One missile crashes into a hill shortly after descending to cruise altitude with little apparent attempt to climb over the hill. The other missile, upon nearing its target, performs a shallow terminal dive with no apparent pop-up maneuver, causing it to hit a building adjacent to the target building. See the attached track file. Kh-59 problem demonstrator.miz Kh-59 problem.trk

Procedure to reproduce Create a mission in which there is a tactical commander on the same side as a unit capable of movement. Run that mission and enter the tactical commander role. On the command map, select that unit such that its control panel appears but do not enter waypoint or target placement. Using the left control - z keyboard shortcut at least once, begin time acceleration. Using the left shift - z keyboard shortcut, stop time acceleration. Click somewhere on the map. Expected behaviour The click in step 6 deselects the unit selected in step 3. Actual behaviour The click in step 6 places a potential waypoint at the location of the click for the unit selected in step 3. More generally, behaviour after step 5 is as though the user has just pressed the button for setting the route of the selected unit. The same state appears to occur whenever the left shift key is pressed with a unit selected in the command map. The procedure described here is intended to represent the most common case in which I experience the problem. I cannot find a key binding that could be responsible for this behaviour. Temporary workaround When the state that follows step 6 unintentionally occurs, it is possible to exit waypoint placement without altering the route of the affected unit by switching to an external view, for example the F7 view, and then returning to the command map and clicking somewhere to deselect the affected unit. If the user becomes aware of the problem after step 5 before accidental waypoint placement, it is possible to exit waypoint placement without affecting the route by right-clicking on the map to normally exit waypoint placement.

Procedure to reproduce Run the attached mission file. It contains only AI units. Expected behaviour The two aircraft should engage the ship using their antiship missiles. All units should behave in physically plausible ways. Actual behaviour Almost immediately after launching its missiles at the ship, the aircraft named "Aerial-1-2" pitches up to begin a nearly vertical climb. After climbing to more than 40000 feet altitude, it undergoes various physically implausible motions. Eventually, it slides backward into the ocean at a supersonic speed with afterburners on. See the attached track file. Su-34 sliding backward.trk 21L6 bug.miz

Procedure to reproduce Run the attached mission file. It contains only AI units. The ship in that mission file is set to have the "weapons hold" ROE to show that the issue does not result from any action by the ship. Expected behaviour The missiles fly in the general direction of the ship until they get close enough for terminal guidance. They then enter terminal guidance and hit the ship. Actual behaviour The missiles fly toward what appears to be where the ship was when they were launched. They continue to do this even as they get very close to the ship. Upon reaching that point, they appear to explode in midair. See the attached track file. 21L5 other harpoon problem.miz AGM-84A problem.trk

Procedure to reproduce Run the attached mission file. It contains only AI units. Expected behaviour The radome is hit by multiple guided bombs and destroyed. Actual behaviour The radome is hit by multiple guided bombs but remains intact. A fire is started but eventually ends without affecting the radome. 21L2 indestructible radomes.miz

Context As far as I know, the KC-135MPRS has a refueling port with which it can accept fuel from a tanker with a boom. The KC-135 is a tanker with a boom. Therefore, a KC-135MPRS with less than full fuel should take fuel from a KC-135 when it is given the "refueling" task at a waypoint while the KC-135 is acting as a tanker. This is the behaviour that occurs for every other aircraft capable of taking fuel from a boom. Procedure to reproduce Run the attached mission file. It contains only AI units. Expected behaviour The KC-135MPRS takes fuel from the KC-135 after reaching waypoint 1. Actual behaviour The KC-135 proceeds to waypoint 2 as though it does not have a tanker from which to take fuel. 21U29 tanker problem.miz

Procedure to reproduce Run the attached mission file, which contains only AI units. Expected behaviour The aircraft launches all 4 of its AGM-84D missiles at the ship. The missiles should then all descend to low altitude, travel toward the ship, and hit the ship. Actual behaviour At least one but less than all of the missiles do not descend after launch. Instead, each affected missile climbs to approximately 30000 feet altitude and then falls down into the water. See the attached track file. It appears from my testing that the number of missiles affected is random. With the attached mission file, I have observed as few as 1 and as many as 3 of the 4 missiles launched affected by this bug. I am not sure if it is possible for none or all of the missiles to be affected. If it is possible for none of the missiles to be affected, more than one run of the mission file may be required to reproduce the bug. harpoon bug.trk 21U29 harpoon bug demonstrator.miz

Yes. I do have an AMD GPU. See the DxDiag.txt file I attached earlier in this thread for details. I hope that, despite the at least partial duplication of another issue, this report at least provides a new, simple, and highly reliable way of reproducing the bug. I continue to be willing to perform new tests as necessary to continue to help understand and fix this issue.

I have just done those things. The problem still occurs. I did not even change any settings away from the defaults after performing that procedure. What testing should I do and what additional information should I provide at this point?

Attached are several files as additional evidence. These are the DirectX diagnostic text file, a track file, and logs. ship problem.trk Logs.zip DxDiag.txt

I did another test after having done those things. Repairing removed a number of CA-related files the installer did not think should be there. Upon starting the mission and entering the tactical commander role again, I did not see the CA control panel upon selecting the ship in the map. This of course made it impossible to conduct the test. Further testing will follow shortly. I intend to delete and reinstall CA. Update after reinstalling CA: The bug occurs again exactly as described in my original post. What additional evidence should I provide at this point?

Everything described here occurred in version 2.7.1.6430. It appears to occur every time I perform this procedure in this version. Steps to reproduce Use the attached mission file. Alternately, make a mission file with a Ticonderoga class cruiser and a tactical commander on the same side as it. Run that mission and take the tactical commander role. Give the ship a single waypoint and a speed so that it moves. Command the ship to fire at a point on land. Expected behaviour The ship should fire a single cruise missile at the targeted point while continuing to move. Things such as the user interface should continue to function. Actual behaviour Upon completing the last step of the procedure above, the following happens. Many GUI elements disappear. This effect continues even after exiting the mission. Buttons that have disappeared appear to still be clickable despite not being visible. The ship slows until it stops. The ship fires a large number of cruise missiles at the targeted point. Evidence The very simple mission file required to demonstrate this bug is attached in case what happens depends on the details of the mission file. This video shows everything described above: 21Y21 ship bug.miz

I am aware that I have previously reported this issue and it may have been fixed previously. Everything I describe here occurs in version 2.7.1.6430. Steps to reproduce: Make a mission in which there is a single aircraft which starts in flight with a single waypoint and a CA tactical commander on the same side as the aircraft. Run this mission and enter the tactical commander role. Using the command map, give this aircraft a route which contains two waypoints. Before the aircraft arrives at the first waypoint, use the altitude and airspeed sliders to command the aircraft to some different airspeed and altitude. Expected behaviour: The aircraft should go to the first waypoint at the speed and altitude specified by the sliders, reach the first waypoint, and then go to the second waypoint at the speed and altitude specified by the sliders. Actual behaviour: The aircraft goes to the first waypoint at the speed and altitude specified by the sliders. Upon reaching the first waypoint, its target speed and altitude change back to what they were before they were changed by the user using the sliders. The aircraft then proceeds toward the second waypoint at the old speed and altitude instead of those set by the user. If the aircraft is selected on the command map at the moment it passes the first waypoint, the sliders will not visually update to reflect this. However, if the aircraft is deselected and selected again after passing the first waypoint, the sliders will show the aircraft's real target speed and altitude instead of what they were before passing the waypoint. Evidence: See the attached track file and this video: waypointpass.trk

Since making the original post, I have attained a better accuracy by making "t_marsh" very large to allow the missile to continue guidance after the rocket motor has burned out. I also set the sigma values to 0 in case that helps. However, this accuracy is still considerably worse than that of GPS-guided bombs. The scud now always falls short of the target by about the same distance. Could the remaining inaccuracy be inherent to the ballistic missile guidance method in DCS? If so, why is it not also present in GPS-guided bombs, which have similar trajectories near the target? Although this obviously does not matter much for the Scud as it currently exists in the stock game, this may indicate that the ballistic missile guidance method would need to be improved if more accurate types of SRBM are added in the future.

This is not really a bug, but this feels like the most suitable place to ask because this is still about DCS behaving in a way that I found unexpected. I was trying to make the Scud more accurate by editing some game files. In missiles_data.lua, each type of missile is given a "sigma" value consisting of a set of 3 numbers which appear to always be identical. Using Google Translate to translate the explanation of the variables at the beginning of that file, the relevant line was translated as: I then changed the sigma of the Scud to {4, 4, 4} to match that of the ATGMs in the same file and then launched the game. I made a scenario containing only a Scud which fires at a point approximately half way between its minimum and maximum ranges. The missile hit a point quite far from the target specified in the mission editor. Why did decreasing the sigma values like this not greatly improve the accuracy of the Scud? Is its accuracy controlled in a way that does not involve these sigma values at all? Is its accuracy instead limited by something that does not involve artificial accuracy values at all? For example, is the guidance method inherently inaccurate?

In open beta version 2.5.6.60966, infantry do not embark in helicopters. When set to do so, they instead wait in line beside the helicopter forever. This issue should be reproducible by running the attached mission file which only contains AI units. Embarking works correctly on my computer in the latest stable version. 21F5_embarking.miz