quantumstate

A few random ideas that I have had about this. As Mythos mentioned for his snaking idea it would be good for units to move relative to the surrounding units, I think it would be better to use all adjacent units rather than just the one in front though. This would require a notion of whether a unit is in formation or not since there is no point trying to follow adjacent units if the adjacent units aren't in formation. An idea for efficiently determined possible positions for units is to use a range limited flood fill algorithm from the formation controllers position, then only allow units to be placed inside of this generated region, this will stop them trying to walk to the other side of a wall. The hard thing seems to be working out how to rearrange the formation so it can fit through a gap. One idea is to take the flood filled map section, then calculate a vector of the direction of travel v, move along v in roughly cell sized steps and count the number of passable cells perpendicular to v, call this n_i. Take some typical minimum value of the n_i, e.g. average the 3 smallest to smooth things out a bit. Use this for your formations width. You could also use the counts to the left and right of v to roughly centre the formation. I made a picture to make things clearer (hopefully). Black is a lake/wood/... Red hashing shows the area too far away from the formation controller for unit placement (generated by the flood fill).

I think it would be interesting to have this in the Alpha to see what it is like, but I am not in charge of stuff like that. Implementing it as you said would be pretty easy, it should be about 2 lines of code to make it display inf. A key difference to the AoE series is that with 0AD there isn't a restriction on the number of units gathering from a farm, so the resource cost for construction is much lower.

AI scripts get run at regular intervals during the game, several times a second. You get given a list of events which include entity creation/destruction and attacks. You can also access information about every entity in the game so you can use this to look at positions of units etc. You can then give entities commands e.g. move, attack. (Every unit in the game has/is an entity basically, so every tree, soldier, building...). You should be able to use some combination of events, entity information and game time to detect when to give units commands.

I have a HD 4830 and I don't see any messages, on Linux using the open source drivers.

This does not generally improve performance, it removes extremely bad performance in certain unusual cases. Performance shouldn't be too bad currently, in late game I find that the pathfinder is more significant. Also performance should be improved by a new API fairly soon.

I tend to prefer doing things based on situation rather than time, so if it has been attacked early it doesn't spend resources uselessly on tactical expansions but I can aim to have to happen at about the 10 minute mark for a typical game. Where do you think would be good for the placement of the expansion? Aiming for resource concentrations is the obvious thing, but how far away should they be. Do you aim to keep a continuous area of territory or aggressively build near the enemy to restrict them more? Also I have recently committed two significant military improvements. Now qBot will retaliate when you attack its offensive troops so you can't just ambush its troops easily like before. Also I put in some path randomization code so the assault could come come from any direction.

The current behaviour is meant to be temporary, buildings should be converted which makes it more like real life since logistically you wouldn't be able to supply a building in enemy territory very well. If you wanted to expand on your ideas it would be good to use a new thread. If you do I would recommend reading the forums (search for relevant topics) and looking through the design docs to see what is already planned. Also be aware that based on previous experience most new proposals don't get accepted since there are reasons for the current design, but if the new idea is good enough then people will like it I guess.

Hi, welcome to the forums. Currently there is no portable version of the game. I don't think you would be able to make a portable version without editing some code. The game has 4 main classes of human unit. Female citizens are good at gathering resources and building (but they cannot place foundations for military buildings). Citizen soldiers, which are trained from the civil center or barracks are good at gathering and building except for gathering food from berry bushes and farms. Cavalry citizen soldiers are good at hunting but cannot do any other economic stuff. Champion/super units are other soldiers who have no economic benefit but are stronger at fighting, these are trained from advanced buildings. It is up to how how you decide to use champions vs citizen soldiers in battle, also since the game is not properly balanced yet be aware some units might be too strong or weak. Hunters don't seem to be very good at continuing as you said. This should be improved but isn't high priority because farming is the primary food source. Healing is not implemented yet. Formations should have bonuses attached to them in the future but for now they aren't particularly useful.

AI's are deterministic, so they will play exactly the same way each time unless you introduce a pesky non deterministic human into the game. ./pyrogenesis -quickstart -autostart="Oasis II" -autostart-ai=1:qbot -autostart-ai=2:jubot is an example of how to run an AI vs AI game from the command line (on windows you would need pyrogenesis.exe). This will have a free camera but it wouldn't be too hard to have a scripted camera given a bit of modding, so I wouldn't let that put you off. The AI scripting isn't perfectly suited to coordinating large battles but it is definitely possible. If you want help I would be happy to answer questions since I know the AI systems pretty well. Also on irc there is often someone around.

