Ykkrosh

I experimented here and got it to apparently work on Ubuntu (by changing some dependencies to non-universe versions, disabling the map editor and associated dependencies, and adding the three that were still needed). Now it's broken on Debian and probably other versions of Ubuntu (I guess I need to learn how to write packages properly, so that it uses the right dependencies everywhere) but it looks like it should be possible to get this working nicely with some more time.

Thanks for your work on this! Patched that Makefile. We just link with "-lbfd", which I would have imagined ought to be the right thing to do. Per this bug, it sounds like binutils-static is needed in order to make libbfd.so actually work. There's already an Ubuntu package from PlayDeb around here, which hopefully does most of the work that's needed. It probably would be good if we could build packages ourselves (via OBS) without relying on them to do all the work, so that we can push updates quicker, if it's not too hard to get that working. It's probably safest to stick with the current release tarball plus patches, since SVN may be unstable and the release isn't too old yet.

I've committed some changes that let you specify directories: ./update-workspaces.sh --bindir /usr/games/bin --datadir /usr/share/games/0ad --libdir /usr/games/libThen it'll look for files like /usr/share/games/0ad/mods/..., /usr/games/lib/libAtlasUI(_dbg).so, etc. Is that enough to work? Also r7757 fixes the printf bugs.

I'm using Gentoo so it seems a little harder since there's no standard packages for the OBS tools, but not too hard . Thanks for your instructions - I got it to do the openSUSE_11.2 local build and that all seemed to work as it should, which is nice! Haven't had time to look in much detail yet, but it seems good so far. It looks like it's only got the ANSI build, and we need the Unicode build. Might it work better if some libwxgtku2.8 packages are added as dependencies? The only way is modifying libraries/fcollada/src/Makefile and remove the "@" before some of the commands. (That's a third-party library (bundled with our code because it's slightly modified, and abandoned upstream) which originally did something extremely complex and broken using SCons, so this was just a quick ugly inflexible Makefile to get it to compile. It probably could do with rewriting.) Those are bugs in the old version of the Premake build tool we use, which by default seems to get compiled with most warnings disabled - we already try to enable all the useful diagnostics for our own code to avoid similar problems. Anyway, fixed in r7755 (though I'm not sure how to apply that patch to the code OBS compiles).

Hmm, I think the clients will get a notification when a network timeout occurs, but that might be a long time (maybe 30 seconds or more). Perhaps it should display a "waiting" message if it goes for 5 seconds without hearing from the host, to let people know what's going on? #513. Player handling definitely needs improvement - currently the game doesn't even know how many players a map supports, so it'll probably need quite a few changes for that to work nicely. Hopefully that can be fixed soonish

Thanks for this! OBS definitely looks like a useful service - if it's easy to use and maintain then I think it'd be great if we could use it to provide binary packages, and I'd be interested in getting that set up. (Currently we just have these, and the Ubuntu one is hosted on a site that doesn't seem to be very stable.) I agree this is a pain, and it causes most of the other issues. The problem has always been that we don't have people with much expertise in build systems, and we have limited time which is usually better spent on writing the game than on rewriting the build system. (The current system works well enough for active developers, even if it's a bit rubbish for users and distro packages.)Various people have suggested changes (particularly switching to CMake), and we've thought about smaller changes (moving from Premake 3.x to Premake 4.x), but nobody has taken the initiative and stuck at it long enough to get it basically working. I'm happy to discuss what's required, and to finish and adopt and maintain a new build system that works better than the current one - I just don't want to have to write the initial version myself, and don't want to spend much time on it until it's a clear improvement over the current system. It seems most people agree CMake is the least-bad option and I think I'm willing to go with that, but we need someone to get it all running properly. We can easily change source/ps/GameSetup/Paths.cpp to initialise m_rdata from an externally-defined macro instead of the default ../data. Is there a standard name for a macro like that? The only thing that takes effect is setting CFLAGS before make. Run "./update-workspaces.sh --verbose" and then make will print all the commands.

How slow is "slow"? I've run on a 945GM some years ago, and I think it was just about bearable. See binaries/data/config/default.cfg, which tells you how to create ~/.config/0ad/config/local.cfg and then try fancywater = false shadowsif you haven't done so already. Also, compile with "CONFIG=Release make" instead of the normal "make", and then run "pyrogenesis" instead of "pyrogenesis_dbg", to run the optimised version. Hopefully those may help.

