hyperion

I don't remember having seen the term in-game, correct me if I'm wrong. Citizen as class is also used for woman. As such the purpose of this change is to rename assets and create more mayhem than a24 did?

For contributors it's important to know upfront what is desired / the target before doing anything. The political part needs to be addressed anyway, the work only if 64-bit is desired and depending on what is desired the work may even change. I don't claim that it's as easy as a compile switch, but I'm sure a 64 bit build is far from an insurmountable obstacle, just a couple hours of work at most.

This is a somewhat ridiculous approach, better just to check https://feedback.wildfiregames.com/results/os/

I don't see any technical issues. As the code is 64 bit safe on other systems there is really not much to worry here. The issue is mostly a political one. Should one offer both or replace the 32-bit one with a 64-bit? What to do with the autobuild? Should there even be an autobuild in the main repo?

Offer a 64bit build? AFAIK Microsoft stopped shipping 32 bit versions of Windows. Moderation: Thread split out from https://wildfiregames.com/forum/topic/45178-a25-svn-version-25810-not-playable

@wraitii , indeed versions are not game changing, however, don't underestimate the importance of it for communication. When bumping the ebuild locally for the rc the first thing I had to do was to come up with a version that can be parsed and sorted properly by the package manager. So assume other packagers have the same issue and so we end up with every other distro having a slightly different version from upstream and from each other for the same release. Also there are crawlers maintained by distros or third parties checking if new releases are available and automatically inform maintainers or users. So instead of trying to inform all downstreams or get all those crawlers to implement custom parsing rules for wfg using a standard version scheme is much cheaper. As for the wiki page, much better now. @Yekaterina, A25 translated to a version in the most natural way would be 1.0.0_alpha25, while 0.0.25_alpha implies 0.0.25_alpha1. So basically 0ad has a tradition of alpha1 with different patch version. One important feature of versions numbers is you can sort them, so how does that work if you replace them with names like Kush Archers Pathfinder? Any version below 1.0.0 already has the connotation of what you expect of alpha above, and even version past 1.0.0 don't prevent new changes either.

I don't want to nag, just point out few things that might help improve the release process in the future. Take it or leave it. As you said alpha of alpha is bad, the rc just released going by file name is actually an alpha of an rc and not the rc of an alpha, so rethinking the version scheme should be done before a26. Looking at the commits after FF you could pretty much do away with it. Just CC would be fine, forcing people to commit early. The terminology used is rather custom and I wouldn't be surprised if I asked all devs separately I'd get different answers, might be worth it to clean up the terms or cleanly define them. The timeline given on the release process page is laughable. As for branches, yes they suck with svn compared to cvs, not even talking about git.

At a glance It isn't obvious to me what the objective is or what balance and garrison are about, move vs attack etc. A help button popping up some sort of manual would be nice.

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. Well, string freeze is the moment I'd send an email to translators asking them if they could take out some time out of their schedule. As this may take a few hours giving sufficient time seems a matter of courtesy. Could it be the reason tweaks might be necessary is deciding on a release name late and misspelling it trice? The test bundles are the same as releases in terms of packaging I presume. So what you call them doesn't really matter for the sake of testing, though giving them a proper label can only help. 0ad version scheme is a bit messed up as rc comes after alpha after all. Using a traditional version scheme the next release should be 0.25.0 instead so you could use the version suffixes more naturally. What I don't get is why you'd not want as many testers as possible, i.e releasing it into the wild. This doesn't make sense to me whatsoever. Commits are actually not permitted later, unless for exceptional circumstances, such as fixing a release blocker issue. Commit freeze if taken literally is tagging the release. Feature freeze is what I'd expect to be the the border between normal commits and commits to fix release blockers only. If FF means you can still commit anything that isn't strictly a feature like rewriting the engine you are bound to be in a mess. This could well mean content and gameplay changes will be done till the last minute putting a lot of burden on those responsible for communication and media. If indeed CF has that meaning then the release should be at least 2 weeks after, better even later, though you don't have to go as far as the kernel with 8 weeks.

String freeze means translators can now work without worry of it being invalid the next day. So working on it prior is mostly pointless unless there isn't a somewhat mature translation already. To give translators a fair chance to translate give them 14 days between string freeze and translation freeze. RC1 is the first time you can reasonably ask people to test, be it players or packagers. What's with the controlled environment? The purpose of an RC is to release it into the wild What is commit freeze when commits obviously are still permitted later?

