View Issue Details

IDProjectCategoryView StatusLast Update
0003184The Dark ModCodingpublic04.09.2012 13:41
ReporterSpringheel Assigned Togreebo  
PriorityhighSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Target VersionTDM 1.08Fixed in VersionTDM 1.08 
Summary0003184: Missions have AAS error in Linux

It seems that under Linux, some missions load with aas errors. AI don't path properly, making the game fairly unplayable. Oddly, the missions work properly under windows.

TagsNo tags attached.




21.07.2012 17:27

administrator   ~0004720

"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."


22.07.2012 16:27

administrator   ~0004721

"Alberic's Curse didn't seem to have any issues"


03.08.2012 10:53

reporter   ~0004736

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.


08.08.2012 19:26

reporter   ~0004743

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.


08.08.2012 19:28

reporter   ~0004744

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.


08.08.2012 19:33

reporter   ~0004745

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.


09.08.2012 09:32

reporter   ~0004746

Last edited: 09.08.2012 09:33

View 2 revisions

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.



12.08.2012 15:11

reporter   ~0004749

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.


14.08.2012 01:16

administrator   ~0004757

I'm going to boost the priority of this one, since it seems like it makes most missions completely unplayable on Linux.


14.08.2012 02:59

reporter   ~0004759

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.


22.08.2012 15:57

manager   ~0004776

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.


24.08.2012 07:05

reporter   ~0004778

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.


04.09.2012 12:18

administrator   ~0004791

Last edited: 04.09.2012 12:19

View 2 revisions

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).



04.09.2012 13:10

reporter   ~0004792

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...


04.09.2012 13:41

administrator   ~0004793

Fixed in revision 5549: compile idlib/Token.cpp with -O1, tested with g++ 4.4.3.

Issue History

Date Modified Username Field Change
20.07.2012 21:24 Springheel New Issue
21.07.2012 17:27 Springheel Note Added: 0004720
22.07.2012 16:27 Springheel Note Added: 0004721
03.08.2012 10:53 tels Note Added: 0004736
08.08.2012 19:26 tels Note Added: 0004743
08.08.2012 19:28 tels Note Added: 0004744
08.08.2012 19:33 tels Note Added: 0004745
09.08.2012 09:32 ECHELON Note Added: 0004746
09.08.2012 09:33 ECHELON Note Edited: 0004746 View Revisions
12.08.2012 15:11 hobbes1069 Note Added: 0004749
14.08.2012 00:56 Springheel Target Version => TDM 1.08
14.08.2012 01:16 Springheel Note Added: 0004757
14.08.2012 01:17 Springheel Priority normal => high
14.08.2012 01:17 Springheel Severity normal => major
14.08.2012 02:59 hobbes1069 Note Added: 0004759
22.08.2012 15:57 angua Note Added: 0004776
24.08.2012 07:05 tels Note Added: 0004778
04.09.2012 12:14 greebo Assigned To => greebo
04.09.2012 12:14 greebo Status new => assigned
04.09.2012 12:18 greebo Note Added: 0004791
04.09.2012 12:19 greebo Note Edited: 0004791 View Revisions
04.09.2012 13:10 hobbes1069 Note Added: 0004792
04.09.2012 13:41 greebo Note Added: 0004793
04.09.2012 13:41 greebo Status assigned => resolved
04.09.2012 13:41 greebo Fixed in Version => TDM 1.08
04.09.2012 13:41 greebo Resolution open => fixed