To get the newest code you can either download the zip or set up git on your computer and follow the instructions on github to download the repository through git. I found http://nathanj.github.com/gitguide/tour.html is one of the easiest tutorials to follow for learning git. Git makes it easier to keep up to date.

I just committed the enabling code for accessibility checking recently, I have enabled it for building placement quickly, I will try and get it done for resource fairly soon. I just committed a fix for this. This needs dynamically adjusting priorities for the different queues, the code is there but what needs to be worked out is how they should vary for good game play. If anyone feels like working out a decent system then I could code it in quickly. Otherwise I will get round to it eventually. Basically it would be a function of the number of female citizens and the number of citizenSoldiers and possibly time (female citizens are much more stable than citizenSoldiers because the citizenSoldiers get sent off to die fairly regularly). (Note for qBot cavalry aren't considered citizenSoldiers because of their limited economic benefit) I am hoping to get through your suggestions list (excluding advanced territory expansion) along with some extra military improvements in time for Alpha 8. The next week will be busy with maths work but hopefully by Friday I will have finished all the work due in this term.

It was only ungarrisoning when there were 0 units within the attack radius (roughly territory sized) previously, which is why it seemed slow ungarrisoning, there is no time delay. I have made it ungarrison more optimistically, this has the effect of making it not garrison female citizens who are under threat if a big defensive force is marching to their aid. This is not necessarily a good thing but is simple for now and prevents things like female citizens popping in and out of where they are garrisoned in some situations. Ideally in this situation I woud like the female citizens to go and gather somewhere else which is safer.

Just an update on progress in qBot. Work has been slowed by me having lots of university work to do. Recently infyquest has implemented garrisoning, this is fairly untested so far so it will be interesting to see how it works out. Also there have been a few random economic fixes over the last few weeks, one was pretty major causing unbalanced distribution of resources. Coming up next should be some military stuff from me, if i can get the terrain analysis working. I have also decided that doing something like JuBots attack code where they engage enemies on the way to a target separate from attack move (which I also need to work on) will give the AI flexibility in its attacks above what attack move should provide. Infyquest is looking at gathering treasures.

I think for this task you won't need to use blender very much. I am not experienced with blender so I won't try and help you there, you can work on animation without tree stumps without touching the models though so I will try and give some pointers for that. For the animation it would be simplest to do this in the code. So you just keep the same geometry and rotate the object in the game world. For a rough example of what this looks like I added a rotation into the render code which gave this http://i.imgur.com/TBYrW.jpg picture. I don't think it will be necessary to crop the trees, adding a tree stump would be good, but I don't think anyone will notice the growth of a felled tree and it saves modifying tree models. This idea is currently used for building destruction, the code is in source/simulation2/components/CCmpDecay.cpp. Helpful pages related to the components system are found at http://trac.wildfire...ionArchitecture and http://svn.wildfireg...om/entity-docs/. You will probably need to interface with binaries/data/mods/public/simulation/components/ResourceSupply.js, it seems to be sending a message whenever the resource amount changes already so you should just be able to listen to that to determine when the tree should fall down. It would be best if you can keep the changed fairly self contained in a single component, this keeps the source tidy. It might be possible to do this in javascript, i am not sure whether the necessary components (CmpPosition seems to be the main one) are exposed, it says on the simulation architecture page that javascript is preferred when possible. Hopefully that is helpful, I am not very experienced with the code myself since I have mainly just worked on AI so hopefully I haven't mislead you. If you have any other questions don't be afraid of asking, if people are too busy then they can always ignore it .

Currently it uses a fixed distance (200) rather than territory, but since they are pretty similar I said territory. I should switch it to use the minDistance value by reading the template. Currently I think min distance is calculated as a straight line but territories use the terrain so it would be possible to have outside of territory but with an invalid min distance.

Currently it shares the same code for building mills and CCs. So it builds a mill if it is in territory and a CC otherwise. This is simplistic behaviour which should be upgraded at some point in the future.

Infyquest is working on garrisoning currently, the basic functionality is there now. What needs to be done is working out when units need to be garrisoned, currently it just garrisons everything when a strong group of enemies comes within your territory. I had forgotten about treasure, this should be fairly straightforward. Territorial expansion might be tricky, I am not sure exactly how I would play with it myself to be honest. I am currently working on some code which will give a list of routes from one base to another. This will be useful for the attack code since it can become more unpredictable and possibly launch multiple attacks on opposite side of the base etc. Also for Mythos' idea since defensive buildings can be placed on the routes into a base. Organisation of other buildings would also be good but is lower priority.

I would like to see qBot to be included as an option in Alpha 8, but I am not in a place to make a decision. By that time I hope to have some military improvements so it will detect enemies on route so you can't pick off the troops as they walk past, and hopefully some more fancy strategies if all goes well. I got a friend to test it recently (with rough attack move) and it was a pretty close game but he had a 2:1 kill ratio so there is a lot which needs doing on that front. University work si fairly heavy at the moment though so progress is slow. Edit: If you don't mind elaborating on this it would be great, especially for prioritizing. You have probably played significantly more games vs qBot than I have since I primarily test bot vs bot because it is faster and I can watch exactly what is happening.

The only problems connecting that I have had is when people haven't been able to configure the ports on their router.

The diplomacy stuff sounds interesting but in my experience playing rts in multiplayer teams are always locked. I think this is desirable in most situations because teams are likely to make unbalanced combinations of players. It is bad enough when I have played with more than two teams which just ends up with some teams feeling picked on. The best experience is when everyone thinks they had a tough game which was fair. So for this model things like multiple tiers of alliance aren't useful. The game enforced ceasefire sounds good and would work great with territories. I like the idea of needing to research technology for these things. I am in favor of cartography without research though.

The formations thing is interesting, it needs pretty big changes I guess. If formations are going to change that radically then attack move will definitely need to be changed when that is implemented. I think I will try improving it anyway when I have time but consider it slightly lower priority. My changes to formations would help fix some of the issues in that ticket since I added since it allows formations to be temporarily suspended.

I have never used it much either, ignoring buildings is an interesting idea, I quite like it. I have considered this behavior, unfortunately there are some issues when actually implementing it. Mainly it is because one unit in the formation gets an enemy in range, then the formation stops, and the single units goes chasing the enemy with the others standing idle. I think it might work to have a move command towards the new enemy, but probably not all of the way there since the enemy unit will probably move towards the attack move units. I might try this idea with a move command to halfway between the current position and the spotted unit. If this approach is workable it is an elegant solution. For the hotkey it seems like moving garrison to alt and using ctrl is the preferred option. @gudo: I think it would be good to have keys like you say as well, I don't see any problems with having both, since people will be used to that idea.

I have been working on an attack move patch. Currently it works as a move command where the units attack any enemies that come into sight along the route,they attack and then are allowed to act using the same code as idle units, so they will attack other enemy units in sight and chase them etc. Once 80% of the formation becomes idle another move command is issued. It is currently bound to super+right click. For the hotkey it has been suggested that ctrl-right click would be used because starcraft uses this and it is convenient. Currently garrison is bound to ctrl-right click however. It would be possible to use both with the same hotkey by using attack-move whenever the right click wasn't on a garrisonable object. I think this is confusing though since two unrelated actions would be sharing the same hotkey. Other possibilities are keeping it similar to currently by using super as a modifier key, this might break with windows though since super (windows logo key) tends to open the start menu (I haven't tested though). The other option is to have a modifier such as ctrl-a which then toggles attack-move mode so the next right click will be an attack move. In terms of the behavior of the attack move I think it would be good to restrict the enemies which are targeted to conquest critical. This would stop random mills and houses disrupting an attack. Another thing is when to resume the walk, someone suggested a maximum distance from the point of sight with the enemy could be used. Another question is when to break the walk and attack, should we only attack large enough groups of enemies so that a lone scout isn't chased all over the map by your army? There might be a case when a distant siege unit starts firing from out of sight on the formation. What do you think about the desired behavior? Edit: The link to the bug report which has the patch is #1001, as I mentioned in the report I have seen some buggy behavior with groups not attacking properly, so I need to try and fix it when I have time.

Another thing if you are recording outside is a windshield. Even the very cheap ones (< £5) make quite a big difference.

Hi, welcome to the forums. You can use Shift-F to display the framerate, which give more quantified information about the lag. More interesting to you is if you press F11 you will load the profiler view, then you will get a breakdown of how much time each component is taking. 0AD doesn't limit the framerate so it is normal for the game to use as much cpu as it has available and I find it uses a significant amount of cpu for me while paused as well.