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