Suggestion: DORDER_ASSIGN & DORDER_UNASSIGN constants

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

Suggestion: DORDER_ASSIGN & DORDER_UNASSIGN constants

Post by aubergine »

Currently there'a load of different ways to "assign" units to other units, and from what I can see no easy way to un-assign them afterwards.

DORDER_FIRESUPPORT is used to assign indirect fire droids (.hasIndirect == true) to a sensor droid (.droidType == DROID_SENSOR).

DORDER_COMMANDERSUPPORT is used to assign weapon droids (.droidType = DROID_WEAPON) to a commander droid (.droidType == DROID_COMMAND).

DORDER_EMBARK and DORDER_DISEMBARK are used to move non-transporter droids on to and off of transporters (.droidType == DROID_TRANSPORTER || .droidType == DROID_SUPERTRANSPORTER).

Could we just simplify things by having DORDER_ASSIGN and DORDER_UNASSIGN constants instead? The orderDroidObj() function would check the type of the source and target objects, and their current status if applicable, in conjunction with the command issued, in order to work out if the command is valid and then translate to the more granular commands used in the C++ code.

Assigning units to a transport would be equivalent to DORDER_EMBARK, unassigning would be equivalent to DORDER_DISEMBARK. It would also be useful to know the "terrain state" of transports - eg. are they landed or in flight? I believe there's a property on the C++ droid objects that provides such information (can't remember what it's called though).

The old constants (DORDER_FIRESUPPORT, DORDER_EMBARK, etc) would be retained for backwards compatibility and also to make porting existing scripts easier, however they would be marked as deprecated to encourage scripters to use the DORDER_ASSIGN and DORDER_UNASSIGN constants.

It would also be useful to have .numAssignees and .maxAssignees properties on droids and structures (eg. sensor or CB towers), along with an enumAssignees() method to get a list of assigned droids for a commander/sensor/transport. For droids/structures that don't accept assignees, both values would default to 0, which usefully type-coerces to false in JS.

Code: Select all

// allows short-circuiting in my code...
if (whatever.maxAssignees && whatever.numAssignees < whatever.maxAssignees) { // we can assign more units to whatever
  switch (whatever.droidType) { // work out what we can assign based on type of whatever
    case DROID_COMMAND: { ... }
    ... etc ...
  }
}
For example, on commanders and transports, there are limits to how many droids you can "assign" based either on the upgrades (for commander) or droid type (for transporters). Currently there is no way to know how close you are to using up that limit. While this could be done with object linking (proposed feature for 3.2), I feel that a distinct and unambiguous set of properties, plus the enumAssignees() function, will remove all the guesswork and code cruft we currently are faced with.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
Post Reply