hyperion

Camels speed was around 13 and horses around 17 which "makes perfect sense". Haha. Well I stop from further harping on this "sense" thing, I think I got my point across by now. I forgot before to mention pikemen were horribly slow, harming economy and were left in the dust by rams. Well the game gets optimized for midland with temperate biome, so high stone and metal cost becomes an issue. Only food and wood is abundant there. So a merc can't cost 100 metal unless you have enough alternative units to choose from.

The number needs to be a multiple of 5 so the 20% pop bonus techs for the houses are straight forward. I agree that having to build lots of houses is annoying. With A24 you will probably have to add Britons, Gauls and Ptolemeus to Mauryan. Well, many people consider houses the primary means to build walls (rolls eyes). Doubling pop boni for houses might be a good idea or make it 10 and 15 if 20 sounds like to much for large houses.

IIRC campaign feature was dropped for A24. At least we got the other major missing feature, namely hotkey editor. Also I think there should only be a tutorial campaign which is officially part of EA, the rest can be mods maintained by whoever wishes to do so, WFG included.

Once upon a time camels were slow, towers out ranged archers and were stronger(?) and the cost of slinger and mercenaries really did hurt. Ptolemeus were pitifully weak, then became stronger and stronger each iteration and in the end it's about the cost of some buildings which break balance? Btw, as far as I'm aware people still usually claim Britons are the strongest. If people often play Ptolemeus, either it's because it's all about winning (guess this is true for a minority) and Ptolemeus are strong or because they consider the distinct play style fun. The Xiongu(?) from TM are the only other one which are truly distinct. The slight difference for the Celtic factions was canned as well IIRC. So it should cost 67 stone 6 wood and 3 metal. Let's fix all other "buggy" resource costs while at it! While I disagree with @borg- I at least consider his a valid point.

Someone needs to commit your patches. The argument of "doesn't make much sense" is bogus. I can come up with this type of argument for pretty much everything in the game and make it sound sane. I feel every time this argument is part of the commit message the patch should be rejected straight away for being misguided. That doesn't mean the change can't be made but at least use sane arguments, "doesn't make much sense" never is. Lets take https://code.wildfiregames.com/D3329 Ptol houses now cost wood even they are built from bricks without any wood. Doesn't make sense at all! Before they were houses and to make gameplay different from other civs the resource cost was substituted by higher build time and larger footprint (important). Perfectly reasonable. As you see I claim the inverse as making sense and no one can say I'm wrong. By the way I consider this another horrible change for the game as in "fun to play".

If you are new one issue is the game speed. For example you do not have the time to hover over icons to wait for pop-ups to tell you this is a farmstead, this is a barrack etc. The same for fights, you do not know by hart how to position units and so forth. Adjust the game speed to 0.25 (game setup page) till you get familiar with units, buildings, techs and other aspects. As for a manual, there is an in-game one and some online ones like https://play0ad.com/category/game-manual/ or https://trac.wildfiregames.com/wiki/0adManual

Also there are 21:9 monitors, so the corners might really be far off.

The only concern I have is that the differences between civs once more decreased.

The tag can substitute for the commit hash git reset --hard A23

You are missing the build dependency fmt, just install it via package manager. The package might be called libfmt-devel or such.

When capturing was introduced I didn't particularly like it. As it came up recently, as in make sieges not capture-able I tried to recall why this was so. One aspect is the capture-delete meta. This could be fixed by buildings needing being demolished as they need be built and could award some of the resources back as compensation. The other was when capturing got introduced I felt the unit behaviour quite a bit annoying. So I changed the code that capturing needs to be explicitly ordered for it to happen. Turns out it feels better but not by as much as I expected. Probably having to adjust to the new behaviour when capturing got introduced made it feel worse than it actually was. So that others may try how it would feel I packaged the changes into a minimalistic mod for A23. You have to add a definition for hotkey.session.capture to your local.cfg (~/.config/0ad/config/local.cfg on Linux) if you still want to be able to capture targets after loading the mod. capture-0.23.0.pyromod

"melee pierce against cavalry" is technically already a damage type. Ideally for balancing you would have a matrix defining how long it takes any unit to kill another. Each such unique vector then can be said to be a damage type. Things like damage, armour, health, attack-speed are just transformations thereof.

Why do you need both Unassigned and Removed?

Hack, pierce, and crush aren't good enough (however they are named) as otherwise there wouldn't be "counters" damage modifiers while still a pain to balance. There should be a couple more damage types. Well I think fire and poison were added by now.

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.