3.2 JS API Wishlist :)

For AI and campaign script related discussions and questions
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 25 Oct 2012, 05:31

addLabel(obj, label) and removeLabel(label)

PARTIAL IMPLEMENTATION: addLabel()

Currently, labels can only be defined by map makers while designing a map.

I think it would be interesting to allow scripts to and and remove labels at runtime, if it's not too much effort.

When adding a label, an object must be specified - either a game object (droid, structure, feature) or an AREA or POSITION object. If the label is already defined, an exception gets thrown rather than overwriting the existing label (it will be trivial to write a little API to manage my labels).

In the AI I'm working on, I'm trying to avoid having too many global vars because often the data I have is too complex to go in a save game (eg. it has function properties or references to other objects).

So, if the custom labels get included in save game data, it would be a great way for me to persist information across the save/load cycle.

enumLabels() - new params

It would be useful if enumLabels() had a couple of new params:

* prefix -- if specified, enumLabels() returns only labels starting with prefix (string). To return all labels, either don't specify a prefix or pass in an empty string.
* player -- optionally filter the list to labels associated with objects that are owned by a specific player (eg. 99 for features, etc).

Clarification on labels

If a label is assigned to a structure that was pre-placed on the map by the map designer, and baseType setting results in that structure being removed at start of game, does the label also get removed?
Last edited by aubergine on 12 Jan 2013, 18:41, 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

User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha » 25 Oct 2012, 09:20

aubergine wrote:
enumLabels() - new params

It would be useful if enumLabels() had a couple of new params:

* prefix -- if specified, enumLabels() returns only labels starting with prefix (string). To return all labels, either don't specify a prefix or pass in an empty string.
* player -- optionally filter the list to labels associated with objects that are owned by a specific player (eg. 99 for features, etc).
IMHO It is more easy to do it in javascript via Array.filter

Maybe it will be good to change disign of api in that way:
all C++ function name stars from _
game has api.js (near rules.js)

Code: Select all

function addLabel(obj, label) {
   return _addLabel(obj, label);
}

function enumLabels(prefix, player) {
   var labels = _enumLabels(obj, label);
   if (prefix) {
         var prefixFilterFuction = getHasPrefix(prefix)
         labels = labels.filter(prefixFilterFuction) 
         }
   if (player) {
         var playerFilterFuction = getHasPlayer(prefix)
         labels = labels.filter(playerFilterFuction) 
         }
    return labels;
}
http://addons.wz2100.net/ developer

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 25 Oct 2012, 12:30

Yes, it's easy to do in JS with post-processing, however if lots of things have labels and enumLabels() is generating a whole bunch of objects and sending them to JS env just so I can find the one or two that I'm interested in. So the filtering would be best living in the C++ code because it reduces the amount of object creation required.

As for wrapping API functions in JS, I don't think prefixing C++ functions with an _ is a good idea, mainly because it's WZ terminology for string localisation (eg. see _() function). There are other robust ways to wrap JS API functions / properties / etc., in JS code more transparently, whilst still retaining access to the originals (eg. via a property on the wrapper function) should they be needed.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha » 25 Oct 2012, 12:53

aubergine wrote:Yes, it's easy to do in JS with post-processing, however if lots of things have labels and enumLabels() is generating a whole bunch of objects and sending them to JS env just so I can find the one or two that I'm interested in. So the filtering would be best living in the C++ code because it reduces the amount of object creation required.
This needs some profiling. I think it is not bottleneck.
As for wrapping API functions in JS, I don't think prefixing C++ functions with an _ is a good idea, mainly because it's WZ terminology for string localisation (eg. see _() function).
It has same level of common as enum and enumLabels.
There are other robust ways to wrap JS API functions / properties / etc., in JS code more transparently, whilst still retaining access to the originals (eg. via a property on the wrapper function) should they be needed.
Any approach should have backwards compatibility.
http://addons.wz2100.net/ developer

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 25 Oct 2012, 13:50

Duha wrote:This needs some profiling. I think it is not bottleneck.
It's not a bottleneck yet, because nobody is using it that much. But it's not simply about performance, IMHO the changes/extensions I've requested are fairly common sense, and suit being centrally implemented in the API rather than have scripts randomly come up with their own approaches.

