quantumstate

500msec is longer than I had been thinking, the might well cause problems. I was thinking though that it would be possible to interpolate backwards from the current simulation step to get the position at the time of impact. It shouldn't add much complexity, and it makes the code significantly simpler for the ProjectileManager especially if we start adding maximum deviation edge cases, and unifies the case with slow moving siege weapon projectiles. Also I have put the relevant posts from the private thread in the spoiler below.

This depends a lot on the problem . For this problem it was very fast because not much code needed to be added and the problem was exactly known beforehand. I try and prioritize bugs in general because it encourages feedback and it is nice not to have lots of issues piling up. Here it was instant knowing the problem, less than 10 minutes writing code, then 5 minutes testing (by repeatedly deleting farms in the bots base so it had to go further afield for food) and then committing the code which was simple. There are basically two sections to a problem. First is finding out what is going wrong, this currently involves thinking about what the code is doing and sticking lots of statements in which print things at various points so I can narrow down what is happening. e.g. Pureon found that on Hellanized Egypt qBot stopped producing anything after a while, the cause was that the maximum resource gather distance was too small so the fix was one number being changed. Finding the problem took maybe 45 minutes though since every test took a while to reach the point where qBot stopped working and I needed several attempts to narrow down the problem. In other cases such as siege not being used properly (still the case) the problem is obvious, since there is no siege specific attack code but implementing it requires careful thought and quite a lot of code so will take a good few hours probably.

This seems to be working well so far with my testing , saving is very nice to have and this will also be very helpful with my testing. For the future do you think it will be possible to serialize the entire AI without any work from the AI script?

I have put a territory check into the resource finding code so this shouldn't happen again. Also fields are built more enthusiastically.

Maybe trample should be excluded from this then, it does seem to make more sense that even when moving they would cause trample damage. It would be simple enough to have a formula with a template based override, having it automatic would probably save quite a bit of work for most units. These all sound quite useful to have, I think it is best for now to limit the scope of this proposal though. That sounds like it may be over-complicating things. This is definitely beyond the scope of this. From reading that thread, it seems that there are technical issues with determining what the missile hit on impact. The general idea I proposed should work similarly with hit detection on launch. One thing to consider though is, as the attack module mentions big projectiles would be best not done this way and people seem to want missiles they can dodge, is it worth considering doing impact based detection? I would imagine it working by cutting tracking out of the ProjectileManager code and always have it aiming for the hit location, you could detect if there is a unit there for visual effect. Then the attack code would just use a timer as it does now but have a hit detect function. Occasionally there would be a visual mismatch from timing lag, but I don't think it would be more very noticeable. I disagree somewhat about the complexity. My idea has a very clean implementation (random normally distributed hit position and check for collision of the arrow), but I you disagree about the gameplay complexity. I think having the missile hit whatever it lands on adds significantly to the strategy, making spread formations useful for something. Making things more physically based where possible is good because it makes the game play more intuitively, so the arrows will do what you expect, if my archers hit a little infantryman half the time then a massive great elephant should be hit practically all of the time, using their in game size gives a good visual indicator of what is going to happen. That is why I added a <FriendlyFire> to the xml proposal. Easier to let someone else decide .

