We have enumTemplate() and enableTemplate() but no way to actually get a template. Once we can get a template, we can then use addDroid() or buildDroid() to create droids using that template.
The return value for getTemplate() could be a fake droid object, that way the properties are familiar and consistent with the droid that will be built/added.
While on the subject, two other wzscript functions relating to templates would be useful:
addTemplate(template[, player])
canBuildTemplate(factory[,template]) // factory provides player id
And, for added brownie points:
getObjectCost(<fakeDroid | fakeStructure>) // returns how much power it will cost to make the droid or structure
(you could pass in a template, which is a fake droid object, to determine how much power it will cost to produce)
Last edited by aubergine on 17 Jan 2013, 13:13, edited 1 time in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
enableTemplate() *should* only be used for construction droids. that particular function is a bit of a hack to deal with the "can't build a truck until HQ is built" bug from some of the earlier 3.1 betas. I've not investigated that one much.
I assume addDriod() doesn't care whether the components are available or not -- it should be able to create a droid regardless, in which case enableTemplate() isn't necessary for what you want to do.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Well, if there's already functions to add/build a droid, and we can already get list of templates, it seems more logical (to me at least) to just have a function to get a template, then we can choose whether we use that info for addDriod() or buildDroid().
Otherwise, you'd need addDriodDFromTemplate() and buildDriodFromTemplate() functions -- 2 new functions instead of 1.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Isn't the whole point of the new API to do things more easily and directly than the .vlo and .slo method? I see this particular item as being quite necessary, otherwise what's the point of even having a templates.txt anymore?
I see that we now have makeTemplate(player, name, body, propulsion, reserved, turrets...)
Would it be worth allowing addDroid() and buildDroid() to take these fake droid objects as a parameter? (so two syntaxes -- the current multi-param syntax, and a new single 'template' parameter syntax)?
And the canBuildTemplate(factory, template) will also be very useful for the scripts (eg. in campaigns) that define their own templates, to check if a template could be made at the factory without risking it actually being built.
One other thing though, it would be useful to be able to access the templates designed by humans for some scenarios in rules.js. So a getTemplate(name) would still be useful for that specific case.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
var engineerTemplate = makeTemplate( // cyborg engineer
me, // player
"Cyb-Engineer", // name
"Cyb-Bod-ComEng", // body
"CyborgLegs" // propulsion
null, // reserved
"CyborgSpade" // turret 1
);
// some time later...
buildDroid(factory, engineerTemplate);
// or ...
addDroid(player, x, y, engineerTemplate);
In both cases, the player in the template is overridden by the player specified in the buildDroid() or addDroid() function.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO