alre

I still miss how you could train everything in one building in a23, most definitely not going to enjoy this if merged.

I liked the closed box better. but with even line width.

great work @maroder on this triky task .

gates logic could indeed be better. I suggest that instead of having them either 'blocked' or 'unblocked', which is clunky and inconvenient, you could have them 'always open', 'always closed', 'open for all allied units' and 'closed for all enemy units'. the difference between the last two would be that when you have both enemy and allies next to the gate, it would stay open with the first instruction, and closed otherwise. this second setting should be the default.

corrals have some competitve use. in a24 they had quite some more, because matches lasted longer.

we just played a ffa game with that mod. there are still bugs: ranged cav can't hunt, also because of building ai, units fire while moving, but without showing up. ranged cav is op in that mod, iber fire cav passes trough armies and it's insta-kill, they don't even need to stop to tear down buindings. that part needs to be fixed for sure.

I did a fully recursive update (can't find this checkout option) and it still can't find that file.

It' s just missing, apparently. It doesn't appear to be deleted, and updating the repo won't download it. it seems like tortoisesvn is totally unaware of the file. I don't know what make clean is.

yes

I can't compile because I seem to be missing the file 'glad/gl.h', required by most projects.

when it came to melee, persians did actually rely on hoplites more than on their own, at least from some point onward. it would feel weird if a persian player relied on melee on the first place. if it did, it would make total sense for him/her to use greek mercs.

why wouldn't you want persians to spam merc hoplites? btw they need not to be ionians, mercenaries came to persia from all greece, and identified as greek.

the problem with hindsight is that it always work, even when it shouldn't. you can make everything out of hindsight, depending on your own biases. Truth is, gameplay changed enourmously from A24 to A25 too, in a large variety of ways. But I agree of course that small changes are more predictable, that was kind of my point too.

it's only going to be useful if the team uses it.

ok, cool. could be called "philosophy" as well. not sure a cost reduction is a good idea, I don't think team bonuses should be that impactful on strategic plans, but a significant time reduction could be a noticeable buff to phase rushing teammates.

we can talk for days about what the balancing team should do or should enjoy doing, but we have seen already in the past what it was capable of doing. it didn't prevent A24 "debacle" and it couldn't predict much of what would happen in A25. it was just luck deciding that A25 has been received so much better than A24. you do an other alpha with the same premises, and you are rolling the dice once again.

team bonuses have a name and a description providing historical contest. what would that be here?

I see, it looks like we should best just follow Kate's suggestion then. Game's not great, but is good, better to keep it that way than spoiling it.

lol which are these wonderful new features that aren't being implemented because there aren't enough balance testers? this is all just debate over ideology and taste. how is that a slippery slope?

more difficult yes, impossible not, in any case it will be some added work to make the merge, but it will be worth it for the accelerated balancing and testing. It wouldn't be the host, it would be mod.io or maybe the lobby server itself, we are not talking big files anyway, a single web page is heavier.

but diffs can also be created using git right? I don't really know svn but if it's supposed to be better than git for binary files, here we are talking about xml essentially. this is how I envisioned the process: - A26 comes out, then the main dev team goes on with svn. - gameplay rebalances get worked on on a different git project, from a different team (it needs not, of course, to be separeted from the original team, but it needs neither to be the same) - every time the game access the lobby, it checks for updates - if the balance update is out, a message pops up asking if the player wants to update the game, and if the answer is yes, ideally, the update gets downloaded and installed automatically as a mod on top of A26, I don't see it being more than a few kb heavy - some time before A27 comes out, the balance update is copy-pasted into a git branch created before moving on from A26, than the branch is merged into the latest development version and the diff is created (if I remember well there is such a git repo updated together with svn)

what's the problem with branches?

THANKS!

I agree on this plan for reworking civs one by one, this is my vision as well. I think all these good intentions could get into the game easier if there was a shorter term balancing calendar of the game, independent on the engine upgrades and the main releases.

May I say that, while there certainly is a conservative faction within the multiplayer community, it doesn't represent all of it. Liking to play against peers doesn't involve disliking the game to change. Balance is important for MP, buy one may disagree on how to pursue it.