I have finished the Unit Listing and am attaching it now. I only found two items that did not have a "Specific" name, a Kush Bireme and Maur siege ram.

I'll start working on the in-game documentation until I get some input from the developers on what they need. I am still kind of searching to find out what exists already.

If you have any ideas or wants just let me know.

Thanks,

Dok

Unit Listing Alphabetical.txt

I wonder if we could go through some and quickly discuss and see if they're really necessary or should be done real quick by someone.

For example, here's one that suggests that lower health units could move slower. It's an interesting idea, but one I'm not exactly sure is one that 0 A.D. is ever going to have.

https://gitea.wildfiregames.com/0ad/0ad/issues/2091

Here are a few others that could be possibly closed or done really quickly.

This issue is about "deciding on whether to have land unit fishing" This is another one that could be decided really quickly, closed, and if we wanted to add it later no harm really.

https://gitea.wildfiregames.com/0ad/0ad/issues/1437

Creating a 0 A.D. war story may have been useful in 2006-2007, but in the year of our Lord 2025 (soon to be 2026) we have YouTube so having a war story isn't really as needed, we could still make one eventually, but having an issue for it right now doesn't seem needed.

https://gitea.wildfiregames.com/0ad/0ad/issues/66

This issue here is just for "adding more victory conditions" which personally I think is a bad issue because it doesn't really give us a goal to work for (and we could be doing this forever. I move for closing it and opening new issues for the specific conditions.

https://gitea.wildfiregames.com/0ad/0ad/issues/1649

This is an issue to add metadata to the soundtrack. I 100% agree this should get done, but even a non-technical user could get it done in less than an hour if Omri didn't have to.

https://gitea.wildfiregames.com/0ad/0ad/issues/3619

Then there are some tickets about adding cliffs to 0 A.D. which I am almost am certain exist in 0 A.D. (so maybe some issues people forgot to close?) I could be wrong, of course.

https://gitea.wildfiregames.com/0ad/0ad/issues/993

Finally, there are a LOT of issues about atlas which either A) seem already implemented (like this one) or B seem a little outdated if atlas is being moved in game.

https://gitea.wildfiregames.com/0ad/0ad/issues/571

let me know what you think closing these issues and if the devs are ok with cleaning the issues I'll post more that we could go through.

I am considering introducing Lua (luajit) as a second modding language, alongside JavaScript. Here’s why:

• performance: Lua is fast, especially for CPU-heavy mods (AI, simulations, etc.), which is critical for large-scale RTS battles.
• simplicity: Lua’s lightweight syntax and C/C++ integration make it easier to expose engine features directly to modders.
• ecosystem: Lua is widely used in gaming (e.g., World of Warcraft, Roblox) and has robust tooling for debugging and profiling.
• sandboxing: Lua’s simplicity allows for tighter security controls, reducing risks of crashes or exploits.

this isn’t a replacement for JavaScript.

javascript mods will continue to work! The goal is to add options, not remove them. Lua could become the preferred language for performance-critical mods, while JS remains great for UI/scripted events.

what this means for modders:

• gradual rollout: Lua support would be phased in, starting with experimental access to core APIs.
• tooling: we'd provide Lua-specific documentation, debuggers, and compatibility layers for JS ↔ Lua interop.

points for discussion:

• are there existing JS workflows we would struggle to replicate in Lua?
• is there any other integrations like this one done in the past or abandoned we have notice of, can we learn from it ?
• where to start, is there any tips for a unexperienced 0ad "core" dev like me or others wanting to help that we can start learning from ?
• other topics of discussion ... please feel free to add and help ?

I only have Linux, so I'd really like to hear from anyone who can try it on Windows or macOS: does the server start, can players connect, and does the sidecar build and run? Please post bug reports, suggestions and questions here or as a GitHub issue. Veredus is not affiliated with Wildfire Games.

Basically any feedback is welcome. 

Why is https://gitea.wildfiregames.com showing this since 08 Oct 2026?

500 Internal Server Error

Gitea Version: 1.26.4+1-g1ac57c9699

I currently have a basic implementation that covers the minimum functionality: duplicating and deleting hotkey presets, while always keeping a Default Preset as a baseline.