You should be well aware https://trac.wildfiregames.com/ticket/6085#comment:2

Now I see what you are up to. However this is a marginal improvement as you still need all those values to compare the units and the "hint" might actually be misleading. I don't mind negative armour (room example above), but then I don't mind an elephant building houses either. The real issue with changing HP is screwing over the current healing rates. Tripple HP meant it takes trice as long to get HP back to full. Same for building and repairing. Imagine needing 30 minutes to repair a ram due to current 50 pierce converted to HP. As for what is shown, well that can be changed

This logic only works if the unit has same resistance for all damage types and if there are no hard counters either. So you could give all units 100 HP for 100% healthy instead.

The amount of damage take seems to be 0.9^A, where A is the armor value. If it is indeed that exact formula, then negative values won´t be a problem. The issue is more of the sort: In a room you have two people, three leave, later two join, now you have a single person in the room ...

It's rare around here that someone actually wants to understand what he is about to change and whether it's a good thing before committing to it. Asking if in doubt is never wrong, though you might not get a decent answer. Finding the commit might be difficult, renames for aesthetics, commit messages like "fix" or "update", etc. Even if you find the commit you might end up with a link to the discussion returning "sorry, insufficient permission"... Why not 0? There are possibly technical reasons, like division by 0 or simply 0 having a special meaning like invulnerable. Should be easy to figure out though. Then there are design reasons. If you set resistance to 0 at the start you will only be able to adjust it into one direction unless you want to utterly confuse people by allowing negative resistance. Then if you want to change it now without affecting the "balance", you have to either change hit points or damage values. Hit points are mostly neat values so you might not want to change them. Alternatively you can reduce all resistance values by 1 and adjust damage across all units which might be not that great either. If just setting them to 0 you have to think about if the change affects the gameplay in a desirable or at least acceptable way.

It's not new, already in A24, just less visible there. Actually that you only now noticed it means it's an improvement UI wise. If you want options for gui layout not even 100 would be enough. Better just think of the corresponding xml as the config file.

And / or reduce gathering rates. As some people complain EA to be to be to spamy reducing gathering rates is probably better.

@wraitii I also thought about it a bit more and while there are cases that aren't that hard to handle they all need additional data beside a type specifier. Even if implementing them one probably still wants a pass par tout boolean to bypass the compat check. checksum_compatible might be a bit of an unlucky name though, checksums are also referred to as hashes. Also a user or first time modder will ask himself what it refers to. Maybe call the boolean skip_mod_compatibility_check instead.

The most fitting ones are where you reenact historic military campaigns of the 0ad heros. But if you want to send a centurion with his man on an odyssey to go save the princess from the evil dragon that's fine as well (finally a use for the dragon ). As for difficulty, make it so it's fun for you first and foremost.

Gather rates are high compared to carry capacity, making shuttling more important in 0ad than most other games I'm aware of. If you want to reduce importance of shuttling you have to make units spend more time gathering instead of walking, not the other way around. I think it was AoE III that does away with shuttling altogether.

If you want the json formatted for a specific tool I'd say make it a mod, unless there is just one such tool or one which basically defines a standard. Otherwise the json should be what makes most sense for 0ad. That format could also be used as a replacement for the current ini-style hotkey configuration which might be desirable anyway, so you can map a user facing string to the key value pair for instance. Then a script to convert it to different tools could be added.

checksum_compatible is probably insufficient. Make it map_pack, campaign, ui, extra_civ. Not saying this list is complete or the naming or even grouping to be good. The point is there should be a tag for each case you might want to handle separately in future instead of an "ignore mod compatibility" flag. That's obvious and nothing wrong with it at all. Though giving it a cursory glance whether the modder got it right or not when approving the mod for mod.io wouldn't hurt.

I already forgotten Sepultura, but the mention and your remark made me remember one of my favourite albums 20+ years ago

Those people have forgotten that there were releases where rushing was far to strong. Then everyone cried nerf rushing. After plenty assorted changes without touching the CS concept we are now at a point were people complain about the reverse. Also unit pushing which I think is part of A25 will have a major impact on the balance of this, so any discussion based on A24 I consider pointless. Basically if balance is completely outside reason after feature freeze do a hot fix adjusting the parameters that were used in the past to nerf rushing, else just leave it as is for now.

You can edit the map. Guess he just wants a map filter so random selection can be used (inferred from "when it happens I quit")