Forums

There is some JavaScript logic going on in gui and simulation/ components folders. They work by calling exposed JS functions in the engine, which are defined in a script interface.cpp in the engine source code.  To implement lua, we probably need to change the definitions in scripting.cpp to adapt for lua calls. Then the mods side js needs to be replaced with lua language. A solution to not overwite completely is to add a parallel list of exposed lua functions at the end of the current scripting.cpp file then call them using lua scripts in the mod folder where necessary 

TG. If it's a 1v1, I would just grab all and push. My superior inf boom will destroy them. But in a TG, especially when I have a weaker ally, it's really difficult  I will try this  

Stay compact. The outer wood line should be the only one direction to stretch for the first minutes Stay busy eco wise: If you need to abandon the outer wood line, use the small wood patch at the cc or gather at the mines although you don't need it atm. Try to intersect / sandwich the camels. Chase with inf while cav come from behind small towers are weak, expensive but sturdy. They need no apm, so you can focus more on eco. Your ally should sponsor them to get you out of this situation. But it's more a solution a weaker player can use to resist a better player. If you boomed with too many female it can be already too late. Some strategic decisions made in fow can already decide the game. I'd say: balanced pop > high cav; high cav > high fem; high fem > balanced pop (if not outplayed by skill) Some civs are just weaker than others

Hi ! 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 ?

«c'est la vie...»

No chocolates.

If you want to use AO you need to have a second UVMap.