historic_bruno

Good news on AI serialization. When I was testing before, I forgot that I had debug annotations turned on in the serializer, which made it generate much more data, more slowly. It needs a lot of real-world testing but so far I haven't gotten any errors and qBot seems to continue seamlessly after loading. The other good side of proper serialization is that rejoining multiplayer games with AIs will work without OOS errors. The bad side is that every 20 turns in multiplayer games, it does a full state serialization for OOS checking and there will be a noticeable stutter if the process takes too long. For saved games, I think the data size and time required are very reasonable, it's only for others things (serialization test, OOS checking) that it may pose a problem. Maybe we can leave out parts of the state in those special cases. For instance, it's not clear to me that the AI state needs to be part of the OOS check, as they run asynchronously (eventually in a separate thread) and can only interact with the simulation through network commands - so any OOS errors will be detected there. Or we could have 3 types of simulation state checks: minimal (currently checks only entity positions), standard (all but AIs) and full (all state including AIs), and do the full check even less frequently. I will continue tweaking things and post a WIP patch on Trac. The new code I've added may need optimizing in places, but I think most of the slowness is due to the greatly increased amount of data processed (7 qBots on a giant map will produce 30+ MB state, Aegis could be even more).

Speaking of that, can you check the ticket and respond to this comment? I might make a test bundle with SDL 2.0 to see if it fixes the Retina display issues people are having, rather than waiting for A14 to find out.

I think the point is to not pay just anybody, but to pay someone with vision and significant hands-on experience with 0 A.D. from the beginning, who will not have available time to contribute otherwise. If you have any doubts, I encourage you to read through SVN logs and forum posts and see Michael's past contributions and then infer what the project would lose without him (of course for fundraising we and Michael have to make this case, but until then, it might be enlightening research). It's true, hobbyist unpaid work has made 0 A.D. what it is today, but for some people, it hasn't been and won't be a little thing they do on the side for an hour a week without care, it's been more like a full time job with no pay. That may be OK when people are in school and not yet "in the real world". But it's not fair to expect people to do that indefinitely, nor is it unreasonable to offer them compensation, if the quality of work they do merits it. In fact, it's the least people could do, if they enjoy and care about 0 A.D. and the future direction of the project. Even people who contribute nothing are benefiting from a piece of quality, free open source software with fairly generous licensing, that will benefit the community as a whole, I think that's an advantage that justifies paying someone to lead such a project.

The game also has a built-in, web-based profiler that you can access by pressing F11 in-game and then opening profiler2.html in source/tools/profiler2 (you probably need SVN for this) The problem with performance issues is we know they exist, but they have different causes for different systems. Since the renderer and gameplay run in a single thread, the user may feel like they're experiencing graphics related lag, because the UI will become less responsive, when really it's the AI or pathfinder causing the trouble - and that varies depending on the exact map and game situation (large formations? water? dense trees?). Sometimes slow hardware can be the problem, more often bad drivers, but with good drivers and a decent system, you shouldn't have much trouble. Multiplayer games add another potential for lag with network latency. Without in-depth profiling it's not simple to distinguish all these cases. FWIW we had a staff multiplayer match a few weeks ago, it was 8 players (4 human, 4 Aegis bots) on a large random land map, and there was surprisingly little lag, either from the game or network related.

When you get into the debugger, use the following command: t a a bt full Did you build the game yourself?

Does binaries/system/libCollada.so exist? If not, I would say the FCollada build failed, try running update-workspaces.sh again and look for any error messages.

Just a reminder that one of the MSVC warnings still exists 1> CBufferItem.cpp 1>e:\devel\ps\source\soundmanager\items\cbufferitem.cpp(88): warning C4702: unreachable code

That looks very nice! A shame that you lost your work, I guess that's a reason to make frequent backups from now on

I've got an HD 6850, purchased when I got my new computer in 2011. The main reason I chose it was that it's quiet and cool (relatively speaking). Performance-wise, you'll probably be better off with an Nvidia, at least that has been my experience in recent years - of course I haven't been in the market and don't obsess over benchmarks, it's just from comparisons with other people doing real-world stuff. I'll never buy an Nvidia again though due to their crappy driver support. They also tend to be noisier. The 6850 is not a shabby card by any means and more than capable of running games. The brand can make a huge difference by the way, as far as how quiet it is, what overclocking they do, what quality the fan/heatsink is, etc. Mine in particular is a "ASUS EAH6850 DC/2DIS/1GD5/V2 Radeon HD 6850 1GB 256-bit GDDR5 PCI Express 2.1 x16"

