quantumstate

I have no plans to remove the old common-api. The common-api-v2 is pretty backwards compatible. I think the only breaking change is that ownEntities was removed. That is assuming that your code doesn't use nasty tricks like qBot did. Though if you only do that you don't get any of the benefits of the new API. 6 months is quite a long time though and there might be things happening like threading the AI scripts which might change some stuff, so it isn't guaranteed that the your AI won't break. Any changes should be fairly easy to cope with though.

Currently there are the "Core Api" changes and UnitAI is exposed to the AI's.

You don't need an account. Accounts are only necessary to make changes.

Yes, but things might break occasionally, also the download size is a couple of GB I think. There are windows binaries included in svn but for other OS's you have to compile yourself. You can keep the alpha installed alongside, they don't conflict.

Svn is a system for keeping track of changes, so we put work done between releases into svn. http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide contains some instructions. They are toroisesvn specific but should translate easily to other clients.

Also could you tell us what game version you are using? Philip has recently committed some big changes to graphics in svn so it would be good to know if these have had any effect.

Atlas is designed to pause when you are inactive so it doesn't use up lots of cpu in th background. I find this doesn't quite work correctly on my PC (I think this is the cause, not certain though). If I constantly move the mouse then everything runs smoothly, otherwise it is very jerky, maybe you have the same thing happening. This topic http://www.wildfiregames.com/forum/index.php?showtopic=15900&pid=237336&st=0entry237336 might help you with where the map editor saves file.

That is a pretty old machine you are using, I am not sure we will ever get 0 A.D. running smoothly with large maps for you. We certainly aim to improve things though. I don't know how to get the entity count fom the atlas js console but one way you could achieve the desired effect would be to modify the AI to print this info. Try adding warn(uneval(this.entities.length)); after line 105 in /binaries/data/mods/public/simulation/ai/common-api/base.js. When you use play in simulation test this should spit lots of messages at you with the total number of entities with an AIProxy component which is basically everything that a player can interact with.

Looking at your log it is the graphics which is running slowly taking 113ms per frame. I think you should be able to improve performance a bit by disabling shadows and fancy water.

Thanks, this is helpful. I am working on some changes to the AI which I hope will improve this.

Thanks, this one is more interesting. Could you give a few more details, I would like to know the game version, what map and how many AI's.

It would be a good idea to provide somewhere where people could upload their files. The FAQ is pretty new so we haven't got the details sorted out properly. Thanks for uploading yours. I took a look at it and it says that it is taking 34.251 msec/frame which should give you a solid 30fps. Is this profile report from a time when the game was lagging?

It would be nice to have the second screenshot slightly larger, I can't read numbers that small .

I'm looking forward to seeing what you come up with. Also I am transitioning qBot to the new common-api-v2. This means that this will go into svn soonish (probably within 2 weeks), I don't know if you are likely to switch. We can leave the old common-api there since it won't do any harm.

Hey again, nice to have you back. You picked a fairly bad time however, basically I am, in the middle of transitioning to the new API. Currently I have fixed all of the errors that popped up due to changes to the API and an working on making everything use the new API functions consistently. This should make the code cleaner and nicer to work with while keeping performance similar. Also I will be pretty inactive until about Friday because I have friends coming to visit. The extra functions interfacing with UnitAI aren't written yet but these should be simple and quick to add. The terrain related functions will probably take a bit longer. This is due to the bot doing some basic terrain analysis at the start of the game.

I can't reproduce this. Please give details of the map and building that you were using, along with the game version.

This sounds like a jokey answer, but i am never sure to what extent on the internet, so I will treat it as a more serious comment anyway. Zooming out isn't a good solution because units get too small to identify and select easily, graphics performance degrades and most importantly it takes longer to walk anywhere making the game feel sluggish.

