historic_bruno

This is no problem, there are already plans to separate the game's libraries by OS. In other words, we'll have \libraries\win32, \libraries\osx, \libraries\linux, etc. Developers will only checkout whichever directory they need. It wouldn't be too hard to add some Android-specific patches, including whatever eases 0ad development on Android, assuming we decide to support Android. Sounds good to me. Maybe start a new topic or Trac ticket for this, as you get closer to a working version of the game.

There was an error in the selection group name, try now

I have no idea about that compilation error, as I've never encountered it. Are you using Mac Ports and have you fully installed Xcode? Is there plenty of free space on whichever volume you're compiling on?

I believe if you run the game with the "-writableRoot" option then all the data gets saved next to the binary, which would make it essentially self-contained. I could be wrong about that though, since I've never tried it.

Just curious, why you'd want to do this? Generally, the engine shouldn't have anything to do with gameplay concepts like attack and damage. If you're just wanting it for some kind of graphical indicator, I'd suggest exposing a suitable API to scripts, if it doesn't already exist, and calling that directly (we do that in a few cases related to health bars and selection rings). As far as debugging scripts, you currently have to do this by hand, uneval() and warn() are your friends

The animation needs to be "baked", or converted from the representation in Blender to transformations of the bind pose bones. It's simply not a usable animation the way the COLLADA has been exported right now. If there are no animations directly affecting the bind pose bones, then by definition there are no animations we can use, hence the error message There are some instructions here in the Animation section about baking rigified animations for COLLADA export, but I don't know if this feature exists or is simply planned. Couldn't hurt to try it.

That's on my TODO list actually, there's so many patches needing review Actually I've looked at it a few times, but as it's a long patch, it needs a long review.

Your C: drive is very small and only has 1GB free space, I suspect you will run into all kinds of weird problems. 10GB is hardly enough for Windows XP, and certainly not enough for later versions. You should fix that and also, sometimes files downloaded on Windows get "cached", so if you try to redownload the file it will use the cached version and skip the download. This obviously causes a problem if the download was corrupted. Did it take the normal amount of time to redownload the installer or was it much faster?

I would leave "event" handling up to the AIs, and make sure all the most meaningful events are provided on the chance they need to be used. But I also think unlike some other JavaScript applications, AIs shouldn't be sitting around waiting for events, but always active processing things, since they have enough to do already We can even provide a decent interface to poll the events. But I think there should be higher level data structures for the really useful data, like entities owned by the player or tile obstructions.

Argument against saved games in (My) Documents: the files have no value without the rest of the game. Screenshots have some intrinsic value, whereas saved games might as well be deleted with the rest of the game data, if it's deleted. Also, I notice Steam used to store all data in Documents, but then a bunch of people complained, so they changed to Application Support. Related question: should we have an "uninstaller" for OS X? Otherwise we leave a bunch of files behind after the bundle is deleted. The same question could be posed for Windows and Linux.

