All Activity

Thanks for putting this survey together, @Atrik! Today we had the chance to play a 4v4 TG. The general impression was that cavalry was way too slow. I would try reducing it to 7.5/8%, half of what it is now, or 10% at most. If not, maybe get rid of acceleration (but i guess that would be a bigger change ) As for the other changes, it's difficult to draw any conclusions from just one match. I played as the Gauls and tried going for fanatics. My impression was that they were still strong (which is nice for the champion unit). However, perhaps the damage reduction is a bit too much, and we could try 10% instead. Regarding armor and HP, I think these changes are positive and might be the way to prevent fanatics from being permanently banned. I hope we can keep testing more games

If the mod has ignorecompatibilitychecks=true in mod.json, than nobody else needs it

1; accidentally voted as IDK, meant to vote yes 2, 3, and 4; yes to all, especially naked fanatics. They're probably the most powerful from the list. Immortals I'm less inclined to agree but then again when I play persians, which is rare already, i just amass a ton of axemen, spearmen, and archers. Not that that makes it an easy win. 5; Voted no, kind of feels a bit cheesy? Like IDK why, just a bit worried. 6; Yes, already too expensive for what it is, and it doesn't have any way to shoot arrows when garrisoned and doesn't expand territory. Will have to see whether the price is reduced enough though. 7; No; I agree with the change to aura range, but not to resistance changes. 8; Yes; axemen should always cost slightly less metal than a sword counterpart. 9; Overall yes, but disagree on the range reduction; Leave range as is, decrease bonus damage from 3 to 2, cost change is good. 10; Yes; foundations are too easy to destroy. 11; Yes; Cavalry does feel too fast, though maybe just a 10% instead of 15%? Could try and balance it on a civ by civ basis, though that would require more work. Eg, good cav civs have less of a nerf, like persians or gauls. Less cavalry centric civs like rome/sparta have a larger nerf. Mostly to try and give them a bit more flavour between different civs. 12; Yes; Champion cav can be way too strong (glares at persians), a nerf to their health would make them less overpowered (in general, not just persians). 13; Yes; Just brings wall towers more in line with how walls work in general. 14; Hesitant yes; I haven't played too much with catafalques, but when I have, especially when you have a high number of them, some of them can make things snowball quickly. 15; Indifferent yes; Isn't that more of a bug fix?

That is a very smart approach, @Asher! Reusing the existing tribute code for the resource transfer and adapting a standard scenario trigger to spawn the allied units sounds like a much easier way to build a first prototype. Also, regarding your earlier ideas: making the Embassy act as a "lifeline" so an ally is only defeated once all their critical units/structures AND all Embassies are destroyed makes the system much cleaner—and it allows the host to simply send tribute resources to revive them! Having civilians automatically flee toward the nearest Embassy, Civic Center, or Fortress when a major building falls would also add amazing atmosphere and realism to sieges. Mentioning the existing survivors-mod is a huge help too! Looking at how that mod handles player defeat and resource/unit transfers could give you (and @Grautvornix) a great starting template for the scripts. Between your Embassy structure setup and @Grautvornix's ideas, we already have a great roadmap for a V1 test mod. Please take your time, and let me know whenever you would like to brainstorm further or test an early version! That is a very smart approach, @Asher! Reusing the existing tribute code for the resource transfer and adapting a standard scenario trigger to spawn the allied units sounds like a much easier way to build a first prototype. Also, regarding your earlier ideas: making the Embassy act as a "lifeline" so an ally is only defeated once all their critical units/structures AND all Embassies are destroyed makes the system much cleaner—and it allows the host to simply send tribute resources to revive them! Having civilians automatically flee toward the nearest Embassy, Civic Center, or Fortress when a major building falls would also add amazing atmosphere and realism to sieges. Mentioning the existing survivors-mod is a huge help too! Looking at how that mod handles player defeat and resource/unit transfers could give you (and @Grautvornix) a great starting template for the scripts. Between your Embassy structure setup and @Grautvornix's ideas, we already have a great roadmap for a V1 test mod. Please take your time, and let me know whenever you would like to brainstorm further or test an early version!

A little, but probably not enough to get this working. Though, it may not be that hard, because you can already send tribute; if there is already a button to do that, then we could probably copy the code and use that, and, there is probably a trigger script or thing that we could modify to do the units. Maybe it wouldn't be that hard

