cow data structure:
Cow concists of 3 tables in a MySQL database:
objects - holds all info about each object
messages - holds the messages for display to users
commands - a list of commands.. (fifo) in a format suitable for processing
since an object only has one of anything (once colour, one host, one name) there was no poitn making a relational table structure.
There are three fields within the objects table that link back to other records in the same table:
loc - what objects is this object inside - its location
host - what object is this objects hosted by (hosting is 'beside' on under')
link - what doorway object is it linked to (one way)
cow.pl records each id as it loops through all records so it can not get in an infinate loop when doing things like exporting all objects.
The commands table (from memory need checking):
loc - where is this command being performed
actor - which object is performing it
target - possible redundant
second - possible redundant
cmd - the actual command (get the cat)
init_obj - who initiate this command
ini_msg - the message that initated this command
The add_date is blanked when the command is being processed so anything with a blank date has been processed.
The message table (from memory needs checking):
loc - where is this message seen/heard
actor - who is the actor in this message
target - who is the target - if its not you and its a whisper, you dont get to see this message (I need to validate this logic)
second - who is the second object in this message
msg - the actual message with embedded [id_numbers] which need translating into object names before sending to the user
init_obj - who initiate this command
ini_msg - the message that initated this command
Players have stored in their object record a lmid - last message ID - this is how we know the last message they saw.
no-frames users have a fmid - first message they saw at logon, so we cna display msgs within this range (for current location) - (a bit clunky)