I was thinking of working on this, it should be fairly straightforward to do what I suggest here and will bring the attack code up to a decent level of functionality (similar to AoK). Here is what I propose. Accuracy Stationary targets This will have an entry in the entity xml for ranged attacks. The value will be in the range 0 to 1 and will mean the probability of hitting an infantry unit at maxRange. When a missile is fired it will be placed according to a (2d) normal distribution (approximately). The normal distribution will be scaled linearly according to distance, so a missile fired half the distance has the same chance of hitting as a missile fired at a a target twice as wide (4x surface area). This makes aiming at nearby targets a lot more accurate. Examples:With a maxRange of 100 and an accuracy of 0.5, the probabilities are (range:probability) 100: 50%, 75: 70%, 50: 93%, 25: 100%, 0: 100%. With a maxRange of 100 and an accuracy of 0.25, the probabilities are (range:probability) 100: 25%, 75: 40%, 50: 67%, 25: 87%, 0: 100%. With a maxRange of 100 and an accuracy of 0.0625, the probabilities are (range:probability) 100: 6.3%, 75: 8.4%, 50: 23%, 25: 64%, 0: 100%. First, by mistake I calculated the results for a 1d normal distribution, here they are for comparison. With a maxRange of 100 and an accuracy of 0.5, the probabilities are (range:probability) 100: 50%, 75: 63%, 50: 82%, 25: 93%, 0: 100%. With a maxRange of 100 and an accuracy of 0.25, the probabilities are (range:probability) 100: 25%, 75: 29%, 50: 48%, 25: 80%, 0: 100%. The 2d results should be fairly realistic, but for the game I think 1d would actually be better because it has a less extreme curve. Archers will automatically attack at maxRange and won't walk any closer automatically (at least currently) so having too much advantage for being closer encourages lots of micro. Of course in dense formations if the arrow might well hit a nearby unit and will cause damage to that unit, this will make spread formations useful. Larger units such as cavalry will be easier to hit if they are stationary. Moving targets This is something that I am less sure about how to do properly so consider this a less strong proposal. Units should by default aim at where a unit is going to move to, using its movement vector. On its own this would lead to moving targets being hit with the same chance as still units though which is undesirable. There should be an accuracy decrease according to unit speed, I suggest having accuracy depend on the square of speed, with walking speed cavalry halving the hit probability and everything else worked out from there. This kind of thing is easily adjustable though so we could test and see what feels good. Again if you have a tight group then stray arrows will be likely to hit other units. Splash Damage I propose this xml structure for splash damage: <Attack> <Melee> <Hack>7.0</Hack> <Pierce>17.0</Pierce> <Splash> <Type>Trample</Type> <Dist>5</Dist> <Crush>4.0</Hack> <FriendlyFire>No</FriendlyFire> </Splash> </Melee> </Attack> This would work by giving splash damage to units within Dist in addition to the conventional attack, so the conventional attack would have to be decreased to compensate since the primary target would receive both conventional and splash damage. I would recommend 3 types of splash damage, with this scheme only one would be possible per attack type (this restriction could be lifted if necessary but it would probably make the xml more messy). Circular This would damage all units in a circle of radius Dist around the location of the attack hitting (the unit being hit for melee or where the missile landed for ranged). It would have a quadratic damage falloff so units at range Dist (from the location of the hit) would receive 0 damage, units at range Dist/2 would receive 0.75x damage, units at range 0 would receive full damage. e.g. the rock throwing siege. Linear This would damage all units in a line aligned with the attack. So for a missile it would damage all units within dist of where the missile hit in the direction away from where the missile was fired from. It seems to be hard to put into words but is a simple idea so I drew a picture. The green blob is your bolt thrower, red are enemy soldiers, blue is the line along which damage is received so three red soldiers get hit. I would suggest quadratic damage falloff again. Trample This is identical to circular but the damage is calculated centered around the attacking unit rather than the position where the attack hit.

I'm pretty sure I've finally removed the source of these errors. They seem to have been a bit troublesome though, if the happen again I may ask someone else to try and sort it out for the sake of my sanity .

The reason for restricting the range of colors is so that people cannot pick colors which look too similar. I think it is preferable to limit the color picker for this reason otherwise you would somethings get annoying situations in multiplayer with little benefit.

I haven't found an IDE which can cope with the javascript particularly well unfortunately. Geany works moderately, to the extent that you get a nice function list down the side so can quickly jump around. Eclipse works with the qBot code because I like using it. I don't think anything would be able to cope properly with the components code because the modules access each other using Engine.QueryInterface(data.target, IID_Identity); which is handled by some C++ code. So I would recommend using Geany and living with the fact that you will have to manually look up code in different modules. Also keep stuff from the helpers folder open for reference. A good search tool is also very helpful.

It is easiest to use warn(). This prints a message onto the normal game screen and into the console. You also get the messages logged in interestinglog.html (found in the log folder which is OS dependent).

Since the AI API is planned to be updated I thought that creating a thread to finalize the changes that will happen. This is marked to be done as part of the Pledgie work by Philip, I would be willing to help but I think some of the planned changes (e.g. running in a separate thread) would be best done by Philip. I would like to have the changes below for qBot, it would be good to have feedback from other AI developers especially, feedback from everyone else is welcome of course. I have tried to mention how juBot behaves where relevant to the extent of my knowledge, I don't know enough about splitBot to comment though. Core API I am calling the current system the core api, these changes may break current AI scripts, depending on how they are done. Running the AI scripts in their own threads. This should improve situations on multi core systems and also stop stuttering of the game when an AI does something expensive. Storing entity objects persistently rather than constantly recreating them. This is fairly simple and should help the garbage collector mainly (plus a little less overhead creating the objects though this should be pretty cheap). I did a quick test by modifying the current api and have attached the code. It works with JuBot (qBot does some naughty stuff) and there seemed to be some performance improvement but it was fairly minor and my setup for measuring is rather crude, I measured about a 280ms to 230ms change at 10x speed but don't take this as an accurate figure. Persistent entity collections. This is what I think will deliver the largest performance increase (qBot currently uses a crude version for this reason), but will require modifying AI scripts to take advantage of them. Based on my testing JuBot spends about 98% of the time filtering through entity collections. Here is my idea of how these should work: You would create a new entity collection by filtering an existing entity collection (I think juBot does this exclusively). You would give the filter function as an argument (see filters.js in the attachment) and it would be stored as part of the entity collection. Then if you wanted to store the entity collection, you would use some sort of registerEntityCollection() function. From this point the entity collection would be maintained by the API. The filter functions of the parent would be inherited. (more technical details, can be ignored) The filter function may depend on a dynamic property, for efficiency I think it would be helpful for the API to be told which it depended on. So you could have player 2's idle units which would depend on the idle and owner properties. The combination of this with the Filter.js file leads to the question of how the dynamic properties would be passed to the entity collection. To keep things neat when using Filters.js putting the function and dynamic properties list into a simple object/array would keep things neat. This makes things more messy for someone making their own filter functions from scratch since they now need to wrap it in an object. I think this method is preferred though. e.g. {'func': filter_function, 'dynamic_properties': ['owner', 'idle']} Filtering based on position presents a potential performance problem since there can be a lot of position updates every turn, I think for now it would be worth keeping thing simple and not doing anything special and see what happens, it should be able to offload it to a C++ component without any interface changes if it is a problem. Another possible performance factor would be storing the entity collections in a hierarchy so you could avoid looking deeper in a tree for a lot of events. This should also be possible without any API changes so isn't important as a consideration currently. (end of technical details) Other Stuff Here are other helpful functions that it would be nice to have an interface for in an AI. I have put them in what I think should be their priority. Accessibility testing, can a unit reach another point on the map from where it is currently? QBot does this already but it is one of the factors causing lag at the start of games and is based on the coarse accessibility map which has caused some issues. Also qBot's version is not dynamic for performance reasons. UnitAI state. It is nice to know whether a unit is walking, attacking, woodcutting... Map manipulation functions see http://www.wildfireg...89 for details. Also see map.js in qBot. Fairly low level pathfinding access or some terrain analysis functions. See terrain-analysis.js for a rough idea of what I want to be able to do. More fancy stuff would be good as well. On a basic level giving a pathfinder using a specified custom map to route over (basically adding some more inaccessible areas). Edit 06-04-2012: Now the code is in svn