Good plan! The intent of post-Atlas was to allow batch editing of map packages (well still editing one-by-one but you can step through the maps) and outputting everything into a mod.

Thank you very much for offering to help, @Grautvornix! To be completely honest, I have only been playing 0 A.D. for two weeks, so I do not have any experience coding for the game yet—my strengths are mainly game design, ideas, and playtesting. Having you set up the Embassy structure (and confirming that the survival rule already works in standard Conquest mode!) would already be a huge step forward for a first test version. @Asher, do you happen to have any experience with JavaScript scripting or triggers in 0 A.D. for the "Restore Fallen Ally" option (and @Grautvornix's resource transfer idea)? If not, maybe we could ask for a bit of help in the modding section of the forum, or I can also try to get some help drafting a basic script for us to test! Thank you very much for offering to help, @Grautvornix! To be completely honest, I have only been playing 0 A.D. for two weeks, so I do not have any experience coding for the game yet—my strengths are mainly game design, ideas, and playtesting. Having you set up the Embassy structure (and confirming that the survival rule already works in standard Conquest mode!) would already be a huge step forward for a first test version. @Asher, do you happen to have any experience with JavaScript scripting or triggers in 0 A.D. for the "Restore Fallen Ally" option (and @Grautvornix's resource transfer idea)? If not, maybe we could ask for a bit of help in the modding section of the forum, or I can also try to get some help drafting a basic script for us to test!

I'm not really that great at coding for 0 A.D., but I'd be willing to help. @Alber 0A.D, do you have experience with coding in 0 A.D.? I think I could help setup the embassy structure (unless someone else wants to), and the survival rule should already work (unless you are doing a different conquest mode). I am not sure how to do the Restore Fallen Ally, we would probably need a script for that

Is the .spec file like the build file, so everytime you build it, it runs that?

Oh, you are right, of course! The reason I asked Claude to provide spec files was that I wanted ensure all documents and the additonal data set for mercator's world map (forms a possible basis for selecting terrain tiles from public DEM sources) are included. the result is ratehr complex and unpleasant to read while your script is straightforward and understandable. I prefer yours actually.

That is a very good idea, @Grautvornix! Transferring the defeated ally's remaining resources to their surviving ally fits the theme remarkably well. It also creates a great strategic synergy with @Asher's revival concept: those inherited resources can directly help the surviving player afford the high cost of restoring their ally at the Embassy later. We could even make it so that you inherit 100% of their resources if you already have an Embassy built (acting as a secure diplomatic treasury), or 50% without one.

Thanks a lot, @Grautvornix! Building a test mod around this with you and @Asher would be awesome! You make a great point about allied garrisoning already existing in the base game—turning that into a real, structured comeback mechanic is exactly what we are aiming for. If you're up for prototyping a mod for testing, we could start with a simple V1 to see how fun it feels in-game before adding complex rules: The Embassy building (unlocked in Town Phase, using an existing building model as a placeholder). Survival rule: As long as at least 1 allied citizen is garrisoned inside, that faction isn't defeated. "Restore Fallen Ally" option: A hefty flat resource cost (e.g., 500 food/wood/stone/metal) at the Embassy to spawn 4–5 allied citizens if they were eliminated. Mechanics like continuous resource upkeep, healer requirements, or XP gain could always be added later in a V2 once the core loop works. Let me know how I can help with the game design or playtesting!

Hi, I've known about 0ad for a long time, but I'm still a total beginner when it comes to actually playing the game. I play a little every few months—usually as Christmas approaches. Are there actually any pre-made Kamania maps out there that I can download and play? with best

Hi, I'd like to test ModernGUI R28. Right now, I'm only playing single-player against the AI. What will it be like later in online mode? Will all players need the same mod for it to work? with best

New cultures are already being implemented into World Rising! We're expanding our world even further, introducing new civilizations, buildings, units, and unique historical features. Each culture is being carefully developed with attention to historical detail, aiming to deliver an increasingly rich, immersive, and diverse gameplay experience. The world of World Rising continues to grow, and many exciting new features are still to come!

