Javascript API documentation

[aubergine]

I'm still scratching my chin over the annotation stuff. Do you have any examples of how it would be used?

Is the primary use so when we construct a droid we can store what propulsion, body and turrets it's using? If so that would be better done by having an annotation param on buildDroid(), or, much better, properties for propulsion, body and turrets (array so as to handle dragon bodies) that get set automatically for all droids.

Having those standard properties for droids would make AI adaption, droid recycling, and a whole bunch of other stuff much easier. Exposing the droid's creation time (can't remember the C++ property that defines that but saw it somewhere on my travels through the WZ source code) would be useful as well in terms of finding out how old a droid is (not sure what would happen for droids placed by map makers though?

Also, can I put in another request for getting some extra properties on playerData objects - player type (PLAYER_HUMAN, PLAYER_SCAV, PLAYER_AI, PLAYER_NONE) and if possible player name?

[NoQ]

How many groups an AI is allowed to have? Is it limited to 0..9 as it is for a human player?

[Per]

How many groups an AI is allowed to have? Is it limited to 0..9 as it is for a human player?

Those are two different kinds of groups. There is no limit (in practice).

[Artofeel]

or, much better, properties for propulsion, body and turrets (array so as to handle dragon bodies) that get set automatically for all droids.

since it's already have, no? Or the old AI wzscript does not work on a new JS AI engine?

• * droid.x
  * droid.y
  * droid.z
  * droid.id - unique ID number
  * droid.player - player ID
  * droid.type - one of OBJ_DROID, OBJ_STRUCTURE, OBJ_FEATURE
  * droid.health - %age number of body points left
  * droid.clusterID - the cluster the object is a member of
  * droid.target - target of the object (in case of a multi-turret object returns target of the default weapon)
  * droid.order - current order of the droid
  * droid.orderx - target location of the droid order
  * droid.ordery - target location of the droid order
  * droid.action - current action of the droid
  * droid.body - the BODY of the droid
  * droid.propulsion - the PROPULSION of the droid
  * droid.weapon - the WEAPON of the droid
  * droid.selected - holds TRUE if droid is currently selected
  * droid.group - the GROUP droid belongs to

The only thing missing, is the type of sensor. For example, when I try to link the VTOL unit to sensor unit, I want to be sure that this Wide Spectrum sensor or VTOL Strike\CB sensor.
Also droid.target only work with weapon, it would be great if it worked with sensor\repair\etc turrets

[aubergine]

Lots of those properties are missing from the droid objects in the JS API:

https://warzone.atlassian.net/wiki/disp ... oid+object

Items missing are:

* droid.clusterID - the cluster the object is a member of
* droid.target - target of the object (in case of a multi-turret object returns target of the default weapon)
* droid.orderx - target location of the droid order
* droid.ordery - target location of the droid order
* droid.body - the BODY of the droid
* droid.propulsion - the PROPULSION of the droid
* droid.weapon - the WEAPON of the droid

[NoQ]

Or the old AI wzscript does not work on a new JS AI engine?

They're separate. You use either one or another, not "one over another". The functions and object properties have to be re-implemented, and they aren't yet (:

[Per]

Added .born field to all game objects, which is the game time at which the object came into the world. A game time of 2 means it was added to the map on start. Added .body and .propulsion string fields to droids. This is their body and propulsion components. The turret/weapon component is much more complicated to add, and I think some cleaning up in that code/data is warranted before finalizing any API for that.

[Emdek]

For turret / weapon it should be probably simple array (I like turrets more, since it is more generic), and there could be concept of weapon handles for future use (like where the weapon / turret is mounted), as properties of turret object (it could maybe also have type property, as I think that we already can have sensor in weapon on Dragon, or we can't?).

[aubergine]

I think the weapon/turret handles should be defined on the body, but that's for future ponderance. I'm already taking that approach with my concept of JS game objects / mutators, but won't be ready to show much results for quite some time.

If you put a sensor on Dragon, it won't let you have a weapon in the other slot

Anyone know what the body ID is for Super Transporter and also the two cyborg bodies? Found answer in body.ini

[Emdek]

aubergine, well, now, but think about future.
Also I'm including place for structures with multiple mount points (consistent API), I want it to be future proof and flexible enough.

[aubergine]

@Emdek ditto! Once I've got some more done on my latest JS project, I'll post the results in the mutator wiki and you can take a look and see if we're thinking along the same lines.

[aubergine]

Droid object docs updated: https://warzone.atlassian.net/wiki/disp ... oid+object

Wherever possible I try and update that wiki with the latest information, even when new features aren't currently released. If you see anything I've missed, please post a comment on the associated wiki page (it should allow anon comments, or you can sign-up via the login link at top-right) -- I get instant notifications when comments are posted and will do everything I can to update docs quickly.

[Emdek]

Yes, that is best approach, as generating from backlog can be painful.

[milo christiansen]

I think this is a complete list of all the functions needed before cam 4 can be ported. Not a lot to say except some are probably optional and I may have missed one or two

[Per]

Added functions setAssemblyPoint(struct, x, y), addFeature(x, y, name), setAlliance(player1, player2, value), and removeObject(obj[, bool special effect]) to 3.2. Deprecated removeStructure(struct).

Milo, concerning your list, I made a check run down of how I think it is currently met:

structButNoWallsInArea --> not needed
killStructsInArea --> not needed, use removeObject(xx, true)
numDroidsInArea --> not needed
droidInArea --> not needed
flushConsoleMessages --> not needed?
numStructsInArea --> not needed
createAlliance --> use setAlliance(p1, p2, bool)
breakAlliance --> not needed, see above
destroyFeature --> not needed, see removeObject(xx)
vanishUnit --> not needed, see removeObject(xx)
getDroidCount --> not needed
addFeature --> addFeature added
setAssemblyPoint --> setAssemblyPoint added

For the area functions, you can use enumRange() to iterate over objects instead.

TODO
removeMessage and addMessage

I still hope to implement a sane version of addMessage, but if this is preventing anyone from working on a javascript-based campaign, I can quickly implement the same hacky addMessage that wzscript has as a stopgap measure.