ToME: the Tales of Maj'Eyal

Hi, i got some issue with the mac os version of ToME.

It hangs sometimes on world generation and always on game load. To fix the first problem i've to remove the T-Engine directory in library/application support/. For the second bug i cannot find a solution.

Any help?

maybe this will help 8p

During load i got this if i start the game from the command line

Lua Error: /engine/Savefile.lua:185: attempt to index local 'f' (a nil value)
At [C]:-1
At /engine/Savefile.lua:185 loadReal
At /engine/Savefile.lua:209 loadWorld
At /special/mainmenu/class/Game.lua:207 fct
At /engine/ButtonList.lua:119 click
At /engine/ButtonList.lua:83 ?
At /engine/KeyBind.lua:175

On new game error i get this

Lua Error: /special/mainmenu/class/Game.lua:171: attempt to index field 'step' (a nil value)
At [C]:-1
At /special/mainmenu/class/Game.lua:171 drawDialog
At /engine/Dialog.lua:123 display
At /engine/Game.lua:94 display
At /special/mainmenu/class/Game.lua:59
At [C]:-1 forceRedraw
At /engine/Savefile.lua:207 loadWorld
At /special/mainmenu/dialogs/EnterName.lua:43 plain
At /engine/KeyCommand.lua:73 receiveKey
At /engine/KeyBind.lua:182
Lua Error: /engine/Savefile.lua:185: attempt to index local 'f' (a nil value)
At [C]:-1
At /engine/Savefile.lua:185 loadReal
At /engine/Savefile.lua:209 loadWorld
At /special/mainmenu/dialogs/EnterName.lua:43 plain
At /engine/KeyCommand.lua:73 receiveKey
At /engine/KeyBind.lua:182

And this error is repeated a lot of time

Lua Error: /special/mainmenu/class/Game.lua:171: attempt to index field 'step' (a nil value)
At [C]:-1
At /special/mainmenu/class/Game.lua:171 drawDialog
At /engine/Dialog.lua:123 display
At /engine/Game.lua:94 display
At /special/mainmenu/class/Game.lua:59

it seems that it fails to open the savegame at line 181of Savefile.lua:

local f = fs.open(self.load_dir..load, "r")


my filesystem is not case sensitive, just to rule that out, and the character name had not spaces in it.

further investigation with

print("TESTING", self.load_dir, self.load_dir..load, f)

reveals:

TESTING /tmp/loadsave/ /tmp/loadsave/main nil


now, if only I could find where save games are stored...


ok bug found:

this line
fs.mount(path, self.load_dir)
gives
nil Archive type unsupported

and this is why the subsequent load fails

save files are compressed zip, so for some reason the default mac installation fails to decompress zip files. missing library program? I've unzip in the path, so it requires something else...

Hum no it does not require unzip :/

Maybe the OSX code provides some wrong paths or forbidden paths ?
Try to add print's to engine/init.lua see if one of the paths is bad maybe
And in engine/Module.lua in the part that handles savefiles

the engine.homepath

ENGINE /Users/LoSboccacc///Library/Application Support/T-Engine//4.0

which exists and is readable

the savegame being loaded:

Loading.. /Users/LoSboccacc///Library/Application Support/T-Engine//4.0/tome/save//world.teaw

which exists and is readable

the multiple bars doesn't give any problem in opening them.

I don't really know anything about how lua works, this is all done by the power of psychic debugging.
I do see a zlib1.dll in the windows version - but mac should ship with a copy of that.
I've tried to snoop into loaded libraries but I don't know mac either and without the good ol strace I'm lost (and dtruss, the equivalent sucks)

but the real question is, where does this fs.mount come from? I can't see any reference of it in the lua documentation nor I can find its definition via the power of grep, so I guess it's compiled somewhere.

YEs it's an export of PHYSFS_Mount

humm

a 'strings' reveal that the zip library is statically included

" zip 1.01 Copyright 1998-2004 Gilles Vollant - http://www.winimage.com/zLibDll"

oh well, I'll get the sources this evening and hack at it.

