historic_bruno

Looks like the DEF bones are the ones that are important (since they're the only ones listed as joints in the inverse bind pose array, around line 1086). As far as I know, animations made with that rig will only animate those bones. Someone can correct me if I'm wrong, but basically: all the rigs used in the game have a <standard_skeleton> entry which lists the bones actually used by the game. Then they have one or more <skeleton> entries, each one maps a different set of bone names and hierarchies back to the original <standard_skeleton>. This lets us have multiple differently named and structured rigs mapped back to a single standard one, for instance there could be one set for Max, one for Blender, one for Maya, etc. When a COLLADA file is imported into the game, it looks up the bone names and tries to find a matching skeleton or throws an error if there's no match. So if you can map your rig to the standard biped, that would be the best route so we have interoperability between existing animations and models. As far as how to do that, it seems like if you don't give a <target> entry for a bone in a given <skeleton>, then it will coalesce into its parent, so maybe it would work if you can only list <target> for the important DEF bones. You need 29 bones (including root) to be compatible with existing bipeds. I don't know if it will work even if you do that, I guess it depends on how robust our version of FCollada is and how good Blender's exporter is...

Hi Spahbod, I notice you're doing random maps with rivers and stuff. I've gone ahead and uploaded my work-in-progress path placer to #892, if you want to take a look at it. Unfortunately it doesn't work perfectly and I haven't had the time to debug it. Basically you pass it two end points, a width, and some other controlling parameters. It generates random offsets from a straight line between the endpoints, connects the offsets with short line segments, then uses some polygon fill code to add all the tiles. There's definitely some bugs in the code though, the resulting curves are not always smooth

Nice job. For what it's worth, I'm working on the PMD-DAE converter script. It works with props now and is very close to working on bones, too. I just need to test a bit more and then we can run it on all the PMDs we want to keep. I'll take a look into a PSA-DAE converter too and see if that's feasible.

If any of them turn out to be useful (unboned models that is), we should convert them to DAEs, and delete the ones that aren't useful. Then if someone wants to redo the animated PMDs in COLLADA *and* provide the source .blend or Max file for other artists to use, they would be my hero.

Did it say "CivilCentre build limit of ___ reached"? How large is a large map? Edit: I just tested and was able to build like 30 civ centres with no problem Other possible build restrictions: Terrain - watch the slope and distance from water Territory - must build new CCs in neutral territory Distance - this is currently configured to be almost identical to territory expansion size, but it's still possible to be in neutral territory but too close to an existing civ

Fixed the crash, but hotloading still fails for unknown reasons.

Hotloading should be automatic in Atlas, like it is in the game, but I've noticed map generation crashes after editing the script, so Atlas has to be restarted anyway. Need to look into that 0 is just the default.

OpenTTD is a "real-time" game that allows orders when paused, as an option. What would be even better in my opinion is an easily accessed speed control, so that in the middle of combat, the game speed could be reduced slightly to allow more thinking time, at the user's discretion of course. I consider that likely to be implemented actually.

Oh, that information is indeed a bit outdated. The R button just generates a random seed now, rather than refreshing the map list. I don't remember when it refreshed the list, but I do remember it used to do that.

As quantumstate pointed out, you can run RMS scripts in Atlas, I think you need to restart Atlas if you add a new map script, so it will be displayed in the list. We don't have a script debugger though, so you'll have to debug by hand, using warn() and uneval(). There's actually a ticket for that: #812

This is one of the reasons why the IRC chat log should be public IMO. If you don't spend all day in there (and aren't on the dev team) you don't know the occasional updates that Philip makes and the challenges considered.

Fractals are a pretty common way of generating random terrain in theory, I'm not sure it works so great for games though, at least games where terrain is critical to strategy. You don't just want a map that looks pretty, it has to be playable and challenging. So that introduces a lot of constraints on the notion of randomness, like paths have to be clear and reasonable, players should be on approximately equal areas of land in most cases, resources should be approximately balanced, every generated map should be valid and playable, etc. I agree our random maps aren't very "random", one of the reasons is that the current API is too low level, it's difficult to establish concepts like islands, rivers, lakes, forests, deserts, which IMO is what you want when creating a strategic map. Also there haven't been any good specs for random maps, but now we have this guide, which should help redesigning our existing ones. That said, you can use any algorithm you want to generate terrain and place entities, as long as you know or learn JavaScript. As Erik pointed out the Trac wiki has almost everything you need to know about how the random map generator works including the data formats.

That would be my favorite map to play, I loved black forest in AoK

