Containers and coordinates | What they are and how to interpret them |
Movement types | Relative, absolute, etc.. |
Location tag | What location tag contains |
Containers and 'absolute' movement | You are on ship that moves at sea |
Containers and relative movement | You are on ship that moves at sea |
Attributes:
def get_absolute_position(self): if not self.ref: return self.pos return self.pos + self.ref.get_absolute_position()As you can see from above code assumption is logically 'tree' like container structure.
If world designer wants to use only one coordinate system and still have containers: Specify pos as 0,0,0 for all objects except bottom level ones.
Movement type | Server | Client | tags | |
a) | Relative coordinates | Nethack and many MUDs | Simple client | vector, relrotation |
b) | Force vector | QUADAS, Cyphesis in future | Normal client | forcevector, torquerotation |
c) | Force vector/limb | Some future world with VR | VR client with suit | forcevector, torquerotation |
d) | Absolute coordinates | Cyphesis currently | Map editor | pos, rotation |
Note that all positions are specified in relation to containers: absolute==absolute in relation to container, relative==relative to current location
If you have better suggestions for tag names, mail to protocols@.
Server should always support less accurate movement:
Advanced server: | a,b,c |
Less advanced server: | a,b |
Simple server: | a |
Same for client. Client tries most advanced method of moving and if it gets illegal event back then it falls back to less advanced method.
Server implementation could be something like this: server:b, client:a Create appropriate force vector for requested move difference and use it as if that was requested.
When 'force' -tag is used by client, then likely server sends movement sights using 'vector' -tag.
Why?
It would be nice if server would work with less advanced clients and vice versa. We can't immediately implement some very detailed moving. It's just that when client uses less accurate 'movement type' then (s)he cannot control her/his character as accurately. For some programs it doesn't make even sense to do it initially (like some existing program).
This is current/new location for entity. It contains id, position and optionally orientation.
Id: Entity that acts as reference for location.
Either pos, vector or forcevector is used for position. Units are in meters unless something different has been decided between server and client.
Pos: absolute coordinates in relation to reference entity. Example (x,y,z):
Vector: relative to receiving character. Example:
Forcevector: Force relative to receiving character. Default unit is newton. Example:
Either rotation, relrotation or torquerotation is used for rotation. Units are in radians unless something different has been decided between server and client.
Rotation: Absolute rotation in relation to reference entity. Example (x,y,z -axis):
Relrotation: Relative rotation in relation to receiving character. Example:
Forcerotation: Relative torque in relation to receiving character. Default unit is newton meter. Example:
You move (no need to specify ship, reference container not changed):
You are on ship that moves at sea.
You move: ship has moved in relation to you:
Somebody else moves on same ship: somebody has moved in relation to you: