NoQ has started work on a new Scavenger AI that makes scavs way more effective in the game.
Some key features are:
- An awesome "Crane" construction droid (designed by Berg, made in to a playable unit by Iluvalar)
- The ability for scavs to create their own buildings (thanks to that Crane droid)
- Scavs will now capture oil resources and build up their base defences
- Scavs will launch attacks on players!
I was so impressed with how much better this mod makes scavs that I made a compelling documentary:
Ok, it's a bit tongue in cheek, but seriously give this mod a try - it's soooo much better than the normal scavs.
To get more information and try out the mod, head over to the topic on the main WZ forums.
Great news - droids are getting some long overdue properties in Warzone 3.2:
- born – the gameTime at which the droid was created
- body – the body that the droid is using
- propulsion – the propulsion that the droid is using
I've already updated the docs so for more details see: Droid object 
This past week has been a hive of activity in respect to the JS API, with loads of new features being planned or confirmed for future releases!
DORDER_RECOVER
Cyp mentioned that DORDER_RECOVER should be making it in to Warzone 3.1 Beta 5.
More importantly, the hard-coded restriction that prevented AI scripts from using it has been changed, meaning that your scripts can now pick up oil barrels and artefacts!
DORDER_OBSERVE
Per has confirmed that this constant has been added to the JS API, although it's not yet clear if it will make it in to 3.1 Beta 5 or much later in 3.2.
It's a really useful constant if you use sensor droids because it means they can observe a target not only for their assigned units, but also your base defences.
If you want to start using it in your scripts right away, check out backport.dorder.js which backports the constant all the way to Warzone 3.1 Beta 1!
Object linking
This is still in the discussion phase, however it's likely we'll soon see a way to associate objects with each other. This is going to open up much better ways to manage droids.
A good example of this is when getting multiple construction droids to help build a structure. Currently it's a bit of a pain trying to work out how many droids are building the structure, which in turn makes it difficult to decide whether to order more droids to help or not. With object linking, the structure will contain links to the droids building it, and the droids building it will contain links to the structure they are building. The same sort of thing can be done for attack droids - they can be linked to their victim, and their victim linked to them.
There will likely be a number of functions around this, such as:
- link(obj1,obj2) – create a bi-directional link between two game objects
- unlink(obj1,obj2) – remove the link between two objects
- enumLinks(obj) – get a list of all objects linked to the specified object
I'm also hoping that we'll get automatic linking done by the orderDroidObj() and orderDroidBuild() functions.
If either object is destroyed, the links will automatically break.
Object annotations
Also in the discussion phase is object annotations. This will allow scripts to store arbitrary data on game objects that will persist as long as the game object exists.
I'm still not sure if I like this idea - I can't decide if it's a good thing or a bad thing – but like I say, it's still at discussion phase.
Listing objects in a specific part of the map
This will hopefully make it in to 3.1 Beta 5 - a function that allows you to get a list of game objects within range of a specific point on the map.
Immediately, this will be very useful for sensor droids because it will allow them to move somewhere then get a list of nearby local targets and DORDER_OBSERVE them.
There are lots of other possible uses too. For example, you will be able to get a list of your droids near an enemy droid or structure.
While this sort of thing can be done using the existing API, having a dedicated high-performance function in the JS API will make it much easier and quicker to use.
I'll be writing a backport of the associated functions when they are released.
Improved data persistence
I'm really stoked about the planned changes to data persistence.
Currently, the JS API will try and persist any global vars with the exception of functions, constants and JS API features. This causes all sorts of problems as I outlined in sessionStorage and localStorage.
To my utter amazement, it looks like the new data persistence approach will be very similar to my proposed solution - we'll be getting two new global objects (the names of them are still under discussion):
- <game storage> – will persist data for the current game, including save/load cycle
- <permanent storage> – will persist data across multiple games
This is just huge, I literally did a Chandler dance in front of my laptop when I read the news!
Not only does this solve a load of gripes I had with the current system, it also opens some huge new possibilities for us scriptwriters:
- <game storage> might be shared between all player scripts, allowing live data sharing between AIs!
- <permanent storage> will allow scripts to remember what happened in past games, an in turn scripts can then be developed that identify trends and adapt to them
That last point is loaded with future potential: Human players learn how an AI script "thinks", identify weaknesses and exploit them. In the future, AI players might be able to do the same thing against human players!
Scavengers
There's been a bunch of work recently around making it easier for scripts to "see" scavengers. In the past, AI scripts haven't been able to get lists of scavenger droids or buildings, resulting in the AI being somewhat useless when there's scavengers on the map.
Luckily that's all about to change (and in fact some of the changes might already be in recent beta releases).
The enumDroid() and enumStruct() functions have recently been altered to allow them to get lists of scavenger player droids and buildings. It's likely that these changes are in 3.1 Beta 4, and possibly even Beta 2.
The problem is that the player ID of scavengers is always greater than maxPlayers so AI scripts aren't currently aware of scavenger objects until a scavenger attacks them. Luckily, we're about to get a new scavengerPlayer global that will tell us what player ID is being used for scavengers on the current map.
So, expect AIs to start getting much better at dealing with scavs in the future!
That's all for now!
I've been searching for some time to properly locate the JS API. Everything pointed to it being on the global object (at least that's where the C++ source code says it's putting it) but so far it's been elusive.
My previous attempts had focussed on Object.getOwnPropertyNames() which:
Returns an array of all properties (enumerable or not) found upon a given object.
Note the bold bit: enumerable or not.
I knew the JS API declarations were almost certainly non-enumerable, after all they weren't showing up in a "for..in" loop. So I expected that getOwnPropertyNames() would do the trick and unearth them, but to no avail - instead it just gave me a list of the normal JS stuff like Date, Math, etc.
So, I decided to give Object.keys() a try, which:
Returns an array of all own enumerable properties found upon a given object
Strangely, this is what delivered the goods (click image to zoom):
So, it seems that the ECMA-262 implementation used by the Warzone API has some bugs when used on the global object:
- Object.getOwnPropertyNames(obj) doesn't list non-enumerable stuff (I tried this by defining my own non-enumerable stuff and confirmed the bug)
- Object.keys(obj) doesn't filter out non-enumerable stuff
I'm not too fussed about these bugs, they don't affect normal stuff that you do with your script (by that I mean they work on all normal objects), but just thought I'd post this info in case anyone else is digging deep in to the Warzone JS environment and JS API.
As well as all the expected properties, doing this also unearthed "gc" and "print" (both functions I assume) that are likely part of the Spidermonkey JS environment rather than warzone.
Anyway, this now means that I have a much easier way to check what's been exposed by the JS API for different versions of the game, which will make cross-version scripting so much easier.
daction.js v0.1
Ever wondered what the droidObj.action value means?
I've grabbed all the constants from the C++ source code and put them in to a handy javascript include called backport.daction.js
At some point I'll be adding all the constants to this JS API wiki, but for now I've just dumped in the contents of daction.js to the .action page.
util.js v0.6
Util.js now has its own wiki with complete documentation and v0.6 has been released - if you've been using previous versions, v0.6 is a recommended upgrade as it fixes some stupid bugs.