quantumstate

This part of the code is written in Javascript, as is most of the gameplay and UI.

I think there is a need to make other food sources more attractive with the current state of the game. This idea sounds interesting but could be potentially confusing (guessing where farming is possible) or too restrictive for players. With the phases idea which will come with technology, farm building could be delayed until later in the game forcing use of other food sources. The other main alternative is to use different gathering speeds weighted strongly enough that there will be enough disadvantage to the farm only approach. This isn't implemented yet, currently corrals just train animals which you would have to kill. The drawback is defining a UI which is easy enough to use and doesn't cause massive confusion for new players, the other key thing is programming manpower which is limited so these kind of features take lower priority. I would guess that with a button which would open an auto bartering panel it would be possible to come up with a reasonable UI. The lack of manpower means that this is unlikely to get into the first release unless someone outside the team decides to implement it.

If you are interested and confident enough with javascript then you could try implementing the paths yourself. To my knowledge nobody has mentioned they are working on the random map scripting. All of th existing code is there in the rmgen folder, and creating a path with added noise shouldn't be too difficult. of course if you don't want to that is fine, but be aware that it might take a while before the feature is added in that case.

When the errors appear there might be errors happening, possibly some AI armies walking to the wrong place on the map. The error messages themselves are a symptom.

0 A.D. civs are a bit different to Age of Empires. In AoE you had the same units shared between civs, with each civ only having a subset. In 0 A.D. the civs will be more unique, each having their own sets of units, although there are lots of similarities like spearmen and archers. I still think lots of civs are good, but we need to be careful when comping with other games that the analogy is accurate. e.g. if Starcraft had 12 civs as unique as the current ones (if that would even be possible) that would probably be overwhelming.

