Additional properties needed for DROID (Maybe?)

[Goth Zagog-Thou]

In the new API I see something that could be added. Maybe it's already there but not obviously so.

I find myself looking around at the OBJECT and DROID properties, and I'd really like to know if I can specify a droid template in a var.

for example, I'm at:

Code: Select all

var TacSergeant = droid("P0Cam4GibbsPythonTwinAssltHT");

and I find myself wishing for:

Code: Select all

var TacSergeant = droid("P0Cam4GibbsPythonTwinAssltHT").template;

And it's good to go.

Is that property there, and if not, what do I use in it's place?

[aubergine]

What's missing in particular is getTemplate()

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)

[Goth Zagog-Thou]

And I see that enableTemplate() is ONLY to be used for ConstructionDroid.

What about simply using:

Code: Select all

addDroidFromTemplate(player, x, y, name, "templateName");

instead?

[aubergine]

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.

[Goth Zagog-Thou]

Or we could just use addDroidFromTemplate(player, x, y, "template") since we can name it whatever we want when we var it.

[aubergine]

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.

[Goth Zagog-Thou]

If it works, why not have the two new functions?

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?

[Per]

I don't understand. Why do you want to use templates?

My recommendation is to ignore templates completely. It is much easier to just create droids from components directly.

Hopefully one day templates.txt can die.

[aubergine]

+1 for .txt death.

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.

[aubergine]

Also, this would allow cam scripts to clearly specify their templates at the top of the .js file, for example:

Code: Select all

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.

[Goth Zagog-Thou]

Alrighty. I'll go according to best practices then.