The advantage of having screenshots in a hidden folder would be...? If it was so important to Apple that apps use Application Support for *all* data, they shouldn't hide it by default, now they are forcing us to consider alternatives. Also if we were writing a native Mac app, I would agree, we would use the standard file open/save UI. But we're not going to have an OS-specific UI in game AFAIK, the path will be chosen by the game but it's the user who takes the action to create the file. Saved games is a debate worth having, but if there's no strong resistance to having them in My Documents on Windows, then I don't see the problem on OS X either. We can't pretend "OS X users don't care about paths but Windows users do" because that's a false statement. Everyone can have a preference about this, which is why something like what Yves suggests might work. Oh. I think I did read that post, but interpreted it as working on bundle stuff, my patch doesn't have anything to do with bundles. Also I looked on Trac and didn't see a ticket and there was little activity on the forum or IRC, so I just started working on it. I wasn't trying to duplicate effort or step on toes. I don't think our work is totally incompatible, and also it was good to get some experience with Cocoa and Objective-C++ (and I discovered some unrelated bugs meanwhile) I mostly started working on it because I knew it would only take a few days, and then we would have code to discuss what's right or wrong, like we are now so I guess it worked No need to throw away what you've been working on. INSTALLED_DATADIR should be an absolute path, so that doesn't sound like a good idea for bundles which are portable by nature. The paths I changed have nothing to do with bundles, but will be the same for SVN vs. releases. I don't understand. Can't we just use CFBundleGetMainBundle or something to see if we're a bundle or not and go with that? I haven't tried it to know if it works reliably (we could also check if there's a .app in the path as an additional validation, which is an "ugly" hack we use somewhere else, but it might work). My feeling is we should use it anyway to get bundle info, like the bundle name, so we can set the paths accordingly (e.g. ~/Library/Application Support/BundleName/). If I'm not mistaken, the VFS already checks if full paths exist or not and creates them accordingly, of course that doesn't help reading the root game data if it's missing, but that's something either the engine (with simple logic) or the installer should get right, rather than being left to user decisions or compile-time options. Yeah, my patch doesn't do anything about mods, and honestly the VFS is in such a state currently that it's not even worth thinking of multiple mods IMO (in fact I recall recent discussions about only allowing a single mod to be mounted as a simplifying case). But if we do, all that needs to happen is, for example: (1) is already mounted in VFS root (readonly), (2)/(4) m_GameData / "mods"/* get mounted in VFS root (readonly), and (3) m_UserData / "mods"/* get mounted in VFS root with read/write permission. Am I missing something? Permissions is a tricky issue and one we try to avoid so far, but it's easy to fix in this case. With sensible locations for all the game's data, there's no need to worry about permissions, because the current user will have full permission for their home directory (where all the runtime data should be created) and read permission elsewhere. And there's no need to worry about whether they exist, because if they are writable runtime data paths, then the VFS will create them for us. The only thing that absolutely has to exist in advance and be readable is the data and binaries bundled with the game, in which cases are these missing or not accessible? It's always worth working on something if it can be done better, because nobody has exclusive rights to change a part of the game's source code That would simplify things quite a bit, right now the simplest case is downloading libraries/osx from SVN, and running the single ./rebuild-libraries.sh script, which downloads, builds, and installs everything, or we can choose to provide the source tarballs, but then it could be argued that doesn't help much because it adds to SVN checkout/update time and doesn't reduce build time, but does increase maintenance.

We will indeed, thanks for reporting it! And have we ever discussed how yucky it is to hardcode template names in the AI code?

I hope I'm not influencing the results too much with all my VMs

As far as data paths go, expect a patch for #1145 very soon, taking care of both Windows and OS X at the same time.

About prebuilt dependencies: I have a few concerns about how this is progressing: By getting rid of the Mac Ports requirement, we lose the nice pkg-config tool, which is what non-Windows builds currently use to get include and lib paths for most dependencies. For some this is not a problem, because they are simpler and self-contained, but for example SDL and wxWidgets need many frameworks and other dependencies as well as compiler directives which need to be included based on the build configuration. Luckily we have sdl-config and wx-config, but it should be noted those tools only return absolute paths from where they were installed (with make install). So my dependencies build script runs make install as a final step for each of them (to a nearby directory so sudo is not required), but that means the results are not really reusable across systems (imagine you have an SVN checkout in /path/to/ps/ but I have it in /some/other/path/to/ps/, well then my bundled wx-config and sdl-config wouldn't work for you). Normally these files go in standard OS-specific locations, so it's the same for each system. So Philip suggested that the dependencies build script should get run every time a new developer wants to build the game on OS X (or more specifically, every time they want to build in a new location). I feel that defeats the concept of prebuilt dependencies, the goal should be to offer them in SVN so all that needs to be done is a checkout of the libraries package for your OS and the game's source. We already do this for Windows, except wxWidgets but I believe we can even include that, since only Windows developers would be forced to download it. The only solution I can think of to fix the lack of pkg-config and the absolute paths of e.g. sdl-config, is to hardcode their results in extern_libs4.lua for OS X, for developers who don't want to build the libraries. So that means we would need two build paths for OS X alone: one for developing with the downloaded prebuilt dependencies (default), and one for those who use the rebuild script (maybe because they can't use the others) or Mac Ports/Homebrew or some other alternative. I guess a flag passed to update-workspaces.sh would select the second case. The worst part about that is the maintenance required, whenever the OS X dependencies changed, they would need to be rebuilt and e.g. sdl-config run to retrieve the necessary info, which would be placed by hand in extern_libs4.lua. That introduces a lot of potential for error, but maybe acceptable if it rarely happens. Any other ideas? Blender SVN offers prebuilt static libs for multiple versions of OS X, Linux 32/64-bit, and Windows 32/64-bit, and they never ask you to build any of them, the result is an otherwise daunting and time-consuming process becomes much simpler. Of course they don't use Premake, but I assume they had other similar concerns in their build system As far as the time it takes to rebuild the dependencies with my current script, I would say maybe 5 minutes on my PC using 4 parallel build tasks, and considerably longer on older hardware, that doesn't include time required to download the tarballs if necessary (I do a test in the script, if the file doesn't exist, it assumes it should be downloaded first - still need to test that actually works).

Unfortunately the engine can't load your animations. However, using Pureon's test files, I was able to see your model in its bind pose so that's better than nothing What process did you use for the animation?

Excellent So the biggest change is the addition of an "accepted" state? Actually I have found it strange that it goes from assigned -> new in unexpected ways when reassigning a ticket and only ends up as assigned if it was accepted. Is it a difficult change?

Ah, it's an -er vs. -re problem and indeed a bug, thanks for reporting the error

That's strange, can you check if those files exist? They should be in /binaries/data/mods/public/audio/interface/complete/building/.

How do you know it's the same error, did you use a debugger? (There are actually a lot of potential causes of "unhandled exception" errors, and more generally, crashes) I'd be surprised if it was the same, since you have a decent graphics card and Nvidia is pretty good about supporting older devices and updating drivers.

Should be fixed in SVN, check it out.

Next autobuild will have a fix for this crash

You could, or you could trivially modify the DAE, maybe the file's timestamp is all that has to be changed? What's happening is the game is only looking at skeletons.xml when the model is converted from DAE, then it becomes a PMD (our internal format of the data), and skeletons.xml is not used again, unless the DAE changes or the cache is invalidated. Clearing the cache is done by deleting the contents of %appdata%\0ad\cache, which is harmless because it all gets rebuilt. I was getting a crash last night, it was a divide by zero error, apparently because there were zero frames in the animation. That was before I cleared my cache, and I couldn't reproduce it afterwards. But looking at <library_animations> in fisherman.dae, I don't see any of the DEF- bones being targeted, so I think there really is no animation we can use. I'm about to make a bug report about the crash though, just need a minimal test case. I don't know if your crash has the same cause.

If you didn't wipe the cache every time you changed skeletons.xml, then that's a possibility. I was doing that some times I tested, but not always (it's easy to forget).

Edit: ignore all that, the test model was cached and didn't reload The script would probably clean up the unused bones, rename them, and apply whatever animation magic goes on in Blender, resulting in only transformations of the bind pose, which is what we need. No, it currently only reads COLLADA. If someone was able to write an importer for BVH, we might use it, I don't know what (dis)advantages it has