mimo

I agree with the fact that our tech tree is too much linear, and that we must open more choices for the player, and I miss a bit the pairs we had before A17. But as they had some drawbacks (the options of each players were constrained by its first choices), we should improve the way they worked. I had started a patch some time ago where I added some requirements in the pair template, such that the first chosen tech would have only its own requirements, while the second one would have its own requirements plus the extra requirements from the pair (such that it can require another phase, or additionnal techs, or ...). That would give a lot of possibilities for diversified tech trees. I could try to finalize it.

wraitii i guess everything depends on what we understand by micro, which is certainly subjective. For me, having only one global counter which tells me what amount of trade i can do, instead of having to manage it by market is not increasing micro. Then i should not have detailed the different ways of computing this regeneration because they have nothing to do with the idea, which is just having a global counter based on your economy which tells you how much trade you can do, and each trade you do takes a bit of this trade counter. All the rest is details of how we want to implement it, and I only quoted some possibilities. But still in the cases i mentionned, having to choose to build more champions which are better for fighting but could decrease your trade capacity, or rather produce some citizen, which can improve this trade capacity but are weaker, is not micro, but strategy. And if I mentionned it, it is simply as an example to show that we can keep the choice between champions and citizen up to the end of the game even if the gathering has a very small impact on the economy, while now, as soon as trade is dominant, we are better with just building champions.

While I fully agree that we need some limition on the number of traders, I've the impression that the proposed way will lead to too much micro, going too much towards a Caesar-style game, and probably also to a proliferation of markets. Futhermore, there is a lack of consistency: why would market resources be per market, while all others are global (for example resources collected at a dropsite are global). I would then modify your proposition to make it much simpler and more in the spirit of the current game: keep the trade basically as it is now, but add a TradeCapacity which would be global to the player (not per market) and would reflect the economy level of the player. Then each trader starting a travel would substract a fixed amount of tradingCapacity, and when not enough tradingCapacity, the trader would have to wait for it to regenerate before starting its route. Then to regenerate this tradingCapacity, some structures can be a TradeTrickle. Civcenter, markets and docks are obvious candidates, but we may also have smaller contributions from farmstead, storehouses and maybe others. We could even envisage that some structures have a negative regeneration, to reflect the fact that they are a burden to the economy (fortresses could be of this kind). If we want to favor more diversified armies in endgame and not only champions, we may even have the amount of workers as part of the tradingCapacity regeneration, while the number of non-workers (champions) would have a negative contribution. Finally, while this proposition put less emphasis on the number of markets, we may still have some kind of market or dock proliferation if their TradeTrickle are high enough, and in that case a limitation of the number of markets and docks per civcenter could be needed.

You can already use waypoints when defining the trade route, i.e. click on the first market, then shift-click on the several points you need to define the route, and then on the second market.

Yes, the ai should scan available templates to make its choice based on the gatherRate-cost stats. Not too difficult to implement as there is already something analoguous done for the choice of fighting units based on their strength-cost. Something to implement for a20. In the meantime, i can put another default when no female template is found. Do you have a replacement template in your mod ? or are your only relying on CitizenSoldier for economics ?

fixed in r17165, thanks for reporting.

nearly the revision version is missing !

done, thanks for reporting.

These crashes should be fixed with r17108.

Now that we have a visual replay easily available, it would help if everybody could do some basic checks - edit the commands.txt and add one or two empty turns (just to be sure that if not reproducible, the game would continue after the crash) - run in the visual replay to confirm that the crash is reproducible and if you have a debugger at your disposal, do this second step in the debugger to see where it crashes Such info would relieve the devs from these time consummings tasks. but i suspect this is connected to http://trac.wildfiregames.com/ticket/3466 which should then be promoted to a release blocker.

I also attach a very short commands.txt showing some problems: a bunch a cav is ordered to move to a given point, and the order succeeded only after the cavs made a lot of back-and-forth moves. In this small test (200 turns), I had to order them to move 3 times for the order to succeed. If we remove by hand the 2nd and 3rd move order from the commands.txt, the group of cavs is blocked at the first obstacle met, and strange enough, one of them stay in FORMATIONMEMBER.WALKING. while all others are in IDLE state. commands.txt

it depends on your OS see http://trac.wildfiregames.com/wiki/GameDataPaths in the config dir

but have you removed your old matchsettings.json file in your config dir before putting it back to true ?

Yes, let's discuss it in http://wildfiregames.com/forum/index.php?showtopic=20058

Strange as it seems broken only for a few users. Do you have the persistGameSettings option enabled ? if yes, can you try removing your old matchsettings.json file in the config dir (we should add a clear previous settings button!). And otherwise, what's your OS ?

If the poor AI was more than one week ago, it may be because of the bad behaviour of the pathFinder we had at that time. A lot of its units were blocked, penalizing its performance. With recent patches from Itms, pathFinding has improved. That could explain what you see, because otherwise, the latest changes in the AI were only minor tweaks and cannot have such an effect.

Strange, there should be no such changes in the AI (except if skynet has taken power on your pc). But can you be more explicit, what is the last svn revision where you did not have these changes ? what is your present svn revision ? are you sure you have no personnal changes (making a svn revert would help). Is it on all maps, or a specific one ?

The saved game was useful: the problem was due to a unit which was cheering while its ownership changed, and that case was not taken into account in UnitAI. In addition, the case of garrisoned units was in principle taken into account, but wrongly. Both cases are fixed in http://trac.wildfiregames.com/changeset/16908 Thanks for reporting the issue.

Thanks for making the test. Still I do not understand how units can be in such state INDIVIDUAL. But checking the code, there was an inconsistency in UnitAI.js which should be fixed with the attached patch. May-be that will solve the issue ? could you test it. And if it does not fix it, it would be nice if you could save a game just a few seconds before the end and upload it here so that I can have a look. unitai.patch

ah, that's important information which would have been useful in the first report, don't you think so. But still, I don't know how to reproduce it. It seems that it needs a lot of conditions: that you attack a AI structure with garrisoned units, and then you loose so that your units pass to gaia owner and one of them is in a state not expected ! As you say that you can reproduce it, could you either save the game just a few seconds before loosing and upload it here or run with the attach patch and let me know what are the warnings printed. gameboy.patch

And as usual, that's not the right file. This one creates no warnings.

As usual, there is nothing we can do without the commands.txt file

Thanks for the error report, it has already been fixed some time ago on svn, see http://wildfiregames.com/forum/index.php?showtopic=19918

Fixed in r16816 (of course not for previously saved games).

I had once the same errors as the one you quote, but only when loading a saved game. Is this what you are trying to do ? if yes, that's presently broken, so no need to report such errors.