historic_bruno

Any more info on this error? I'm not able to reproduce it. It doesn't appear related to the AI serialization bug.

Documented the JSON here: http://trac.wildfiregames.com/wiki/Random_Map_Generator_Internals#DefiningtheMap

It's all fairly well documented on Trac actually: http://trac.wildfiregames.com/wiki/Random_Map_Generator Except for the .json file, I don't see documentation for that yet Basically it follows the same format as scenarios, if you look in maps\scenarios\*.xml in the <scriptSettings> element, you will see for example: { "CircularMap": true, "Description": "Arch enemies, Rome and Carthage, square off on a richly detailed map of Southern Italy.\u000a\u000aScout the lands to find free Treasures and to secure new resources.", "GameType": "conquest", "Keywords": [], "LockTeams": false, "Name": "Acropolis III", "PlayerData": [ { "AI": "", "Civ": "rome", "Colour": { "b": 13, "g": 13, "r": 166 }, "Name": "Player 1", "Resources": { "food": 400, "wood": 400 }, "Team": -1 }, { "AI": "qbot", "Civ": "cart", "Colour": { "b": 168, "g": 64, "r": 55 }, "Name": "Player 2", "Resources": { "food": 400, "wood": 400 }, "Team": -1 } ], "RevealMap": false } I'll try adding documentation about this.

Made a ticket for this http://trac.wildfiregames.com/ticket/1184

I can't reproduce this, any other specific steps that are needed?

Yeah, it should work fine on 10.6. I think we could support 10.5 with some hassle, but it's not something I'm pursuing, maybe once all the dust settles someone in the community will work on that

Great, glad to hear it! I've updated the instructions

Every short URL is surely taken by now, I'm surprised it was still available in 2001

OK, I talked with the maintainer of those Fedora packages, it just happens to be our very own Philip (Ykkrosh) The Fedora 16 build of 0 A.D. was disabled on the OpenSuse Build Service, but it appears to be working now: https://build.opensuse.org/package/show?package=0ad&project=games Can you try now with my last suggestion? You may need to clean up the other failed attempts. If it works, we'll add that to our Fedora instructions

Did you rename the sounds or were they exactly the same?

Quite right and apparently that was the inspiration for Apple releasing their own package, but as 10.6 is older than 1-2 years, they obviously feel no need to support it Of course if someone is on 10.6, they can install an older Xcode and get the command line tools installed.

Was doing a bit more digging and discovered this list of where App Store apps are allowed to write files. Note even ~/Documents is not listed, if we "manage" pictures we should use ~/Pictures, but we really don't so even that could be debated. Clearly saved games would have to go somewhere in ~/Library. It's very restrictive and I think it would be a good idea to follow those guidelines as general rules even if we don't plan to be on the App Store (for those curious, there are potential licensing conflicts between GPL and Apple's App Store policies). ------ Some people may have noticed you can't build 0 A.D. anymore even if you install Xcode and MacPorts. The reason is that GCC is no longer included with Xcode and the command line build tools have been removed by default from Xcode 4.3. If you installed an earlier version, as I did, it should work even if you upgraded. This annoyed a lot of people and caused some havoc among developers. Just recently Apple has released a standalone package called "Command Line Tools for Xcode", which includes LLVM-GCC (it pretends to be GCC) and all the libraries needed. It's a free ~160MB download from the Apple Developer Downloads site. You need a free Apple ID to access it. Or if you have Xcode 4.3+, you can download the same package through Xcode Preferences. I've tested, and it's possible to build the game and all its dependencies with only that package, in place of Xcode. However, because no SDKs are provided for backward compatibility, it's not possible to build a practical bundle without Xcode. Anyway I'm modifying the build scripts to handle either situation.

I don't have experience with this, but if you're on Fedora 16, shouldn't the first command be: curl http://download.opensuse.org/repositories/games/Fedora_16/games.repo >/etc/yum.repos.d/obs-games.repo Maybe the instructions just haven't been updated for Fedora 16.

Well first of all, most of what you can "easily" mod is located in binaries\data\mods\public. To create a proper mod, you will want to copy things from there into another folder like binaries\data\mods\yourmod. Most of the time when we talk about paths in the game, we mean relative to that mods folder. So civ data is defined in civs\*.json. Those are just plain text files in the JSON (JavaScript Object Notation) format. Units and structures in terms of gameplay are defined as XML, in simulation\templates (we call them formally "entity templates"). They also have art definitions (we call them actors) which are likewise XML, defined in art\actors. They define the 3D models, animations, and textures comprising the unit or structure in-game. Most gameplay logic is defined in JavaScript, located in simulation\components. That's just a brief overview, the mod also contains AIs, scenarios, random maps, sounds, and other miscellany. It sounds like if you don't want to change art, you'll have to stick with entity templates and civilizations. Interesting mods could be made just with those changes, but of course art is essential You can edit XML or JSON in any text editor, I also use Notepad++ because it has nice features.

