hyperion

I checked the listed bugs based on the above and with my limited knowledge of 0ad development I see the following. Mac display and keylogger issue can be fixed by simply updating sdl which is a nobrainer and a must do anyway. The only question if users of old mac os need to build from source on their own or whether to provide some ld_preload equivalent wrapper so one package can suffice or whether to provide two separate packages. For BSD there are couple of patches probably by the maintainer of the 0ad port. The trivial bits should be merged and stuff you aren't sure about without some research can remain part of the port for now. As for Linux the only obvious issue is the dependency on python2 which is against packaging policy due to it being EOL. From a quick glance python is only used for unit tests and maintenance tools as in server side components. So basically it's just dependency for running the tests and as such can be overlooked by a packager short term. The Ryzen issue seems understood and patches are available even if you have to call them hacks. Most importantly none of them are regressions. A broken a24 is still better than a broken a23. The most glaring issue of all is no release in 2 years and not the quality thereof.

Just checked my a23 public.zip and there it's <SpecificName>Cassivellaunus</SpecificName> while it's changed in svn to <SpecificName>Cassiuellaunos</SpecificName>. So maybe you have both installed (or leftover artefacts) and somehow this results in this unexpected behaviour? What is your locale set to? One of pl, nl, cs?

So Cassiuellaunos is the source string and with your language settings the displayed string is Cassivellaunus. Just change the source string should what you want, meaning the string can't be translated any-more and should be displayed as-is

Add some metadata to mods describing their changes for example if an analytical approach is to tricky so a less conservative model can be devised. Just because a mod may change others doesn't mean they do. I mean if I add a mod with some maps nothing changes unless I play those maps. So such a mod should not prevent me from replaying a match played with those maps missing.

Well, mods that don't change the simulation can be said to be compatible (simplified) and there is no need to enforce all participants to have the same set/order of installed/loaded mods to be able to play with each other. There was more than one occasion were I wanted to pull my hair because I couldn't even run a replay of a match because of a "wrong order of mod" or similar error message when there shouldn't have been an issue in the first place. Hence a more fine grained mod compatibility model should be devised or refusing to sign mods which "hide" could be considered a regression as far as I understand.

Isn't the reason for "hiding" the mod not about wanting to get an "unfair" advantage but because of the "broken" mod compatibility check? Will a24 address this issue with a finer grained mod compatibility model?

If we ignore aerodynamics and if I didn't screw up my math "<range> = <speed>2 * sin(2 * elevation) / <gravity>" for even terrain. I wonder how this whole arced trajectories can be reasonably done so the unit animations matches the required elevations.

Yeah, production mixes units and buildings, the idea is to have an overview of what a player is investing in. Could possibly be changed and configured later. Tech mixing in progress and finished is intended as well. Researching can also be considered investing... It still boils down to the current split only making partial sense. Maybe allow 3 rows per player via hotkey as there is enough vertical space for it in 1v1 games. Unfortunately there's not much to be done on that end, it stores each turn gathered res in a buffer of 25 turns (~ 12.5s) then do a delta from last to first, I suppose I could do a moving average too but I want the changes to be at least a bit responsive. Any ideas would be welcome. So you are already using a moving average, just that most workers won't complete a gathering cycle in 25 turns, so maybe 40-50 turns would be better, hard to say. Getting even better results gets complicated fast, so the current approach might be just good enough. Also updating the displayed number every 0.5s is to fast for comfortably reading it, maybe every second turn instead would be better and help alleviate the feeling of to jumpy. Can you elaborate? I'm not sure I understand Probably the line should read "K/D: 15.6 [78 (13700) / 5 (1950)]" or similar instead as only the single value 15.6 is usually associated with kd, well really a minor issue thou.

A few comments after a short test: * strange behaviour of space + [q,w,e] -> maybe just use to switch between modes (tabs?) instead. * bogus spilt of modes: production mixes units and buildings, while units have their own mode buildings/structures do not. Finally tech mixes available and in progress. -> maybe have modes units, structures, and techs and all with the current techs behaviour. * gain per sec stats are to "jumpy" -> maybe replace function or make it configurable. * gain per sec stats also ignore loot. * KD -> maybe reverse order of actual KD and calculation thereof, seems more natural. * KD values in parenthesis only sometimes match with Res. Killed/Res. Lost -> bug? / other meaning, why duplication if not. Anyway, overall a useful and visually pleasing mod, so thanks for your work.

Balancing civs is trivial, just have a unit type, let's say jav cav, be OP enough and make it available to all civs and you are done. The above is a solution but it goes to show that balancing civs may well be undesirable or far from the only goal. So when is balancing even relevant and who is even qualified to talk about imbalance. Just recently I saw a match-up on yt where a much better player beat a weaker player and the conclusion of the commenter was civ a stronger than b. In my opinion the game would have ended the same even if you doubled the gathering rate of b by a factor of two and reduced build and train time by half. Except for pro players which can constantly play a good game a good run vs bad run is far more relevant than whether civs are balanced or not. I mean what's the point in talking about balance when you struggle to even reach pop cap 25 minutes into a sandbox game? So let's assume we have two players both able to reach 300 pop in well less than 20 minutes, one knows to dance the other not. Balancing civs is still irrelevant. My point is unless you are one of the few who know to use and abuse the game at it's limit you shouldn't care. What do those 2 or 3 dozen players which can be counted as pro players need for the game to be interesting for them as well? A few none identical civs which each supports multiple strategies at roughly the same level will do just fine. If for a release a certain civ is considered game breaking just ban the civ by convention from rated games or tournament rules and be done with. For rated games enforcing mirror match-ups on balanced maps might be another way. Going back to the original topic, why force tiers in the first place? If we check the earlier linked video those tiers appear naturally. So the act of introducing official tears with support in the code can be considered an act of over-engineering. The release cycle is also a reason why you guys face such pressure regarding balancing. If it goes wrong it will be wrong for the next 2 years or so. Let me delve a little into what I consider wrong about the release policy as it may be called. Alpha means it builds and runs for the most part. Basically what trunc should be at any point. Just any snapshot after minimal testing is worthy the label alpha. In my opinion a reasonable version scheme would be a major of 0 to indicate the intent of further enhancing the engine and getting rid of some major issues. Then the minor for the next release would be 24 and patch level 0. So the next release would be 0.24.0. There can be an alpha/beta release thereof. If so feature freeze trunc and publish the binaries and source release and give user and packagers time of like 2 weeks to report release blockers. If appropriate tag the release and create a release branch. Then do a patch release once it's evident that game balance is screwed. Other than balancing changes apart from the obvious bug and security fixes there can also be changes to art or even new maps could be added. A patch release just mustn't break mods. To sum up, there only needs to be a subset of civs that can be used for pro players in competition, which can just as well be empirically determined after the release and balance issues should they crop up should not be cemented for such a long time. Well, I spoke a lot in little detail about a rather complex topic but hope it a least shows a different possible take worth discussing.