anonymous commented

PS: This error also occured in the last stable version..

Buginator commented

Do you have any crash dumps, or any errors/warning messages?

We don't really have a active mac developer, so we can't troubleshoot this ourselves.

demonburrito@... commented

I'm running on a ppc g5, and I got it to work with a nasty hack in move.c. I replaced the assert with a condition that sets the direction difference to 0 when it's out of bounds. Probably a little too dirty for a real patch, but it seems to point to the problem.

Somewhere in game.c, a droid's direction is being mis-cast (big endian problem?), apparently. I'm a little confused by all the different save file formats, but I suppose I could track it down with a little time, unless (hopefully) this makes sense to someone who has been working on it. If you're that someone and you know exactly what it is, I'd be happy to test.

Giel changed blocking which not transferred by tractive

Giel changed resolution from `` to fixed

Giel changed status from new to closed

Giel commented

(In [6512]) * Do not perform endian swapping twice when loading, as it'll undo the first swap

• Make saving and loading of move controls symmetric

This should fix #96, #127 and #177

Giel commented

(In [6513]) Merged revision [6512] into the 2.1 branch via svnmerge from trunk

........
[6512] | muggenhor | 2008-12-28 15:31:54 +0100 (zo, 28 dec 2008) | 5 lines

• Do not perform endian swapping twice when loading, as it'll undo the first swap
• Make saving and loading of move controls symmetric

This should fix #96, #127 and #177
........