wraitii

This is mentioned in the very first post in this thread. I don't really like it, but I also don't think it's a very realistic situation outside of toy examples. I also don't expect it to be a particular balancing problem, but maybe I'm incorrect on that account. The 'pushing distance' can easily be modified by changing pathfinder.xml if you want to test out other settings.

See also the discussion at https://code.wildfiregames.com/D3686

Committed, thanks for reporting all

Should be fixed by https://code.wildfiregames.com/D4066 if someone else can confirm

Mh, yes, this is working as designed actually. I figured it was better to show cheats are always enabled than to not show it at all like in A24. I can either hide it again, or make it configurable.

Can you upload you matchsettings.json in the user config folder? Then delete it, that will fix the problem.

Mh, given the wide range of options we have, this does seem like something I'd be open to. Think elexis was a bit too strict there.

Thanks @Nobbi, very insightful comment Right. The latter has a patch for it, not the former. You can no longer train horses at the barracks, so I think we should just change the barracks here, for consistency. The decay is on purpose, though whether it should be changed is an open question. Not sure what you mean about train time. Yes Made a ticket for that, it's less trivial than other things. You are indeed incorrect, there are no other bonuses in A24/25 (so far) Mmh, that sounds like a bug indeed. I don't necessarily disagree, but I think removing towers was a good move and we don't really have more than 3 town-phase buildings as things stand, so it's simply not possible.

I largely disagree. While translation freeze means it's completely fair game, the chances that we do major change after feature freeze are low, and as it turned out for A24, translators usually have quite a bit of work to do anyways. And if tweaks are made, they'll usually be small tweaks that Transifex helps with fixing. Packagers, aye, players, maybe, but 'testers', certainly not. After all, people play SVN. Well, the first few bundles won't be RC but testing bundles, as per the above, so it's logical to not release it 'into the wild' too much. Commits are actually not permitted later, unless for exceptional circumstances, such as fixing a release blocker issue.

Check out a tutorial online, like this one.

Mh, that seems rather weird. I would suggest trying to get a more complete callstack by running in a debugger.

If there is a specific topic for A25, please start a thread in the balancing discussions subform or make a diff.

I think these are all things that would be "too much", from the unitAI standpoint. Players are still supposed to play the game That being said, I think we could have a higher level AI-assistant (that would be an actual AI in coop) for these kind of things in the (probably far) future

You should be able to play over local MP, but not over the lobby unless you can configure something known as "NAT loopback/hairpinning" in your router. This should indeed be fixed in the next version.

@ValihrAntcould you make a diff with the training times? I think we're missing that on Phabricator and A25 will be closing soon. Should we merge the 'remove root from fortress' patch as well, in your opinion?

The concrete difference is that you can't edit scenario settings, while you can edit some skirmish settings (mostly the civilisations). This could be changed if/when we allow 'freezing' the civs in the gameosetup, which wouldn't be too difficult. Edit -> but we also have "random maps" that are only partly procedural now, with fixed terrain, the the distinction has grown increasingly confusing. I wouldn't be against cleaning all that up sometimes soon, particularly since the whole concept of "map type" is annoying in the code.

You might need a few changes, as some templates were renamed (things like the elephant stable), but overall A24 and A25 maps should be compatible I believe.

Correct, which is where Armour comes in: it modifies that base HP to make the unit more/less damageable against other types. Which is why negative values make sense. Yes, but that seems less obvious because we show HP and not armour.

It actually does not. Compare: 200 HP, armour of 10 everywhere > you can take 200 / 0.9^10 => 573 HP of damage before dying 573 HP, armour of 0 => 573 HP of damage before dying. It's much easier to compare units if they all have a base armour of '0' and HP variations than if they have both.

Agreed, it's a reasonable take. However, the current way ratings work waits for a message from all players until it actually rates the game (to avoid one user cheating, obviously). This means it can't rate a game where one user disconnects. Changing that without making it possible to cheat is not so easy.

large-address-aware is used by default in releases and in the auto build, but not when compiling on your own. It's a flag to enable using more RAM than the default 32-bit limit on Windows, which iIrc is 2GB ?

I fear the reason is a lot more human than you think: there was no "0 armour" anywhere, and so when standardising (mostly @Nescio's work) we still didn't use 0. I actually commented that somewhere on some diff, and I think it's agreed that we should probably use 0 armour. It's basically a series of unfortunate mistakes. Armour is an 'HP modifier', and to make things simple we should have a base HP and then sometimes positive/negative armour on top, but that's not really the system we have (e.g. champions have more armour than Citizen soldier, but that doesn't make sense, they should have more HP instead). --- edit: I'll point out that 0 A.D.'s used of 'exponential armour' is unique as far as I know. It is indeed very convenient: there is really no 'start' point, so you can have -10 or 30 armour and it works the same: 1 point difference is worth about 10% more/less HP. This property _is_ what makes it possible to use HP efficiently, but we still didn't

Yes that's essentially my conclusion as well. I was actually struggling with the name quite a bit, skip_mod_compatibility_check seems a good proposition to me, thanks

I have some project for a tutorial campaign (see that thread), but so far haven't uploaded anything actually concrete. I can make it available on GitHub if you'd like. -- As for campaigns itself, yes you just make a Json like the tutorial 'campaign' and then load scenarios. You don't necessarily need to bother much with triggers.

I thought of that a bit and think those would be 'tags' for the users to look at, not really for the engine. Sure, this would help narrow down the compatibility, but at the end of the day I don't think we'd ever have a perfect system, and it seems like it would mostly complicate things. Which is why I went with this boolean "this does [not] change checksums". And yeah obviously we'd need to check the mods that we approve for signing, but that's not the only way people share mods.