hyperion

Well, a proper implementation probably should decouple capture and attack. The mod only hacks the default behaviour of attack to not be capture. But I'd certainly appreciate if developers who think this is a possible improvement in unit behaviour could state so. Then it be worthwhile to do it properly. Will package the patches with the next version of the mod. For the other issue mentioned in the initial post I have locally added an extra patch, which still needs some testing. Simply didn't had the time yet. Break the capture-delete meta Capturing should be meant for own use afterwards. Currently capturing is cheap alternative to kill/destroy an enemy entity. This only works as delete as a game mechanic is instantaneous without cost or leaving debris behind. Long-term one might want to change delete to be more like building. However this requires a lot of thought and new artwork. For structures it would work to require it to be connected to an owned territory root to prevent capture-delete in relevant cases but might prevent freeing space if the CC got destroyed or captured to make room for building a new one. However this approach doesn't extend to captured units. This patch therefore implements a 3 minute ban on deleting after an entity changes ownership.

@FeiLongbay, thanks for the feedback. pyromod is a zip file, so you can use unzip to extract it. See also https://trac.wildfiregames.com/wiki/Modding_Guide#Howtoinstallmods I agree that flaming cav sees the biggest improvement. This is out of scope of this mods initial idea, but I think it's worth looking into. The main issue might be a quite noticeable performance penalty though. Will have to test it out. Do you mean if you ungarrison a siege? I'll do that with enemy troops around. For buildings you can set a rally point (move, attack-move, attack-move-unit, capture ...). So I haven't noticed this issue yet, will see were it comes from. They do but they won't switch if they are already attacking a siege which is likely the correct behaviour.

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.