hyperion

There is a reason why @wraitii split spidermonkey update to v78 into more than a single patch where the patches in the whole series are arguably more related than this one. With the argument "all changes are related" you could even merge all commits between a23 and a24. If I were the maintainer I wouldn't accept your patch even if I agreed with the changes. Ideally this patch would be split into a series. Let's make "[1/x] remove splash damage" the first one. The commit message should reference the commit which added splash damage. That commit ideally explains the rational for adding it in the first place and how it's supposed to work. The removal patch then further discuss why in hindsight this was a bad decision / design and why removing instead of tweaking is the better choice. Unless the commit messages explains why "in practice it's rather flawed" I have no way to know. Proposing alternatives then is impossible. This sort of feels like there is "dancing" so "there is a flaw with unit motion" therefore lets remove "units" just that the consequences are less dire when doing this with splash damage. Similar with "if something doesn't make sense", how does a miller living in a mill are nones living in a cloister not make sense. So pop cap boni for various buildings is perfectly justifiable from a realism point of view and I don't see how this hurts gameplay at all.

https://code.wildfiregames.com/D1762 (gives fortresses a territory root; see also this forum poll) Territory control having been exercised mostly via castles and other fortifications makes this a reasonable choice. -- https://code.wildfiregames.com/D2493 (make siege engines uncapturable) Never particularly liked capture mechanic (maybe mostly due to unit behaviour / maybe also capture-delete meta). While only slightly averse to capturing buildings I clearly dislike it for sieges. -- https://code.wildfiregames.com/D2494 (overhaul artillery attacks) This is dropping splash damage and lot of unrelated changes. Such do a bit of everything patch makes it incredibly difficult to follow the change in codebase. Further the description only says what the patch does which can be just inferred instead of why this changes is positive or what it hopes to achieve. -- https://code.wildfiregames.com/D2507 (allow building palisades in neutral terrritory) Well everyone only ever plays mainland. -- https://code.wildfiregames.com/D2801 (enable stable for all civilizations) https://code.wildfiregames.com/D2815 (give all civs rams) https://code.wildfiregames.com/D2950 (keep population for houses) Generally any patch that reduces the difference between the civs I consider bad. This trend is ongoing for a long time already and I can only see it stop when civ is just a skin for the same unit roster with possibly only absolutely inconsequential differences remaining. The above are very obvious examples of horrible in terms of diversity. Some of the other patches listed do have a similar effect albeit less obvious.

Remove all extra shaders from autoziv. I see you are on linux, if you are using vim you can directly edit the mod zip file. Then comment out / remove the broken ones or those you do not like in shaders/effects/postproc/hdr.xml

If it isn't much for you why do you think it's not the same for the one doing those attacks. A proxy service backed by a ddos mitigation service like azure or cloudflare would solve the issue. Would also reduce the need for people to fiddle with their own firewalls. As 0ad is free and open source it shouldn't be all that difficult to get a sponsorship deal if a couple hundred dollars yearly are hard to bear.

objdump is part of binutils

Thanks for sharing. Just a little nitpick. Would be nice if you could add a mod.json to your repository so it could just be cloned into the mods folder as-is.

