> Object Common Fields
>
> Your list is fine by me. Nash had suggested having a "parent" field for the
> object that contains the current one.
Absolutely - symmetry is nice.
Executive Summary: All state about an object should be stored in the
object - requiring updates on other objects is silly.
In particular since I don't know if an object has been reparented until
I get it's new parent or it's old parent - things are a bit icky.
(Internally it means I see a problem that receiving the parent can cause
the child to get two updates - once when I receive data on the child,
once when I receive data on the parent).
Example: (parent --> child)
Initial state
HomeWorld --> Fleet
NewWorld
After new turn is genned actual state:
HomeWorld
NewWorld --> Fleet
Update sequence:
Updated info on Fleet (client state):
HomeWorld --> Fleet (with wrong position)
NewWorld
(So client is in an incorrect state until...)
Updated info on NewWorld:
See child is now fleet
Update fleet, see it's old parent is wrong, so need to update
it's parents data.
So update causes updates on: HomeWorld, Fleet and NewWorld.
A naive client which doesn't follow the whole chain has:
HomeWorld --> Fleet
NewWorld --> Fleet (with Fleet thinking NewWorld is it's parent).
Updated info on HomeWorld:
Now see the updated (correct) child list (which may include other fleet
changes aside from Fleet).
This can be avoided by basically blocking until all updates are done..
but I'd really like to avoid that sort of thing.
We could require some arbitrarily complex update order (which is hard
with other order guarantees). But one extra field does all that is
required.
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