The API is increasingly well documented (both by the devs and also with external docu such as my wiki), scripts generally don't get so much attention to documentation of what their code is doing. So putting useful things in to the API also results in those useful things getting documented better.
Duha wrote:
As for wrapping API functions in JS, I don't think prefixing C++ functions with an _ is a good idea, mainly because it's WZ terminology for string localisation (eg. see _() function).
It has same level of common as enum and enumLabels.
I don't understand what you mean by "level of common".
Any approach should have backwards compatibility.
I don't see how it would break backwards compatibility - if new params are added to the JS API itself, they just default to making things work the usual way and thus backwards compatibility is retained.

For example, if enumLabels() gets new params, and those params aren't specified, it will work just like it does currently.

The stuff I mentioned about having a property linking to original API function on a JS-wrapped version of that function was specific to the way I might code things. I grab a reference to the original function then eval some code in to global scope to replace the original reference to that function to a new function of my own, and have a property on my function that references the original one should I want to still access the original one -- I just do it that way instinctively so that I don't have to go back and create such a reference at a later date. So far, whenever I've shoehorned one of my functions in to replace/wrap the native JS API function of same name, I've never wanted to even use the original JS API function again. But I like to think one day that some of my scripts will be interesting enough for others to want to use them, and so provide a "backdoor" to the original JS API function just in case someone else wants to still use it directly for some reason I've not thought of.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha » 25 Oct 2012, 15:31

aubergine wrote:
Duha wrote:This needs some profiling. I think it is not bottleneck.
It's not a bottleneck yet, because nobody is using it that much. But it's not simply about performance, IMHO the changes/extensions I've requested are fairly common sense, and suit being centrally implemented in the API rather than have scripts randomly come up with their own approaches.
My sudgestion was to make middleware with new functional. It is easy to do. And after this API will be tested some features will be ported to C++ code.
The API is increasingly well documented (both by the devs and also with external docu such as my wiki), scripts generally don't get so much attention to documentation of what their code is doing. So putting useful things in to the API also results in those useful things getting documented better.
That way don`t change you documentation (in any case you will change it)
Duha wrote:
As for wrapping API functions in JS, I don't think prefixing C++ functions with an _ is a good idea, mainly because it's WZ terminology for string localisation (eg. see _() function).
It has same level of common as enum and enumLabels.
I don't understand what you mean by "level of common".
Nevermind.


I don't see how it would break backwards compatibility - if new params are added to the JS API itself, they just default to making things work the usual way and thus backwards compatibility is retained.

For example, if enumLabels() gets new params, and those params aren't specified, it will work just like it does currently.

The stuff I mentioned about having a property linking to original API function on a JS-wrapped version of that function was specific to the way I might code things. I grab a reference to the original function then eval some code in to global scope to replace the original reference to that function to a new function of my own, and have a property on my function that references the original one should I want to still access the original one -- I just do it that way instinctively so that I don't have to go back and create such a reference at a later date. So far, whenever I've shoehorned one of my functions in to replace/wrap the native JS API function of same name, I've never wanted to even use the original JS API function again. But I like to think one day that some of my scripts will be interesting enough for others to want to use them, and so provide a "backdoor" to the original JS API function just in case someone else wants to still use it directly for some reason I've not thought of.
My sugestion was to create api that is completely replaces c++ api. when dev dicide to change internal realization from
_enumLabels(options) to enumObjectList('label', options) no one get hurt. It is like buffer between c++ and released mods.
http://addons.wz2100.net/ developer

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Post by Per » 25 Oct 2012, 15:45

aubergine wrote:addLabel(obj, label) and removeLabel(label)

Currently, labels can only be defined by map makers while designing a map.

I think it would be interesting to allow scripts to and and remove labels at runtime, if it's not too much effort.
That is an interesting (ab)use of labels. I will try to add that.
aubergine wrote:Clarification on labels

If a label is assigned to a structure that was pre-placed on the map by the map designer, and baseType setting results in that structure being removed at start of game, does the label also get removed?
Yes.

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 25 Oct 2012, 21:47

cancelProduction(factory)

Cancels the current production order at the specified tank/cyborg/vtol factory, returning some power to the player.

Unlike humans, AIs can't currently cancel a production order to free up a factory or get some power in emergency situations.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 26 Oct 2012, 02:26

Ability to specify preferred colour in .ai files

Hey, I'm making an AI that's purple with green leafy bits, these things are important d: ...yes, that's a backwards :p

Code: Select all

[AI]
name = "Egg Plant v0.000001"
js = eggplant.js
tip = "Purple with green leafy bits."
colour = Purple,Infrared,Ultraviolet,Pink
Colour names taken from https://warzone.atlassian.net/wiki/page ... Id=7635546 (and Brown doesn't look remotely brown BTW...)

If the first colour isn't available, it tries the next and so on. If none of the listed colours are available, WZ chooses an available colour at random. Player can still override the colour in player setup panel.

I doubt this will ever be implemented, but putting the idea up just in case (:
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 27 Oct 2012, 23:59

Tweak to .range property of DROID and STRUCTURE objects

Currently its unclear if .range will give sensor range on objects that have a sensor, or whether .range is purely for weapon range.

Would it be possible to add a new property and clarify the old property:

* .weaponRange = max range of weapon (null if no weapon)
* .sensorRange = max range of sensor turret / or innate sensor ability

IIRC, all structures/droids have some innate sensor range, regardless of whether they have a sensor attached or not. So even an oil derrick would have a value for .sensorRange, it would just be somewhat small compared to a structure or droid that has a dedicated sensor turret.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
Duha
Trained
Trained
Posts: 287
Joined: 25 Mar 2012, 20:05
Location: SPb, Russia

Re: 3.2 JS API Wishlist :)

Post by Duha » 28 Oct 2012, 09:45

Logs:

Add special log format for scripts:

Code: Select all

info    |11:35:18: [script]
Force syntax errors to block game start. Usualy all scripts loads at the begining and syntax error can be checked before game starts.

For example if you make syntax error in rules.js it will not be shown in console, only in logs. game will continue.

Code: Select all

info    |11:35:18: [loadPlayerScript:390] Syntax error in multiplay/skirmish/rules.js line 1: Expected `;', `;'
info    |11:35:18: [loadPlayerScript:390] Assert in Warzone: qtscript.cpp:390 (syntax.state() == QScriptSyntaxCheckResult::Valid), last script event: '<none>'
http://addons.wz2100.net/ developer

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3753
Joined: 03 Aug 2006, 19:39

