mimo

There is also one point worth to consider with trade which is to have the possibility to put some limitations on the number of trade routes we can have on each market. A simple way to achieve this feature would be to have a new component (something like TradeSupply.js) acting on each markets and docks and in which we can implement such a code. This would have the additionnal advantage that some variables presently defined as constant in the JS could be put in the market's xml (like for example the bonus for international trade).

I use a simple timer which checks every 10 s if the cc of the player is still alive. If not, the player is defeated. For the victory, it's much simpler as I just test on the number of attacks without being defeated.

I'm not sure to understand your question. May-be look at http://www.wildfiregames.com/forum/index.php?showtopic=17101 for details

Thinking again to it, I agree. That would be the simplest approach.

A fraction has the advantage of being more versatile for future evolution of the game : it may depend for exemple on the civ. If we have by default 50% of the international trade for the player and its ally, we may turn it to 70%-30% when one of the civ was good in trading (like carthage for exemple).

In fact, the proposal in the quoted thread was not exactly that one : it was to give only a fraction of the international bonus to the ally. So if the international bonus is 50% and that we decide to give 50% to the ally, the ally would only have 25% (50% of 50%) and the player 125%. So the player still gain more than with domestic trade where he would get only 100%, but part of this extra income is shared with the allied.

I forgot to add the file just create a defense directory in your binary/data/mod one, put there the zip file and run with 0ad -mod=defense

I guess everything is possible. But why would you need a regular AI which would develop its economy in such a mod. In addition, you would always find some players to raid the AI, which is not at all the goal of this mod which should emphasize defense. So there are no AI here, only an empty map and ennemies appearing at some given time, and attacking the player with some appropriate orders. In fact, I originally developped the move-attack order for this mod.

As there was some interest in a defense mod (you have some time (8mn by default) to develop your economy, and then every 3mn, a bunch of ennemies attack you, with the number of ennemies increasing at each attack), I put here a version of such a mod. The game stops if the user has still its cc after 12 such attacks. It's still a very WIP version : just try it with the default settings of the gamesetup gui, without changing any option. And it is adapted to the svn version of today.

In fact, there is no need of trigger for such a mod. A simple timer will do pretty good. I've written such a mod some time ago. Still a WIP, but I will post it in the mod section if some people are interested.

Thanks for the answer. I've tried to zip my mod folder and this now works. So when the public folder is zipped and not the mod folder, that does not work (at least on Linux), but when both are zipped that's ok (I've not tried the case where none are zipped, but I guess this should work as that's what you are using). If somebody could point me to the piece of code which manage that, I could have a look. Concerning svn, you are right in principle, but in practise this ppa:wfg/0ad.dev is updated every few days, so that's fine for my needs. thanks again, mimo

hello, I use a ubuntu build from ppa:wfg/0ad.dev, which installs the public mod as a public.zip file in 0AD/binaries/data/mods/public : If I create a simulation directory in this public directory and put there some modified files, everything works fine and the game take my modified files But if I create a mymod directory, i.e. 0AD/binaries/data/mods/mymod, and put there my simulation directory with the modified files and then run with -mod=mymod, only the original game is run Is this a known problem ? or am I doing something wrong ?

Concerning the gameplay improvements, I think the most important one would be to add the delay, so that the effect of the tribute is not immediate. Then what does the caravan adds up ? - visually it would look nice. - could be destroyed by the ennemy before reaching its destination. But how would it be done ? from our's civic center to the allied one ? and what if you have several cc ? should we choose the nearest pair ? then in practise people will build a cc just at the border of their ally territory and all the benefit of the caravan in term of gameplay will be lost. So while I agree the caravan idea could be nice, it needs more tinking. On the other side, adding only a delay should be quite fast : the main change is on the diplomacy gui. Now, each time you click on a resource, 100 of it is sent as tribute. The needed change would be that such clicking allow you to gather your tribute, and having a "send" button to send it when ready. And this "send" would trigger a timer for the delay. Sometime in the future, when the caravan proposal has matured, we would just have to replace this timer by a caravan. But at least, the main fonctionnality (adding a delay to avoid abuse of tribute) could be in the game quite easily.

