UV_Completion

I have no knowledge at all about Java script but is the evaluation of such expressions fixed by the standard? I.e. is unit && !unit.position() evaluated from left to right and is the evaluation stopped if unit==false (without checking the second condition)?

Did you (re)consider putting your code in a public git/svn? This would make testing it a bit easier. One of your latest revisions contained a .git-folder. This was an accident, I guess?

Thanks. Is the Wiki page (http://trac.wildfiregames.com/wiki/HotKeys) meant to be for the developer version or the recent alpha? If the former, it would be nice if someone could update it.

I just ran a quick test with recent svn on Oasis II (qBot Carthagians, Marilyn Hellenes). The game segfaulted (without a useful error message) before the game was finished, but it looked like Marilyn got the upper hand towards the end. qBot had the better start but its attacks were too uncoordinated and slowly Marilyn gained ground. There was one (non-fatal) java script error in Marilyn: WARNING: It appears there is som sort of enemy army in my territory WARNING: New land attack found. WARNING: Asked for dropsite for wood at 439.1544189453125,394.7325744628906 ERROR: JavaScript error: simulation/ai/Marilyn/map-module.js line 18 TypeError: p is undefined ((void 0))@simulation/ai/Marilyn/map-module.js:18 ((void 0),[object Array])@simulation/ai/Marilyn/terrain-analysis.js:108 ([object Object],[object Object])@simulation/ai/Marilyn/Attack_city.js:373 ([object Object],[object Object],[object Array])@simulation/ai/Marilyn/military.js:1040 ()@simulation/ai/Marilyn/marilyn.js:154 ([object Object])@simulation/ai/common-api/base.js:117 @:0 It seems to be reproducible so if you need more information, let me know. PS: The shortcut for the developer overlay (Shift+D) is non-functional at the moment. Somehow scrolling right has been assigned the same shortcut. Is this on purpose?

He has quite some days left so no need to hurry. Also, I strongly disagree. The best reason for me to donate would be to know that this would get some "unfancy" but important work done, first of all optimizations (and stabilization, but the game seems pretty stable to me already). I also think that Philip is right to spend quite some time on reviewing patches. If 0AD gains only a single regularly contributing person by this, it already was totally worth it (and even if not, you have at least some nice improvements made, even if they come with a more-than-necessary amount of work.) To make it clear, I actually think that Philip's work is in fact quite fancy, especially the new profiler and the network stabilization work.

With the most recent qBot, I get the following Java script error: ERROR: JavaScript error: simulation/ai/qbot/qbot.js line 82 TypeError: this.toUpdate[i].update is not a function ()@simulation/ai/qbot/qbot.js:82 ([object Object])@simulation/ai/common-api/base.js:92 @:0 The error appears after roughly two seconds on every map I tried and repeats itself over and over again.

I put some debug code in Hotkey.cpp:HotkeyInputHandler() two weeks ago but haven't been able to trigger this bug again since then. This is kind of strange because it happened on an almost daily basis to me before. Either it's a weird timing problem which would make it impossible to debug for me because I have no detailed knowledge about the inner workings of that code or some third party dependency got updated in the meantime (I'm on Debian Testing and perform an update every day). I'll try without debug code again as soon as I find time to do so (may take a while though). I'm pretty sure I tried this and it didn't work. That's the reason why I suspect HotkeyInputHandler() because there is some code which prevents key up events from doing anything under certain conditions (which I do not truly understand). This makes sense.

I tested the latest GIT and hit some problem in the tree map code: ERROR: JavaScript error: simulation/ai/common-api/base.js line 36 TypeError: name is undefined ((void 0))@simulation/ai/common-api/base.js:36 ([object Object],[object Object])@simulation/ai/common-api/entity.js:177 ([object Object],[object Array])@simulation/ai/qbot/economy.js:267 ([object Object],[object Object],[object Array])@simulation/ai/qbot/economy.js:330 ()@simulation/ai/qbot/qbot.js:70 ([object Object])@simulation/ai/common-api/base.js:91 @:0 I was playing against two JuBots and a qBot on a random map.

I agree that villagers should remain conquest critical, but to avoid tedious searches when playing versus an AI opponent the AIs should implement a surrender condition. The minimal condition could be something like no dropsites left and not enough resources to build a new civ center. A more elaborate condition would be to compare the strength of the own team with the strength of the other team and give up if the situation is hopeless.

I tested the (almost, due to git lagging behind the subversion repository) newest JuBot and am quite impressed with the progress made. Apart from more strategical improvements (building new civ centers, building drop sites more efficiently, counter unit types, ...) I would propose (as Pureon pointed out already) that JuBot builds more siege units and does it much earlier. It really makes a huge difference if attacking fortified positions. Apart from this, I also ran into performance problems when I destroyed the civ center of one of the JuBots before destroying any other building. It then tries to find a place to build a new one but doesn't succeed, so it tries again and again (I don't know why it fails, something with territories perhaps?). To find a building site it calls addInfluences for any of its buildings which seems to be quite expensive. The real fix for this is of course to find the reason why it doesn't find a building site but even then the finding procedure should be optimized. A proper but probably difficult to implement fix would be to calculate the influences map only once and update it when a new building is constructed or an existing one is destroyed. But there are some easier optimizations (I didn't profile this, so I don't know which one is worth trying). The most expensive operation is probably the square root in the distance calculation. You could switch to a quadratic (rather than a linear) fall off to get rid of it or use some approximation (see for example http://www.azillionm...t.html#distance). Another easy performance improvement would be to reduce the influence radia, at least for some buildings (houses!). Probably you even could ignore houses altogether in this calculation.

this.lastGoodPosition = org.zeroad.splitbot.core.Point.arrayPoint2Point(this.getCivicCenter().position()); while(true) { this.lastGoodPosition.x += Math.round(Math.random() * (width + 10) - (width + 10) / 2); this.lastGoodPosition.y += Math.round(Math.random() * (height + 10) - (height + 10) / 2); if(!org.zeroad.splitbot.helper.MapHelper.isObstructed(this.lastGoodPosition,width + 10,height + 10,["building-land","foundationObstruction"])) return this.lastGoodPosition; } Couldn't this end in an infinite loop? And I think a random walk from the civ center is not the most efficient way to find a building space. Are you sure that you multiply with/divide by cellSize at all relevant places?

I tried your Bot in a random map and it put up a lot more resistance than JuBot, nice work! The only obvious flaw I could spot is that it builds an insane amount of units before it attacks which hurts performance a lot (it may be that not all of its attacks are that huge because I played with more than one qBot and they probably attacked each other earlier in the game). As I started an attack on its base it threw literally hundreds of infantry units at me, in the middle of an almost equal number of females. I didn't check the code but maybe you could lower the number of units it gathers before attacking a bit.. at least as long as the performance impact of large armies is so high. Other things I noticed: One of the qBots tried to build a farmstead directly at my border (far away from its civ center). And the bot could probably build some defense towers, if only for aesthethic reasons. But I know that you just started working on it (and yet it's already quite impressive). EDIT: Just had a brief look at the code and noticed this piece of code in military.js: gameState.entities.forEach(function(ent) { if (ent.owner() === i && (ent.hasClass("CitizenSoldier") || ent.hasClass("Super"))){ count ++; } }); And then he tries to build an army twice the size of the strongest enemy army. I don't know Java script so I just assume that === does a comparison But if you play with more more than one qBot this code could probably lead to an arms race between the two qBots (which explains the fact that in my game the second qBot only attacked when I had reduced the army of the other one significantly).

I have almost no knowledge about modern Windows versions but shouldn't it be easy to at least run pyrogenesis.exe in a command shell and check the standard output? I am also a bit puzzled by the debug instruction page. Is the Windows binary a debug build by default?

I'm on Debian GNU/Linux and using the most recent git version. Thanks, I will take a look as soon as I find time. But as I'm not familiar with the code I can't promise anything.

If you scroll around using the keyboard sometimes the "key up event" seems to get lost so that the game scrolls forever in one direction. I haven't been able to find a workaround for this other than aborting the match. If you try to scroll in the opposite direction you can compensate the scrolling as long as you press down the key but there seems to be no way to restore normal conditions. This bug is difficult to reproduce. It seems to me that it occurs primarily when the game lags for a short moment while scrolling. It does not seem to happen if one uses the mouse for scrolling. I could try to give further information if necessary or even to look at the relevant code if someone could point out to me where it is located.