By the way, there's a problem with Ardennes forest as it's spec'd. The game will crash if there's too many trees, due to running out of memory, even with less than shown in your example map. It's not really possible to make a large obstruction only out of trees, at least not currently. I suppose actors could be used instead of tree entities, but the problem then is they have no obstruction, so it's only for visual effects. Also rendering trees is terrible for performance. Those are the biggest obstacles to an AoK-style "black forest" map in 0 A.D. The same goes for any other map with dense clusters of trees.

Is that the config file that produced the crash? Also, the crash dumps mention an error that usually occurs when it can't find the game data, I don't know how or if it's connected to renderpath changing.

Good to know, that simplifies things a bit

The VFS (virtual file system) means you can mount real OS paths as relative to a virtual root in the VFS, then almost every file the game uses goes through VFS (the virtual path gets translated to a real path by I/O functions). You can mount multiple real paths to the same VFS directory, with different priorities. Basically it's a way of abstracting how different OSes and file systems handle paths, and allows us to easily support mods that overwrite parts or all of the game data. Atlas-based tools also use VFS, they pass messages from the UI to the game engine, which handles the I/O. Currently it's a bit messed up because although VFS reads follow the priorities system, writes do not, making the concept of a user mod useless until that's resolved. IMO, total conversions should consist of a new app bundle, because it's likely the engine itself will be changed. In the case of other mods, I don't think we should place anything in or with the app bundles after distributing them.

Sweet list, this will no doubt help random map scripters

I guess NDK doesn't provide POSIX asynchronous I/O either, maybe look into using Boost.Asio? If you look at posix_aio.h, we already emulate it on Windows (waio.h/cpp), so perhaps you could use Boost to provide the same interface? Doesn't sound trivial to me :/ Maybe AIO can be avoided in your case. I'm guessing Jan wrote all that code, maybe you could ask him for advice.

Agreed. The thinking behind "user mod" is that it will always be mounted in the VFS, unless they're an SVN user, and everything that the game tries to write in public/ now, will go in the user mod directory instead. So in that sense, it's not user managed, because the user doesn't have a choice to save things there (until we have a mod editor), but they could certainly copy files in and out of that directory. The only time we give the user a file dialog to save/load files is with Atlas-related tools, but this is wrong because they don't directly access the underlying file system, going through the VFS instead. The fact Application Support is hidden on Lion is troublesome, that might be the best argument for storing mods elsewhere Saved games are definitely managed by the game, as the user doesn't get to choose the names or where they are located. We'll be adding a "delete" button to the load game menu, so at that point they will be fully managed by the game. It looks like Steam uses Documents at least for screenshots: But if you want to move Steam game data to a new computer, you only move files in Application Support: Another argument for using Application Support for mods, it provides an easy single location to uninstall game data or move to a new computer.

Some opposing viewpoints: They suggest using NSSearchPathForDirectoriesInDomains to find the user's Application Support directory (instead of something like getting the $HOME environment variable, or trying to construct the path manually), which is part of the Cocoa API, so we'd probably need to write a C wrapper in order to use it. Apple also has some clarifications about when to use ~/Library/: ~/Documents is not even listed as a possibility.

I like the idea of that Wiki page, I updated it with a table for Windows and clarified some things. Might I suggest we combine all three OS paths tables into one? They should have the same number of entries and that way it would be easier to compare at a glance.

AoK allowed transporting your own units in an ally's siege ram. To be honest, I found it confusing and not very useful, because as Erik says, you can't control where the units go, but also it's not clear what mix of units is in the siege ram at a glance. AoK provided some limited controls, I believe the ram's owner could unload all units but the joining player could only unload his own. There's also the issue of multiple players competing for the limited spots in the ram, and the difficulty for the owner in coordinating it all. We might be able to improve on how AoK implemented this, but still it seems low priority.

Can you zip up both crash dump files in %appdata%\0ad\logs\, maybe add your config file too, and attach them here?

While it could be argued this is more "realistic", we're really not an agriculture simulator, our farms are just an approximation I wouldn't be surprised if we added technologies that allow the user to improve farm production, or if there were civ-based bonuses for that. I think the intention for sheep and some other domestic animals is that they will be corralled, which will provide a steady supply of resources (approximating milk, new offspring, etc.) Instead of killing the animal for meat, you would normally take it to a corral. Read about that here. This sounds like a bug, it might be my fault. The AI should definitely take advantage of markets, both bartering that we have now and trade which is yet to come. I don't really like the idea of having "auto-bartering", because people have different strategies that are hard to combine into a coherent option, and it doesn't seem too hard to barter manually.