Leaderboard

Was in need to query the templates more often than acceptable and code got littered with ifs, switches and very long condition lines. So I've spend my bot a triple store and its own query language. This is how it loads: : reading 1188 templates : 65/1188 nodes for athen : 139/1188 nodes for gaia : ignored: Brit(1), brit(59), cart(84), celt(69), gaul(55), hele(93), ..... : loaded 0/0 nodes from Hannibal.Data.RootNodes : created 79/ 79 nodes for classes : created 41/ 41 nodes for technologies : created 14/ 14 nodes for resources : created 4/ 4 nodes for resourcetypes : created 613 edges on member (entities membering classes) : created 613 edges on contain (classes contain entities) : created 111 edges on provide (entities providing resources) : created 165 edges on gather (entities gathering resources) : created 274 edges on build (entities build entities) : created 26 edges on train (entities train entities) : created 46 edges on hold (entities holding class) : created 3 edges on heal (healer heal classes) : created 39 edges on research (entity researches technology) : created 57 edges on require (entities require technology) : created 57 edges on enable (technology enables entities) : created 12 edges on accept (entities accepting resourcetype (dropsites)) : created 156 edges on carry (entities carrying resourcetype (ships, trader, gatherer)) : have 2 civs, 13 verbs, 342 nodes, 2172 edges: : have [accept, build, carry, contain, enable, gather, heal, hold, member, provide, require, research, train]The database has nodes and edges, edges represent a verb and have a direction. Nodes have a unique name. So you start a query with some nodes. Here are a few sessions, 'i' denotes the query (a plain string), 'o:' the parse tree and R a result line: Parser: i 'healer, hero' : o: ["healer, hero"] Q: executed: msecs: 0, records: 2 R: node: healer R: node: heroQueries always return nodes and obviously two classes return two class nodes Parser: i 'healer, hero CONTAIN' : o: ["healer, hero",["CONTAIN"]] Q: executed: msecs: 0, records: 6 R: node: units.athen.support.healer.a R: node: units.athen.support.healer.b R: node: units.athen.support.healer.e R: node: units.athen.hero.iphicrates R: node: units.athen.hero.pericles R: node: units.athen.hero.themistoclesHere I added a verb after and now the query has a direction, it points from classes to entities. All verbs are keywords and uppercase. LIMIT, SORT, RAND, WITH are keywords too. Parser: i 'infantry, hero CONTAIN SORT > costs.metal' : o: ["infantry, hero",["CONTAIN"],["SORT","> costs.metal"]] Q: executed: msecs: 3, records: 21 R: node: units.athen.hero.pericles, metal: 200 R: node: units.athen.hero.themistocles, metal: 200 R: node: units.athen.hero.pericles, metal: 200 R: node: units.athen.hero.themistocles, metal: 200 R: node: units.athen.champion.infantry, metal: 80 R: node: units.athen.champion.marine, metal: 80 R: node: units.athen.champion.ranged, metal: 50 R: node: units.athen.infantry.archer.a, metal: 50 R: node: units.athen.infantry.archer.b, metal: 50 R: node: units.athen.infantry.archer.e, metal: 50 R: node: units.athen.infantry.javelinist.a, metal: 50 R: node: units.athen.infantry.javelinist.b, metal: 50 R: node: units.athen.infantry.javelinist.e, metal: 50 R: node: units.athen.hero.iphicrates, metal: 0 R: node: units.athen.infantry.slinger.a, metal: 0 R: node: units.athen.infantry.slinger.b, metal: 0 R: node: units.athen.infantry.slinger.e, metal: 0 R: node: units.athen.infantry.spearman.a, metal: 0 R: node: units.athen.infantry.spearman.b, metal: 0 R: node: units.athen.infantry.spearman.e, metal: 0 R: node: units.athen.hero.iphicrates, metal: 0The syntax is simple, it starts either with nodes or a verb clause. Then you may put one verb clause after another verb clause to traverse the mesh. [ nodes | VERB [prop [, prop, [...]]] [WITH prop op value [, prop op value, [...]]] [SORT op prop [, op prop, [...]]] [LIMIT value] [RAND value] [VERB [...]]]The idea is the DB represents the involved civilisations, it's a knowledge base of their capabilities. Who can do what, what does it cost and how long does it take. Next step is to retrieve not only templates but real game units, buildings, etc. and in the far future queries written in SPARQL. Currently the code is not optimized and I don't know what happens when 8 bots load their own triple store each with 8 civilisations. You start the whole thing like this: civs = new Hannibal.Civilisations(this, ["athen", "gaia"], this.settings.templates);HCQ = Hannibal.Civilisations.Queryquery = new HCQ(civs , "infantry, hero CONTAIN SORT > costs.metal");nodes = query.execute();Code (still hot, but working) is attached, comments welcome! querylanguage.zip

