Syntax:
Code: Select all
var results = enumObjects([filterObj]);* player: either player ID or meta player such as ALLIES, ALL_PLAYERS, etc
* type: DROID, FEATURE, STRUCTURE (default: no filter)
* subtype: filter to specific sub-type[1], or list (array) of subtypes
* x, y, range: filter results to those within range of x,y
* x, y, x2, y2: filter result to those in the region specified
* idle: true/false. filter to DORDER_NONE (for droids) or similar (for structures) - eg. unoccupied rearm pad would be idle
* bornAfter: filter to objects older than stated game time
* bornBefore: filter to objects newer than stated game time
* costMore: filter to objects costing more than value
* costLess: filter to objects costing less than value
* canHitAir: filter to objects that can hit VTOL
* etc...
Basically you'd be able to filter to any of the common properties of droids, structures, features, plus a few other useful filters.
[1] List of proposed sub-types:
* WEAPON (include LASSAT?)
* SENSOR (excludes sat uplink)
* SAT_UPLINK
* COMMAND (commander droids and command control structure)
* CONSTRUCT (anything that can build a structure)
* REPAIR (anything that can repair a droid)
* REARM (anything that can rearm a VTOL)
* TRANSPORT (.bodySize tells us whether it's cyborg or super trans)
* ARTIFACT
* OIL_DRUM (rename to DRUM?) [2]
* OIL_RESOURCE (shrink to just RESOURCE?) [2]
* RESOURCE_EXTRACTOR (bit lengthy - maybe rename to EXTRACTOR?)
* BUILDING (sky scraper, log cabin, etc)
* FACTORY (any type of factory)
* GATE (incl. retractible tank traps, eg. in Contingency mod)
* WALL (incl. static tank traps)
* HQ
* POWER_GEN
* RESEARCH_LAB
[2] In future it might be desirable to have other forms of power collection / generation, other than oil, hence removal of "OIL_" from those sub-types. Example, in campaign 0, it might be desirable to treat food as power. Drums, resources and extractors could be given a .resource property (in future some time) that would state what sort of resource they relate to (eg. OIL, FOOD, etc). So one day we could have a game where there's multiple resource types, with multiple "power bars" - one for each resource type. A player might need food to maintain their troops, and power to recruit troops.
-----
Scripts are regularly doing a lot of this filtering themselves. Having a function like this will make code easier to maintain, but it should also reduce the amount of processing time. For example, if I want to get a list of sensor towers I have to enumStruct() filtering to stattype DEFENSE, then filtering that to try and work out which of the DEFENSE objects relate to a sensor tower. With enumObject I'd just do enumObject({type:STRUCTURE, subtype:SENSOR});
The new .sub property would be added to existing objects and scripts could start transitioning over to using it. The older .stattype and .droidType properties would be deprecated and eventually phased out in wz 3.3 or later. Likewise, several of the enum functions could be phased out over time, as enumObject() is more flexible than all of them combined (or they could just internally route to enumObject).
The sub-types could possibly be referenced in technologies as well. So a tech could state roughly what it will affect, taking us a step closer to having AIs that don't need quite so much pre-programming of research paths.
For example, all weapon research techs could have a .sub = WEAPON, indicating they unlock or upgrade weapon turrets. Research techs could also be given an .effect property (or something like that) with values such as UNLOCK, ROF, DMG, ACCURACY, etc. If we get to the point of having weapon classes, scripts could then say "I need better ROF on MGs, what techs are available to do that?". Obviously, this won't be a panacea - with the new research system there can be techs that have completely custom effects only understood to the script in rules.js that processes them, but for general stuff (which is what most research is) it would make life a lot easier.