The presets are stored in binaries\data\mods\public\moddata\hotkeypresets.json (in theory, this would be mods/user in a compiled redistributable version). Just like with user.cfg, this .json file only stores hotkeys that differ from the default hotkeys. Initially, I wanted to use an INI-style file structure, but I'm not sure if there is an equivalent function to WriteJSONFile for that. I chose this location because it is already included in the whitelist, so I can avoid making changes to the Engine. I also didn't want to use user.cfg and add dozens of extra lines to it.

So basically, the code adds a .json file that stores, reads, and modifies hotkey presets, and then copies/applies the active hotkeys to user.cfg.

As for mods that interact with hotkeys, the idea is to change the current workflow as little as possible. So if there are any details I should take into account from a modding perspective, please let me know.

Do you think this functionality would be useful to have?

And, especially for the devs, does this seem like an appropriate approach, or would you recommend a better alternative?

I put together a "Structure" listing as you suggested. I went through each template in the "Structures" directory to pull the "Specific" and "Generic" names for the list. Some items didn't have anything and some only had one or the other. I used some of the generic templates from the "Templates" directory itself and some of the names I found by playing the game to see what displayed. Could you please look at the file and let me know if this is what you wanted? A few of the structures don't seem to exist in the game, such as "Range" and Workshop" or "Stables" for most of the Civs.

I'm working on the unit listing now.

Thanks,

Dok

Structure List Alphabetical.txt

I'm Josue (josue on Gitea), a fairly new contributor. I want to share a project I'm about to start, get your feedback before I write code, and later hand you a fork to test and pick apart.

The itch

Petra is a solid executor. It gathers, builds, places, trains and fights well. But it plays the same linear game on every map, against every opponent: gather, age up, train, attack the nearest Civic Center, repeat. It doesn't use terrain, it doesn't read you, and difficulty is mostly a handicap (gather rate ×0.42 on Sandbox up to ×1.56 on Very Hard, plus some caps).

Meanwhile the game ships 51 historical heroes across 15 civilizations: Hannibal, Alexander, Vercingetorix, Leonidas, Fabius Cunctator, Viriathus, Themistocles... and the AI never fights like any of them. Petra's Leonidas doesn't hold a pass. Petra's Fabius doesn't delay. Nobody builds Alesia.

The idea

https://gitea.wildfiregames.com/josue/0ad/src/branch/strategos/mvp1/docs/strategos

Split the bot into hands and head.

• Hands stay Petra: economy, building placement, gathering, queues, trade and garrison mechanics, the actual battle.
• The head is new: a small strategy layer that picks a stratagem: wall the choke by the river and wait; build a trade network; garrison the towers along the enemy's approach; strike their army while it's strung out in a pass; fall back.

A stratagem enters Petra through one door (Headquarters), which hands it to the manager that already knows how to execute it. The ambush and the Persian trade network go through the same channel.

Who picks the stratagem? We write the doctrine, a model judges.

• Civ doctrine: read from the civ bonuses that already exist as data. Romans fortify, Carthage goes to the sea and to elephants, Persians trade, Spartans hold ground.
• Hero archetypes: 5–6 playbooks mapped to the heroes: siege builder, ambusher, hammer and anvil, hold the pass, delayer, naval raider.
• Stages triggered by the game, not the clock: early game follows the civ doctrine; mid game picks a hero and runs their playbook (hero dies → next hero); when heroes run out the AI goes defensive: commerce and fortification.
• Opponent model: is the other player rushing, booming or turtling? Where is their army heading? Are they weak at sea? This is what changes every game, and it's what Petra has never had.

The model doesn't invent strategy. It answers typed questions ("hold, strike or fall back?", "rush, boom or turtle?") with probabilities. That's a classification job, which is why a small model can do it.

Free and open, by design

