mimo

If you want to report something, adding some details would help (I've not encountered it). I guess it is on svn, but - which revision did you first see it ? - is it only when using your mod, or also with vanilla 0ad - can you upload a commands.txt (for vanilla game) which give the problem ?

still there in latest svn, these props should be removed from art/actors/structures/seleucids/market.xml

When creating a trade route, select your first market, then use the shift key to add some points along the route you want to follow and then to select the second market.

Thanks for reporting the error. Could you give more details was it on a20 or on svn ? and can you upload the replay ? we need the commands.txt file in the replay directory (see http://trac.wildfiregames.com/wiki/GameDataPaths for file locations).

This commit is only supposed to give a starting boost when no resources, so it will help in your case but will not enough to ensure a full food production. Currently the AI only builds one corral. I'll complete it soon to make several when farm fields are disabled, but will need some trials to find the optimal value. If you are interested in doing such tests, that would be great.

Have you tried to redefine the key associated to the Pause in your user.cfg file, associating it to a letter for example, so adding something like [hotkey] pause = "X"; Have a look at http://trac.wildfiregames.com/wiki/GameDataPaths for the locations of the files.

As i said, there are a few places where i know that the code has to be changed (and these i could do easily), but i'm pretty sure this will not be enough and that we will have to track all the possible remaining sources of differences (as some values which have been cached or whatever), and this could possibly need quite some time and tests.

elexis: your statement is a bit misleading. AI serialization is implemented (and works fine on singlePlayer games), but it is not fully "reproducible" in the sense that the state after serialization is not exactly the same as the one before. And your percentage also is misleading: playing multiplayergame with AI should have 0% chance to be OOS if you don't need to rejoin, and 100% when you rejoin. imarok: yes, please, create a ticket. If you are willing to have a look at it, that would be great. I see 2 possible ways to work this out: - 1) make the AI serialization fully "reproducible". That's only Javascript code as all the AI is scripted. I know a few places where the code needs to be changed (so i could either guide you or try to implement it myself when i have time), but that's certainly not all what is needed to be changed, so further JS debugging would be needed. - 2) when a player rejoins with AIs, we could force an AI serialization/deserialization for all players. That should be mainly c++ code. But that may be just a temporary hack, as 1) would make it useless.

Having plans is not what make these features implemented. It will be only when someone finds the time to do it, but certainly not a20 which is being finalized.

And does the OOS happens when somebody rejoins ? if yes, that's normal in the sense that rejoining with AI is not yet supported, i.e. the state after deserialization is not exactly the same as the one before.

I suppose you are on A19. The path was changed on svn (and unfortunately the wiki was changed without refering that important point). So you have to look in ~/.config/0ad/logs/sim_log Concerning the AI error, I remember having fixed in svn some errors i had in attackPlan, so it may be that your bug will be already fixed when a20 is released.

But you've misunderstood the trade concept in this game : you don't have to exchange resources for trade, it only adds you some resources shown by the resource carried by the trader ! and the percentage gives you the proportion of the resources you want. So in your case, you will never receive wood, and you will receive food in about one travel out of 20. You can also barter (left part of the market panel) : bartering really exchanges resources (so seems to be what to want), but be aware that the more you barter, the less the rate will be.

Can you be more explicit on what does not work for you ? the yellow frame is not important to know what you will trade, only the percentages are, and they are kept, not ignored.

No, the AI checks the accessibility before trying to gather. But you may still have a problem with UnitAI (which controls the automatic behaviour of all units either AI or human). When finishing one tree, it will switch to the nearest one without checking on accessibility.

You could replay one of your games (non visual replay is enough if the lag comes from the AI, but you can also do a visual replay). That should create the file profile.txt which can already give some hints on the possible reasons for the lag.

Lion, maybe something messed up in your svn ? can you for example remove the simulation directory in your public one, and then do svn revert -R .

I've done an autobuild, so could you try with r17731 ?

If on windows, do you recompile yourself ? if not, there was no autobuild since 10 days, could be the reason.

fixed in r17722 by putting the iber cc. Delaying the town phasing after the migration as suggested before would imply that only fishing boats can be used to migrate (other ships are only available in town phase) except for cart which would then have an unfair advantage.

What i find silly is your way to report this kind of possible mistranslation by a non-english native. That's a bit pathetic. The important notion to convey is that it can be either negative or positive, which penalty does not as far as i understand it, or do you propose penalty-bonus ? that would look akward. So any input from a native speaker would be appreciated.

ah ok we have still to discuss it within the team, but hopefully that will be included.

Hi lion, thanks for the tests. But can you rephrase you last sentence ? I'm not sure how to understand it

av93 I don't think reducing the cc arrows is the right fix for this issue (even if it may be useful for other purposes). For this specific problem, the main problem is that farms needs too much time to be destroyed in early game when we have only soldiers (as pointed by wowgetoffourcellphone). So the alternative would be to reduce the armour of farms, but i've the impression that decaying unused fields could bring something new to the game.

I've tried to implement two changes in farms, which are available as a mod. 1) the first one is rather cosmetics, it gives to the farm the same ownership as the terrain on which it is. This doesn't change the gameplay as units can already gather from any fields. But this has 3 advantages: - there was no reason for enemy farms in our territory to not switch ownership after we have expanded territory - idle soldiers will no more try to destroy these farms which we could use - that will ease the job of the AI, which currently only tries to gather its own fields 2) the second change tries to make early rushes more efficient in destroying the enemy economics. Currently, an easy defense is to garrison its gatherers in the cc with a few arrows, and wait for it to kill the attackers. As units does not make significant damages to fields, the economy is usually not really affected. The proposed changes is that fields loose health when not worked on, and only regain health (very slowly) when having workers (i.e. they are no more directly repairable). Thus during a rush, if we succeed to kill all gatherers (or make them flee), the field will be severely damaged and eventually destroyed if the attack is long enough. As the goal is really to help rushes in early game, I've also added a tech (irrigation, thus fields need less maintenance) only available in town phase which decreases the health decay when not worked on (there is a temporary icon for it, but if anybody could provide a good irrigation icon, that would be great). Any feedback welcome. newFarms.zip

Concerning the bug itself, it has been fixed in the dev version, http://trac.wildfiregames.com/ticket/3710