I've been working on including some ancient greek ceramics to the game, that I found and modified to work for 0 A.D. Everything is baked on the same texture. I'll add a mod for anybody wishing to test it. This is some of the current pottery in the game: We could use them for eyecandy objects with food, trees, plants, on shelfes etc: Normal Map: Some common pottery shapes as reference: Here are the sources for the highpolys. Except for the pithos (the large one) which uses CC-BY, all models are licenced under CC0. We might have to give attribution to the author or I would remodel it myself. I still need to make a procedural material to bake a proper diffuse for the terracotta amphora. The actors also need some editing. If there is an interest I'm thinking about adding more products to fill into it, which could be pomegranate, figs, pears, grapes, olives, onions, fish, grain, wine, water, dirt for the plants etc. heleprops.zip

I'm going to test an existing mod to observe its behavior; indeed, I've noticed that the Atlas Tools Kit seems designed for mods built with the most recent versions. So I'd like to check whether it still works with an older mod or if it needs adjustments. I also have my own mod (made up of 20 files); @Grautvornix how will the output process work with my mod ?

I saw that you cannot use the -w flag with using the .spec files @Grautvornix, so I think just building from the .py files will be ok. Was there a specific reason you did the .spec files? Here is an update version of the build script: build-1.0.1.zip

Cool! But does that script work? (shouldn't it be e.g. "pyinstaller mercator.spec" instead of "pyinstaller mercator.py" ?) Embarassingly stupid remark, apologies for that!. Now that is a challenge! No, I don't have any yet, possibly something like the attached (still ugly with the tongue hanging out)

build.zip (remove --onefile from build script so it doesn't take as long to run the program)

@Alber 0A.D @AsherI like your proposals! If you have options to recover from an almost total defeat, this addds a nice twist to an otherwise straightforward win/loss result. Part of it seems possible already I keep seeing single ally's units garrisoning into my CC etc. It is just not a strategy I was using so far. Wonder if we can build that into a mod for testing...

Do you have icons for these, @Grautvornix? And here is the update build script build.zip (I included the files @Grautvornix posted above)

Hi @Asher thanks for the quick reaction -and the good idea! The tool needs PyQt6, Pillow, numpy, scipy, and pyqtgraph/PyOpenGL. Your script is great, but there are actually two tools in the package (Mercator and post-Atlas) and they need to have their specific environment. My intention was to keep it open as editable python code so anyone can inspect and modify it as needed. But you are certainly right - not everyone has python installed or would like to look into the code. Here are the two pyinstaller spec files Mercator.spec and post-Atlas.spec . A plain pyinstaller --onefile Mercator.py only follows Python imports. It misses non-code resources that get loaded relative to the installed files — docs/ (Help, User Manual, Design notes, Credits), CREDITS.md/LICENSE, and most of all mercator/world/*.json.gz (the real-elevation-data feature). Attached are pyinstaller spec files that can be called by pyinstaller Mercator.spec pyinstaller PostAtlas.spec This would work as a standalone double-click exe, however: The hand-over between the two tools will not work as built: Check or convert in post-Atlas... and Convert > Edit in Mercator launch the sibling tool via sys.executable -m <module> (atlas_ui/other_tool.py). Inside a frozen exe, sys.executable is that exe, which doesn’t understand -m — and worse, the check for “is the other tool installed” (importlib.util.find_spec) will always say no, since each exe only bundles its own tool. So the button offering the hand-over won’t even appear. That’s a significant regression for frozen builds specifically. I ask my coding buddy (Claude) to find a solution for this as I believe the linking o fhte two tools is an important aspect. @lilypoppy suggested to create a single tool but that would make the GUI even more complex than it is today, I am afraid. But he does have point here. Size: Mercator.exe is ~140 MB, Post-Atlas.exe ~116 MB on windows. They are bundling PyQt6 + NumPy + SciPy + Pillow + pyqtgraph/PyOpenGL for the 3D views). Versus the ~6 MB release zip, this is a very different distribution. This would clearly call for a single exe only. @Asher @lilypoppy Claude just implemented a fix in version 0.23.0, see initial post of this thread. So the only remaining issue is size. Still unsure if we should dare going for a single tool. Mercator.spec PostAtlas.spec

@Grautvornix @Asher

build.sh Just made a build script to make this into an executable. (Should work across systems). Maybe you'd want to add this @Grautvornix? Also, does it just need pyqt6 and scipy to also be installed, or are there more?