I've loved tome and hated the old interface, I can't wait for this new cool version to work



edit:


/usr/bin/ranlib: file: bin/Release/libphysfs.a(macosx.o) has no symbols

I do HATE mac osx. no matter what I do the stupid library compile without symbols.
(I've already tried every platform available via messing with the premake4 --platform switch AND adding -arch and -m32 by hand at the environment)

and obviously that ends in:

Undefined symbols:
"___PHYSFS_platformSetDefaultAllocator", referenced from:
_PHYSFS_init in libphysfs.a(physfs.o)
"___PHYSFS_platformRealPath", referenced from:
(lot of lines)
_PHYSFS_isDirectory in libphysfs.a(physfs.o)
_PHYSFS_getLastModTime in libphysfs.a(physfs.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status


nm shows that symbols are indeed there:


bin/Release/libphysfs.a(physfs.o):
00002420 T _PHYSFS_addToSearchPath
00003460 T _PHYSFS_close
00002500 T _PHYSFS_deinit
00002d90 T _PHYSFS_delete
00002d00 T _PHYSFS_enumerateFiles
(etc etc)


probably it has something to do with the symbols namespaces...

did you use any particular flag or macosx version for this? or some older gcc compiler?

guess what?

I've managed to build it, nuking the ifdef $isamac of the src/physfs/platform/macosx.c file that was clearing the file content.

and obviously with my build there is no problem at all in loading saves.

I've built it with that change and these commands
./premake4 --platform=x32 gmake
config=release32 make -B

I've then copied the Resources folder from the downloaded game archive but not the framework one as I've all the stuff installed already.

oh well.

Ahh nice!
I'll change it for next release..
Err .. what line ?

darkgod wrote:Ahh nice!
I'll change it for next release..
Err .. what line ?

nooooo only for the next release? CAN'T WAIT!

@LoSboccacc: Great!

this executable works for me, use it at your own risk bla blah disclaim disclaim:

http://www.mediafire.com/?mngcyinn2jj

and goes in t-engine.app/contents/macos/
it may contain virus accidentally delete all your computer files and on and on and on
don't trust stranger's file on the internet etc etc

I've removed:

#ifdef PHYSFS_PLATFORM_MACOSX

and

#endif /* PHYSFS_PLATFORM_MACOSX */

because for some reason using that compilation parameters this ifdef was failing.

but I think that the load game working is actually some random one in a million chance obtained by differences in the building environment and not an effect of the aforementioned changes.

hum...
what OSX version you use ?

snow leopard

>sw_vers

ProductName: Mac OS X
ProductVersion: 10.6.3
BuildVersion: 10D573

>cc -v

Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5659~39/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5659)

Some version here

ProductName: Mac OS X
ProductVersion: 10.6.3
BuildVersion: 10D2125 <- difference here, but this sould not be the problem.

For the

#ifdef PHYSFS_PLATFORM_MACOSX

Is somewhere defined PHYSFS_PLATFORM_MACOSX? Maybe the author would like to pass it from make and just forgot it.

Can't find it, but there's some trick to pass definition from a makefile ... anyone know where to find some docs??

Well, if you wanted to set a preprocessor variable from the command line (makefile, etc.) instead of #define-ing it inside a source file, you'd invoke the C compiler like this:

cc -DPHYSFS_PLATFORM_MACOSX=1 ....

Which means, in a makefile, you'd probably add -DPHYS... to some variable like CFLAGS. It would depend on the makefile.

The top-level Makefile calls make with TEngine.make as input, for building the T-Engine bits. So I guess you'd start there. Keep in mind that editing a generated makefile is a kludge, and won't fix the underlying issue.

OK, firstly I'm not supporting non-Xcode builds for the Mac. DG can if he wants but I'm not putting energy into two builds.

So if premake doesn't set the defines properly for the OS, use the Xcode build. It does.

Further the premake build probably isn't setting the same location for the saves, in ~/Library, so your build will be incompatible with the ones I'm going to be making.

So if you think the static libz is an issue, take the Xcode build and add a dynamic libz to it and see if that helps you.