Messages

1

Mac / Re: OSX build of UFO:AI 2.3 available as torrent

« on: January 06, 2010, 08:04:33 am »

My wife is still running 10.5. I'll see if my local builds run on her machine. I've been trying to be at least somewhat careful in my builds, but I haven't tried testing. The main problem with pre-release builds is that they are so quickly out of date. That said, having more non-coders poking around and discovering bugs is always a good thing. Mattn, is it worthwhile to upload weeklies or something to sourceforge?

2

Mac / [FIXED in macports trunk] SDL_mixer + OGG broken? Fix in macports!

« on: December 21, 2009, 03:10:03 am »

Edit: this has been fixed in macports trunk, but this may be useful info if you don't use the source version of macports.

Hi fellow mac users. I've been experiencing a problem the last couple of weeks with OGG sound files not playing, and getting an error:

Code: [Select]

S_LoadSound: There are 0 joysticks available.
S_LoadSound: Could not find sound file: 'footsteps/water_under'

IF you are having the same problem (i.e. no footsteps being played, among other things), then read on! Otherwise, pretend that this message ends here.  

I finally tracked it down and it is a problem with SDL_mixer that has only been fixed with version 1.2.11 (which is not current in macports). It is fairly easy to modify the macports Portfile and PortIndex files to upgrade your version. First, find the port file using port file libsdl_mixer, and open it in an editor as the super user.

• Change the line that reads version 1.2.10 so that it reads version 1.2.11
• Comment out the line that reads patchfiles patch-leopard.diff
• Change the checksums: md5 65ada3d997fe85109191a5fb083f248c, sha1 ef5d45160babeb51eafa7e4019cec38324ee1a5d and rmd160 559355116a1c380edf71879da0dbcf5359f05476
• Save the file and exit the editor.

Next, you need to change the PortIndex file so that it knows about the change. If port file libsdl_mixer returns a path PREFIX/audio/libsdl_mixer/Portfile, then you need to edit PREFIX/PortIndex (again as the super user). Search for libsdl_mixer, and change 1.2.10 to 1.2.11. Save and exit.

Lastly, run port upgrade libsdl_mixer. Done!

I'm going to notify the port maintainer to get this modification upstream. And no, mattn, I'm not going to update the wiki because this problem will hopefully be extremely short lived.  

ps. if this doesn't work for you, keep in mind that I'm using the source version of macports from their trunk and using the most up to date dports. Modifying the instructions to work for a packaged release of macports is left as an exercise for the reader...

3

Mac / Re: Mac binary thread (now 26313)

« on: November 16, 2009, 11:01:28 pm »

Tiger is 10.4, right?

It should work, as far as I know. Possible problem: MacPorts turns out not to be intended for distributing binaries, but for recompiling on the local destination system. (Yea, that threw me when I saw that discussed on the MacPorts forums). The behavior of putting the MacPorts compiled libraries and frameworks into a program is unsupported at best.

It might be that the stuff compiled for 10.5 doesn't like 10.4; if so, that's ... well, so much for binary API compatibility :-).

<Sigh>. Best I can say at the moment.

You can make it work by setting MACOSX_DEPLOYMENT_TARGET before compiling macports. IIRC, there may be extra hurdles to jump through - but I got it to work when compiling 2.2.1 on 10.5. I had to talk to the macports people on IRC though. Yeah, it sucks bad to recompile everything you have in macports...

For more info, see the discussion threads starting here: http://lists.macosforge.org/pipermail/macports-users/2008-August/011334.html

4

Mac / Re: Game doesn't start

« on: November 16, 2009, 08:47:01 pm »