The present implementation of tributes is not satisfactory as it has an immediate effect, which is neither realistic nor desired. Having some delay between the action of sending a tribute and its use by the ally would force planning in advance of tributes and not wait for the last minute (i.e. when your ally is attacked). I've seen that someone proposed to have caravans for tributes : that could be ok, but would require a lot of code addition. An other, easier option, would be to add a delay between the sending of the tribute and its use by the ally. I could think for example of a delay of 40s for the first 100 resources + 10s for each additionnal 100 resources. The first delay can be seen as the travel time while the second is the time to prepare the resources for the tribute. And no new tribute (to the same ally) could be sent as long as the current one is not finished, so being warned when your tribute has arrived would be useful.

I may-be have misunderstood you, but because you are contradicting yourself. You say you like the way farms are now (so finite farms), but in the same sentence, you seem to support the way infinite sources work ? how should I understand it ? Then you say that having in mind to rebuild farms does not add anything to the game, which I fully agree. But then, how can you like the way it is now ? and futhermore, that's exactly what I proposed the AI to take care : managing automatically the rebuild of farms. So yes, I have still not understood what you meant, nor what are your propositions. Concerning agressivity, I do not see any in my previous post : to my knowledge, "Pollution" is not a nasty word ? it was meant to be direct, but not agressive. Otherwise, attribute it to my bad english practise. But I still support what I meant about out-of-subject contributions : look at the post "please read before posting" and I think that corresponds to what I said in my previous message.

I'm not complaining but proposing something. Secondly, your example goes just in my direction : sheeps need food to produce (more) food. That's fine. What I want is that (the future infinite) farms need wood to produce (more) food, and not that its food is free and unlimited once the farm is built. But it is impressive how people succeed to pollute the forums, without adding any useful information. So let's try to refocus this discussion : - most people (including me) think that infinite farms are needed; that's also the first point of the link given by zoot. - but there are different ways to implement infinite farms. - I've made a patch to make them automatically rebuild when exhausted, that patch I proposed here for people to test and discuss -> discussions with pro/cons about the other ways to implement such infinite farms are interesting points for this thread - In order to improve this patch, I've asked for infos or docs on how the gui works -> technical details or advices on it would be also very interesting for this thread Other discussions on sheeps or hunting or whatever, and their compared merits would be more appropriate in the "general discussion and idea" forum. I thought the goal of this one was technical points on development.

That's in practise equivalent to the patch I've attached. Farms cost 100 wood and produce 2000 food, and when exhausted, they rebuild themselves automatically, so cost another 100 wood and some construction time and then produce 2000 food, and this infinitely except if you run out of wood or if you are no more allowed to construct it (decrease of territory for example). I use it in my games in order to avoid the hassle of always rebuilding farms, and find it much more realistic than purely infinite farms. The construction time can be seen as the planting and the gathering period is the harvest.

Lion : What's your question ? I've not played AOK since years and do not remember how it works ? Pedro : I disagree on your second sentence : the interest of having different maps with different amount of resources is that you have to adapt to it, and find the best way to win with a limited amount of resources. Infinite resources is for me quite antinomic to strategy : the only thing which then matters is your mastering of control keys and your clicking speed. Futhermore, with bartering and trading, resources are never limited, but we should ensure that they are not too easy to accumulate. But I fully agree with your last sentence that we should avoid micro-management. But for that, infinite farms or auto-rebuilding farms are equivalent : you do not have to care about them. The advantage I see with auto-rebuildings farms is that it will cost some wood and some time, which is more realistic (i.e. no production during winter). Also, if your territory decreases a bit so that the farm becomes outside it, it won't rebuild. Mythos_Ruler : Sure, but you do not discuss the point of infinite farms compared to auto-rebuilding ones ?

Thanks zoot for the link. I didn't knew it. I agree completely to all what is there (specially the diminushing rate with additionnal farmers and its dependance on the terrain), but the first point "farm fields are infinite". This is quite vague : for the moment, 2000 food are produced with 100 wood. How is the infinite managed : - 100 wood for infinite food ? that's much too cheap - increase the cost of farms ? but they will then be too expensive for first phase of the game - automatically deduce 100 wood every 2000 food ? that's more or less what my patch does, except that it also accounts for a small maintenance stop of the farm (by requiring it to be rebuild). So my patch is equivalent to all farms being infinite with some cost and maintenance from time to time. The point I still want to improve is that now, all farms are infinite. But it may-be better to have the possibility to have some farms infinite, and some others not : in the first phase of the game, we won't have the choice of the terrain, but then when we expand and find a good location, we may want to have new farms and remove the old ones : of course, we may always destroy them, but it would be much nicer to then put them finite and let them be exhausted. To be able a set a farm finite or infinite by the gui when selecting it would be a solution.