If it were a simple git send-email no problem . We already have noteworthy historical figures (heroes), nobles (champions) and citizens/commoners/females/slaves/priests/cattle ... (the rest) according to selection marker. So the class/caste system is already mirrored in the game, maybe not that great of a job was done as it wasn't explicitly designed for but just grown as such. You can endlessly complicate that to more closely mirror history but ultimately I doubt it will make the game any better and if not careful actually worse. Female soldiers always existed and will always exist but if it's the norm the civilization is screwed. Loosing 90% of your man is a big hit but so what, this can be fixed by men having multiple wife but losing 90% of the females means you are done for. Well capturing them from other places sort of works too but then those places are screwed. Cynically speaking females mostly not partaking in the same stupidity is termed sexist today? Honestly I like that villagers (purely economic unit) as concept like in AOE doesn't exist in 0ad, everybody fights if it's a matter of life and death. That nobles (champions) don't farm is fine. From a game perspective female is just a unit type which is cheaper and therefore weaker than a sword-man and as a result is rarely sent to the front-line but it's not like it never happens. A female in 0ad is a melee type unit dealing hack damage and as it's easily optically distinguishable from other unit types makes it one of the best unit designs from a playability perspective. Go ahead and add variations in gender, size, body type, clothing and then give them all pink hair so we still recognize them as the same unit type at a glance. This works also for other unit types, like blue helmets for spear-man and yellow hats for slinger and so forth. The 15 variations of knifes earlier mentioned is pretty much a joke, I can't even tell whether it's a knife, a short sword or simply an iron bar which is held from the usual distance (zoom) I play (My hardware can cope with it so I won't complain either). It's fine to give some thought to political correctness, which obviously differs based on cultural background (Waits for someone asking that females in game need to cover their faces) and historical accurateness but it's ultimately a game or how would you explain that a female can regrow a lost limb in 5 seconds in a temple while a hero needs 30 seconds to cure a broken finger. Thorfinn seems to have found some possibilities for other female based unit types and I'm certainly in favour of looking into that. Female priest for some/all civs could be said to be a stroke of genius.

Woman can indeed fight, they are even decent ram counters. Spartan woman are even stronger. It can basically be said woman are like their male counterparts, they just don't run around with armour and a weapon meant for war all day long. So if the tutorial states they can't fight that's wrong and should be fixed. Though the base hit points of woman is to low and could arguably use some tweaking. Would also help reduce the impact of early cavalry rushes.

Making the top bar more functional is a good idea and for sure welcome. A few remarks: Make background opaque, the current alpha value doesn't really help to see what is going on behind it and it isn't click through in the first place anyway. Use the same skin including the golden rim, so it looks just as if part of the original UI. The coloured background for the emblem and font of player name is already sufficient, no need for a coloured bar as well. Ideally use the same height for the panel as the menu on the right hand side, so it perfectly blends with the rest of the UI. The original functionality (the three bars prod/tech/unit) seems pretty broken. Anyway thanks for your continued work on this.

Yep, like @Stan` said. With the current Zen2 based CPUs we get random slow-downs and speed-ups while playing the game. It's, like someone suddenly sets the game speed e.g. from 1 to 0,1 or 10. I don't have the skills, to review the patch, I only be able test it. Are you talking about https://code.wildfiregames.com/D2726 First a general comment, the patch does more than one logical change and thus should be split accordingly. Then let's just look at the changes in timer.cpp, which I assume is what Stan refers to as the Linux fix. Split out that part of the patch and ensure that without you experience the slowdowns and that the new minimal patch indeed prevents the issue. If so you found a bug in third party software and you should report it upstream and 0ad must not change the code in the name of fixing Ryzen. This new minimal patch may have merit on it's own. Both CLOCK_REALTIME and CLOCK_MONOTONIC give different guarantees for measuring time elapsed and without digging through the use of timer in 0ad my first impression is CLOCK_MONOTONIC is likely what should be used in the first place.

It's not a no brainer as SDL updates have been known to break a lot of things in the past. Also Windows is still using 2.0.5 My experience with mac players is that generally you can't ask them to compile the game A no brainer in the sense that dropping support for old mac os is acceptable but not supporting new ones is out of question, in the sense you need to stick close to upstream so that if you run into issues you are qualified to report them or get other forms of help. Also I'm playing a23 which was built against 2.0.12 without apparent issues for months albeit on Linux. My experience with mac is you are a good customer while your hardware is less than a year old, a decent if less than three and out of luck thereafter. Unlike Microsoft which puts considerable effort into forward compatibility Apple is perfectly fine for it's user to run into issues few years down the line. So if Apple doesn't care why should you? And if someone actually cares putting out a community build is already good enough IMHO. It's also needed to build SpiderMonkey which runs half the code of the game. Looks like spidermonkey-52 needs python for unit tests only. 52 is what I think Itms currently is at. They also affect all the other CPUs so they might make the game unplayable for other cpus Well, with a bit grepping the only use I found for all that cache handling is an aligned allocator which cares about L1 while the issue seems to be limited to L3, so commenting out the respective code and adding a TODO should work for now.

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.