alre

why do you say that?

well...

Nevertheless, I hope the game is never made too stressful for less aggressive player, many beginners are like this, before they start to realise the fun of aggressive play. Just a gentle reminder that turtling is a legitimate strategy.

look at bongui mod. they changed that panel quite a lot, for the better I think.

There has been discussion, but without reaching an agreement on how to procede. computation burden is an issue. @wraitii is the sole dev who's worked on it. blobs will be practically the same in A26, changes are minimal. I believe they move a bit better thanks to newly introduced pushing friction, but they seem to me more or less as dense as before. I couldn't manage to get better results by changing pathfinder.xml alone. I think the number 300 came out at some point when there was the feeling that more was better, that people wanted big battles, and that 300 was a number the engine could bear with, at least in a 1v1 setting. Personally, I enjoy much more 100/150 max pop settings. From my MP perspective, A25 is only better at lower max pop.

I just verified that if you select units from different civs controlled by the same player the icons duplication doesn't happen. However, it seems that some civ-specific buildings can leak to the available list with the civ-specific units. this is avoidable because it doesn't happen with mercenaries.

not really, if you can get a messy UI by having a messy selection, that's fine. users understand. as long as it doesn't crash, it's ok. this is a good point. I didn't expect that what units buildings can train depends on the civ, but what buildings units can build does not. that wasn't how it worked in my mind, I thought available buildings depended on the civ.

tu quoque @wowgetoffyourcellphone

that's just a fancy way of saying he doesn't want to handle it, and he's not. you are so overcomplicating this! - when you conquer a new building you didn't have access before, you can train new units you didn't have access to before. immediately self explanatory. - units trained from captured buildings are the same as if you controlled those buildings as their own civ. no need to change anything, not the appearance, not the stats. - you don't have to train units you don't want to anyway, if you conquered an enemy building you are probably winning regardless. - if new units changed the set of structures you can build, that would be actually confusing. luckily, noone asked for that. - there are no edge cases at all, all building produce exactly the same units regardless of the owner civ, period. can't be simpler than that. - the ui can possibly get messy, but that can already happen if you select a ridiculous amount of different buildings of the same civ. just don't select a ridiculous amount of different buildings and you'll be ok. the ui can handle up to 4 rows full of trainable units icons. we get that you dislike the proposal, but you are speaking out of turn. it's ok if you personally prefer the current status, but don't twist a new proposal to create strawman arguments and drown us in words, rather ask if you don't understand something. in a25, carth merc cav was arguably the unit that was most characteristic of that civ playstyle, and other players could and can train it if they manage to conquer the building that trains it. you guessed it: it really created some LOL moments to me. by the way, I don't think there are any gameplay downsides to this feature, and I don't see any problem for extending it to all kinds of units.

.

the game, sadly, doesn't have a gameplay manager (Stan's words)

the latter.

both. just make that a building trains whatever unit it's supposed to train regardless of its owner civ. it's cool and it's simple.

I don't think there's any problem here, have you been accused of anything? making more info avaiable is only good. also rated team games would be wonderful.

how so? BAR is still like this, isn't it?

you wouldn't

para hacer eso necesitas un mínimo de familiaridad con las estructuras del software. puedes crear una mod tuya que cambia el valor de la resistencia de los arietes, no es difícil. busca como funcionan las mods que cambian las unidades.

I think the problem is that, if one wanted to follow history strictly, gastraphetes should probably not even exist as independent units, they should just be actors that shoot bolts from walls and siegeworks, because they were never ever employed in the field.

they weren't questions. anyway, in certain real play situations, experienced armies are already very strong as is.

taking good fights and avoiding losses is already rewarded, you don't need to over-reward, that's called snowballing. you'd better just give the victory to whoever takes the edge first at that point. besides, you didn't answer to borg concern at all.

very nice. elephants are not countered by swords though, quite the contrary: ranged damage is best against them.

that would be easy, if you only count ranked. the discord bot records all the lobby chat, which includes all the rating bot messages, which in turn includes all the nicknames that play a ranked game. second accountd ofc would be recorded as separate players.

I wpuld drop the script, too much work. I don't know if it's currently possible to have gameplay information written in the units' info, but I think it should be. at that point it's only a matter of writing them and maintaining them. with fabricator patches I guess.

my ideal would be: - rams are cheaper - rams can be built on the battlefield - rams are much slower - rams are fairly easy to counter with any melee/short range assault this could or could not be integrated with @Darkcity's proposals. I think rethinking the pierce/hack differentiation would help with that, but I guess it's not necessary if they are convertible like Darkcity proposes.

every now and then someone cames up with this concern. it's funny because currently rams are quite out of the meta actually. the problem, I think, resides in the unintuitive counter system based on the pierce/hack differentiation. noone seems interested in rediscussing it though, because of the "small incremental changes" line of action.