This AI is still in early stages of development.
GO 3.1
Using GO, you can run Warzone 3.2 scripts on Warzone 3.1...
Overview
GO 3.1 upgrades the JS API to a state that is much closer to that in Warzone 3.2:
Implements several bug fixes
Adds many missing functions, events, constants, globals and properties
Updates existing JS API features to work like their 3.2 counterparts
All of this is transparent – you develop your script as if it were for Warzone 3.2, include a few files at the start of it, and GO takes care of the rest.
GO is ideal for AIs, scavfact.js, rules.js and 'extra' scripts. If you're scripting campaigns, GO can't help much - you need Warzone 3.2 for that.
There are obviously some things that can't be implemented, such as chat and beacons, however fake functions are created so your code remains simple and consistent across Warzone versions. The API allows you to determine the status of each part of the JS API, for example to work out if you're using a native JS API feature, or an upgraded/modified implementation.
Adding GO to your script
Two lines of code need to be inserted as close to the top (ideally the very top) of your script:
include("path/to/APIs/Util.js");
include("path/to/Defines/GO31.js");This will cause a bunch of scripts and APIs to be loaded, including:
Define API and numerous "defines"
Events API
All the scripts are designed to minimise global object/scope pollution wherever possible. See linked documentation for more details.
In the documentation below, the following icons are used:
= Safe to use without worrying
= Use with caution / understanding of limitations
= Don't use (not implemented or removed)
= Minor note, nothing to worry about unless you are doing crazy stuff.
Groups
GO provides almost identical group implementation to that found in WZ 3.2, meaning you can group any game objects (including structures and stuff owned by other players). So use groups in exactly the same way you would in 3.2.
The only limitation is groups defined by labels in labels.ini – however it's highly unlikely you'll be using those in AI scripts or rules.js, etc.
Objects
GO adds most missing properties to droid, structure and feature objects, and basically makes them look like their Warzone 3.2 counterparts.
It achieves this using a range of techniques:
Deducing values based on information available in the 3.1 JS API
Extrapolating values from game events (eg. working out attackers .range when they attack you)
Integration with your scripts
That last point is where you come in, especially for items marked in the table below. Your script will often have lots of additional data about the droids and structures it builds, custom research trees and so on. You can hook in to GO's decision making processes to increase the accuracy of results.
Compatibility Matrix
Properties | Droid Object | Structure Object | Feature Object | |||
|---|---|---|---|---|---|---|
born | Accurate values for all map-placed droids. Accurate values for droids created by your script. Approximate values for other players droids. | Accurate values for all map-placed structures. Accurate values for structures created by your script. Approximate values for other players structures. | Accurate values for all map-placed features. Accurate values for features created by your script. Approximate values for features created by other scripts. | |||
group | Fully 3.2 compatible grouping system. | Fully 3.2 compatible grouping system. | Fully 3.2 compatible grouping system. | |||
armed | Defaults to null for non-VTOLs. | Defaults to null. |
|
| ||
isVTOL | Full implementation, even works on droid objects that are no longer on the map. | To improve performance, .isVTOL property also appears on structure objects as a static false value. |
|
| ||
cost | Fairly accurate values for droids created by your script using buildDroid(). Inaccurate values for everything else. | Fairly accurate values for structures created by your script using orderDroidBuild(). Inaccurate values for everything else. |
|
| ||
isRadarDetector | Generally accurate identification for all droids. | Generally accurate identification for all structures. |
|
| ||
isCB | Generally accurate identification for all droids. | Generally accurate identification for all structures. |
|
| ||
isSensor | Generally accurate identification for all droids. | Generally accurate identification for all structures. |
|
| ||
range | Inaccurate values for all droids. As you get attacked by other players' droids, their range value becomes more accurate. | Inaccurate values for most structures. As you get attacked by other players' droids, their range value becomes more accurate. |
|
| ||
canHitAir | Fairly accurate for all droids, especially any that attack you. | Fairly accurate for all structures, especially any that attack you. |
|
| ||
canHitGround | Fairly accurate for all droids, especially any that attack you. | Fairly accurate for all structures, especially any that attack you. |
|
| ||
hasIndirect | Not very accurate, although it checks for droids assigned to sensors and will sometimes guesstimate based on range. | Generally accurate for defence structures, and obviously laser satellite. |
|
| ||
weapons[] |
|
|
| |||
body | Very accurate for droids created by your script. Usually accurate for human player droids, unless they choose custom droid names. Often inaccurate for other AI players unless their droid names are recognisable. |
|
|
|
| |
propulsion | Very accurate for droids created by your script. Usually accurate for human player droids, unless they choose custom droid names. Often inaccurate for other AI players unless their droid names are recognisable. |
|
|
|
| |
bodySize | Not currently implemented (I need help to rectify this). |
|
|
|
| |
cargoSize | Not currently implemented (I need help to rectify this). |
|
|
|
| |
cargoCapacity | Not currently implemented (I need help to rectify this). |
|
|
|
| |
cargoSpace | Not currently implemented (I need help to rectify this). |
|
|
|
| |
cargoCount | Not currently implemented (I need help to rectify this). |
|
|
|
| |
droidType | Fixes some cyborg-related bugs. |
|
|
|
| |
API hooks
As mentioned earlier, your script can hook in to GO to help increase accuracy of the properties listed above:
go.guessSensor(gameObject, property) – called when GO is trying to work out whether a game object has a sensor, CB radar, or radar detector.
go.guessWeapon(gameObject, property) – called when GO is trying to work out information about a game objects' weapons.
go.guessBodyProp(droidObject, property) – called when GO is trying to work out body or propulsion of a droid object.
go.guessDroidType(droidObject) – called when GO is trying to determine droid type. Note: The droidObject is often a fake object so be careful how you interact with it.
<more docs on this bit at later date>
Constants
Pretty much all constants found in WZ 3.2 are backported. Also, constants removed in 3.2 are removed from 3.1 to ensure you don't use outdated constants.
In addition, many missing constants (even with respect to 3.2) are also added - such as those applicable to .action and .order.
Globals
The following globals are backported:
Global | Notes |
|---|---|
groupSizes[] | Almost identical to Warzone 3.2 implementation, with the exception of groups defined in labels.ini (no way to get to them in 3.1). |
scriptName | Optional – include <this script> at the top of your script if you want this backport. |
... |
|
Events
As insane as it might sound, GO even backports some of the WZ 3.2 events to 3.1!
Event | Notes | |
|---|---|---|
Identical to WZ 3.2 in that it will be triggered when enemy objects and even features are destroyed. Only triggers for your own objects, or objects your script has interacted with (eg. if you do an enumDroid() that's counted as an interaction for all droids listed, any objects in other events, etc). Feature objects are a bit hit and miss, which can be fixed if required, just let me know.. | ||
Full implementation, just like on WZ 3.2 – even triggers if a grouped enemy object gets destroyed! | ||
Full implementation, just like on WZ 3.2. Will sometimes give a false positive (other player reached the item a split second before you did) and will sometimes report the wrong claiming droid (if you have two droids that are both close to the object). | ||
Triggers whenever one of your transports lands. Not triggered for other players' transports. | ||
Triggers whenever one of your transports takes off. Not triggered for other players' transports. | ||
... |
|
|
Functions
The following functions are implemented or modified by GO, and any function that returns a game object will return a WZ 3.2 style object unless specified otherwise:
Function | Notes | |
|---|---|---|
Hooks to this function ensure that the droids' .born property is accurately set, as well as .propulsion, .body and (if applicable) .weapons, etc. Also, the function will attempt to return the newly created object like its WZ 3.2 equivalent. Allows same parameter syntax as WZ 3.2, however it's recommended that you still provide droidType param to avoid problems (or provide go.guessDroidType() function). | ||
Hooks to this function ensure that the droids' .born property is accurately set, as well as .propulsion, .body and (if applicable) .weapons, etc. It will also estimate the droids .cost fairly accurately. Allows same parameter syntax as WZ 3.2, however it's recommended that you still provide droidType param to avoid problems (or provide go.guessDroidType() function). | ||
A close approximation to the Warzone 3.2 function that returns fairly accurate results without loss of performance. In cases where a decent approximation can't be obtained, the full accuracy approach will be used... For full accuracy, at the expense of performance, set countDroid.enhanced = true. This will make the function use enumDroid() internally to get fully accurate results. When in enhanced mode, caching can be applied – set countDroid.ttl = <milliseconds> (eg. 1000 = 1 second cache). | ||
The results are recorded in an internal cache for use with propulsionCanReach(). | ||
Not currently implemented. | ||
Conversion to WZ 3.2 style droid objects, while fast, may impair performance on big lists. Optionally enable caching by setting enumDroid.ttl = <milliseconds>. Use Native.enumDroid() for the standard version that returns WZ 3.1 style droid objects if you need max performance. | ||
Fixed a bug that would throw nasty errors if used on destroyed droid objects. See also: <droidObj>.isVTOL | ||
Full implementation of features, including DORDER_RECYCLE support. | ||
Structures built with this function will have fairly accurate .cost properties auto-calculated. | ||
Hooks to this function are used to generate transport events, and certain droid properties, etc. | ||
This long-deprecated function is removed to prevent accidental use. Use orderDroidLoc() instead. | ||
Hooks to this function are used to determine certain droid properties. | ||
If you pass a game object to queue(), the queued function will receive a WZ 3.2 style version of that object transparently. If problems arise, it's likely that you've made the queued function immutable – eg. defining it as a const, or using object.addConst() etc. If so, update your code to manually Hook the function before making it immutable. | ||
See notes for queue() above – same applies here. | ||
Hooks to this function ensure that the feature's .born property is accurately set. Also, the function will attempt to return the newly created object like its WZ 3.2 equivalent. | ||
See notes for enumDroid() above – same applies here. | ||
? |
| |
? |
| |