Javascript API documentation

[aubergine]

When an object is destroyed it's label should also be removed, at least that's how labels defined in labels.ini work. Same should be true of addLabel() labels IMHO.

Would be nice for debugging if getObject() returned undefined = label not found, null = label found but no object.

@NoQ: Also, remember that labels are shared amongst scripts - more info here: https://warzone.atlassian.net/wiki/display/jsapi/Labels

[Per]

Labels are removed the moment the object they point to is destroyed. So "label found but no object" should never happen.

[NoQ]

So "label found but no object" should never happen.

Well ... it does, somehow. I'll try to investigate more closely, but i'm sure i had this assert fail:

Code: Select all

		case OBJ_DROID:
			psDroid = IdToDroid(p.id, p.player);
			SCRIPT_ASSERT(context, psDroid, "Droid [%s] not found!", label.toUtf8().constData()); // this
			ret = convDroid(psDroid, engine);
			break;

[stiv]

Race condition?

[Per]

Not a race condition.

Ok, I see I simply had not implemented the remove-label-if-object-dies code yet. And perhaps for good reason. So what I did was that I changed it the way aubergine suggested: If label does not exist, an undefined is returned, and if object does not exist, then a null value is returned.

[Goth Zagog-Thou]

I ran into a problem trying to use eventResearched(). It dosen't work like the wzscript researchCompleted() function does. I ended up having to use the wzscript function.

eventResearched() seems to be based upon a structure rather than a player, and that's fine for AI's pursuing research paths. Could it be expanded to be:

Code: Select all

eventResearched(research, player, structure [optional]) {
   // do stuff
}

[aubergine]

You can get the player from structure.player property

[Per]

I'd rather not change its function parameters like that, since that would break backwards compatibility.

I'm not sure what the problem is, though? Perhaps if you try to explain it, we can find a workaround

[aubergine]

Maybe its when an ally researches something - the event is triggered, but lab parameter is undefined, meaning you know what's been researched but not by whom? I can see that being an issue in custom campaign scripts...

[Goth Zagog-Thou]

Heh! Didn't occur to me to use structure.player.

I'm still unclear as to whether you need to enumerate the player's research structures or not. For example, would using

Code: Select all

eventResearched("MG1Mk1", structure.player) {
   // do stuff
}

be enough, or do I need to enumStruct() first?

Sorry for the noob questions but I'm really trying my best to wrap my head around .js.

[aubergine]

No, the structure param is a structure object:

Code: Select all

function eventResearched(tech, lab) {
   // tech = research object
   // lab = structure object

   var player = (lab) ? lab.player : undefined;
   // if lab not specified, no way to know who did the research
   // but the fact this event was triggered means that 'me' can now use 'tech' (it's been researched)
}

Docs: https://warzone.atlassian.net/wiki/page ... eId=360594

In JS, the event triggers are always handled by the JS API. Unlike WZscript where you had to define them yourself. So eventResearched() will always be triggered when player gets new tech, so long as you've defined the function (see example above). And that function will be the only event handler for research completions, so you do the switching based on what was researched within the handler, rather than having separate handlers with separate triggers.

[Goth Zagog-Thou]

Thanks buddy, that helps a lot.

[NoQ]

changed it the way aubergine suggested: If label does not exist, an undefined is returned, and if object does not exist, then a null value is returned.

Yay, almost works now
Can we remove the error message when the label is not found? Or just reduce it to LOG_INFO or LOG_SCRIPT. Or provide a way to check whether a certain label exists, without throwing an error if it doesn't.

[NoQ]

Or provide a way to create a label that points to null (:

upd: whoops? Already decided?

[aubergine]

• A repeat timer will stop if it returns false. This is just a convenience which does the same as calling removeTimer() but shorter.
• If a timer is set (or "queued"), and a timer with the same name and arguments is already set, it will either replace it, if time to first invocation is shorter, or be dropped. The reason for this is that it is very easy to call timers too frequently without knowing it, causing lots of unnecessary CPU use, and checking each time is cumbersome. I discovered this when investigating CPU spikes in Semperfi-JS recently.

Did either of these two things get implemented?

EDIT: I'm kind of hoping not.