hyperion

BSOD is always a system issue, so OS/drivers/hardware.

The Mauryans acclaimed as über OP don't sport pikes. Isn't it great other civs have something in their favour? --- For gameplay purpose we want a tank with little damage and high defence (aka. OP unit of the week). Once we settle what stats that tank should have it's time to find a representation which is historically and realistically at least somewhat plausible. If everyone thinks a pikeman is a misfit for this role, propose another skin. Not the other way around.

Na, what I don't like is storing binary artefacts in a repo and only providing the last step in a proper manner, instead how it's done for mac is how I see it should be for Windows too. Building from ground up in Windows strikes me as more difficult than cross-compiling for me. Some tricks were required but It was rather straight forward until I ran into rust. Never expected that bootstrapping a rust cross-compiler targeting Windows would be such a headache. I only expected 0ad itself to need quite some work to allow for cross-compilation which would be worthwhile irrespective of a potential win64 build.

As I don't like this approach I created a cross root to build a static 64-bit pyrogenesis.exe. Well, I got all dependencies cross-compiled with only sm and fcollada missing. Got stuck at building a rust cross std lib, guess will take a while until I have time and energy to get back to it.

Most slaves were the children of slaves and not some criminals. Thou sending criminals into mines sounds plausible.

Visible and invisible classes are the same internally. So nothing would "break". Why make it visible? So you can refer to it in descriptions. E.g this building can be garrisoned by Citizen. So it is visible because it is in use in UI texts and needs to remain visible. Sure it can be renamed but must be a name that isn't used already. As such Worker is not an option. Let's say you find an appropriate name for this class. Dependent text and code must be fixed (bearable). This still leaves the use of the term citizen-soldier in code and templates (variable/function/file names). If you even fix the latter even more dependent stuff needs fixing, possibly breaking quite some mods out there. Even if you fix any references in the source tree, the term will remain in the heads of people after being used for decades. There are also all sort references to the term all over the place (wiki, forum, youtube, twitter ....) where most can't be changed any longer. So I get your point and a better name might have been chosen once upon the time but I doubt you will find a dev willing to do all that work now and take the blame for the fallout.

Classes are meant to allow certain technologies, effects, aurae, selection to be performed on a group of entities. 0ad "Classes" and historical social classes have nothing in common at all. So slaves as a unit type could and probably should also get the Class Citizen. While the Class name Citizen isn't perfect it's not half as distorting history as depicting slaves as miners. The CEO of a global consortium like Nestle might have been a slave in Rome while the beggar living under the bridge would have been a freeman. Anyway changing the Class name Citizen wouldn't improve historical accuracy as it has technically nothing to do with history in the first place. On the other hand it causes major issues. The suggestion to only rename it on the surface increase complexity for maintainers and new contributors alike and should be considered code rot. The opinion that it's easy and doesn't come at a major cost and just has to be done right won't ever be uttered by a seasoned developer either.

So in your opinion dropping 32-bit build before 2023 is undesirable (sounds reasonable) which makes a straight replacement impossible for now. So how should a 64-bit build be handled?

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.