Matrix Games Forums

Game Version 1261.1

In the attached save. an AAW Patrol flight is flying at 2000ft despite the mission settings indicating it should fly at 36000ft. If you manually set the altitude to 36000 ft and then set it back to auto, everything works fine (though the next flight launched will again start at 2000ft). Not hard to workaround from a player's perspective (if slightly annoying), but would likely cause issue for the AI.

Yes this is a annoying lite bug that actually brakes a lot of scenarios because the AI runs out of fuel flying so low.
I think it has been there since the first "Tiny". I'm surprised this hasn't been fixed jet, considering the AMAZING work being done right now

Didn't wanna start an entirely new topic for this, but its not just an altitude issue. It seems AAW patrols completely disregard any altitude and also speed settings in the mission editor. Please fix.

Can you please check if this is still happening in B1263.1? Thanks.

Tested it in B1263.1. The issue is still there unfortunately.

The issue is still there, though slightly evolved in my 1263.1 tests. After takeoff, aircraft maintain 2000ft. They maintain 2000ft until they reach the patrol zone, at which point they climb to 36000ft. However, if the simulation is on fire speed, the aircraft will remain at 2000ft, and will only climb once switched out of fire speed and after they reach their next waypoint.

I've noticed that the patrol mission altitude keeping does better depending on Movement style, with Repeatable Loop doing better than Random within Area.

BTW, This seems like almost exactly the same bug that was present when CMO first came out in 2019. I have a hypothesis that "Tiny" is reusing code from Command PE on a branch of code that does not benefit from 2 1/2 years of being nitpicked by internet amateurs. To test my hypothesis, I checked the sprint-drift behavior of ships/submarines. Indeed, sprint-drift is bugged again as it was in the early builds of CMO.

Edit:

I'm not saying that last part to complain or be overly critical, but for the practical reason that we might speed up debugging quite a bit by recognizing what problems (and solutions) have already been encountered before.

Indeed, changing the movement style to repeatable loop makes everything work as intended, at least in 1265.1. I'd mark this issue as resolved, then. Probably will cause issues for a few existing scenarios, but my general impression is that most scenario authors use a patrol box, so it probably won't be too much of a problem.

Why would it be resolved? It is just a workaround. You don't think any player ever want to use random box instead of repeatable loop?
As for the scenario design I would say that 99% uses missions with random box. In every scenario I played since the first Tiny I have had to change the AI side in the editor so it wouldn't be affected by this bug. It is tedious, causes spoilers and changes the mission from what the designer intended.

You're right Swant, it was premature of make to make that comment. At the time, I thought that the issue was related to me creating patrol missions with only two points but leaving the movement style on random within area; however, on further testing it looks like the problem is with "Random Within Area" generally, as the issue persisted even when I created a patrol box using four waypoints.

Ok no problem! As you might have guessed this bug is starting to irritate me