ToME Wiki
ToME 3
User data storage
Status: RESOLVED
NeilStevens: Right now, all the user data gets dumped into ~/.tome, instead of ~/Library/Application Support/ToME/
Fixed in CVS now.
Link problem
Status: RESOLVED
ShrikeDeCil: I'm trying to plug along on the Mac OS X Build Instructions, but I'm at the 'trained monkey' level of using configure/make. (XCode is more my speed). Step 3 seems to go off the rails if I'm reading things correctly. I assumed in step 2 that I wanted SDL-1.2.9.tar.gz, and SDL_net-1.2.5.tar.gz as the latest stable versions. Raw output from the configure line is (temporarily) available http://homepage.mac.com/bluea/FileSharing5.html (The ToMEbuildoutput.zip file.)
Here's the detailed notes of that I thought I was doing: Added notes:
- MacOSX10.4.4, Powermac G4 12" (867). Install XCode 2.2. This corresponds to "gcc version 4.0.1 (Apple Computer, Inc. build 5247)" as reported by "gcc -v" at the command line. Everything seems fine here.
Get the sources, here's the links I used. http://www.libsdl.org/release/SDL-1.2.9.tar.gz http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.5.tar.gz
- I used the Finder to untar.qz the file to a new folder: ~/Desktop/SDL-1.2.9 In Terminal:
cd SDL-1.2.9 CXX="c++ -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc" CC="cc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc" LD="ld -syslibroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc" ./configure --prefix=/usr/local --build=ppc-apple-darwin8.4.0 --host=ppc-apple-darwin8.4.0 DESTDIR=/tmp/SDL/ppc make install
The last couple lines of output are:
ld: Undefined symbols: __Unwind_Resume /usr/bin/libtool: internal link edit command failed make[2]: *** [libSDL.la] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 bluea [~/Desktop/SDL-1.2.9]: ls -lart /tmp/SDL/ppc/usr/local/lib/ total 72 drwxr-xr-x 3 bluea wheel 102 Feb 2 12:23 .. -rw-r--r-- 1 bluea wheel 36472 Feb 2 12:23 libSDLmain.a drwxr-xr-x 3 bluea wheel 102 Feb 2 12:23 .
That doesn't seem to be 'the whole library', so the install phase is dead. I can't determine if the 'configure' phase went off ok. So... could someone provide a hash of a 'working' version of the SDL libraries? Or am I using the wrong version? Clue?
NeilStevens: Your link doesn't work, and without the full output of the compile I can't help you.
OK, well, I don't know how fragile the SDL build is, but you're skipping a step. Before installing it, you'll want to just run a plain make to build it. It's trying to build anyway, but I don't know if running install before make might cause something to be missed in the build process.
ShrikeDeCil: Ok, that makes sense. So I blew away ~/Desktop/SDL... and dearchived a fresh copy of the source. At http://homepage.mac.com/bluea/FileSharing5.html there's a 'TOMEoutput02.zip'. I used the "./configure" line above, and the second command was a raw "make". I appear to get essentially the same output (at least, I get the same final error, although the word 'install' is dropped in the error message). Setting DESTDIR doesn't sound like it would make any difference for the 'raw' make. So.... Hrrmp. I'm using the right version(s)? Is there some other hidden dependency? X11? Fink?
NeilStevens: I certainly don't have anything like Fink installed, and would never have ToME depend on such a thing. Yes, DESTDIR is only relevant to the install rules, so its inclusion or omission should be completely irrelevant to anything that could cause a link failure.
If you're on OS X 10.4.4, have Xcode 2.2 with everything that brings, and are compiling the exact same version of SDL that I compiled (and you are), then nothing should work differently, so I'm not sure what could be going wrong here.
I'll see if I can run through the process again in the next couple days, and check that I'm not doing anything different from how I documented it.
NeilStevens: Solution: at the start of the process, run this:
- export MACOSX_DEPLOYMENT_TARGET=10.4
ToME 2
setuid issues
Status: IRRELEVANT TO CARBON BUILD
HarryErwin: I managed to get 2.3.2 to compile and run flawlessly on MacOS X 10.4.2, but I had to disable SET_UID to do it. I know RR did something similar in V-3.0.6 to address the same SET_UID problem, but I haven't figured out what yet from the source, and he hasn't gotten back to me by e-mail.
MichaelCroft: I did the same thing as HarryErwin, almost, by making the following change to config.h after line 123:
/* * Prevent problems on Mac OS X using "SAFE_SETUID". * The SAFE_SETUID code is weird, use it at your own risk... */ #ifdef MACINTOSH # undef SAFE_SETUID_POSIX #endif
Err... that is, that's what I wanted to do, but it didn't work, so I commented out the SAFE_SETUID_POSIX just above that. Clearly, I'm hunting around a little here...
I know that MacOS X disabled setuid "scripts" in 10.3.9, but compiled apps should be safe. It seems to run fine with SAFE_SETUID but not SAFE_SETUID_POSIX. I have a compiled version of 2.3.2 for OS X w/8 bit and 16 bit graphics I don't know if that's too much or if it should be more specific to 10 or 10.3+ or what...
NeilStevens: When you posted that link before, I mailed the illustrious maintaner about it. Thank you.
KentBehrends: MACINTOSH is not defined here - The makefile does define USE_MACOSX. This works:
/* * Macintosh and SAFE_SETUID_POSIX do not get along... */ #if defined(USE_MACOSX) # undef SAFE_SETUID_POSIX #endif
NeilStevens: I'll apply a modified version of that. What's the OS define that the compiler sets for that OS?
KentBehrends: You can use cpp -dM to see them all, the system-specific predefined macros expand to the constant 1. Here are the more interesting ones:
ozma:~ kent$ cpp -dM hello.c #define __ppc__ 1 #define __APPLE__ 1 #define _ARCH_PPC 1 #define __BIG_ENDIAN__ 1 #define __MACH__ 1 #define __POWERPC__ 1
I would not use any of the powerpc predefined macros... the __APPLE__ (gcc likes double underscores for system/predefined macros) macro seems the best to use.
NeilStevens: Agreed, thanks.
HarryErwin: I'll investigate Behrends' report. By the way, has anyone tried compiling tome 3 for Macintosh yet? I blew off with a number of undefined symbols: _gzclose..._gzwrite, _format, _quit, _vstrnfmt
HarryErwin: Behrend's fix seems to work.
NeilStevens: If I get SAFE_SETUID_POSIX undefined, it doesn't work here. I'm unable to write the "raw" files. I'm using makefile.bsd on OS X 10.4. If you guys remove the raw files (lib/data/*.raw), is your setuid/setgid tome able to regenerate them when this fix is applied? Thanks,
Graphics
Status: RESOLVED
HarryErwin: Here are two questions for Michael Croft:
- Have you put Behrends' fix in your code?
- How did you get graphics to work on MacOS X?
The reason I ask is that I'd like to get 32 bit graphics working.
HarryErwin: Here's what Angband 3.0.6 does to put the graphics tiles into the application:
TILES = 8x8.png 16x16.png 32x32.png
APPRES = $(APPCONT)/Resources
install-tiles: $(TILES)
install -m 644 $(TILES) $(APPRES)
The .png files have to be carefully prepared. The comment says: Make sure setting dpi to 72, *not* preserving the actual size of image. I did some work with RR to get the 32x32 tiles working smoothly, but I don't know how Angband loads and uses them.
NeilStevens: 'pelpel's Carbon code looks for the graphics in Contents/Resources, not in the libdir. So yes, that's where they have to be specially copied over.
I'm currently working on the code to fully bundle-ize it. Currently, by my reading of the code, it looks for a libdir OUTSIDE the bundle! That just won't do.
HarryErwin: Be careful that you leave the bone, data, save, user, scores, script, and help files outside the bundle. What RR did was store that stuff in the user's preference directory ($USER/Library/Preferences/Angband). You probably want to do the same.
NeilStevens: I was intending to use ~/Library/Application Support/ToME, but it's the same principle.
HarryErwin: Preferences/ToME is probably more obvious.
NeilStevens: If Application Support is good enough for iCal, Firefox, and Freeciv, it's good enough for ToME, I say.
NeilStevens: I think it's done. Try the 2.3.3(CVS) build at http://www.hakubi.us/tome/ToME%202.3.3%20CVS.dmg and see how it works for you. Prefs are in the same place as pelpel's old builds, but the user directory (which works how the unix builds work, except that the Carbon builds also put the "data" directory there to avoid the need for suid anything) is ~/Library/Application Support/ToME.
HarryErwin: It can't find the user directory, which means preferences and automat aren't working. Here is a start on the list of the directories that you'll have to keep in Application Support/ToME: apex, data, mods, note, save, and user. It looks like you've got data and save but not the rest.
NeilStevens: As with the Unix installs, many of those are collapsed into the same top-level directory. I need to run some better tests though to reproduce this. I think I'll try turning off all write access to the directories in the bundle to aid in that, heh.
HarryErwin: I found that moving everything into the top level directory made things work, but it means it contains a whole lot of stuff in no specific order.
NeilStevens: That's how it is in Unix land, heh. So, once you moved your old files in the right place, it all works for you (save for the graphics option below)? If so, once that graphics option is fixed, I think we're ready to release ToME 2.3.3.
Window Issues
Status: RESOLVED
NeilStevens: For me, the window sizes and positions don't quite restore correctly. Especially the Mirror window acts funny until resized manually once.
HarryErwin: No problems for me once I selected 16x16 graphics, but I use only the one window. One question, though, it looks like you're automatically setting up double-width graphics. That's fine by me, but seems a little odd, especially when you have graphics turned off initially. You'll have to enable the menu item to turn it on and off if you want to keep the people who don't use graphics happy.
NeilStevens: I didn't touch the graphics.
HarryErwin: That means the settings are being pulled in from some pref file and the double-width setting is being automatically set from that. The menu item to toggle double-width is disabled. To adjust the graphics, the player needs to open their pref file in a text editor. 8(
NeilStevens: I'll look into it.. it might have been caused by my commenting out the 32x32 tile option in the menu.
Yeah, that was my fault. I put the 32x32 menu item back in, and instead just kept it disabled in the menu. I'm glad you brought this up, because I didn't notice that menu option, and had been manually getting doublewide tiles by tweaking the other settings there, which was ugly for the text!
Alright, mods and apex taken care of, graphics menu taken care of, so this should work: http://www.hakubi.us/tome/ToME-Mac-2.3.3CVS.dmg
Modules
Status: RESOLVED
HarryErwin: Mods aren't working for me. 8(
NeilStevens: Can you be more specific? How did you install one, and what happened when you did? Thanks,
HarryErwin: I copied the mods directory to ToME/2.3, and it worked (as I recall) with your first release, but the list of modules at startup disappeared with your second release. Of course, I also copied the mods directory into the bundle for the first release and not for the second, so that may play a role.
Also, the scores report at shutdown has lost my pre-2.3.3 characters. What file is it accessing? The scores.raw in ToME/2.3/apex is not being updated. Just the one in ToME/2.3.
Added a little later: this is strange. I renamed ToME to ToME old in ~/Applications Support and now when I launch the second release of ToME 2.3.3, I get an error message: can't create directory ~/Applications Support/ToME. I had been using the directory created by the first release up to now and now I'm running with the second release. Note however, I installed Mac OS X 10.4.3 this morning, and Apple may have moved the goal posts again. (Checking) No, the 30 October release is fine. It can create the necessary directory. It's something you did in the second release. (Checking something else). No, putting the mods directory into Applications Support/ToME/2.3 doesn't show the modules for the 30 October release. (Trying something) But putting the mods directory into the application bundle for the 30 October release works fine. It looks like not all of the directory moves for the second release actually worked as planned. Time to punt?
NeilStevens: OK, the latest CVS fixes modules. I had forgotten to add the actual change of the Module dir on the Mac, after going to the effort of hacking around an issue that prevented me from making that change!
You will have to manually make a directory for the module inside ~/Application Support/ToME/2.3, or at least I had to create ~/Application Support/ToME/2.3/annalsea when testing Annals of Ea.
As far as I'm concerned, we're not ready to ship on Mac if the user has to modify the bundle.
Now I need to figure out how to get modifiers working better in macros...
HarryErwin: Where is the latest CVS? If I go to the one on TomeNet, it seems a bit old.
NeilStevens: Don't forget that you want the tome_230_branch of the tome2 module on CVS.
HarryErwin: I suppose that means I need to use the following command
cvs -d :pserver:anonymous@t-o-m-e.net:/var/cvs/tome checkout tome2 -r tome_230_branch
OK, it's complaining about not being able to create the directory inside ~/Application Support
I changed the name of the old directory back to ToME. Now it starts up and finds the modules. I had to restart graphics, but that was understandable. It seems to be OK. I do have a suspicion I'm not running your latest changes. Is there a way of checking?
NeilStevens: You are using my latest stuff if you got the sources that way. It sounds like whatever other versions you've been running have you messed up from time to time. If people who start fresh, and copy in whatever files they need, can use it fine, then that's all I can ask.
I just got an idea: drop the 'mods' dir inside the user directory, and just have the modules live directly inside the users directory. That way nobody will have to take the extra step of making the directory.
HarryErwin: Well, I did start fresh, and it couldn't build the ToME directory inside ~/Application Support. I'd suggest having a mods directory within ~/Application Support/ToME/2.3 to handle the second issue. That actually worked once I used the old ToME directory (built by the first release of 2.3.3).
NeilStevens: Oops. I re-ordered some things since I tested, to clean up the ifdefs a bit, forgetting that I had to make the parent directory first, heh. Fixing now.
Is there a identifier anywhere in the tome2 sources that gets updated each time you do an update and that I could report whenever I do a rebuild? That way we can avoid getting confused. BTW, how do you like bug459?
NeilStevens: Just run a cvs update command, and if nothing changes, you have the latest. Also, if you join the tome-cvs mailing list, you can be notified of all changes.
As for that bug report, I haven't looked.
Update: tome-cvs mailing list is now linked on the CVS page, and I just committed the module change, which has been tested and seems to work when I unpacked Theme in ~/Library/Application Support/ToME/2.3/theme
HarryErwin: So far, so good. Ran it with my current test character.
NeilStevens: With my input issue resolved, then as far as I can tell, the only outstanding issues are your Orc Cave crashes and my window size inconsistencies. That's pretty close to perfect, heh.
HarryErwin: The Orc cave stuff looks like an edge effect. The affected line is doing a deref for a pointer in an array. I'll bet you the array isn't quite as big as expected or there's a fence-post (off-by-one) error.
Input Issues
Status: RESOLVED
NeilStevens: Making a full set of macros is proving tough, when command-anything appears to be ignored, and alt-anything just does the usual composition, ruling out keys like alt-i.
NeilStevens: OK, I ifdefed out the code that intercepted command for use with the menus, replacing it with code that sends the command-modified keystrokes into the engine, so that I can get my Sorceror macros back!
Let's see if anybody complains.