quantumstate

I had a quick look and you can easily generate a project using premake4. You could add a line to update-workspaces.sh (around line 69): premake4/bin/release/premake4 --file="premake4.lua" --outpath="../workspaces/codeblocks/" ${premake_args} codeblocks || die "Premake codeblocks failed" (If you are using windows you could add an equivalent line to update-workspaces.bat) Edit: I just tried building and it didn't work correctly. It threw quite a lot of errors when linking.

I would expect that editing a saved game and then resuming a match would rapidly give an out of sync error.

Sorry, I had missed a line from my commit. It should work now.

I would like to see capturable fortifications. Otherwise you either get units knocking down fortifications with their swords again or you get overpowered fortifications. What would happen to the loyalty just after you captured a building? Getting 100% loyalty immediately seems like too much of a jump, if two players are fighting over a building I would expect them to be able to recapture it quite easily. 0% loyalty doesn't work with the territory based loyalty decrease since it would immediately switch back to the enemy if you captured a building in their base. Maybe a small value (10-25%) would work best? About the regeneration of loyalty, I think that there should be a territory increase and that units should have an aura which also helps increase it. The unit auras would allow some amount of control over loyalty increase. I would say that the rate of territory increase should be a % of total loyalty per unit time and the unit auras should be a fixed rate per unit time. This allows buildings with a lot of loyalty to be back to full in a reasonable amount of time while not allowing a small group of units to overpower the capturing effects for large loyalty buildings.

Soon this problem should go away as qBot gets territory support, I will have some more free time past Wednesday unless infyquest completes it before then. It will be interesting to see how important territory denial is. I think Mill placement is working correctly and is fairly decent, what isn't working correctly is getting workers to work on the resources near the mills. Also relatedly gathering rates should eb taken into account for this code as well. One of the main reasons so so many females at the moment is the fact that the men suddenly go off to war, so having lots of females stabilizes the economy a bit, plus they are cheap and pop cap isn't a big issue like you say. Thanks for the feedback. It is helpful. (Some stuff I didn't comment on was useful, I just didn't have anything to say about it).

I'm curious about more details of your strategy. Especially about types/numbers on units, I still haven't figured out the benefits of female citizens vs. citizen soldiers. I guess females should definitely work on fields but I wonder if it is worth using soldiers for other stuff since then you have defence. Also what map are you playing? With a lot of maps it doesn't seem to make sense building an expansion since you could build barracks instead (for training) and you have enough resources nearby for quite a while so mills are more efficient.

I think it would be nice to have the music available for easy download on the website. Currently you can find it at: 0ad/binaries/data/mods/public/audio the location of the 0ad folder depends on your operating system and installation method.

Yes, that would work well. The mill building problem is because qBot used a distance based approximation before territories got added, soon there should be proper territory support.

I don't like the idea of a random resource selection. Added randomness introduces more luck and I think that luck should be made as small as possible, in multiplayer I don't want chance to put me at a disadvantage. I would suggest limiting it to a specific resource (possibly civ specific) and then allowing others to be unlocked. Everything else sounds pretty good. Edit: Just thought I would say that I really like your idea of a foreign trading bonus. Encouraging cooperation is good but I didn't like how in AoE2 you couldn't trade in single player so games became gold limited so long games would turn into spearmen/skirmisher/light cavalry slogs.

Is there any way to fix this by using a relative path? In the meantime I have removed the extra directory.

Could you give more details please? Also check you have the most recent qBot since there was an update yesterday affecting walkToCC.

To make things simple and convenient for players, when you right click a market, the code should work out the route which would make the most profit (profit per trip/distance). This is what AoE online does and it is quite nice.

This would mean that the game would stop being open source. All contributors to the code would have to agree to this change or their contributions would have to be rewritten for it to work (because of the GPL). In my opinion making 0 AD closed source again would discourage programmers.

This is a nice list. The suggestions are so good that most of the items are planned already . The assignment/rally point has #745 (bug 745). Speed is due to be adjusted when charging/running has been implemented. Non siege units will be able to capture buildings (#996), so won't be able to destroy them. For blood I found Blood so it should be implemented at some point. I am pretty sure someone is planning to make heroes limited to 1 at a time. Herding animals and the corral are going to be fairly different, with you garrisoning herd animals in the corral for a steady income so the current version is temporary. Currently triple click selects all units of a type ignoring rank. I would personally prefer double click to work like you said but I don't know is its likely to change.

In real life farms are planted with seed in spring, then you wait a while and harvest the whole lot at once. This is pretty unlike the current system. In 0 AD a farm is built then workers can gather food from it as fast as they like until it runs out. An infinite farm would have a limited number of workers and would be modeling a farmer working a farm to produce food, and farmers normally replanted their fields. The only difference from real life would be that the food gathered is spread out over time as an average rather than all gathered at harvest time. So I think that this is actually more realistic, though the realism is lost by the constant income. The main factor we should be considering is game play since realism is bad either way. I actually like WhiteTreePaladin's idea of being able to research an infinite farm. This allows for cheap farms near the start of the game and a lack of annoying micro later in the game. Or maybe just cheap infinite farms with a slower gather rate.

Having different tactics available for qBot would be nice. In the future it should be possible to make qBot randomly pick a strategy and perhaps have them selectable on the AI options screen.

I have just written a rough overview of how qBot works. It is found at https://github.com/quantumstate/qBot/wiki/qBot-Structure-Overview

Nope, see all of the other AI's for proof that the API works. However I have discovered something a little bit crazy when testing. Swapping the x/y coordinates in BuilderAgent.hx line 261 seems to fix the problem for Oasis II. However when testing in Oasis IV an AI in position 3 started building onn the opposite corner of the map with this swapped. This might suggest that the Point data structure you are using isn't entirely stable, I haven't looked at the code for that though. I left it running for quite a while on fast speed so it built > 10 buildings with no issues on Oasis II which would be really unlikely by chance. It seems pretty weird. EDIT: Just realized that the flip must be happening somewhere in the isObstructed() function. So your code has been checking for obstructions on a diagonal mirror image of the map I think. On line 138 MapHelper.hx you seem to have the x and y swapped for some reason, try flipping them round there.

I also just tested on Oasis II and also got the message that it cannot find a place to build. I did a bit of testing and it seems to work a bit better with the obstruction mask set to 6 which is what q/ju/testBot uses. It still makes some errors with foundations on top of foundations however. obstructionMask = gameState.getPassabilityClassMask("foundationObstruction"); obstructionMask |= gameState.getPassabilityClassMask("building-land"); is a bit more descriptive . This definitely doesn't fix it though, even adding ridiculous amounts of padding to the building size still didn't seem to work correctly. I cannot see any problems though .

F10 for menu

Dividing by 1000 should give seconds .

It should be fairly easy to adjust things in an AI to make it play worse and make the game easier. I think it would probably be more fun having a developed AI not playing optimally than an earlier version trying to play optimally but badly. In qBot this will definitely be possible.

The Romans only used the corvus for a brief period, by the end of the first punic war they had abandoned it probably because of the effect on handling in bad weather. They used marine forces but i don't know how much naval specific training they had.

This does look much nicer than the current selection rings, nice work. For the single/multiple quad issue I think that single should be fine as well. Since all of the models will be designed to work on flat ground I think if they were large enough for the selection rings to look bad then the model probably would as well. Making the selection rings hover slightly might be an option as well, you would need to test to see what would look strange.

Ah yes, I was pi/2 out, it is corrected now for prettiness.