The target model is Laya (convaiinnovations/laya on Hugging Face): Apache 2.0, 421M parameters, a classifier that answers typed questions and runs on a CPU (the model card says roughly 200–450 ms per question on CPU; I haven't measured it yet).

• Optional download (~650 MB). Without it you get plain Petra; nothing changes.
• No account, no API key, no network, no cost.
• Multiplayer-safe: only the host runs the model, and its decisions go out as ordinary network commands. Clients don't need the model, lockstep holds, replays replay. This also sidesteps floating-point differences between platforms. One engine change is needed for it: today the server drops commands sent on behalf of another player unless cheats are on (NetServer.cpp), so the host must be allowed to send this one command type for AI-controlled slots. Single-player is unaffected.
• Mod first: a strategos mod that overlays only the Petra files it touches. Default Petra stays untouched.

An honest note on prototyping: to learn quickly which questions matter, the very first prototype uses a hosted typed-question API (TypeSafe's Jev), called from an external Python script through the existing RL interface. That is developer scaffolding only. It will never ship and players will never need it. Both models take the same question format, so swapping to the local model doesn't change the questions.

Performance: what it costs

Lag is already the most common complaint, and AI plus pathfinding are big parts of it. Today every AI runs on the simulation thread, on every client, every turn. So this has to be designed not to make it worse:

• The in-engine part is tiny. Petra reads at most one hint per played turn and hands it to a manager it already runs. I'll measure Petra's turn time (the existing PetraBot bot (player N) profiler section) with and without the mod, and publish the numbers. The target is ≤5% overhead.
• The model never runs on the simulation thread. At 200–450 ms per question on a CPU, running it inline would freeze the host, and in lockstep that means everyone. So questions are asked every few seconds (not every turn), inference runs on a worker thread, and the answer comes back as a command a few turns later. The engine already has a TODO for exactly this pattern (async AI tasks that return after a fixed number of turns, in CCmpAIManager.cpp), and it lines up with the ongoing threading work (#5874). If that helper gets built, Petra's own heavy analysis could use it too.
• Only the host pays. Clients run nothing extra. The host pays CPU on a spare core, plus the model's memory (roughly 0.5–1.7 GB depending on quantization; I'll measure and publish it).
• It won't fix lag. I'm not promising a speedup. At best, stratagems replace some of Petra's per-turn strategic scans with a cached decision; that's a side effect, not the goal.

How it relates to existing plans

From the Gameplay Feature Status and Game Performance wiki pages:

• Advanced AI is listed as "partially complete" (#973, #3003). The terrain and threat reading here (choke points, the enemy's approach) overlaps #3003 ("Petra should be aware of dangerous areas"). Anything reusable goes upstream on its own.
• The naval raider archetype depends on #3002 (Petra using ships for warfare), so it comes later.
• Directional attack bonuses (flanking) aren't implemented, so "hammer and anvil" can only win through positioning and surrounding, not a flank bonus. I'll keep the playbooks honest about what the game actually rewards.
• "Ambush" here is AI behavior (hold a choke, strike at the right moment). It's unrelated to the concealment mechanic in #3177.
• Narrative and strategic campaigns were cut from Part 1. A historically flavored opponent in skirmish is a cheap way to get some of that feeling back.

How I'll prove it (before anyone gets excited)

MVP of the MVP: one map with clear choke points, one stratagem (ambush at the pass), one question (hold, strike or fall back). Three arms on the same seeds:

1. vanilla Petra
2. ambush + a dumb distance rule ("strike when their army is within N metres")
3. ambush + the model

Arm 2 vs 1 measures the stratagem; arm 3 vs 2 measures the model. Before any game, the model has to beat the rule on 50–100 hand-labeled game states. If it can't, I'll post that result here too.

Roadmap

• Phase 0: headless Petra vs Petra harness through the RL interface; determinism checked through replays.
• Phase 1: the hint channel (a new strategos-hint command → Headquarters dispatch). JS only, no engine changes.
• Phase 2: choke points extracted from the passability grid.
• Phase 3: the ambush stratagem in Petra.
• Phases 4–5: rule arm, labeled dataset, model arm; results posted here.
• After that: the local model on the host, outside the simulation (optional ONNX Runtime dependency, off by default), the small network change above, then more stratagems, civ doctrines, hero playbooks, the opponent model.

What I'll share, and what I'm asking

I'll share:

• Everything in my fork, https://gitea.wildfiregames.com/josue/0ad (branch strategos/mvp1): code, match results, replays and the labeled dataset, for anyone to test, reproduce or tear apart.
• Fixes, as normal PRs, for the RL-interface bugs I run into along the way. #7854 and #7628 look like the first ones I'll hit.

I'm asking for feedback from:

• Petra maintainers: is a single "stratagem hint" entry point in Headquarters acceptable, or would you prefer a different hook?
• Engine folks: what do you think of an optional ONNX Runtime dependency behind a build flag, off by default?
• Players and history nerds: which hero should fight how? Which maps have good passes?
• Everyone: is this a direction the project would consider upstream one day, or should it live as a mod? Either is fine with me.

Disclosure: I drafted this post with help from an AI assistant (Claude). The plan and the decisions are mine, and any code will go through the normal review process.

I've been looking into the possibility of creating Proto-Germanic voice lines for the Germans in 0 A.D.

First, a note about AI: I used ChatGPT to help me find linguistic sources and prepare the first word suggestions below. This is preliminary research, not a finished translation. I'm not a historical linguist, and the proposed forms have not been independently reviewed by one. Some of them may well be wrong.

No audio has been generated yet.

My idea is not to reconstruct exactly what the Cimbri spoke around 100 BC. As far as I understand, the surviving evidence simply doesn't allow this.

Instead, I would like to find a reasonable linguistic approximation that fits the historical setting of 0 A.D. and sounds good in the game.

We only need about 18 short voice lines. Ideally, they should be one or two syllables long, but I don't think this needs to be a strict requirement.

Before experimenting with recordings or text-to-speech, I would like to get the words and their pronunciation into a reasonably good state.

1. Which language should we use?

Release 28 describes the Germans as a coalition of the Cimbri, Teutones, Ambrones and other Celto-Germanic groups.

Official Release 28 announcement

The linguistic situation seems rather uncertain.

For example, Gilles Quentel discusses early contacts between Continental Celtic and Germanic. There are also different interpretations of the surviving names of the Cimbri and Teutones.

Bichlmeier and Blažek discuss several possible etymologies of these tribal names in their 2020 publication.

I think reconstructed Proto-Germanic could be a reasonable common language for the faction, as long as we make clear that this is an approximation, not a reconstruction of an attested Cimbrian dialect.

There is also the question of the First Germanic Sound Shift and its chronology.

For our purposes, I would initially use a consistent reconstructed Proto-Germanic pronunciation rather than trying to reconstruct a hypothetical earlier dialect specifically for 100 BC.

Of course, I would be interested in other opinions on this.

2. First suggestions for the voice lines

I used the English meanings from the Audio Voice List, with the Latin translations as an example:

Audio Voice List – 0 A.D. Wiki

The following is a working draft, NOT a finished or academically validated translation.

All proposed Proto-Germanic words and forms are reconstructions, not directly attested historical expressions. Some of the specific forms still need linguistic verification.

Most candidates were initially found through Wiktionary's Proto-Germanic reconstruction entries, which often refer to etymological dictionaries such as Kroonen or Orel. However, I have not independently checked every individual reconstruction against these books.

I also used the freely available Proto-Germanic grammar by Winfred P. Lehmann and the IE-CoR linguistic database.

Some forms are more tentative than others. I have marked the particularly uncertain ones instead of pretending that we already have a complete solution.

Selection and greetings

Movement and fighting

Working and gathering

Regarding hunting, the IE-CoR database gives huntōn- as its reference form, but its explanation also mentions hūnton-. The vowel length and the actual spoken form therefore need further checking.

Other

(I will put myself into) garrison — felhō
Intended meaning: "I enter / go inside". This is one of the least secure suggestions and needs both lexical and grammatical checking. It is not an attested term for entering a garrison.

A few remarks about the list

The grammatical forms are not consistent yet. Some are first-person forms, others imperatives, infinitives or reconstructed stems.

Personally, I don't think every response necessarily needs to be in the same grammatical form. The important thing is that it works as a short and natural-sounding acknowledgement in the game.

However, we should make sure that the individual forms are actually plausible and not simply invented by an AI.

Also, several suggestions deliberately use a broader meaning than the English original. For example, "I travel" instead of "I march" or "I drive" instead of "I herd". These would be gameplay decisions, not exact translations.

I would be happy to replace any of these suggestions if there are better alternatives.

3. Sources

Here are the main sources I found.

Historical background

Gilles Quentel (2012):
Early Linguistic Contacts between Continental Celtic and Germanic: Lexical Aspects.
Publication on ResearchGate

Harald Bichlmeier and Václav Blažek (2020):
"Cimbri" et "Teutoni".
Journal article – Acta Linguistica Lithuanica

Václav Blažek:
On chronology of the First Germanic Sound Shift (Lex Rask – Grimm).
Publication via DOI

These publications discuss historical names, etymologies and linguistic developments. They do not provide translations of the 18 voice lines.

Grammar and pronunciation

Winfred P. Lehmann:
A Grammar of Proto-Germanic. University of Texas at Austin.
Complete online grammar

The chapters on phonology and inflection are particularly relevant.

R. D. Fulk (2018):
A Comparative Grammar of the Early Germanic Languages.
Publisher's page – Open Access e-book

The complete e-book is freely available. I have not worked through the whole book, though.

Vocabulary

IE-CoR – Indo-European Cognate Relationships
Linguistic database

One useful example is the entry for "hunt": IE-CoR: hunt.

It references Kroonen's Etymological Dictionary of Proto-Germanic and also illustrates why some details need further checking.

I also used Wiktionary's Proto-Germanic reconstruction entries as starting points for individual words:

Proto-Germanic reconstructed terms

Some examples:

• fehtaną – to fight
• timrōną – to build
• fiskōną – to fish
• hwētaną – to attack

These entries are helpful for finding possible forms and references, but they are not a substitute for checking the original academic literature.

4. What is still missing?

Before recording anything, I think we would need:

• Someone with knowledge of historical Germanic linguistics to review the suggested words and their grammatical forms.
• A consistent pronunciation guide, preferably using IPA.
• Better solutions for the uncertain expressions, especially retreat, repair, healing and garrison.
• A decision on the battle cry.
• A way to produce natural-sounding recordings that can be freely distributed with 0 A.D.

I know there has already been some discussion about AI-generated content in the project. I'm not attached to using AI for the final audio. Human recordings would be fine as well.

For now, AI has mainly helped me find sources and put together this preliminary list.

I would be interested to know whether AI-assisted linguistic research is acceptable for this kind of contribution, and what the requirements for the final recordings would be.

5. Questions

Does this general approach make sense for the Germans in 0 A.D.?

Would reconstructed Proto-Germanic be a suitable choice, or should we consider another linguistic approach?

And is anyone here familiar with historical Germanic linguistics who could help check the proposed words and pronunciation?

I would be happy to continue working on this if there is interest.

Thanks!

Second, what about ships and engines being able to be "champions"? One could make use of elite triremes for Athens for example, instead of making up things that weren't characteristic for them. I guess the main point of champions is to indicate that organic units do not work, but I think there's also a "good unit" implication being made that could be useful for a few inorganic units (they could also have some particular restriction or characteristic, like auto repair? Repair only at Dock/Arsenal? No repair? Whatever is balanced).

Liu Bang, the first Emperor 

Han Xin,his brilliant general

Wei Qing, a later great cavalry general under Emperor Wu.

only the Han Xin's design makes sense to me,although I'm interested to know what exactly this Northern and Southern Army bonus is referring historically to.

Liu Bang was not a great individual fighter,or a tactical battlefield commander. His success came largely through his own charisma and the ability to recognise talent.His rule is also known for lower taxes and agricultural reforms so, the cavalry bonus makes no sense to me. If anything, his bonus should be a economy focused hero,or atleast something a bit more non-combatant. 

now here is the problem for which I made the entire post:

WEI QING.

he was LITERALLY KNOWN for his horsemanship and praised by his emperor for it. WHY DOES HE THEN RIDE A CHARIOT? he was also known for his marksmanship,so it would be fine to make him an archer cavalry hero, probably the first of its kind in the vanilla game.

I also suggest adding the cavalry bonus to Wei Qing,as he was the Grand Master of the Horse- Grand General,

General of the Chariots and Cavalry.

additionally with these big changes,I believe his aura of reducing enemy cav attack should remain. the 30m will be less powerful when you realise he is an archer

Would it be possible to move units laterally along a wall towards the actual attack replacing fallen units? (this could happen from segment to segment, we could e.g. even replenish from the barracks to auto-replace a fallen defender using some auto-queue mechanism).

Not sure it would work as between wall segments there are turrets that have a different garrisoning scheme. Would "teleporting from wall segment to segment be a solution (using the rally point mechanism) ?

Such a feature might strenghten defense and actual use of walls, but not in an unfair fashion- siege engines would still be much more powerful and eventually break the walling. This would be more a slightly better defense against infantry/cavalry troops attacking.

A side note: the same pathfinding mechanism might be useful some time later when it comes to discussing (short) bridges again 

Issues:

1. The game version text on the top panel takes too much real estate in-game
2. There is no ceasefire feedback to players not using the game time overlay
3. It is not easy to identify if Wonder Win or Regicide is active - I have seen this determine matches

Actions:

1. Move the game version info to an About page available in-game freeing space on the top panel
2. Add color and countdown status to the diplomacy icon 
3. Enhance the Match Settings icon to give feedback about Wonder Win and Regicide 

I'll post some screenshots in comments below this for discussion.

Disregard, looks like its an older version

My name is Luther, and I am a Computer Science graduate student located in Mexico.

I am currently working on my Master's thesis, which focuses on formal verification. For my research, I am planning to use the 0 A.D. engine's network code as a case study.

I would love to get in touch via email, Discord, or any other method with a developer who is familiar with the game's network architecture to ask a few questions about it.

Any info would be highly appreciated!

Thanks,
Luther

Vulkan drivers from different vendors are usually much lighter than GL ones. That's the way to have less driver bugs and crashes. But we still need testing how it works on different hardware. So everyone who has a Vulkan compatible device please try to enable it in options (along with feedback). If you're able to run SVN then you already can test it. Else wait for the next RC. Note: to run the game you'd need to download and install a separate mod with precompiled shaders (it'll be bundled in RCs and the Release): https://releases.wildfiregames.com/rc/0ad-spirv.zip. Vulkan can't run pure GLSL shaders (which we use for GL), it uses a special binary format for shaders: SPIR-V.

Vulkan allows us to use different interesting features. For example it allows to select the most appropriate GPU to use. It means no more crashes because of wrong GPU, I hope  Also Vulkan supports multithreading.

If you still have some time you could run the game with validation enabled. It makes the game slower but validates a lot more different internal things. It should help to make Vulkan stable for the release. To enable validation you need to add the following lines to your usef.cfg:

renderer.backend.debugcontext = "true"
renderer.backend.debuglabels = "true"
renderer.backend.debugmessages = "true"
renderer.backend.debugscopedlabels = "true"

Known issues:

• Screenshots aren't implemented yet, but going to be during Feature Freeze rP27552
• Some precompiled shaders are missing, please report if the game says so
• macOS isn't supported yet, but we have plans to do so via MoltenVk rP27488
• Missing silhouettes rP27418
• Unsupported depth formats cause an assertion rP27421
• Stretching on window resize after fullscreen switch rP27422

A: help people who are hosting a match of 3 or more people, and have to go mid-game

B: fix hosts being able to cheat the ratings system by exiting the match, the other players could then defeat they’re uncontrolled units and structures.

Structure regeneration rate 5 (garrison 1.0) I assume that means the building regenerates its capture points 5 every 1 second?  If a champ has capture attack of 5, and building regen is 5 and no one garrisons then that building can never be capture? 

If building is 5, and you garrison 1 (+6/1 second?) then 2 champs trying to capture the building would keep losing 4 points per second?  Still think some buildings may be a little too easy to capture, trying to figure out how to maybe tweak them.

Also building loot, that only happens if you attack the building and destroy it?  Not if you capture correct?