quantumstate

Thanks. I have changed my local copy. I will not commit right now because we are in feature freeze.

I had another go a reproducing this with the gaia towers like you said and it still didn't give infinite range attack. Could you give some step by step instructions which reproduce this bug? Thanks for reporting it, this one sounds quite mysterious.

One possible answer would be that testing long games hasn't been done very well because it takes ages to reach that point . I would be interested to know if saving and reloading the same game makes qBot play differently.

This looks nice. Building are especially improved. To eliminate the halos perhaps it would be possible to not apply SSAO to the terrain. This might require an extra buffer, I am not experienced with this stuff.

Thanks, this should now be fixed in the latest svn. If you see this again please tell me with details about what map and what time in the game (F12) it happened.

The actor xml might be useful. If I understand things correctly they help link together models with textures, animations and props.

All of the 3D models are in the collada format. How you use the models in another game depends entirely on that game. Unless that game happens to use the Collada format as well you will have to convert the files to the correct format. Which xml files are you referring to? Also I am not sure what condensing an xml means.

Philip said that it is probably due to the unitId parameter being passed as the target. I will change the function so that the type of 'unit' must be an entity object. From this I would guess that your change to detecting unit.id() is what fixed it. The previous method of using typeOf probably failed for some case so an object (containing a circular reference) would have been passed. Thanks for the information.

I have no idea what that error means. Also the fix doesn't even seem to do anything. Googling that error gives this thread as the only result. Looking at the code I can't see any recursion. Were you able to reproduce the error?

Thanks I added this. Yes, all assignments with objects or array in javascript are by reference. Thanks, I have fixed this. It happened when the entity collection had a unit added or removed before the length was requested. Trying to increment or decrement 'undefined' is a bad idea. Out of memory is a nasty one to debug, currently there isn't a good way I know to debug them. One that I came across before which hit some GUI javascript was a mismatched profiler start/stop which lead to the profiler tree continuously growing. Not currently, I am fairly busy at the moment. I also don't know quite how ti will be implemented.

To send commands to the game you use Engine.PostCommand({"type": "walk", "entities": [this.id()], "x": x, "z": z, "queued": queued}); The commands are shared with the GUI so your AI can give all of the same commands a player can. See simulation/helpers/commands.js which is where he commands are handled. Alternatively you can read the entity.js file in common-api which is where most commands are sent for AI's. In order to train a unit you must first find a structure to train the unit from. The other AI's use functions in gamestate.js which filter the list of entities that the game gives to find the correct entities to train from. The process is similar for finding a worker to construct the building (working out where to put it is quite complicated), then you need to send a repair command to make the unit actually build it (slightly strange, but that is how it works). If you look at the existing AI code it should help you figure out how things are done. The demo/test bot is the simplest demonstration.

It should also be possible to directly connect with other players. To do this you need to find them first though, the #0ad irc channel is somewhere to go although there aren't that many people who play.

I personally much prefer lots of different threads. A 90 page thread is a terrible organizational structure. Of course replacing one giant thread with 50 variants of "my suggestions" doesn't help anyone either. I would favor a suggestions sub forum with threads being about one idea e.g. "Town Bell", "Farm Reseeding".

Female citizens do not increase the attack when garrisoned currently.

You can trade with your own markets or barter to get metal.

Search and destroy sounds interesting. So it would work like scouting but with attacking every enemy that got into the line of sight?

Also mk12 has had code committed. I forgot to say in the commit message for [11569] though .

Technology restrictions aren't enforced for AI's yet. The check will be re-enabled at some point in the future so adding support for AI's will be needed. The common-api is lacking support for techs at the moment though (you can research them and view their progress in the training/production queue (this should be renamed at some point as well)) but you can't easily query to find out what has been researched or find out what effects a tech has. Big features left are ship movement (and AI support), formations (for fighting), diplomacy, walls/gates which are a WIP and conversion/capturing units/buildings. What counts as big is fairly subjective though. Also performance could be considered a big feature, it definitely will need some work. We seem to have been making good progress recently which is nice.

Fixed a problem with save/load so now it works.

The AI is a sub-section of the network synchronised gameplay simulation. The game provides a proxy representation of the state of the simulation. Direct access to the rest of the simulation is not allowed so that theAI can be safely made asynchronous. The proxy representation is a set of javascript objects, with one for every entity in the game, with appropriate properties. Diff's are sent each AI turn to keep the list up to date. This is done with the combination of AIInterface and AIProxy (simulation/components). The AI has the function HandleMessage(state) called each turn. state is an object with quite a few properties, see the function in base.js for more details. The thing which gives you all of the entity information is state.entities which is an object of the form {5: {id: 5, owner:1, ...} , 7:{...},...}. So state.entities[id] is an object containing all of he changes to an entity in the last turn. When an object is created then state.entities[id] will contains all of the properties for that object. The common-api applies the diffs each turn to keep all of the entities up to date for the AI. The AI performs actions by calling an interface called Engine.PostCommand() which sends a message to simulation/helpers/commands.js which runs the command. There are a few other Engine commands, which should be self explanatory (run a search on the AI folder to find them all). They are defined somewhere in the C++ (I can't remember exactly).

Before the release I would like to make a basic tutorial scenario using a custom AI. It would teach basic movement, building, training and fighting. It can use the AI script to see the players units and then send chat messages with instructions.

This should be fixed now since Mythos transferred the units from internal to public. (The resource warning is still there.)

Interesting, I didn't think that would happen but it does as you say. I will make the changes you suggest. It is === undefined. Edit: I also think I have introduced a save/load bug with the new api, I will try and get this fixed soon.

Because I want them to go back to doing what they did before fighting. I'm not sure exactly how that would work though.

You need everything that you have and you also need to make sure that fbotAI inherits from baseAI. Here is the relevant qBot section. function QBotAI(settings) { BaseAI.call(this, settings); ... } QBotAI.prototype = new BaseAI(); Your other question is quite a big one, I will try and answer it later, I don't have time right now.