Builder group size is incorrectly defined
Closed this issue · 5 comments
I think the group size of a builder group is incorrect.
In grp-builder.js the group size is w.units.size = w.units.size || config.size || 5; but config.size doesn't exist in config.js.
I suppose it should be something like config.civs.[myciv].builders to get a correct amount of builders. Am I right?
Hi Niektb,
short answer: config is the parameter the launch function is called with. Here's the signature:
function launch (w, config)long answer: In the test release everything starts in tester.js.
"1": [T.builder ( "house", 12, 20), "building 20 houses"],This line says: Launch at tick 1 a builder group with 12 units to build 20 houses. A bit up in tester.js you can see 12 and 20 turn into size (units) and quantity (buildings). So, at the time the launch function is called config looks like this:
{size: 12, quantity: 20, building: "whatever the civ has as house"}What you probably miss is the part calculating the amount of houses actually needed and the amount of units to build them in time, because these metrics are different for most civilizations. In future the builder group will get a target from the planner like: Build enough houses for a population of X in Y time. And then the group increases the amount of units until the math fits the plan.
Same will happen to resource groups, they'll get a target defined as flow: e.g. metal/minute, even military will target area/minute or (destroyed healthpoints)/minute.
I hope, this explains the upcoming logic. For testing the current system is clever enough.
Sounds epic. So we finally have both, market influence and reference value!
The reference flow by a higher instance (in this case mayor<-global player AI) yet again increases the epicness of Hannibal because it's the more generic math.
This reference value simulates artificial control of the market, e.g. if the higher instance (e.g. state) sets a reference flow, then the derived reference size of 10 members per baker<-supplier group despite 'bad market' (supply versus demand) prevents the baker group instance(s) from further releasing members if this reference is reached (in addition to personal matters but that's UnitAI).
Despite all the amazing additions to PetraAI, pitching it against Hannibal and Hybrid already leads to quite interesting results.
This probably is the most underestimated mod (while all mods generally are underestimated/valued as we bitterly got to feel).
Well, everything derives from the idea of autonomous groups. In that sense it is an distributed AI.
Distributed system is a great approach.
Both the design of Hannibal and core 0AD is great - and yet they are growing to duplicates, just differing in codestyle and design.
Have tested against PetraAI and it's not there yet. Way too strong at least with the Hannibal settings I could figure.
Put together a short video showing your groups in action:
http://youtu.be/K--SROTPF8Y
Definitely huge work.
Please use the 0AD forum for generic discussion.