Page 20 of 25
Re: Javascript API documentation
Posted: 31 Jan 2013, 15:01
by 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
Re: Javascript API documentation
Posted: 31 Jan 2013, 16:09
by Per
Labels are removed the moment the object they point to is destroyed. So "label found but no object" should never happen.
Re: Javascript API documentation
Posted: 31 Jan 2013, 16:51
by 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;
Re: Javascript API documentation
Posted: 31 Jan 2013, 20:49
by stiv
Race condition?
Re: Javascript API documentation
Posted: 31 Jan 2013, 21:13
by 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.
Re: Javascript API documentation
Posted: 31 Jan 2013, 23:12
by 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
}
Re: Javascript API documentation
Posted: 01 Feb 2013, 00:10
by aubergine
You can get the player from structure.player property
Re: Javascript API documentation
Posted: 01 Feb 2013, 00:30
by 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
Re: Javascript API documentation
Posted: 01 Feb 2013, 00:34
by 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...
Re: Javascript API documentation
Posted: 01 Feb 2013, 00:38
by 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.
Re: Javascript API documentation
Posted: 01 Feb 2013, 01:10
by 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.
Re: Javascript API documentation
Posted: 01 Feb 2013, 01:33
by Goth Zagog-Thou
Thanks buddy, that helps a lot.
Re: Javascript API documentation
Posted: 01 Feb 2013, 14:11
by NoQ
Per wrote: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.
Re: Javascript API documentation
Posted: 03 Feb 2013, 14:31
by NoQ
Or provide a way to create a label that points to null (:
upd: whoops? Already decided?
Re: Javascript API documentation
Posted: 06 Feb 2013, 14:54
by aubergine
Per wrote:
- 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.
