Version 1.5.1.1 (2012-01-04)

Moderators: GSH, Ultraken

Post Reply
User avatar
Ultraken
Patch Creator
Posts: 373
Joined: Fri Feb 18, 2011 6:06 pm
Contact:

Version 1.5.1.1 (2012-01-04)

Post by Ultraken »

Version 1.5.1.1
Released 2012-01-04


Downloads:

Testing Executable and Symbols


What's New:

* Fixed some third-party maps not loading
- The maps had a terrain name with extra '.' characters at the end
- 1.4 stripped these but 1.5 didn't so it couldn't find the map data
- The loader now strips the extension (if any) from TerrainName

* Removed a costly sprite index lookup in SubmitMissileLight
- It was costing about 1% of the total execution time (!)
- SubmitMissileLight now looks up the index once and caches the result

* Fixed some units not recycling properly
- This mostly happened when approaching along a diagonal
- AI processes not derived from UnitProcess didn't get updated
- They now use collision radii and assume a square footprint like other units do

* Recycling a Scavenger credits any scrap held
- Their held scrap was previously lost
- Players rarely recycle Scavengers so it didn't come up much

* Receiving a state update for a deleted object no longer recreates it
- This should fix "indestructible" objects appearing in multiplayer
- This may help with infinitely-exploding units (a.k.a. "volcano" or "firestorm")

* Fixed the TAG Cannon leader round when holding fire and shooting into the distance
- The shot timer kept running waiting for the round to expire
- The next leader round got a high start time so it would appear far away
- The weapon now clamps the shot timer to prevent that
teepean
Scrap
Posts: 6
Joined: Thu Dec 29, 2011 2:57 pm

Re: Version 1.5.1.1 (2012-01-04)

Post by teepean »

Mission 12 is very choppy on my system and becomes unplayable after a while. Other missions work without problems. I created an example savegame:

http://www.mediafire.com/?80chrcizyei5ge1

My system:

Code: Select all

   Operating System: Windows 7 Ultimate 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.110622-1506)
           Language: Finnish (Regional Setting: Finnish)
System Manufacturer: Gigabyte Technology Co., Ltd.
       System Model: GA-990XA-UD3
               BIOS: Award Modular BIOS v6.00PG
          Processor: AMD Six-Core Processor (6 CPUs), ~3.0GHz
             Memory: 8192MB RAM
Available OS Memory: 8190MB RAM
          Page File: 2906MB used, 13770MB available
        Windows Dir: C:\Windows
    DirectX Version: DirectX 11

          Card name: ATI Radeon HD 5700 Series
       Manufacturer: Advanced Micro Devices, Inc.
          Chip type: ATI display adapter (0x68B8)
           DAC type: Internal DAC(400MHz)
User avatar
Ultraken
Patch Creator
Posts: 373
Joined: Fri Feb 18, 2011 6:06 pm
Contact:

Re: Version 1.5.1.1 (2012-01-04)

Post by Ultraken »

Based on past history, my guess is that it has something to do with the pathing system.

When it slows down a lot, could you try profiling it to see what's going on?

1. Run Very Sleepy (an open-source profiler)
2. Select bzint.exe in the process list on the left
3. Select the main thread (the first one in the list) on the right
4. Press "Profile Selected" to start profiling
5. Switch back to the game and let it run for a minute or so
6. Switch to the profiler and click "OK" to finish collecting samples
7. Save the profile result and attach the resulting .sleepy file here

Optional but helpful: take a screenshot of the results
teepean
Scrap
Posts: 6
Joined: Thu Dec 29, 2011 2:57 pm

Re: Version 1.5.1.1 (2012-01-04)

Post by teepean »

Here's the results with version 1.5.1.2.

http://www.mediafire.com/?a59042njfj957ca
User avatar
Ultraken
Patch Creator
Posts: 373
Joined: Fri Feb 18, 2011 6:06 pm
Contact:

Re: Version 1.5.1.1 (2012-01-04)

Post by Ultraken »

It's definitely spending a lot more time in pathfinding than it should.

When I ran your save file in a debug build, I got a fair number of pathfinding calls that took 100+ milliseconds. That's long enough to produce an obvious and objectionable hitch. It seems to happen when one end of the path is inside the enclosed area of the map and the other is outside, forcing the pathfinding algorithm to traverse (almost) every node in the map. Now I just need to figure out why it's doing that...
Post Reply