Pitfall: When trying to publish I get a: Warning: Document aliases could not be accessed: CLIENTSIDECACHE_LOAD_UNABLE_TO_OPEN_FILE .
Quote:
Pitfall: Unable to save resource file... Operation not permitted (1) error occurs during publish preparation (hence, can't publish the map). Occurs for file /Users/<username>/Library/Caches/TemporaryItems/StarCraftIITemp/Publish/<map name>.SC2Map/Screenshot01.jpg
Both are the result of incorrectly set permissions on your computer. They are not SC2 problems or caused by the patch.
Generally there are two causes for such an error. The first being the SC2E process lacks sufficient permission to access the files. The second being another process is accessing the files at the same time SC2E wants to.
To fix the permission cause run SC2E as an administrator. In the long term you should fix your permission settings rather but it is a good short term solution.
To fix the concurrent access cause try disabling any program that can be accessing the file at the same time. Such programs usually include backup solutions like dropbox (who will lock the files while synchronizing) and anti virus solutions like Kaspersky which will lock the file while scanning it (which it does for all new files).
Again, I have 8gb of ram and two 970's.... the 64 bit client is simply not working as intended when it comes to units. I get 150+ fps on my map via the 32 bit client and 1 fps on the 64 bit client. lol
However why would it be doing that? The code should build to be functionally identical as defined by the compiler. The actual produced code will be faster in the 64bit client due to the extra available features. The only slow down comes from larger object sizes as a result of alignment and packing constraints and bigger pointer sizes which requires more memory bandwidth and fewer fit into the cache.
Quote:
two 970's
Out of interest have you tried disabling SLI? It could be a compatibility problem with SLI and the 64bit client. This is usually the case when performance is that different.
Quote:
Anyone else have problems with their action actors now?
Make sure your game settings are high enough to show them. I believe such eye candy is turned off at lower visual settings. Patch 3.0 reset everyone's visual settings to some auto detected default which might be considerably below the maximum setting.
We've experienced substantial performance hits as well; I didn't imagine it was due to map size (256x256), but will test.
As I mentioned earlier, it is probably memory related because the 64bit client uses more memory than the 32bit client for logical reasons. The 64bit client executes faster but will perform worse if memory is a limiting factor. It can be memory bandwidth (moving data from memory to CPU), memory availability (how much memory SC2 can use before having to use virtual memory) or even cache coherency (64bit build has less cache coherency due to elements being bigger so using more cache space so fewer fit in the cache).
Pitfall - Hiding Units no longer truly hides units/gives performance boosts in 64 bit clients. Basically, if your map requires lots of units (grids etc) that are hidden so as to not create performance issues, it will works on 32 bit but breaks on 64 bit. Additionally, opening maps that have this problem in the 64 bit editor will cause this issue to occur on both 32 and 64 bit clients.
Sounds like a problem with memory bandwidth rather than incorrect behaviour. Both 32bit and 64bit clients should be hiding units the exact same as otherwise they will out of sync (anything else makes no sense). The 64bit build will use more memory per object than the 32bit build due to a combination of structure/class alignment and wider pointers. Although the 64bit build will execute code faster (bigger registers, more registers and native instructions for single 64bit integer computation) some of this speed is lost by the increase in memory bandwidth (iterating the same objects uses more memory bandwidth) and decrease in effective cache capacity (elements are slightly bigger so cache can hold slightly less).
As soon as your system is pushed to the limit of memory performance then game performance will fall sharply. This can either be due to insufficient memory bandwidth (an increasing problem since todays RAM is not that much faster than RAM 10 years ago) or your system is out of free memory (having to use paging, running SC2E + SC2 on 4GB or less systems can easily cause this with complex maps).
From personal experience I feel like the 64bit versions have given me performance. This might be due to overall SC2 optimizations applying to both versions however in situations which used to lock my screen at 0 FPS I get at least 2 FPS odd.
Pitfall: PlayerHandle, the native which returns a player's account handle is now an error if called while testing a map. This is because it tries to access the player handle data which does not exist since local test players are never assigned one. Before it used to return null and print no error.
Solution: Before calling PlayerHandle a conditional test is needed to make sure the current session is not a test session. How this is done I am not sure but testing if the game is a manual test will not work (arcade sessions count as manual tests). What might work is checking if the game is online since if it is then the player should have a handle however I have not tested this approach yet so it might also not work.
Pitfall: Borders of warcraft button assets were removed (not even completely)
Solution: manually add border texture to every used icon
You are aware it was a bug they had boarders in the first place right? The boarders are meant to be added via overlays if any so that they are applied to all icons for overall map style consistency. The fact WC3 icons had boarders meant that they were completely incompatible with SC2 icons as it looked ugly having WC3 boarders next to SC2 borderless icons.
Quote:
Pitfall: Multiple Texture sets don't work correctly. Solution: Don't use it until it's fixed. Keep your current textureset. If you wish to experiment, please backup your map.
It seems to me SC2 is showing errors and warnings with simple stuff that just shouldn't show any errors, e.g. Display Boss Bar. I have decided not to pursue them until LotV is released.
You guys are aware this is LotV right? Only without the data mod (is it without the data mod?) but the engine is the same.
It does look like Blizzard finally obliterated their English localization nonsense. Now there is (as there always should have been) only 1 English language to choose from.
I think a lot of people are being too hard on this patch complaining that it broke their stuff. It is possible your stuff was broken to start with just SC2 was some how managing to make it work. I will need to investigate details more closely to find out the truth.
Quote:
I've got an odd problem: when I try to open my map, which uses the standard Blizzard Warcraft III Assets (not Renee's mod), I'm getting an error that the dependency cannot be found. I tried finding it through the Editor, looking at Blizzard dependencies and I can't find it anywhere.
Any idea of Blizz removed their Warcraft III assets? Or maybe it's just in a different place or something?
They are investigating the problem and any such message should be a bug.
For people complaining about enUK localization do remember the patch is not fully released yet in Europe (still down for maintenance). As such if you managed to patch you will have done so registered as American and due to the nature of the patch this might have changed you to using enUS as your active localization.
Maintenance is scheduled to conclude at 10 AM GMT which is in 4 hours time. Only then should EU players start patching.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Both are the result of incorrectly set permissions on your computer. They are not SC2 problems or caused by the patch.
Generally there are two causes for such an error. The first being the SC2E process lacks sufficient permission to access the files. The second being another process is accessing the files at the same time SC2E wants to.
To fix the permission cause run SC2E as an administrator. In the long term you should fix your permission settings rather but it is a good short term solution.
To fix the concurrent access cause try disabling any program that can be accessing the file at the same time. Such programs usually include backup solutions like dropbox (who will lock the files while synchronizing) and anti virus solutions like Kaspersky which will lock the file while scanning it (which it does for all new files).
However why would it be doing that? The code should build to be functionally identical as defined by the compiler. The actual produced code will be faster in the 64bit client due to the extra available features. The only slow down comes from larger object sizes as a result of alignment and packing constraints and bigger pointer sizes which requires more memory bandwidth and fewer fit into the cache.
Out of interest have you tried disabling SLI? It could be a compatibility problem with SLI and the 64bit client. This is usually the case when performance is that different.
Make sure your game settings are high enough to show them. I believe such eye candy is turned off at lower visual settings. Patch 3.0 reset everyone's visual settings to some auto detected default which might be considerably below the maximum setting.
As I mentioned earlier, it is probably memory related because the 64bit client uses more memory than the 32bit client for logical reasons. The 64bit client executes faster but will perform worse if memory is a limiting factor. It can be memory bandwidth (moving data from memory to CPU), memory availability (how much memory SC2 can use before having to use virtual memory) or even cache coherency (64bit build has less cache coherency due to elements being bigger so using more cache space so fewer fit in the cache).
Sounds like a problem with memory bandwidth rather than incorrect behaviour. Both 32bit and 64bit clients should be hiding units the exact same as otherwise they will out of sync (anything else makes no sense). The 64bit build will use more memory per object than the 32bit build due to a combination of structure/class alignment and wider pointers. Although the 64bit build will execute code faster (bigger registers, more registers and native instructions for single 64bit integer computation) some of this speed is lost by the increase in memory bandwidth (iterating the same objects uses more memory bandwidth) and decrease in effective cache capacity (elements are slightly bigger so cache can hold slightly less).
As soon as your system is pushed to the limit of memory performance then game performance will fall sharply. This can either be due to insufficient memory bandwidth (an increasing problem since todays RAM is not that much faster than RAM 10 years ago) or your system is out of free memory (having to use paging, running SC2E + SC2 on 4GB or less systems can easily cause this with complex maps).
From personal experience I feel like the 64bit versions have given me performance. This might be due to overall SC2 optimizations applying to both versions however in situations which used to lock my screen at 0 FPS I get at least 2 FPS odd.
Pitfall: PlayerHandle, the native which returns a player's account handle is now an error if called while testing a map. This is because it tries to access the player handle data which does not exist since local test players are never assigned one. Before it used to return null and print no error.
Solution: Before calling PlayerHandle a conditional test is needed to make sure the current session is not a test session. How this is done I am not sure but testing if the game is a manual test will not work (arcade sessions count as manual tests). What might work is checking if the game is online since if it is then the player should have a handle however I have not tested this approach yet so it might also not work.
You are aware it was a bug they had boarders in the first place right? The boarders are meant to be added via overlays if any so that they are applied to all icons for overall map style consistency. The fact WC3 icons had boarders meant that they were completely incompatible with SC2 icons as it looked ugly having WC3 boarders next to SC2 borderless icons.
Tried XML modifying the fields?
You guys are aware this is LotV right? Only without the data mod (is it without the data mod?) but the engine is the same.
It does look like Blizzard finally obliterated their English localization nonsense. Now there is (as there always should have been) only 1 English language to choose from.
I think a lot of people are being too hard on this patch complaining that it broke their stuff. It is possible your stuff was broken to start with just SC2 was some how managing to make it work. I will need to investigate details more closely to find out the truth.
They are investigating the problem and any such message should be a bug.
For people complaining about enUK localization do remember the patch is not fully released yet in Europe (still down for maintenance). As such if you managed to patch you will have done so registered as American and due to the nature of the patch this might have changed you to using enUS as your active localization.
Maintenance is scheduled to conclude at 10 AM GMT which is in 4 hours time. Only then should EU players start patching.