Ykkrosh

Originally, the game just understood .pmd files (a custom file format) and we had a custom 3ds Max exporter tool (should be in source/tools/pmdexp/ but it requires a specific old version of the 3ds Max SDK). Then we switched to Collada (.dae files) as the main input format, using standard exporter tools for whatever 3d programs people fancy using, so that's what should be provided in SVN, and the game automatically converts and caches as .pmd (since that's a much more efficient format to load). There are standard importer tools for Collada, so that's generally quite straightforward. New meshes should all be .dae files, but we haven't converted all the old ones so they're still just .pmd, and there's no existing tool to import the .pmds into editing programs. The file format is reasonably simple, so it shouldn't be too hard to write one, but we haven't needed it so far.

This would mean it would prefer a 99-tile-long path on grass over a 101-tile-long path on road, so it would rarely pick the road. The differences need to be much bigger in order to have visible effects. I don't know exactly where a sensible cutoff is, though. This is C++, not Java . (Some of the code (in .js files) is JavaScript, but that's not Java either - they're unrelated except for their names.) In the VC++ IDE, I think you need to right-click on "pyrogenesis" in the project explorer panel on the left of the screen, and select "Properties", "Debugging", "Command-line arguments", and put -sim2 in there, and then run it from the debugger as normal (press F5 or whatever). Hope that works

Thanks, uploaded! (I only had flag images for countries so I had to make up one for this - I hope I got it right )

