 |
"I tried a few of the FMs and on Alchemist I got :WARNING: aas48 is out of date". On Awaiting the Storm I got "WARNING: AAS file 'maps/storm.aas32' is out of date WARNING: AAS file 'maps/storm.aas_rat' is out of date". I could find more but I think this is enough for now." |
|
|
"Alberic's Curse didn't seem to have any issues" |
 |
The warning is emitted in this place (line 1125 in ): c = token.GetUnsignedLongValue(); if ( mapFileCRC && c != mapFileCRC ) { common->Warning( "AAS file '%s' is out of date", name.c_str() ); return false; } So it seems it is not a timing issue, but a CRC issue, probably some sort of "unsigned vs. signed" or the computation on windows and linux slightly differ (so AAS compiled on Windows is OOD in Linux, and vice versa). The bug might be simply because GetUnsignedLongValue() returns an unsigned long, not an unsigned int, which crc is cast to during assignment. |
|
|
Here is what the code prints out: WARNING:AAS file 'maps/outpost.aas32' is out of date (mapFileCRC 3934177544 vs. token CRC 3934177546) WARNING:AAS file 'maps/thiefs_den.aas32' is out of date (mapFileCRC 4071290106 vs. token CRC 4071290054) WARNING:AAS file 'maps/alchemist.aas32' is out of date (mapFileCRC 2240627115 vs. token CRC 2240626987) WARNING:AAS file 'maps/living_expenses.aas_rat' is out of date (mapFileCRC 4133433449 vs. token CRC 4133433448) Why there is a difference and why it is so small is still a mystery. |
|
|
Even more curious is that the .cm file contains the same token (number), but is not considered "out of date", while the AAS file is. |
|
|
The CRC from the map data is computed by idMapEntity::GetGeometryCRC(). This in turn just XORs the CRC of each map entity together. That is basically the string CRC of the material, plus the float CRC of the vertices etc. There might be some rounding errors when computing these for floats. It is hard to say, tho, without tracing the entire CRC computation on windows and linux and comparing the output. |
 |
I don't know if it can help, but i solved this problem on windows updating the map files to 1.07 version with dmap command. |
 |
Since I was the source of the reporting let me know if I need to provide additional information! Some anecdotal info... When I load a map with aas issues you can sometimes tell because the AI's will walk in tight circles or have other erratic behavior/movements. Although you probably know this already, this can also be a major PITA if you have saved games because after fixing a map with runAAS the saved games can not be used. |
|
|
I'm going to boost the priority of this one, since it seems like it makes most missions completely unplayable on Linux. |
|
|
I wouldn't say unplayable but you better catch it on the front end or it can make things very frustrating when you have to start over on a map after running runAAS. :) I wonder... This doesn't seem to affect a lot of people (at least bad enough to report it). It could just be that the TDM linux population is quite small... Could it be that it only affect 64bit linux? Although Fedora is fully multi-lib and of course I'm using 32bit libraries for everything or it it wouldn't work, but could there be a round-off difference in some calculation? More than the CRC calculation. It would be one thing if the CRC's just don't match and the game is otherwise unaffected, but there seems to be an actual problem with the aas data. |
 |
The code is quite restrictive, so if the game thinks the aas file is out of date, it doesn't use it at all. Tha AI has to navigate through the map without the aas, so it is basically stuck with " go into this direction, and let's hope you'll get somewhere." A workaround would be to just emit the warning but use the aas file anyway. |
|
|
That would not a good idea, as it can lead to very frustrating problems when mappers betatest their mission and overlook the warning, likewise, the AI might have unexplainable bugs under Linux and people will blame the mapper (while in reality TDM loaded an outdated ASS file). It would be much better to find out why the CRC differs on linux and on the AAS file only (and it seems, only if you use an AAS file compiled on windows). Someone with access to the source, and linux and windows would need to look into this. |
 |
It seems this is due to g++'s -O3 optimisation setting, which is producing slightly wrong floating point values (it's off by the lowest bit, hence the small difference in the XOR calculation). It doesn't occur in debug builds which have optimizations turned off. After some research it boils down to the file idlib/Token.cpp which must be compiled with -O1 in order to fix the problem. (Also, it appears the SConscript part that was responsible for compiling idlib/bv/frustum_gcc.cpp with -O1 didn't actually work, which will be fixed when this problem is resolved). |
|
|
Awesome! Thanks for taking the time to figure this out. I'm a Fedora packager and our guidelines are that -O2 should be used and never -O3. I don't know what the difference between -O1 and -O2 is, but perhaps this is a good reason why not to use -O3... |
|
|
Fixed in revision 5549: compile idlib/Token.cpp with -O1, tested with g++ 4.4.3. |
- Anonymous