To see the output from e.g. debug_printf in Windows, you need to use DebugView or run the game in the debugger and use its console (the output window in Visual Studio).

We could use an image instead of text

Fixed.

I think the problem with this is they wouldn't really communicate anything to the player, if they weren't familiar with those writing systems. Even transliterated words, if you know the alphabet, can seem familiar and you can try pronouncing them, etc. That said, it would be interesting to show names in the original writing systems somewhere, where they are known, maybe in the manual or the in-game unit info screens (TBD) or civ profiles on the website. They would likely only clutter up the in-game UI though.

I liked the idea of farmlands, I think we should at least try it before scrapping the idea, and I haven't seen much opposition to it. As far as implementation, I think it could be done fairly easily with special entities placed on the map by the designer (probably invisible in-game?), and then farms within X meters of that entity will get infinite yield or whatever bonus(es) we think best. Then you have to think about UnitAI, does it need to calculate which dropoff will be optimal based on the bonus vs. distance? If not, how does the user control that? Again, what if the CC and farmstead are approximately equally distant from the farm, which does it choose and why?

As a slight modification, what if you could only build farm fields while you had a farmstead? Instead of only needing to build one at the very start of the game. I guess making them the only dropsite for grain would accomplish that. However I agree with zoot and don't like special casing which dropsites accept grain (not only because it's a confusing concept), but I do like the idea of some kind of bonus for having farms close to a farmstead and/or away from the CC. I wouldn't tie it into where the grain is actually dropped off, because then you end up with cases where a farm might be equally distant from both a farmstead and a CC.

Right, but that variable would have to be initialized with something on or prior to deserialization, otherwise the AI would try to access it and spew thousands of undefined property warnings I tried to mix these approaches, but I think that references to those excluded objects might still be part of the AI state and so they would get serialized (which is why I say the AIs have been designed without considering these issues and it might not be trivial now to solve them).

I have installed 0 A.D. on Windows 8 and it works fine There's no need whatsoever for a fork just to support Windows 8 (whatever other reasons there may be).

Also, I have been looking into full AI state serialization after fixing #407, it seems feasible but possibly inefficient and it may require some redesign of the AIs, since they have unfortunately been written with the assumption that full serialization is impossible or ignored that it might be possible in the future. (I've mostly worked on qBot in my testing because it's simpler, but it should be possible to port most changes to Aegis as well). I would like to at least make this possible for A14 and then we can decide what is the best course for the AIs (personally I think automatic full serialization is much preferable to the current piecemeal, hacky, broken approach).

I don't think anyone wants to switch back to qBot, since Aegis is so much improved, I think we can live with saving not working perfectly for A13, and can mention that in the release announcement and in the AI description.

This is indeed what happens in my tests. In one game, it failed to load the saved game: ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 327 TypeError: myKeyEntities.toEntityArray()[0] is undefined ([object Object],[object Object])@simulation/ai/qbot-wc/qbot.js:327 ERROR: AI script Deserialize call failed WARNING: JavaScript warning: simulation/ai/qbot-wc/qbot.js line 287 reference to undefined property this.pathInfo ERROR: JavaScript error: simulation/ai/qbot-wc/qbot.js line 287 TypeError: this.pathInfo is undefined ()@simulation/ai/qbot-wc/qbot.js:287 ([object Object],[object Array])@simulation/ai/qbot-wc/qbot.js:90 ([object Object])@simulation/ai/qbot-wc/qbot.js:156 ([object Object],[object Object])@simulation/ai/common-api-v3/base.js:66 @:0 ... quicksave-0002.zip In another test, quickload worked, but with the following warnings repeated: WARNING: JavaScript warning: simulation/ai/qbot-wc/attack_plan.js line 708 reference to undefined property this.path[0][0][1] WARNING: JavaScript warning: simulation/ai/common-api-v3/utils.js line 11 reference to undefined property b[1] ... quicksave-0002.zip

Our packed siege units have spoked wheels, why not trader carts? Also in the case of an animated unit, I think the polys won't have the biggest impact, rather the number of bones for wheel rotations, which isn't affected by spoked or solid wheels.

Thanks

Specifically which version of OS X Mountain Lion are you using? Also it might help to know which model of Mac you're using, some people have reported issues with Retina displays, but not everyone with a Retina display encounters them.

Errors after loading saved, single player game with 1 human and 3 Aegis bots (after about 25 minutes, when they started attacking): Errors rejoining in multiplayer game with 4 humans and 4 Aegis bots (near the end of the game): There was also an instant OOS on my end, but I seem to recall rejoining never worked correctly with AIs?

In response to Geek377's build log from IRC: you need to install cmake as described in the instructions