GO 3.1

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.

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.

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.

Fairly accurate for all droids, especially any that attack you.

• id & name – Fully accurate for droids created by your script; inaccurate for all other players' droids (I need help to rectify this).
• armed – Rough approximation for VTOLs; static 100% for all other droids.
• lastFired – Rough approximation for enemies that attack you; inaccurate for all other droids.

• id & name – Currently inaccurate for all structures (I need help to rectify this).
• armed – Rough approximation for your LASSAT; static 100% for all other structures.
• lastFired – Accurate for your LASSAT; rough approximation for enemy structures that attack you; inaccurate for all other structures.

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.

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.

Fixes some cyborg-related bugs.

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.

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).

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).

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

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.

If this function is used by your script on WZ 3.1 RC3 or earlier, the data will be cached to allow getStructureLimit() to be used within your script.

The function is not modified on WZ 3.1.0 or above.

On Warzone 3.1 RC3 or earlier, this function will be backported but will only give accurate results in two scenarios:

• If your script is rules.js and had used setStructureLimits() for the queried structure.
• If the queried structure isn't available to build, but you have already built at least one such structure, the function will return the current number of that structure you have.

In all other cases, Math.max(currentCount, gameDefault) will be returned as a "best guess".

The function is not modified on WZ 3.1.0 or above.

Fully functional including support for non-droid and non-owned objects.

As mentioned earlier, can't handle labels.ini groups.

It has to list all matching game objects and then filter to those within the area, so on big lists performance may suffer.

Caching can be enabled by setting enumArea.ttl = <milliseconds>, if same parameters are used before cache expires the cached results will be returned.

Note, however, that if you use enumArea() filtered to your own droids it will be just as fast as WZ 3.2 even without caching (groupAddArea() to the rescue!).

See enumArea() above – same applies here.

If you enumRange() filtered to your own droids, it instead does an enumArea() to gain the same performance boost mentioned above.

Yes, 3 warning icons. Had lots of trouble backporting this one.

The function will always return accurate results for VTOL propulsion – it will always return true if the destination is within map bounds (let me know if this assumption is wrong).

It will return accurate results for land propulsion (wheels, half-tracks, tracks, legs) if there are confirmed land-propulsion droids (including ally/enemy droids) on the map. However, if there are no confirmed land propulsion droids, it will choose the oldest surviving non-VTOL droid and assume that's a land propulsion, which might not necessarily be the case.

Once there are confirmed hover droids on the map (including ally/enemy droids), the results for hover propulsion checks will be accurate.

However, if there are no hover droids, it will often return false even if hover propulsion could reach the location, rather than give a false positive.

Confirmed accurate results are cached for the duration of the game to help minimise inaccurate responses.

Full implementation of the function as per WZ 3.2.

One exception: Not possible to retrieve group objects via labels, which probably won't be used outside of campaign scripts.

Getting structure/feature at a specific tile can be quite slow because the enumArea() implementation (as described above) has to be used.

Oil resource locations are cached to boost performance (assuming more scripts will start using getObject() in conjunction with derrickPositions[]).

hackGetObj()

objFromId()

droidFromId()

All these long-deprecated functions are removed from the JS API to prevent accidental use – use getObject() instead.

You can use Native.<function> if you still need access to them, eg. Native.droidFromId()

This deprecated function is removed from JS API to prevent accidental use – use getObject() instead.

As with the other deprecated functions, you can still get to it via Native.labels()

Uses hacky DORDER_DESTRUCT when attempting to remove droids – may be hit and miss.

Unable to remove features in 3.1.

This deprecated function is removed from the JS API to prevent accidental use – use removeObject() instead.

If needed, you can still access it via Native.removeStruct()

Works as expected for your own factories.

Does not work for other players' factories.