On Mon, 26 Aug 1996 14:50:29 -0700, JCL wrote:
} > } [JCL:]
} > } I think Alex had the right idea is saying that by default all commands
} > } should be forced to compleat in entry order. His suggestion of also not
} > } starting processing on one until the prior command compleats is
} > } tantalising[...]
} > [Alex:]
} > A direct requirement of the C&C model.
} > An event that didn't successfully complete does not exist.
} [JCL:]
} Not true. What you appear to be missing is the difference between an event
} starting processing, and an event compleating. Consider:
}
} > Command1
} > Command2
}
} The requirement is that the above commands must compleat in order, ie Command1
} must compleat before Command2 compleats. What this does not mean is that
} Command1 and Command2 cannot be processing at the same instant. Consider:
}
} > Command1
} > Command2
} Command2 starts processing. // Note: the order of what command started
} Command1 starts processing. // first is immaterial.
} Command2 finishes processing, but blocks, waiting for Command1 to C&C.
} Command1 finishes processing.
} Command1 C&C's.
} Command2 C&C's.
But what happens if Command1 contends with Command2?
} Now I can simplify the processing model somewhat by requiring that a command
} can only start processing when its immediate processor has compleated
} processing, and there may be some efficiency gains to be garnered from this
} rule due to fewer events failing C&C and having to be rescheduled,
That is more or less what I meant.
} but there's no behavioural requirement for it.
OK.
} > } [JCL:]
} > } My idea is that a command resulting in an event which does
} > } not call a method on the same object as the event it is sequentially dependant
} > } on, may start processing prior to the event it depends on compleating first
} > } compleating.
How would you know *beforehand* what objects will be involved in the execution
of the events?
} The example quoted below looks at a specific case of three commands entered in
} sequence, and allowing their out-of-order processing, while continueing to
} require their in-order compleation.
}
} > } Given the following sequence of entered commands:
} > }
} > } > #1
} > } > #2
} > } > #3
} > }
} > } Where those commands result in events A, B and C respectively, and
} > } where event A calls a method on ObjectX, event B calls a method
} > } on ObjectX, and event C calls a method on ObjectY.
} > } A will start processing.
} > } B cannot start processing until A compleats.
} > } C may start processing before B compleats.
} >
} > Some questions:
} >
} > 1) Event C calls a method on objectY, which calls a method on objectZ, which
} > calls a method on objectX. How will you handle?
}
} Event C may fail C&C, and so will be rescheduled. No special handling
} required.
I disagree. Indirectly calling a method on objX will not necessarily cause event
C to fail C&C.
} > 2) You mention events that are the result of commands.
} > What about events that result from mob programs, user-written scrips,
} > etc.?
}
} They follow all the same rules, except that (one would hope) such automated
} events not originating from player characters would not need the ability to
} kill all prior uncompleated events.
I think that the serialization requirement (when needed) should be based on
events, whether they result from commands or not.
Commands are just a simple case where we have predetermined the order of event
invocation.
Consider the case of two events, A and B.
It may be the case that the order of event completion will influence the results
of those events (we had lots of "dragon examples" to that effect).
I think that we need a mechanism that will ensure that the end result of all the
invoked events will be the same as if the evens were processed in strictly
serial fashion with a predetermined order.
} I believe I have already admitted the need for guaranteed serialisation of user
} commands, which I am intending to approach thru sequence numbers.
Can this sequencing be generalized to include all events?
In the sake of "purity" I feel that the engine should not be concerned with the
origin of events (user commands or otherwise).
Have fun,
Alex.