How I worked around the "helicopter bug"

For general topics about Urban Assault and any Urban Assault-related topic that doesn't fit anywhere else. If you're not sure, it probably goes in here.
Post Reply
M1kkko
5P0 Air Prism
5P0 Air Prism
Posts: 49
Joined: Fri Oct 22, 2010 9:59 pm
Location: Finland

How I worked around the "helicopter bug"

Post by M1kkko » Thu Sep 25, 2014 3:17 am

This is a brief explanation on how I managed to work around the infamous "helicopter bug" in Urban Assault, where the helicopters controlled by AI are just spinning around and not doing much else. Some users have suggested editing the game's configuration files to change the helicopters' maxrot values as a workaround for this problem, but today I'm presenting an alternative that produced much better results for me.

Today (well, technically two years ago) I was hinted by another user's post on this forum that the faster your CPU is, the worse the AI's pathfinding gets. Now, instead of speeding the game up like this user suggested, I decided to slow my computer down to see if it makes any difference. And boy it did.

If you have a fast computer, follow these steps to make AI work like it did on the computers this game was designed for. No editing of game files required, and your game experience won't be noticeably affected either (except for the working helicopters, of course). I used Ubuntu 14.04 here, you may need to adjust these instructions a bit according to your operating system.

0) Restore original helicopter files (optional)

If you already tried making changes to helicopter config files, you can restore the old ones back. No need for changing those.

1) Lock your CPU's frequency to lowest supported one. (SAFE)

Note: It may be possible to underclock some CPU's all the way down to just a few hundred MHz, but that's not always stable or safe to do, and that's not what we'll be doing today. You can try it if you want, but you'll have to find instructions elsewhere.

The point here is to make sure your CPU doesn't switch to a higher clock frequency when it's under stress.

I have a relatively fast computer with a quad-core (8 with hyperthreading) i7 processor from 2011. I used the cpupower tool to check what kind of frequencies my CPU supports:

cpupower frequency-info

Code: Select all

root@lapidus:~# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 3.40 GHz
  available frequency steps: 3.40 GHz, 3.40 GHz, 3.30 GHz, 3.10 GHz, 3.00 GHz, 2.90 GHz, 2.80 GHz, 2.60 GHz, 2.50 GHz, 2.40 GHz, 2.20 GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.70 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 1.60 GHz and 3.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 3.40 GHz:8,26%, 3.40 GHz:0,06%, 3.30 GHz:0,90%, 3.10 GHz:0,49%, 3.00 GHz:0,41%, 2.90 GHz:0,31%, 2.80 GHz:0,50%, 2.60 GHz:0,25%, 2.50 GHz:0,23%, 2.40 GHz:0,45%, 2.20 GHz:0,21%, 2.10 GHz:0,23%, 2.00 GHz:0,23%, 1.90 GHz:0,51%, 1.70 GHz:0,19%, 1.60 GHz:86,78%  (185950)
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores
It appears that my current CPU frequency is 1.60 GHz, which is also the lowest supported one. We can also see that the current policy is that the "frequency should be within 1.60 GHz and 3.40 GHz". You can set the lowest one to be your new maximum with the command:

cpupower frequency-set -u <<lowest reported frequency>>

Code: Select all

root@lapidus:~# cpupower frequency-set -u 1.60GHz
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Now, as we can see, the policy regarding max CPU frequency has changed:

Code: Select all

root@lapidus:~# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.60 GHz - 3.40 GHz
  available frequency steps: 3.40 GHz, 3.40 GHz, 3.30 GHz, 3.10 GHz, 3.00 GHz, 2.90 GHz, 2.80 GHz, 2.60 GHz, 2.50 GHz, 2.40 GHz, 2.20 GHz, 2.10 GHz, 2.00 GHz, 1.90 GHz, 1.70 GHz, 1.60 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
 [b] current policy: frequency should be within 1.60 GHz and 1.60 GHz.[/b]
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
  cpufreq stats: 3.40 GHz:8,21%, 3.40 GHz:0,09%, 3.30 GHz:0,89%, 3.10 GHz:0,49%, 3.00 GHz:0,41%, 2.90 GHz:0,31%, 2.80 GHz:0,50%, 2.60 GHz:0,25%, 2.50 GHz:0,23%, 2.40 GHz:0,45%, 2.20 GHz:0,21%, 2.10 GHz:0,23%, 2.00 GHz:0,23%, 1.90 GHz:0,51%, 1.70 GHz:0,19%, 1.60 GHz:86,79%  (187926)
  boost state support:
    Supported: yes
    Active: yes
    25500 MHz max turbo 4 active cores
    25500 MHz max turbo 3 active cores
    25500 MHz max turbo 2 active cores
    25500 MHz max turbo 1 active cores
2) Give UA.exe a lower priority

While the game is running, find out the pid (process id) of the running game process. For example, I found out that the pid (process id) of UA.exe on my system was 28329. Then I used the renice-command to change its priority. (higher value means lower priority)

renice 10 -p <<pid of UA.exe>>

Code: Select all

root@lapidus:~# renice 10 -p 28329
28329 (process ID) old priority 0, new priority 10
Note that if you do it this way, you'll have to "renice" the process after every time you start the game.

3) Generate some stress

Next, we need to give all those cores some "higher priority" work to do. Luckily we have a tool for that as well:

stress -c 9

Code: Select all

root@lapidus:~# stress -c 9
stress: info: [28409] dispatching hogs: 9 cpu, 0 io, 0 vm, 0 hdd
This generates 9 hog processes spinning on calculating a square root function. How many hogs you need depends really on how powerful your CPU is and more importantly, how many cores/threads it has. I used the number of my CPU threads (8) plus one, but you can experiment with different values.

4) Watch them fly

Order your helicopters to move to a location and watch them fly there beautifully. But also beware, the Ghorkovs are a deadly force now, as it turns out that those choppers that used to float around aimlessly are now heading to your location, and loaded with some nasty missiles.

Notes:
  • I also tried a tool called "cpulimit", which supposedly lets you limit the CPU usage of a given process. It didn't help me much, as it caused some nasty stuttering for the game.
  • It could also help to temporarily limit your system to only use one processor core.
  • If you are running UA inside a virtual machine, you can adjust the number of processor cores available to the guest OS from the settings of the virtualization software.

Post Reply