Re: 3.2 JS API Wishlist :)

Post by Per » 28 Oct 2012, 12:21

Duha wrote:Force syntax errors to block game start.
I'd love to, but that requires GUI changes, and the GUI code ... well, you know... :(

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 29 Oct 2012, 20:48

More labels stuff

If possible, I'd like to be able to add multiple labels to a game object, although I appreciate this might cause issues with enumLabels() etc.

Alternatively, the ability to add "tags" to game objects, and have a tags property (array) on game objects returned by JS API.

The more I think of it, tags might be the best approach - that way labels are reserved for map makers, tags are reserved for script developers.

Tags could be things like AP/AT/etc to designate what a unit is best at destroying, along with things like MK1/MK2/etc to indicate that the droid components or structure design is an early tech set-up, thus making later upgrades a bit easier to deal with. Ability to set tags when creating droids (by any method) would be useful as well. Other functions could then be updated to allow filtering by tag, eg. enumDroid/enumStruct/enumArea/enumRange.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 31 Oct 2012, 01:43

cheatActive() function

Implemented! eventCheatMode() added to master :) see: https://warzone.atlassian.net/wiki/page ... d=16777375

Returns:
* true -- cheat mode is active (Shift + Backspace)
* false -- not active

Use cases:

* AI scripts choosing whether to converse with enemy players or not based on debug mode
* Scripts outputting extra info to console/debug/chat when in debug mode
Last edited by aubergine on 04 Dec 2012, 06:24, edited 2 times in total.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: 3.2 JS API Wishlist :)

Post by aubergine » 04 Nov 2012, 00:49

Improved ideas for chat

I've been coding a Chat API that wraps around the WZ 3.2+ chat() and eventChat() features and thus been thinking more about how to deal with chat commands and "hidden" chat messages. I think processing the return value of eventChat() will be the best approach, for both scripts and the WZ JS API.

Implementation:

a) If human sends a chat message via console, trigger eventChat() in the script associated with that human (usually rules.js) before echoing or sending the message.

b) When a chat message is received, trigger eventChat() first before echoing it to the console.

c) If eventChat() returns true: Do not echo message to console; Do not send message to other players.

Note: Messages sent via chat() always send the message but do not echo it to console.

That's basically it. With that set-up I can implement both chat commands and also "hidden" script-to-script chat messages very easily and hopefully it's only minor mods to WZ engine & JS API.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO

Post Reply