Ykkrosh

Trac has most of the information, particularly build instructions and bugs/tasks (though they're not very well organised or prioritised; I'm currently working on the gameplay system and aiming to improve the organisation there, which is probably where it's most needed). I agree it would be good to make these things more findable from the web site. (There have been plans for redesigning it for quite a long time, but that doesn't seem to have got very far, so I'm not sure what the situation is with updates.)

Which build error? ("cannot find -lboost_system-mt"?) It can work with 1.41 (that's what I use, on Gentoo) but Slackware might do something a bit peculiar with the library naming.

Mixing priorities does make it more complex, but I think it's probably worthwhile - it gives more control to scenario designers, it avoids the complexity of having an external data file to specify the relative priorities of all terrain textures (or the arbitrariness of basing priorities on filename), and it almost works fine in the renderer. Hmm, that's probably not so good - I think we'll want to be able to change terrain at runtime (like when you construct buildings and it draws a buildingy texture underneath), so changes should be reasonably efficient and visually localised.It's possible the requirements are over-constrained and make a solution impossible, but I still can't see why it should be The problem reminds me of polygon z-sorting, since there's one polygon (/set of tiles with the same texture) partly in front of and partly behind another, which makes me wonder if it's possible or useful to effectively split the first polygon into two so that there's a consistent ordering. But I don't know if that even makes sense... I suppose I can imagine a situation like: a B a B A b A bwhere each letter is a tile, a/A is one texture, b/B is another, uppercase is higher priority than lowercase. For the top row and bottom row, we just use blendedge (and flip one of them) to draw one texture on top of the other, so that's fine. But for the middle rows, it looks we don't have any set of blend shapes that can join the two outer rows smoothly. So we really do need to split the aaAA column into two splats, rather than treating it as one because it's all the same texture. I think. Still don't see the solution, though.

I wonder if you could just test every possible combination. Each tile is only influenced by its 8 neighbours, and for each tile the texture is either new or the same as another's, so I think that's this sequence and with n=9 there's only 21147 texture combinations; and each tile can have a priority that's equal or different to the others, and it's a total order, so I think that's this and with n=9 there's 7087261 orderings, so you just multiply that by the texture combinations and get ... Okay, maybe that's not going to work.

If the only problem was time, we'd have already finished I think the main difficulty right now is slightly deeper than just AI and single-player - the simulation/gameplay system is missing some fundamental features, and isn't designed in a way that makes it easy to extend or build on, and the implementation is complex and prone to bugs. I believe that's what's caused progress on the game as a whole to be slow for years, but I've only realised it recently. There are definite plans for improving that - I've been redesigning and reimplementing that system for the past three months or so, and making reasonable progress, and it should be largely complete after a few more months. Once that's done, it will be a lot more feasible to implement AI and more complex gameplay concepts on top of it and make it into a proper game. So I definitely agree that aspects like graphics aren't the critical ones to be worrying about now - apart from gameplay, most of the engine basically exists and works (though always there's room for improvements). I'm fairly confident (more than I have been for the past two years) that the critical problems will be solved in the near future, and the project isn't doomed to failure. But there'll still be a lot of work needed on important but less fundamental problems, so assistance would certainly be appreciated

Yeah, as far as I'm aware it's not theoretically impossible with the current rendering system but I never managed to work out the logic to make it work. Let me know if you have any questions with building or running or following the code . (It has changed a bit since 2004, though sadly not as much as one might hope...)

Hello - nice to see you around again About the terrain painting: Um, yeah, that's not quite fixed yet . Not sure when you last looked at it - Atlas gives users more control over texture priority (left click to paint 'over' the surrounding tiles, right click for 'under') so a single texture no longer has a constant priority, and I think there were some tweaks to the renderer some years ago so that that worked more reliably, but it's still possible to get sharp edges where the wrong blend texture is used. (Some old examples/discussion here.) There's some things in Trac - I assume you're still mostly interested in graphics, so I see some potentially useful ones like terrain triangulation, terrain decals (I think this is mainly required for farms (though useful for other effects), like in the front and back here, which should have a texture flat against the terrain but probably not constrained to grid squares, and ideally the crop meshes should adjust to non-flat terrain too; hopefully that'd help bugs like this), a desire for randomised terrain blends (preferably pseudo-random and deterministic) (I think the "chunky" problem there isn't a graphics problem, it's just unintuitive UI in Atlas), fixing transparent objects with water, adding fog. And more!

They're not currently supported by the graphics engine. (It should be possible to add them, but the problem is making sure all the art is consistent and good in its use of the available features, and we also want it to be easy for inexperienced modders to make content that fits into the game, so there are fairly high costs to adding new features.)

Also it'd be useful to post the system_info.txt file, which is probably in a location like c:\users\whatever\appdata\roaming\0ad\logs\

(This is implemented now here (tests) - hopefully not many bugs...) (I've left the Crypto++ include/lib/DLL files in SVN in case we do decide to use it in the future; if we decide to do something different for networking, we can clean it up then.)

Seen that problem before - it seems to affect GCC 4.4 but not 4.3. (Haven't tested 4.5). Don't know if it's an issue with GCC or wxWidgets or our code, so I'm not sure what to do about it.

When you get that error, you need to run "make clean" (or "CONFIG=Release make clean" in this case) and then rebuild.

Thanks, that explains it - I was accidentally using bash-only features in build.sh, so it doesn't work in Ubuntu (which defaults to dash). Should be fixed in SVN now - if you run build.sh again, then make again, it should be better.

Yeah, that would definitely be complex enough to justify an external library . I'm just thinking that since we don't yet know what those requirements will be, we can't make any correct decisions about what library we'll need, and it would be wasteful to set one up now and then find we have to throw it away later, so I'd prefer to wait before picking one (and avoid relying on any in the meantime).

One way is IRC (#0ad on QuakeNet), since I'm connected permanently and will see anything reported there. I suppose Jabber could work too - I've set up an account excors@jabber.org which should reach me. (If it's not a problem that I can fix, I can forward the information to someone who can (e.g. Jan) ) We're always interested in help with programming (since there's a lot of it to do ) - probably the best approach is to try to fix some bugs or add some small features (there's a list of a few here, and some more in Trac not in that list, and lots just TODOs in the code - I should probably spend some time adding things to the list, else I'll just forget them all); and try to get some familiarity with parts of the code while doing that, to see if it's a project you're interested and able to work on. Then if you want a more major role and are willing to give some time commitment and take on more responsibility for getting things done, it would be good to apply for the role (Edit: Oops, I took too long before posting, and Jan beat me to it )

Thanks, should be fixed in r7267

Hmm... Not really . Seems like a lot of bloat and complexity and potential for unexpected breakages (like this OS_RNG_ERR thing), plus the cost of reading the documentation and working out how to use it. I'd expect it should only take half an hour to copy-and-paste an MD5 implementation and write a wrapper to feed it 16-byte chunks and test it, so I'd be happier to simply do that. (I could do that later today, depending on how wildly wrong my estimate is.)

Yeah, I think you have to delete the whole SVN checkout and start again. I was hoping nobody would have updated to the revision before I deleted it (I was merging changes from Hg using hgsvn and it silently committed thousands of temporary files too, and I didn't want to leave them all in the repository history, so deletion seemed the least painful solution.)

What do you see if you run "svn info"? I messed up SVN earlier today and had to delete one of the revisions (r7259), so if you happened to update to that version before it got deleted then your copy will be out of sync with the server, and as far as I'm aware the only solution is to check out a fresh copy. If that's the case, then sorry about that But if you didn't update to the now-deleted r7259, then something unexpected is broken...

I've just merged a large change into SVN, which is a step towards rewriting the gameplay code (basically everything that is concerned with objects in the world). (I've been using Mercurial to develop this code before merging into SVN, since it's much nicer). (The new system is disabled by default - you have to use the "-sim2" command-line flag to enable it). It's taken a lot of work so far, and will need a lot more work, but I believe it's worthwhile because of some fundamental difficulties with the old implementation, mainly: Scripting - writing non-performance-critical code in JS is usually much nicer than C++. The old system has a complex JS<->C++ interface (lots of classes and functions, lots of raw JS API used on the C++ side, etc), and a lot of gameplay that could have been written in JS was instead in C++. Serialization - saving games to disk, comparing multiplayer clients for sync errors, etc. The old system didn't handle that at all, and bolting it on would be very difficult and buggy, since the simulation state was spread over lots of objects with no easy way to keep track of everything. Synchronisation - our multiplayer system assumes every player performs precisely the same computations given the same inputs, but we also want to support multiplayer across different OSes and processor architectures. In particular, that makes floating point computations (as used in quite a few places in the old code) very dangerous, so the simulation code should use integer or fixed-point instead. (FP is fine for graphics code, since that doesn't have to be synchronised.) Testing - automated tests are very useful, but the old system made it hard to test parts of the code in isolation since there were lots of dependencies, and so it had no tests and quite a few bugs. The new system attempts to solve these problems (and some others): gameplay is split into lots of fairly simple, mostly self-contained components, each of which is responsible for its own serialisation, and each can be tested in isolation, and each can be implemented in either C++ or JS without adding any complexity to the other code that has to interface with it. The new system probably introduces problems of its own, but hopefully they can be resolved, and continuing on by patching the old system (instead of redesigning and replacing it) does not seem feasible. The current status is that the new system basically does what it was designed to do, and provides a stable infrastructure for implementing the proper gameplay code on top of, but the gameplay hasn't been implemented yet. (You can click on units and tell them to walk to a point, but that's about all). There is documentation on Trac briefly covering some of the high-level concepts and low-level design. That page also links to the list of Trac tickets, and there are lots more TODOs in the code itself - if anyone wants to help with these, please feel free . There isn't a concrete plan for the design of the gameplay code yet, but that's something I want to look at soon. So, that's what I've been working on for a while, and I think it's going in the right direction so far - any feedback would be appreciated

The libfam.so file is provided by both FAM and Gamin (which is why they conflict) - Gamin is newer so you should stick with that one. Sounds like the same problem as in this post (and the previous one) - does that solution work for you?

Ubuntu bug. Not sure how to solve it though (is there a new package that Karmic users can install?)

"error: one or more PCH files were found, but they were invalid" - that means you should run "make clean" and then "make" again, since the old build output is incompatible with the current build settings.

Quickest solution is to install Valgrind . (I should probably change it to not rely on Valgrind by default, or (probably better, to avoid yet more configuration options) bundle the Valgrind headers with it, but it'll be a while before I get around to that.)

Thanks, looks like the problem with Atlas is one I've experienced before, probably caused by the slightly strange way we link SpiderMonkey. It might work better with the experimental new version - if you go to libraries/spidermonkey-tip/ and run build.sh (and if that doesn't give any errors), and then run "./update-workspaces --with-spidermonkey-tip" (in the appropriate directory), then "make clean" and "make" as normal, hopefully it'll work without that problem (and without any new problems - this way hasn't been tested much).