Support COB GETTERs

[Xon]

Standard Total Annihilation Getter/setter values:

#define ACTIVATION			1	// set or get
#define STANDINGMOVEORDERS	2	// set or get
#define STANDINGFIREORDERS	3	// set or get
#define HEALTH				4	// get (0-100%)
#define INBUILDSTANCE		5	// set or get
#define BUSY				6	// set or get (used by misc. special case missions like transport ships)
#define PIECE_XZ			7	// get
#define PIECE_Y				8	// get
#define UNIT_XZ				9	// get
#define	UNIT_Y				10	// get
#define UNIT_HEIGHT			11	// get
#define XZ_ATAN				12	// get atan of packed x,z coords
#define XZ_HYPOT			13	// get hypot of packed x,z coords
#define ATAN				14	// get ordinary two-parameter atan
#define HYPOT				15	// get ordinary two-parameter hypot
#define GROUND_HEIGHT		16	// get
#define BUILD_PERCENT_LEFT	17	// get 0 = unit is built and ready, 1-100 = How much is left to build
#define YARD_OPEN			18	// set or get (change which plots we occupy when building opens and closes)
#define BUGGER_OFF			19	// set or get (ask other units to clear the area)
#define ARMORED				20	// set or get

From my old TADR extension getter;

 // indicates if the 1st parameter(a unit ID) is local to this computer
#define  UNIT_IS_ON_THIS_COMP 68
 // returns the lowest valid unit ID number
#define  MIN_ID 69
 // returns the highest valid unit ID number
#define  MAX_ID 70
 // returns ID of current unit
#define  MY_ID 71
 // returns team of unit given with parameter
#define  UNIT_TEAM 72
 // basically BUILD_PERCENT_LEFT, but comes with a unit parameter
#define  UNIT_BUILD_PERCENT_LEFT 73
 // is unit given with parameter allied to the unit of the current COB script. 1=allied, 0=not allied
#define  UNIT_ALLIED 74
 // gets kills * 100
#define  VETERAN_LEVEL 32

[MHeasell]

Most of these should be straightforward once the relevant concepts are in the engine.

 // indicates if the 1st parameter(a unit ID) is local to this computer
#define  UNIT_IS_ON_THIS_COMP 68

Do you know what determines whether a unit is local to a computer? This is not a well-defined concept in RWE as multiplayer will employ a lock-step model where all players simulate all units.

[Xon]

For each side, Total Annihilation tracks if it was either; local human, local AI, or a remote player.

[Xon]

This is because Total Annihilation 's multiplayer is only appropriately lock-step multiplayer, As each instance knows knows if authoritative for a side. If it is, it send out periodic unit re-sync packets, and if not accepts them for a side.

The local AI/local human is a fairly obvious reason, to know if a local side has an AI driving it or not.

Even with lock-step multiplayer, you are going to need to handle the affects of latency between players. latency masking means the engine would need some sort of resync behaviour of some sort to 'rubberband' things back to the correct spot.

Honestly lock-step multiplayer has some significant complexities due to NAT everywhere which makes p2p model painful and general flakiness of consumer networks.

[Xon]

After a bit of thinking, I think UNIT_IS_ON_THIS_COMP is just a bad fit for anything but exactly Total Annihilation's multiplayer model. I'm not sure how heavily used it is however

[MHeasell]

Started work on this in 422afd0f696cf50714311219756a71218cde6150 on branch 'getters', not tested an awful lot yet. At the very least, RWE can load the commander from ESC now (after renaming all the "E" suffixed dirs back to normal).

[Xon]

FYI, CobExecutionContext::pop() should return 0 (or do error reporting) if the stack is empty rather than unexpectedly explode/break. As TA has no bounds checking which allows a script to pop off the bottom of the stack and then allows modifying of the TA's in-memory unit scripting structure.

I don't think any 3rd party units really on this bug.

[MHeasell]

I spent some time playing with the Zarganeth (one of Zodius' units with a fancy ground-tracking walk script) and got things working to the point where this is useful enough to be on master, so I've merged the getters code in.

I'm going to leave this issue hanging around for now as some of the getters/setters are still TODO. Either I will implement them or create other issues to track them before closing.

I have opened #56 to track fixing pop().