I couldn't help it, I "peeked" and here's what I found out Mountain Lion won't be including X11, if an app requires X11 to run, the user is prompted to visit Apple's website with instructions on how to install XQuartz Apple is deprecating more unspecified parts of Carbon (C/C++ API for OS X, also primarily 32-bit), obviously pushing people into the Objective-C/C++ 64-bit Cocoa API There's a new feature called Gatekeeper, it blocks apps from running if they don't have a special signature from Apple, you have to be an approved Mac developer to acquire one, assuming that means paying at least $99/yr. Modifying a trusted app makes it untrusted and the OS X firewall will block it.

The existing horse is 624 triangles, looks like it wouldn't hurt from having more either. I think that will have slightly more impact with skeletal models than static, because each vertex has to be skinned, even so the camel is over 1500, lions and zebras are almost 2000. Given how common horses will be in the game, it's more important to make them look good IMO, compared to other fauna.

OK this is reproducible even without an app bundle, I believe the cause has been found and will be fixed in SVN.

If you're dealing with positions, there are several reasons why it might be undefined. The target could be garrisoned, dead, or training in progress (created but not yet spawned). Basically you want to check the position is not undefined before using it, as early as possible so the errors don't propagate all over the place. I think this should be added as a helper function for AIs.

The biome selection should become a part of rmgen, maybe in classes as vaguely documented here. But just moving them into a single global function would be a reasonable start

If you don't commit them directly (now that you're on the team ), then please make patches for any existing maps you change, it makes the changes easier to understand

Excellent, it's good to test these things Oh, that's not good. What action causes the error? I tried opening different maps and using various tabs/controls but couldn't reproduce it. If you have gdb, can you try something like this to capture the call stack: $ gdb 0ad.app/Contents/MacOS/pyrogenesis (gdb) run -editor *crash* (gdb) bt full

There's no technical reason, but that's how Alpha 9 data will be packaged If you think about it, it doesn't really make sense to require conversion of archived COLLADA documents at runtime.

Nice icon! I'm using it now In return I'll provide you with an app bundle: http://hotfile.com/dl/147504648/be7bb7e/0ad-r11112-osx.dmg.html (Edit: Fixed app bundle with correct icon, new link)

That's a bit more complicated than what I've got working now, but it sounds like it would make the build process slightly less painful. That would be more of an incremental improvement than an initial change. I don't think it will ever be foolproof, compiling software is hard and at least some technical knowledge is needed I haven't noticed linking taking longer than usual, though I do run the build with "-j5" The binary size is about 14MB using the static libs, so not huge but not small either. Yes, the version keys should be strings formatted like "X.Y.Z", but I have no idea how we want to format release numbers. For anyone interested, Apple has good documentation on the Info.plist keys here and a list of recommended keys here - I added the recommend ones. Sound is a totally separate issue from building and deploying bundles for OS X Nothing works in this bundle that wouldn't already work without a bundle. Not saying it won't be fixed, but you have to take one thing at a time.

Build script for OS X libraries, but note you can't really run it because paths have changed: By default, it builds against OS X 10.6 SDK with minimum required OS X version 10.6 (what this means: only system libraries available on Snow Leopard or later are linked. Further, you will likely get compile errors if you try building on 10.5. Changing these variables and it might work. However, the minimum version also tells the compiler how to link system functions: for 10.6 or earlier functions they are linked at compile-time, i.e. "strong linking", but 10.7 and later functions (assuming you changed the SDK) are linked at run-time, i.e. "weak linking". We don't handle that distinction yet, nor do we have much cause to, we'll just need to be aware of this). Because I was so tantalizingly close, I made a quick app bundle script which does all the things needed for a release. I'm sure it can be improved, but at least this way we might have something in place for Alpha 9 like we originally planned: (note: this script won't work for you, because I've changed libraries paths and Premake scripts, it's just to show what's involved Very much subject to change) As you can see the steps to creating a bundle are: Clean and generate workspaces with Premake Build game Confirm tests succeed Create standard app bundle directories Run archive builder on public mod (precaches XML, textures, and COLLADA models) Copy files into the bundle (shared libs into Contents\Frameworks, data into Contents\Resources, binary into Contents\MacOS) - for the reasons see Apple's Bundle programming guide Create Contents\Info.plist using PlistBuddy - this is just an XML property list file that contains info about the bundle Almost everything is done on the command line with the exception of creating the 0ad icon (icns seems to be the only format OS X recognizes and I created it using http://iconverticons.com from our crappy low resolution 0ad.png) and compressing the bundle into a dmg. I'll investigate whether/how these steps can also be performed on the command line. Final package ends up being around 375MB and I don't know anywhere to upload this for testing I tried copying the bundle from Lion to different locations on Snow Leopard, and it ran perfectly including Atlas. As far as making the bundle paths work, I've got a patch that adds some sysdep code so we can detect if the binary is in a valid bundle (tests if the bundle identifier is "com.wildfiregames.0ad") and a few functions to get the internal Resources and Frameworks paths (unrelated to previous paths patch). Paths are not hardcoded into the build unlike most of the solutions used previously.