Yeah, I have not successfully run the program in 10.3.x. That version of the Mac OS is now very old, your friend can likely get 10.5 for a reasonable price now that 10.6 is out (which doesn't support PPC so is not an option).

If your friend has some programming experience, he might want to try checking out the 2.2.1 branch from subversion and compiling himself. Just make sure to use the maps from the downloaded version.

5

Mac / Re: Problem compiling 2.2.1 (now serious -- see second post)

« on: June 30, 2009, 01:29:39 am »

It is known that every released version does not work properly if run from outside an app bundle. This has been fixed in trunk.
For 2.2.x just run "make macinstaller" and you should end up with the correct app bundle in src/ports/macosx/installer

Mattn: will try to get a clean checkout to compile and post the patch for you to integrate with the branch/tags.

6

Mac / Re: Problem compiling 2.2.1 (now serious -- see second post)

« on: June 28, 2009, 10:45:24 pm »

In the build/*.mk files you need to remove the -M options (-MD -MT $@ -MP) from the build rules. I thought that I had checked that in, but apparently only in trunk and not in the 2.2.x branch/tags.

I think that you can just remove the include of Carbon.h from osx_main.m - that should clear up the last error.

HTH

7

Mac / Re: What was the last revision that could compile a map and play on a G4?

« on: April 27, 2009, 07:12:38 am »

I don't think it's been tested in a very, very long time. I don't have G4 hardware anymore, sorry.

8

Mac / Re: Still cannot load a map

« on: March 23, 2009, 12:12:43 am »

You've probably specified this somewhere else on the forum, but what HW/OS version are you running? I have a MBP/10.5.6 and have not had any problems with locally compiled maps. If you are on PPC then there might be an endian issue? Another option could be some invalid type/size assumptions in a vararg call?

9

Mac / Re: 2.3 Finally compiles but crash on trying to start a game

« on: February 22, 2009, 06:45:25 pm »

Try making a new ufoai configuration/preferences directory, i.e. move (mv) ~/.ufoai to another location before starting the game. If that doesn't work, run an 'svn up' followed by 'make clean' and 'make'.

I am on a MacBook Pro, Core 2 Duo, OS X 10.5.6 and everything works just fine, other than known problems with pathfinding, etc.

10

Discussion / Re: How Far Can we Go?

« on: January 02, 2009, 08:31:04 pm »

All of a sudden, the game finished after the corrupt city. Is that as far as it's got so far. Is it a time thing (ie. limit)?

I think in 2.2.1 there is a limit to the total number of civilian deaths you can incur before the game ends (40?).
Yes, it's arbitrary and many people complained about it and a more sensible measure of the end of the game
is being worked on.

Also, I captured UFO fighter and harvester, but couldn't research any of them - kept getting the "Need tech it's based on first". Have I stuffed up or do you need a scout before you can research further.

Yes, you need to capture a scout in order to research many of the alien technologies. I don't know why the scout was singled
out like this - I think the capture of any alien ship should be enough. But that's me.

11

Mac / Re: 2.3 dev version for mac question

« on: December 17, 2008, 10:49:39 am »

OK, I think we all can admit that the compile for mac wiki page is written for people with at least a little programming experience. One of the issues with providing 2.3 "nightlies" is that you cannot be guaranteed that any particular revision in the SVN trunk will work. Sure, everyone tries hard to make it so, but new features are being added all the time. Keep in mind that chances are anything stevenjackson provides to you will likely be outdated in less than 24 hours.

It seems that the fink instructions need to be modified to make sure that the *-dev versions of all the packages are installed. Also, I'm a little worried by people fiddling around in /usr/* with what appears to be limited knowledge of what they are doing. If you are using fink you should not need to add anything from /usr/local ! Everything from fink is installed in /sw/ precisely so fink doesn't clobber /usr/*! If I were you I would try to return to the original state of /usr/ (/usr/local/ is not important - everything in there is put there by users, not the system). For example, you should not have a /usr/shared/SDL (nor a /usr/share/SDL for that matter - I certainly don't.)

FWIW, I really wanted to get universal binaries working, and when I found out that fink does not support them at all, I switched to MacPorts. MacPorts is not perfect, but it works for me.

About the SDL frameworks: they need to be installed in /Library/Frameworks (I think ~/Library/Frameworks may also work, but I've never tried it.) So you should have folders named /Library/Frameworks/SDL.framework, /Library/Frameworks/SDL_ttf.framework and /Library/Frameworks/SDL_mixer.framework.

CFLAGS/LDFLAGS: these tell make which additional options to pass to the compiler/linker. When you say CFLAGS="-I/sw/include" you are telling the compiler to look inside /sw/include for additional header files (*.h) that it can't find in the default locations (/usr/include and /usr/local/include). Similarly, LDFLAGS="-L/sw/lib" tells the linker to look for libraries in /sw/lib. After that line you can use -ljpeg and the linker will look for libjpeg.dylib in /sw/lib in addition to /usr/lib and /usr/local/lib. Note that /usr/lib and /usr/local/lib are searched by default and should never need to be manually specified to configure! If you are using fink and configure complains about not finding a header file, then the correct package has not been installed successfully. For the record, AFAIK, there should not be a jpeglib.h in /usr/include. Apple does not ship libjpeg (jpeg is supported by Cocoa) and /usr/include is a "system" directory, i.e. it should only contain items that Apple puts there (you should put your own modifications in /usr/local/include)

Hope this helps.

12

Coding / Re: Offsite Installation development

« on: June 13, 2008, 10:09:25 pm »

There is also a chance to refactor the struct. It would be possible to place the common elements in the beginning of the struct, with the specializations at the end in a separate struct. Then the common code can use pointers to the base struct, while the specialized code uses pointers to the specialized struct. This is a more significant refactoring job that just ignoring the unused members though.

I'm not sure why the UFO yard can't be handled by the existing struct though. We may need a new "building" type, but other than that I don't see a problem, TBH. Also we would need to modify the member map to be a baseBuildingTile_t * and dynamically allocate the array based on the required number of rows and columns. So a UFO yard could theoretically be a very large installation! Similarly, a SAM site may be a 3x2 or 3x3 base with only a few preset buildings inside it. That change will probably generate some serious errors, but thankfully those are the sort that the compiler is good at catching. 

It's important to note that although this approach makes off-base and base installations identical to the code, this will be mostly hidden from the user. I would like to see the off-base installation management completely automated.

13

Coding / Re: Offsite Installation development

« on: June 11, 2008, 08:27:28 pm »

I've also been thinking about this problem and I've come to the conclusion that it probably isn't necessary to make a specific off-base installation data type. I think the easiest and perhaps best solution is to simply use the existing base structure with some small modifications.

One way would be to just relax the 8 base limitation. This is a very, very easy way to allow players to build installations all over the globe. There is some more micro-management involved, but it would be up to the player to manage how much they are able to take on.

A slightly more complex solution would be to allow the base struct to have a heap allocated array of buildings. This would allow bases that are much smaller and/or much larger than the existing base. By keeping these other base types in a separate "off-base" linked list (or similar container) we could restrict their size and building composition to a set of prototypes as defined by ufo files. This would also allow us to manage the resources for the player (i.e. keeping missiles stocked for the SAM site, etc.).

The advantage of these approaches is that there is much existing code for dealing with base management that would need little to no modification to be used in the new context. They would be just regular bases that aren't necessarily under direct player control. Also, making new off-base installation types could be as simple as adding a new prototype definition to the ufo file.

14

Mac / Re: Update 2.2.1

« on: May 28, 2008, 08:29:44 pm »

Wish I could help. Personally, I hate the music from most games (I find it distracting) and just turn it off so haven't noticed this problem.

You should be able to figure out which song it is by running the game from Terminal.app. It is in the utilities folder inside the main Applications folder. You need to type UFOAI.app/Contents/MacOS/ufo to see the messages. When the problem occurs, quit the program and check the output to see the last music started message.

15

Mac / Re: Trouble with configure and jpeg_CreateDecompress

« on: May 24, 2008, 04:24:32 am »

I think the only known way is to use MacPorts instead of fink. With MacPorts you need to install the libraries with the +universal variant (which works now for all the dependencies.) The configure script is also set up to automatically recognize MacPorts libraries in /opt/local. The principle I was working on is that up until a month ago no one else seemed to want to compile on Mac, so I wanted it set up such that all I need to do is type ./configure in order to prepare a release. I think eventually I'd go nuts if I had to type ./configure CFLAGS="-I/opt/local/include -arch i386 -arch ppc" LDFLAGS="-L/opt/local/lib -arch i386 -arch ppc" every time I had to run configure.