As part of a general redesign of the simulation system, I've actually reimplemented the pathfinding code in the past week - it's still pretty basic (we need to find someone who can spend a lot of time making it work nicely with terrain and unit sizes and groups and formations and then worry about making it all faster), but I think it probably works better than the old version. It's off by default (since the new simulation system is quite incomplete), but you can try it by using the "-sim2" command-line option. The code is here, and it's pretty much just doing A* over the map tiles with some tweaks(/hacks) to make it prefer more smoothly diagonal paths. One thing to be careful about is that the game compiles in Debug mode by default, with no optimisations, and (particularly with MSVC's STL) there's a lot of extra checks that slow things down - you ought to use Release mode to get an accurate view of the performance. (There's something in MSVC's GUI to change it, or "CONFIG=Release make" on Linux and run the pyrogenesis (not _dbg) executable). With optimisations, the new pathfinder only seems to take a few milliseconds maximum to compute long paths, which is okay for a single unit (though not great if you have hundreds all moving at once). Another thing is that the simulation (both old and new) only updates once every 350ms (I think), and whenever you give a command it can't take effect until the next simulation update, and there might be some extra turns of delay to handle multiplayer latency (it can't execute the command until every player knows about it and can execute it simultaneously). I think we need to adjust the timings a bit, but the result will probably be that commands could still be delayed by a few tenths of a second in total, which is usually fast enough that players won't notice much (particularly if there's an immediate audio or animation response, before the unit actually starts moving). The triangulation code (in the old pathfinding system) is disabled by default, partly because of problems with licensing. If I understand correctly (though I've never looked at this closely so I may easily be wrong), the idea was that instead of doing an A* search over every tile in the map (which can be a hundred thousand nodes), you split the map up into a smaller number of large triangular areas and do A* over them. One of the main difficulties with A* is that doing anything a hundred thousand times is going to be a bit slow, so simplifying the map into a much smaller graph is going to help even if the simplification is fairly complex. But I don't know how much of a practical improvement it makes, or how it compares to other optimisations. I've set up a very rough performance testing thing for the new system (run "./test -test TestCmpPathfinder" (or test.exe on Windows, or test_dbg or test_dbg.exe for debug version) in a profiler, or record how long it takes and try to subtract any constant overhead), so it'd be good to see what effect any changes have. Yeah, you can do that by changing the costs for movement between adjacent tiles. The tricky bit is that if your heuristic overestimates the true cost then A* might never discover the best path, and if your heuristic underestimates the true cost then it'll have to explore a lot more tiles before it's confident it's found the best path. So you need a careful balance between complex movement costs (used to model terrain types and slopes and keeping distance from enemy units etc) and reliable heuristics, to get correct and efficient behaviour.Pathfinding is interesting since you can easily get something that basically works, but then you can spend months adding features and optimising it - I think I've mostly stopped working on it myself (since it would take too long to gain enough expertise to do a good job of it, and I need to work on other things instead), but I'd like to see what other people can do with it

Sounds good to me - I've updated LICENSE.txt to reflect the new status. (In case anyone is wondering what effect this has on the overall game: it has no effect. The game is now mostly a mixture of GPL and MIT, so a compiled version of the game has to follow both licenses, and since GPL is the most restrictive you effectively have to just follow the GPL the same as before.)

What we currently have is a standalone program that generates map files that the game can load. The map scripts are JavaScript, like this, using various functions provided by the C++ RMS generator code.

A quick update on this after four weeks: I've mostly been working on adding an outline of the gameplay design - there's some Atlas editor integration, building placement, population counters, GUI interaction, pathfinding, combat, and minor other things. Currently planning to add some resource gathering and (extremely primitive) AI players too, and that should be alright for an initial outline. Then there's a load of details to fill in, and then it might be almost playable

The engine is already released to the public, in its current (incomplete) state - the game is now open source, including the engine code. There's information around here on getting and building it from SVN. The code is all GPL licensed, so if you wanted to use it and modify it then your changes would have be publicly released too - I don't know whether that would be acceptable to you or not. Ease of modding has always been a design goal: most data is specified in XML files, and much of the gameplay logic is in JavaScript (at least in the current ongoing redesign of the gameplay system), and we've tried to avoid putting game-specific stuff in the C++ engine code. The focus is on making 0 A.D. and not on making a generic reusable RTS engine, but I think we still want to encourage reusability, particularly if it means we can share resources with people who want to do similar things to us

Try again in half an hour, once the autobuilder has updated - that should fix some problems (hopefully the ones you're experiencing).

Is there any way we could do something equivalent to adding a .lnk shortcut file in SVN, which points at the %appdata% path, so people browsing the game installation directory in Explorer can find the log files more easily? (I have no idea how portable .lnk files are, or whether they can point to non-absolute paths.) Actually, maybe it'd be easier to just have an OpenLogsFolder.bat file that does "start %appdata%\whatever" to open the folder. I can't see why that wouldn't work, and it's easier than requiring people to read the .txt file and to understand what "%appdata%" means.

Welcome We just use OpenAL. As I understand it, there are known problems between OpenAL and PulseAudio in Ubuntu that cause problems for quite a few games, and so it should be fixed by Ubuntu people soon (maybe next release or something) and there's nothing we can easily fix ourselves. Not sure if there's anything you can do immediately except disable PulseAudio (and presumably switch to ALSA), which doesn't sound trivially easy.

Try Start menu -> Run -> "%appdata%\0ad\logs" and it should open the logs directory - it's not in the SVN ...\binaries\logs directory. (The readme.txt in there points at the %appdata% location.)

See #270 - I think switching on GL_ARB_shader_objects should be sufficient.

Nice, I hadn't seen that before - the FAQ claims OS X support too so it covers all the interesting platforms, and it looks more focused than Awesomium on simply providing a portable embedded browser (which is what we want). This definitely seems like something worth watching The interesting part of Chromium (from my perspective) is not the API, it's the backend - graphics engine, network layer, video codecs, database, filesystem interface, etc. WebKit itself doesn't contain any of that stuff, so you have to combine it with some usually-platform-specific port (which rely on OS X frameworks, or on Gtk, or on Qt, or (like Chromium) on some other set of libraries). The ports provide the embedding API, and Chromium also adds a (optional?) new JS engine, but the portable backend is what we most need.

Erik mentioned the first problem yesterday, but it works for me and I've got no idea what causes it. For the second problem, one guess is that it could be fixed by creating a text file ...\binaries\data\config\local.cfg saying fancywater=falseOtherwise could you find the files that are probably in C:\Users\Whoever\Roaming\0ad\logs called system_info.txt, crashlog.txt and crashlog.dmp, and upload them somewhere?

Well, most basic things don't work either . But a few do, and I think it should now be fairly straightforward to get the rest done in the next few weeks, and it should be reasonable to switch to it as the default then. So hopefully it won't be long to wait

Yeah, I think the changes I've made shouldn't affect the old system (though I could be mistaken) so I'd prefer to blame someone else for the bug . I wouldn't be too surprised if I had accidentally broken it, though. But in any case I'd agree it's probably not worth spending much effort to fix, since all of this should be replaced by the new simulation system soonish, which will get rid of those old bugs (and add a whole set of new ones). If you're running from Visual Studio, and it's on the (default) "Debug" configuration, then you'll be running the ones you built yourself (pyrogenesis_dbg.exe), and the ones in SVN (pyrogenesis.exe) are separate. If you build the "Release" configuration (which has compiler optimisations enabled) then you'll overwrite pyrogenesis.exe, and SVN will complain of conflicts when you update, so you'd probably notice.

Sounds like this bug - does fancywater=false fix it for you? (The 2 test failures are currently expected on Windows, because our fpclassify emulation doesn't work (the exact error messages will be somewhere higher in the debug output window) and it hasn't been fixed yet.)

I think somewhat-regular releases are a good idea, and I've recently been suggesting it a bit . For it to really work, I think we need to start in a situation from which it's possible to reach a decent completed game by lots of parallel incremental steps, and I believe the problem we've had in the past is that the gameplay code became too messy and incremental improvements weren't feasible, and nobody wanted to work on it, which blocked progress. So I've been redesigning and reimplementing it now, which is a lot of non-incremental work but I think it's getting closer to a stable state - I want to finish getting the broad features in, built on a solid framework, but then I'd like to pull it together into a release before starting the long incremental process of adding and polishing all the desired features and details. So I expect it'll be a while (a small number of months) before we could reasonably move onto a more OS-friendly release system, but that's what I'm currently aiming for, and I think it's likely that it will work out

People have had success with some versions of Ubuntu but I don't know if any were on Jaunty. If the suggestions here (libboost-system-dev etc) don't help, you could try running locate '/usr/lib*/libboost_system' and pasting the output here, since that should show if it's installed under a different name.

Might be good to have some introductory documentation, kind of like the Playing0AD page but more focused and goal-oriented - perhaps have a page for "I've installed the game, what do I do now?" with topics like "make a map" and "edit a texture" and "add a new unit into the game" and "modify the GUI layout" etc, where each one gives brief step-by-step instructions on what programs to run and what files to edit in order to achieve something simple. That could help people become aware of the functionality that's available, and encourage them to start exploring it themselves in more depth.

Yeah, it'd be good to have more documentation of the features and make it reasonably findable . (I quite like how Inkscape shows common actions and key modifiers in the status bar, depending on your current mode/tool, so maybe something similar could work for Atlas). (Right-click in AoM appears to select the texture under the mouse for future drawing, which I guess is also a useful feature - maybe Atlas should have some way to do that too...)

Yes it does, seemingly. A one-tile strip of rock on grass appears half a tile wide, a one-tile strip of grass on rock appears two tiles wide. Atlas gives you more control since you can choose the in-front and behind behaviour in both cases. (But, Atlas does cause these rendering glitches.)(Also in that screenshot, AoM does let you have a lot more than 3 textures on one tile; our game does the same.)

In Atlas, use the right mouse button when painting terrain to make it go 'under' the surrounding tiles instead of over. And set the brush size to 0 if you want to draw the tiniest little bit. That should let you draw half-tiles. (I suppose it's a bug that the brush display vanishes when you set the size to 0, but it still draws. I think there's also a problem that the brushes were designed for altering vertices, but terrain textures apply to tiles, so there's a half-tile offset.) The image actually has four textures on one tile, where the black+grey+grass+lava meet. I think you ought to be able to get nine on one tile, if you use a different texture per tile and the middle one is the lowest priority.Does AoM have hard-coded texture priorities? i.e. you can draw a half-tile-wide strip of black stuff on top of grass, but can you draw half-tile-wide grass on top of the same black stuff?

(By the way, currently Atlas (in the TerrainHandlers.cpp code) gives each tile a priority that's unique amongst its neighbours, but it seems fairly easy to change it to prefer to share priority with existing neighbours if they're the same texture as this new tile and are already higher/lower priority than all other neighbours. That would prevent some of the common cases where priorities are unnecessarily varying, so it might usefully mitigate the problem, though it wouldn't solve the worst-case errors and they'd still need to be handled somehow.) { I think we do need to fix this eventually, but it's not critical by itself and it's not blocking any other work, so no urgency is required . It's been a niggle for years so it'd be nice to get it out the way, though. }