The plugin-based exporter is obsolete, and you should use the COLLADA export instead. That page describes how to add prop points just using Dummy objects.

Should be fixed in r7743.

It should be possible implement flying units with just some changes to the gameplay scripts and data files. Replace their UnitMotion component (which talks to the pathfinder and makes people walk around and avoid each other) with a new component that implements some kind of flying motion (which could even handle realistic planes with minimum speeds and turning circles etc) and responds to the same "move to target" commands. Change some of the attack code to ignore unreachable targets (e.g. melee units can't hit flying units, ranged units have to account for vertical distance). Then it should basically work, I think. We won't need that code for 0 A.D. and should probably focus on writing features that we do need, but I think the engine makes it quite easy to add.

The latest release (released today) lets you simply resize the window by dragging the edges like any other program, or press alt+enter to switch to fullscreen. Does that help with your problem?

The engine implementation doesn't impose any tight limits - most data like armour strengths is simply processed as normal JavaScript numbers (effectively 64-bit floating point), so it can handle anything up to around 10^308 and about sixteen significant digits. The GUI currently just uses JS's normal number-to-string conversion, so you can enter "9.500" in the entity XML file but it'll display as "9.5".

See VFS. The LoadScripts function takes a VfsPath argument, so "simulation/components/" is a virtual path. ps/GameSetup/GameSetup.cpp's InitVfs mounts physical paths (like ".../binaries/data/mods/public/") onto virtual paths (like ""), so the VFS can translate back to the physical path when the code wants to open a file. There can be multiple mods loaded at once, so files will be read from a combination of them all. And the VFS can also load .zip files, so the virtual path might correspond to a file inside the zip instead of a single physical file.

Release-mode builds would work fine. (The only drawback is the lack of debugging information when it crashes, but it shouldn't crash much, and usually it'll be easy to reproduce the steps that lead to the crash so it's easy to debug anyway.)

I've been making some changes to better support multiplayer, and I think it basically works now (though it's far from perfect). If anyone wants to help test it using the code currently in SVN, feedback would be appreciated! The host may need to open UDP port 20595 in their NAT/firewall, and will need to tell their IP address to the other players (there's no master server to help players find each other). After that, hopefully it's fairly obvious how to set up multiplayer games. The "techdemo-mp" map has support for up to 8 players and is probably the best one to test on (if you don't mind it being ugly). Cross-platform matches should work (any combination of Windows/Linux/OS X, 32/64-bit, Debug/Release mode, etc). It's possible to run multiple copies of the game on a single computer to test it, though you may need to click "continue" past some warnings on Windows. There should never be any out-of-sync errors (assuming all players are using exactly the same version of the game) - if you find any then please report what platforms the player were on, the oos_dump.txt files generated for each player, and ideally what actions triggered it.

The missing models are very likely caused by the Collada DLL not loading - that's been a problem for some people who compile the Debug version themselves in VC++. If it's the same situation here then that's a known (but not understood) problem; otherwise it's something new and more worrying.

What OS are you using? Did you use the pre-alpha release, or download from SVN instead? Did you run it from the precompiled .exe files, or compile it yourself?

Enable/disable shadows how? Via the .cfg file, or the console, or something else?

persistent.cfg is AoM's config file (in whatever directory AoM gets installed into), and those options were for visualising how AoM's pathfinding works. (Our game now has some buttons in the top-right of the screen when playing the game to enable similar visualisations for our pathfinder.)

Yes, it's Age of Mythology. The config commands can go in the game's startup\persistent.cfg file (just add them to the bottom).

It's storing the translation in (_14, _24, 34) which I will continue to claim is the fourth column (i.e. the fields are named _{row}{column}), which is consistent with the SetTranslation code and the operator* code and with glLoadMatrix/glUniformMatrix's interpretation of the storage, and with the Translate comment that says the bottom row of the matrix is always (0,0,0,1).The (almost) only thing that is inconsistent is the "float _11, _21, _31, _41;" etc definition which is visually arranged like a row when actually it's defining a column. That could be made less misleading by putting it all on 16 lines or 1 line instead of the current transposed 4-line layout, or by adding a comment or something. (Also inconsistent is operator()(int col,int row) which should flip its naming of col and row.) Does this interpretation of rows/columns still not work?

Hmm, yeah, if the storage is column-major then the constructor arguments are row-major... Translation is set up with void CMatrix3D::SetTranslation (float x, float y, float z) { _11=1.0f; _12=0.0f; _13=0.0f; _14=x; _21=0.0f; _22=1.0f; _23=0.0f; _24=y; _31=0.0f; _32=0.0f; _33=1.0f; _34=z; _41=0.0f; _42=0.0f; _43=0.0f; _44=1.0f; }which is the usual shape of translation matrices, where _n4 is the fourth column. In glLoadMatrix's column-major convention, that means _14=m[12], _24=m[13], _34=m[14], _44=m[15], which matches the class's storage definition: struct { float _11, _21, _31, _41; float _12, _22, _32, _42; float _13, _23, _33, _43; float _14, _24, _34, _44; };where the fourth column (_n4) is stored last. So I think that's all okay. The constructor uses the left-to-right-then-top-to-bottom matrix order (_11, _12, _13, _14, _21, ...) instead of the storage order. In operator*, that means the first 4 values it computes are the first row of the result matrix, and they're based on the first row of the current matrix (_1n) multiplied by columns of the argument matrix. So I think that's all okay too. operator*= is wrong because n*=m should be equivalent to n=n*m (regardless of what operator* does), and currently it does n=m*n instead. (What SSE asm matrix multiply? Why is that needed? I don't remember any profiling data accurately but I think skinning was the main thing that did lots of multiplications, and that maybe doesn't need a general-purpose 4x4 matrix multiply since it's only ever translations and rotations and could probably be done more efficiently in a special-case way.)

I think the ordering of the field definitions in the source code is necessarily misleading, given that their memory layout must match what OpenGL expects. _13 is written on the 3rd source line but it corresponds to 3rd column 1st row in the column-major memory layout. _data2d[2] has to be the 3rd column since each column is a contiguous chunk of memory. operator()(col, row) seems to have its names the wrong way round - they're more like (row, col) now, so m(0, 2) is column 2 row 0. It's definitely confusing . If I remember correctly, the first time I figured out what was going on I decided I didn't want to risk changing anything because I'd probably just cause more bugs and more confusion, so I added that comment claiming the confusingness to be a feature and not a bug to be fixed.

Before formations, I believe we need a simpler kind of group movement (which is currently not implemented at all) - my current thought is to do something like what AoM does, where the game constructs an artificial group proxy object which computes a path and moves along it while all the individual units move towards a target point that's a per-unit fixed offset from the proxy. That should be enough to get a group of units moving coherently and ending up in a sensible spread rather than all rushing towards precisely the same point. After that, it'd be possible to add the special formation behaviours, like the various shapes and unit type positions and any special movement (wheeling, turning in place, etc) and attack bonuses and so on. I think the basic group movement is algorithmically simple but it requires quite a few changes to the complex unit motion code, and it's important to get it done quite soon (since it's needed whenever players move more than a handful of units at once), so my current plan is to do that myself within the next few weeks. I don't expect I'll work on the extra formation things any time soon, though. So I'd probably recommend looking at smaller things to gain familiarity with the engine code, and/or try to research and plan a detailed technical design for how formations would work - how they will move (wheeling, turning, etc), what happens when they're ordered through a narrow passageway or around a tree, exactly how units will be assigned to positions in the formation, how they'll move into their initial positions, how they'll switch between different formations, what happens when someone in the formation is killed or ordered out, etc. I don't think we know the answers to any of these questions yet, and it'd be good to have a solid clean design before hacking on the code

Looks like we never use operator*= (except in a test where the order doesn't matter), so that should probably just be deleted (or else be implemented in terms of operator* so it's always going to match). The internal storage of CMatrix3D has to be column-major to match OpenGL, i.e. (_11, _21, _31, _41) is the first column. So operator* is multiplying the first row of 'this' by the first column of 'matrix', to get the first output cell, which I think is the more normal direction of multiplication (and matches what Wikipedia shows). So I'm not seeing the problem here.