Suggestion: DORDER_ASSIGN & DORDER_UNASSIGN constants
Posted: 21 Mar 2012, 06:21
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.
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.
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 ...
}
}