You first have to log in/register, then there is a 'New Ticket' link in the navigation bar. If you want me to I could create it for you, but if you create one then you will be informed about any updates to the ticket.

Just noticed nobody has replied to this topic. This would be useful, I think that several things would need changing since a few directories are used for storing logs and screenshots, maybe ti would be best to open a report on trac.

running clean_workspace.sh and maybe also make clean in the gcc folder should put the 0ad folder back to something like its original state. This won't undo any packages you installed though.

Some more advanced ranged units have a secondary attack defined. This isn't implemented yet though.

I would say that it uses the no LOS to cheat a bit at the moment. Basically it uses it to measure your army strength and uses this to affect how many troops it trains and when it attacks. There are no resource benefits though. Pureon: I fixed the first one by stopping qBot for trying to gather those kinds of treasure. The second is more tricky, I might be able to sort something out so it can recover after a period of time, I will see.

Since feature freeze is just a time when you stop adding new features nothing visible actually happens. Release is planned for the 23 December, I am not aware of anything which will prevent this happening.

I think you would probably want to look at binaries/data/mods/public/gui/session/input.js. Some other files in those folders might be relevant as well. You will find that these often call simulation components, http://trac.wildfiregames.com/wiki/SimulationArchitecture gives an overview of the simulation system. The js parts are in /home/jonathan/programming/0ad/binaries/data/mods/public/simulation the components folder contains the simulation components and the helpers folder has some stuff which they use, commands.js is an important file since it handles commands sent to entities. The C++ components are found in source/simulation2. There is a lack of high level documentation for the game unfortunately, hopefully this will help you a bit.

"The planned due date is for the feature freeze, the actual release is scheduled to be about a week later."

The config file is a good idea which we should implement. This should allow us to do nice things like making aggressive and defensive versions of the bot which can by easily switched between. One thing to consider is that a lot of properties which should be configurable should also be dynamic. One possibility is allowing some functions to be defined in the config file. Making the config file too complicated does cause problems though.

Since you reminded me of AoE3, I remember that for moving cannons a short distance they would not be packed up, they would just get pushed along. Empire Total War did not have this feature and it felt pretty annoying to see the units hitch up horses to move 10 meters. What do do you think about having a slow movement speed for unpacked siege?

Can you explain why you think it is better doing it like this instead of how I outlined above. I always found trebuchets fairly annoying to use in AoK and sometimes wondered if that was a design decision to make them less powerful.

I think making them basically automatic but also having manual buttons available. Requiring infantry units would be very annoying, for eyecandy it would be better to have a couple of operators as part of the model, I don't know how easy that would be for art people though. One idea would be to have three possible modes; unpacked, auto and packed which would be modified through the UI. In unpacked/packed mode the unit would remain in that state until it was turned off again through the UI. In auto they would follow your instructions automatically so attacking a unit out of range means it would pack, walk and unpack without manual intervention. This would be the default mode and I think would give a good blend of manual control and automated helpfulness.

The advanced building list will only ever build one fortress. Have you observed the warning about build too many fortresses since my last commit? I should have fixed it there. The defensive building code is designed to build up to the build limit of 10 fortresses (at least on open maps) but it will take its time doing so.

I have simplified this code a bit, basically it raids for the first 6.5 minutes and then attacks as previously after that. The raids are random, it is possible that no raids happen at all, though I increased the probability a bit so that should be rare. I forgot to disable the debug messages before committing, they are disabled now . There was a bug in he check for building limits, <= instead of <. It builds forts on the most important (shortest) attack routes first and then just keeps going after that. Also I slowed the fortress building rate a bit. Edit: Pureon: I have added another check into the attackMoveToLocation code, Hopefully this will stop the error you got, it seems to be a bit persistent.