fabio

That problem also happens on current selection rings. See #1368 (#1517 also related).

The WPOS error: is triggered by this code: http://cgit.freedesk..._derived.c#n552 while with: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_state_derived.c#n488

No, but is there a way to enable the selection box on single parts? This is probably the key that trigger the problem.

Hmm, I'll try tomorrow with my current driver (from mesa 9.1) but according to the 0 A.D. OpenGL capability report for GL_MAX_VARYING_FLOATS_ARB (although it's not updated since long) all ATI cards have at least 32 slots (or also 40 on some version of RV530, my codename). EDIT: also that error message only appears with glsl mode, while the corruption happens also on standard mode.

On Mesa R500 has complete OpenGL 2.1 (the hardware doesn't support NPOT textures, but they are implemented in software, the only problem is a slowdown when they are used). It's likely a driver bug however.

Sure, this should obey usual code standard. Eventually a requirement could be to work tracking progress on a ticket or a thread forum rather than doing a single code drop. Also the reward should be given after the code is approved and committed and at least after two weeks without reported bugs. Good news with the pathfinding! Other example bounty could be: usable Android port; cleanup and commit tickets like #885; improvement of 5% speed of a reference game replay, working on an area of choice (excluding pathfinding if it's being rewritten); use a thread to get at least a 10% speed up of a reference game replay; other improvements few ones have interested in doing but that can benefit the game.

OK I tried, but I cannot reproduce the problem with just waterfall and/or water. Note that the problem only happens when the mouse is over the gardens and the selection box appears (even if I don't click on it). When using the lonely water or waterfall the selection box doesn't appear over them, so this is probably why the problem cannot be reproduced with just these.

Postproc effects are not working properly o my Radeon X1600 with mesa drivers, see screnshots below. If I also enable preferglsl I get similar screen but also with these:

I measured the gathering speed: citizen: 1 food/s cavalry: 15 food/s It doesn't seems very realistic. Cavalry also has advantages of faster speed of movement and can transport 30 food vs 20 of a citizen (but has the disadvantage of gathering only meat and not vegetables).

Yes, I created a map with just the gardens and it happens whenever I hover the mouse on it. What do you mean with the "which prop is causing the problem"?

You maybe could set up an open source bounty to who is able to improve the pathfinding (or other areas).

Why don't just put in the game a check for the latest version (just check a file on wildfiregames.com containing latest release) and if > of installed version show a button with "New release available, check the 0 A.D. site!" that links to http://trac.wildfiregames.com/wiki/LatestRelease (or even better one of the subpage depending on the OS)?

It looks it was properly build . Run the test executable and then run the game!

It also has a tooltip with the Civilization name.

Screenshot added in the first post. As zoot said I also only get it when the wonder is on the screen.

Cavalry can only gather meat, not vegetable food. Dunno if it's intended.

The Persian Sandbox demo map has a partially missing and broken GUI when hover the mouse cursor over it. EDIT: added screenshot.

I noticed that cavalry can gather meat at an impressive speed. Probably related to the recent hit for animals?

http://trac.wildfiregames.com/wiki/BuildInstructions

Maybe the default maps should just include fast maps (small and only one AI), the others could be put under a "Slow" group.

Wow, very impressive, and I like the fountains!

Thanks! The link in the spoiler is non-public. How can be seen the Gardens and other Wonders in game (is there a map with it)? How they will be used?

It's four weeks without them, will be there other Weekly Reports?

What about pushing the latest code to SVN so that it can be widely tested? Thanks

Another approach could just use the final "capital": count the total spare resources + the resources needed for all your assets (multiplied by a value depending on the phase, the difficulty or the time necessary to build them). If you kill enemy units you don't get points, but you decrease the enemy points. Obviously the loser will get 0 point and if you win at the "last man" you'll get very few points. This approach would then reward not who just fight or build the most but who's also able to keep a good city after the win (Pyrrhus would get few points). This could be useful in campaigns, if you get many points (so you still have many resources) you'll have a bonus on the next match. Another idea could also consider the total time: if you do the same in fewer time you'll get more points.