We chatted about this on irc a while back. Basically the outline above will create a potential field, non round threat hulls would be useful to have, and should be easy to add. Also I have extended my prototype code, now I have updating entity collections working (I think, I didn't test thoroughly though). I am still a bit unsure about the interface, my function names could be improved and the grouping of filters and dynamic properties still feels a bit messy. It almost maintains compatibility with juBot, changing line 65 of gamestate.js to return this.ai._ownEntities; makes it work. No performance benefit is achieved without changing lots of code though. Having ownEntities as a special case makes less sense with this new code, my new code just registers it as an updating EntityCollection and lets the standard code handle it from that point. I think it should be removed and left to individual AI's. A usage example is: if (!this.allWorkers){ var filter = Filters.or(Filters.byMetadata("role", "worker"), Filters.byMetadata("role", "militia")); this.allWorkers = gameState.getOwnEntities().filter(filter); } Metadata updates instantly affect the entity collections. For efficiency, metadata filters use "metadata.{key}" as the dynamic property, using just "metadata" is supported and will catch all metadata changes. Deleting metadata is unsupported currently, also saved games are broken.

There aren't many settings available currently, You can try the graphics settings in game using menu-settings and see what effect they have. Also there is a fixed render pipeline option but I can't remember how to enable it.

Yes, it is the code that works out how to get the units to where you told them to go. So they don't just walk into a tree and get stuck. It is a fairly complex task, which is not helped by having formations. Philip (Ykkrosh on forums) is currently working on improving the code.

This is caused by a combination of two things. Firstly there are problems with performance in the game, mostly AI and pathfinding, these are being improved for the next release hopefully. Secondly on linux the game uses opengl cursors so the mouse movement is synchronized to the games framerate so it feels much more jerky than if you play on windows. Hopefully this can also be changed.

Do other full-screen games have this problem? If not I would guess it might be to do with not using an opengl cursor. I am not very knowledgeable about these things though.

At attack warning will be implemented at some point. Double click not selecting units of different ranks is a feature which there has been some debate over in the past. Currently use triple click to select all units of one type. I have created #1098 for the garrisoning bug. A town bell is planned, but I don't know what will happen to citizen soldiers for this. To have customizable defence plans sounds complicated and is unlikely to be implemented, a limited selection of presets might be an option e.g. ignore the bell, start fighting, garrison. With the newly implemented military select (hold Alt which dragging a selection box) doing it manually should be a bit easier for now as well (currently in svn).

I believe it would be 'resigning with dignity in the face of the inevitable'

It is a range from 2-4096 so if it was split linearly into say 4000 pieces then the resolution is 1 everywhere, changing the 2 to 4 effectively makes no difference, even setting it to 1024 only makes it about 0.75 units. In the OpenGL docs I found it said that the z buffer value is the reciprocal of z (so saying it was logarithmic was wrong). With this example, the far plane is at 4096 and 1/4096 is small so lets call it 0 for convenience. So for near=2 we have a range of 0 to 0.5, for near = 4 we have 0 to 0.25 so the resolution is doubled, for near=8 we have 0 to 0.125 doubling the resolution again.

I played around with the shoreline code a bit for this map. I have uploaded a diff and the file if you are interested. I basically made the beach slope gradually and moved the dry/wet sand terrain transition underwater because it looks ugly (the blending in the engine should be fixed really). Also in the process I found that the height for tiles is specified for the corners which, based on your code, I don't think you were taking into account. Because that is not the way I want it to work I patched the rmgen script so that now if you set TILE_CENTERED_HEIGHT_MAP = true;using setHeight/getHeight will do it for the center of a tile. You will need the latest svn for this to work though. If you don't have the latest svn it will just have the height map shifted by half a square towards the bottom left of the map, so it is safe for Alpha 8 users (most noticeable that the right hand beach is larger). Edit: Just noticed my previous diff was in the wrong direction, link is correct now.

Nope, qBot tries to generate a bit of entropy based on the players actions. Proper random seeds should be implemented, they need network syncing though which makes them a little more tricky to implement for people who don't know the code so well. Edit: Just realized what topic this was in, I don't know if we will get them for Alpha 9.

I think a king is more interesting since you can move your king so you aren't stuck in one place on the map. If implemented sensibly then the king will be made visible once the player is in a losing situation, AoK had a treason technology for this. Also most players will resign when they are beaten anyway. I think it would be good to add these modes to the game, I think that the primary mode should be conquest but these are good for variety every so often.

I'm not currently working on much to do with qBot, I am fairly busy with other things in life currently and the next main thing with qBot is probably going to be working out/integrating new API changes.

Thank you for the reminder .

#947 means ticket 947 http://trac.wildfiregames.com/ticket/947 , this is a source code patch though so you would need to build it yourself.

There are fairly severe performance issues currently. I posted a proposal on the forum http://www.wildfiregames.com/forum/index.php?showtopic=15410 , which gives a rough idea of what might happen, This is not definite though. So it will probably be similar but will be extended a bit so that it can be used consistently, it probably won't break much but performance will be bad if you use the API naturally like testbot/jubot do (qbot uses a variety of different data structures to hold lists of units which is a mess, with efficient entity collections these will be used everywhere).

Other languages aren't an option, unless you find one that compiles to javascript e.g. haXe. There is some documentation http://trac.wildfire...i/Rmgen_Library and you can look in the public/maps/random/rmgen folder to see the javascript functions which you use in the random map scripts. Reading existing scripts is probably the best place to start though.

If you want to start developing the game then it is recommended to get the svn version, this means you will keep up to date, this is especially useful with AI which is likely to change significantly over the next release. If you get the svn then you can just start editing anything in the binaries/data/mods/public folder. If you don't want to use the svn then you can extract the public.zip folder which is found somewhere in your 0ad install (OS dependent) and the game should then start using the files from the unzipped folder. Random map scripts are found in public/maps/random, there is some documentation http://trac.wildfiregames.com/wiki/Rmgen_Library and you can look in the public/maps/random/rmgen folder to see the javascript functions which you use in the random map scripts AI scripts are found in public/simulation/ai there is a common-api folder which is shared by the bots but this is going to change soon. For changing the max population see: mods/public/simulation/components/Player.js 14: this.maxPop = 300; // maximum population

Marilyn equivalent treasure hunting is now in qBot.

view.near is the key thing to change, I set it to 32.0 with your other settings and things looked ok. I seem to remember philip (Ykkrosh) saying that the depth resolution is on a log scale so changed 2 to 4 actually doubles the resolution. Also I noticed that the carpets at the front of the persian CC show z fighting on every camera setting I tried (including the defaults) so ignore them.