Thanks for the detailed post. It sounds like a good system for tree growth should we want one. One little point is that when you say O(n) it is key to know what n is, in this case I assume it is the number of trees. I think it is still unlikely to be put into 0 A.D. however for the following reasons. The primary reason is that 0 A.D. is primarily an RTS warfare game. When you play a game the objective is to destroy your opponent, which is done by building a large army killing their soldiers and razing their base. Everything else is a means to that goal, so we have resources in order to provide more depth to the strategy. Now players can concentrate different amounts of their focus to different things, I personally concentrate on gathering resources so I can train more soldiers to overwhelm the enemy. Other players like to spend more time managing their troops, so fewer of their soldiers die in fight etc. So for regrowing forests we need to ask the question; how do they make the game more interesting to play. Infinite resources certainly add something since it allows for players to play defensively, building a strong base which means any enemy must attack while under arrow fire, putting them at a disadvantage. We already have infinite resources in the game, namely farms and trade routes. In order to keep the game balanced though there must be disadvantages to these infinite resources. We do this by making trade routes more profitable if they are longer so having a small defensive base means trade income is slow, and by making farm gather rates slower. Regrowing forests must therefore be slow, as you say, to keep the game balanced. This means if you wish to use them you must control a large amount of forested land. But if you control a large amount of forested land there are a lot of trees to cut down so in a typical game you probably won't run out anyway. So I would claim that regrowing forests don't actually change very much about strategy for a normal length game. They do have some effects of course but the effects need to be significant enough to outweigh the costs of having them in the game which I will discuss next. Regrowing forests add complexity to the game. There is bound to be some kind of performance cost, I have no idea how big this is likely to be though, so lets assume it is minor. There is additional code which has associated bugs and maintenance as well as requiring more art assets for saplings. The UnitAI, which controls unit behavior, is one of the most tricky bits of the game to get right, a good chunk of bugs are due to this and a lot of feature end up changing the UnitAI code. We want units to act intelligently but they must obey the player, this gives priority balancing issues. Having forests regrowing adds complexity to this. Since trees only regrow next to other trees to keep a good supply of wood units need to selectively harvest trees rather than just gather the closest. However this may not always be what the player wants. Early in the game I want wood fast or my enemy can kill me before I even get to the late game stage where regrowth is significant, so it would be better not t selectively harvest. Or I want more space to build and the pesky trees are in the way and I want them removed. Adding more controls to allow for this makes the players life harder which isn't a good thing in general. As an example Globulation built an entire gameplay mechanic around regrowing resources, 0 A.D. isn't trying to do that. Allowing for sapling transport makes this even more complex. You also make life harder for the AI developers who have yet another thing to teach the AI. The spread of forest will need to be limited so bases don't become wooded and paths don't become obscured, this could be done fairly simply by never allowing a forest to grow beyond the boundaries at the start of the game. Infinite fish stocks sound reasonable to me, they give a reason to control the sea later in the game on non island maps while not adding much complexity. You other suggestions are basically eye candy so are low priority and must not hurt performance very much. If someone came up with a really nice fast implementation it might be included. Causeways interest me more, being able to bridge a river sounds pretty fun. Maybe a deployable pontoon bridge could be trained from the dock as well. This is going slightly off topic though, maybe start a new thread.

I was thinking about the story, I'm just being nosy basically.

That sounds interesting, do you have any more details? I think this is most likely to happen using a trigger system, the way AoE did it felt a bit like a hack to me. I would rather have a trigger where if you walk to a certain area these units get converted/created. A trigger system isn't planned for the part 1 release though. For part one there are plans for an "imperial campaign" which will be similar to risk, where you conquer regions. This is so that we can have a campaign without needing triggers to be implemented. Beyond that I don't think there are any plans.

Looks like Mythos agrees http://trac.wildfiregames.com/changeset/11378 . Now 400 wood and build time is just under half what it was.

We had a chat on irc and ended up with changing the engine's random map loader so it does the conversion. This means the change will only affect random maps rather than the whole engine so not too much needs changing. So this will need coding, I don't know if you are interested in doing it? Otherwise I can have a go. Edit: Also it must be documented (or we risk histroric bruno's wrath).

The plan is to have formations which will be more rigidly organized, rather than the melee chaos that we have now (though I imagine a lot of battles may have looked more like chaos). Making skirmishers work nicely is tricky, I think it is likely that horsemen will be needed to chase them down or using a covering screen of your own ranged units. This means that they should have a fairly weak attack though.

Perhaps the building time could be shortened to emphasize the idea that the purpose is to rapidly put it up as a temporary attack base without the opponent being aware. This would fit well historically since the roman legionaries were great at rapidly constructing a camp.

You new getAngle function could be defined quite simply in terms of the current one as GetAngle(0,0,x1,z1) - GetAngle(0,0,x2,z2). I don't know about function names, I can't think of any that make it really clear what is being done. I would like to replace the current unit placement angle with the anticlockwise angle from positive x. This is quite a big change though, I don't know what the other programmers think about it.