As I was tired of always rebuilding the same farms (specially because usually you only notice that you are out of food when you urgently need some), I've made a patch to automatically rebuild the farms. For those who want to try it, I've attached it here (to be more precise, I speak about farms but this patch would apply to all resourceSuppliers which have a construction cost). But for the time being, I've made it so that these resourceSuppliers with construction cost have an automaticRebuild property set true. I think it would be nice to have it false by default and, when we select them, have a button to say if we want automaticRebuild or not. But I've no idea how this could be done. Any help or advice on this gui stuff would be much appreciated . farm.patch

ok then, compiling the different opinions on this thread, I hope we can reach a consensus if we link the fraction of gain going to the market and the bonus to international trade (for internal trade, we do not mind as both trader and market have the same owner). so let's take b this "international" bonus (which is 0.5 now). After a round trip, an internal trade will give a gain of 2 while an external trade will give 2*(1+ . We want that extra gain 2*b to be shared between the player and its ally, with proportions not necessarily equals. Let's call a the proportion taken by the player (i.e. the owner of the trader). We then want that the player gets 2+2*b*a and the ally gets 2*b*(1-a). with the patch I proposed, which gives part of the gain (when a trader arrives to a market) to the market (proportion f) and part to the trader (proportion 1-f), after a round trip, the player will have (1+ *(2-f) and the ally will have (1+ *f so it is enough to take for the proportion of gain going to the market f = 2*(1-a)*b/(1+ to have what we want. as an example, if we keep b=50% for the "international" bonus and want that a=60% of that bonus goes to the player, we should then take f=0.26. So I propose to modify the patch so that the quantities to be modified/tuned are a and b as they have a simple reading in the game, and f would be computed from them.

This in fact depends on the way the outcome of trade is computed. Looking at helpers/TraderGain.js, we see that it depends on the distance between markets, plus a 50% bonus when both markets are from a different civ. so for a given distance and a round-trip, we have presently (i.e. all income going to the trader) : 1 + 1 = 2 when trading inside our civ 1.5 + 1.5 = 3 when trading outside so a real push towards trading with allies, but the fact that the ally does not earn anything from this trade is not nice. with my patch (i.e. 1/3 for the trader and 2/3 for the market), we have 1 + 1 = 2 when trading inside our civ 1.5/3 + 1.5 = 2 when trading outside so we loose the bonification for external trade which is in fact gained by the ally which get 1.5*2/3 = 1 rewarding the ally was the goal of my patch. But I agree that loosing the bonus for external trade may also be seen as a problem (although helping its ally should already be a good motivation). having all the income to the market as was proposed by some people in this thread would even be worse in that respect 1 + 1 = 2 when trading inside our civ 0 + 1.5 = 1.5 when trading outside and the missing 1.5 given to the ally thus if we want to still favor external trade while keeping some part of its gain going to the ally, we should - either increase the bonus for external trade - or increase the trader share (but most people in this thread wanted to decrease it) - or change the way the trade is implemented going for example to trader=1/2 market=1/2 as I first proposed would give 1.5/2 + 1.5 = 2.25 for external trade and 0.75 for the ally increasing the bonus from 50% to 100% would give 2/3 + 2 = 2.66 for external trade and 1.33 going to the ally I've no preference, as long as the ally gets its part of the cake.

Yes, but in history, civs who were doing trade between two other civs brought wealth to their own civ (otherwise they would not do it ). But once again, the percentage to go to the trader can easily be modified in this patch if people think so.

In my first version, each market would receive 25% and the trader 50%. In the second version, both markets and the trader receive 33%. But I guess the exact percentage can be tuned later. The point now is to be sure that we agree this is the direction to go.

In fact, I do not agree that the market should have all the gains. The trader should be rewarded for his work :-) and the risks. But may-be 1/2-1/2 as I did was not the best. I've done a new patch with 1/3 for the trader and 2/3 for the market. But any-way, this percentage is a const variable which can be easily modified in my new version of the patch. I attach it here again as I do not know yet how to create tickets. I'll have a look at your link. mimo trader.patch