0 A.D. Main log (warnings and errors only) WARNING: JavaScript warning: gui/summary/summary.js line 576 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 591 reference to undefined property teams WARNING: JavaScript warning: gui/summary/summary.js line 808 reference to undefined property teams ERROR: JavaScript error: gui/summary/summary.js line 809 Error: Invalid value for setting 'size' init([object Object],(void 0))@gui/summary/summary.js:809 ERROR: GUI page 'page_summary.xml': Failed to call init() function ERROR: CRenderer::EndFrame: GL errors occurred commands.txt

Perhaps think about possible units we could include in a "Mercenary Camp" system, where all players, regardless of civ, can capture a Gaia "Mercenary Camp" and then train specific units from it. Here's how I have proposed it works: We can have multiple mercenary camps in Atlas, each one having slightly different mercenaries available from it based on culture or biome (say, "Middle Eastern", "Anatolian", "Italian", "North African", or whatever) with around 2 units available based on this culture, and then the Merc Camp would also have 2 or so units available based on the owning civ (say, Cretan Toxotes and Thracian Peltasts for Athenian ownership, "Samnite Swordsman" and "Celtic Auxiliary Cavalry" for Roman owners). So, up to 4 units available from the Merc Camp; 2 based on the map or maptype and 2 based on the owner of the camp. With that in mind, what kind of "Merc" units would you choose for the Persians? Maybe Sacae (Sythian) Horse Archer and Cardaces Hoplite and perhaps Indian War Elephant? This way we can give the Persians some extra strong units, but only if they can manage to capture the strategically important Mercenary Camps? These mercs would have benefits (they cost no population room and they are trained at 'Elite' levels), but a few minor drawbacks (they keep "loot" to themselves, so the player doesn't get any of the "Loot" they get from kills, and you can only train a limited number of each).

Something like this? Sorry for the blurry text.

The movie has nothing to do with AoM. It's about the forgotten empires expansion for AoE 2.

Possibly the Satrapy's Court building could be used for this very purpose.

I can't be bothered to review all the French translations so I'd be more than happy to leave it to voluntary translators. I know I've added a few (like 10 of 'em perhaps ), but that's about it. If there's some sort of specific issue that can't be decided without team input I'd be happy to help however.

Making a mod isn't that hard (or shouldn't be, if you have other questions, you can always ask them). But spreading is harder, it requires users to find your mod, download it, and extract in the right place. After that, 0 A.D. needs to be launched with the right cli option. This process could be made easier. As easy as an in game download and use button. When mods get more exposure, more people will install them, and more will start to mod.

Problem solved! It looks like a bug in VisualStudio, but passing the JS::Value as reference instead of using a return value works around the problem. It was a bit of work to adjust all implementations of ToJSVal and change all call-sites, but I don't see any disadvantages for the final result. I've registered at Github too and created a branch for the SpiderMonkey upgrade. You can get it here: https://github.com/Yves-G/0ad It should build as normal on Windows and Linux now and shouldn't require any additional steps. Feedback is appreciated but be aware that it still contains some known issues too. EDIT: On Linux you need to install libnspr-dev

I Agree with that, but we need a someone do the option graphic settings in Menu game.

I'm going to try a new format for the spatial subdivisions which would remove the need for uniqueness sorting, potentially improving efficiency. Basically it's like spatial subdivisions but subdivisions would be a lot smaller ( like about a big bigger than a building footprint, so that most entities boundaries are smaller than a single subdivisions). You only add entities to the subdivisions their center is in, and when you range-query you return the subdivisions around your query too (see schema) sp that you're sure to get it. Entities that are too big would not be put in the subdivisions but at the basic level, so all entities would be considered "close" to all other entities. If we can manage to have few enough of those, this should work well. On the schema, the black lines are subdivision limits, the red square the range query, and the reddened squares are what would be returned by the existing query system, which needs to be sorted for uniqueness, while my method would also return the green squares, but won't sort. So maybe that'll be faster, maybe it won't be, we'll see. My hope is that if we make subdivisions just bigger than most item bounds, we'll have small subdivisions so we wouldn't add too many items, yet it'll be quite efficient since it's still all vectors and mostly static, and we won't have to worry about doubles and stuff like that which would allow faster queries. Maybe.