Greetings. :)

[Nathan Yospe]

On Sun, 6 Apr 1997 coder at ibm.net wrote:

:On 01/04/97 at 09:47 AM, Michael Hohensee <michael at sparta.mainstream.net>
:said: >On Mon, 31 Mar 1997 claw at null.net wrote:

:>> Hehn.  I actually make no distinction among players, mobiles, rooms,
:>> objects, utility objects, etc.  There are just no unique object types. 
:>> They're all the same to the server.
:>
:>Doesn't that waste memory?  
:
:No really.  I don't run in memory.  I run off a heavily cached disk-based
:DB, so there is no in-memory class structure.  

I think we're hitting upon a fundamental philosophical difference between
the server approach and the codebase approach. I've noticed that my
internal language is resulting in my system, in some respects, drifting
more and more toward what you describe, to the point that, if I yanked
every existing object, I might have a crude and clunky version of your
server (with a seriously different sort of threading and event scoping...
the event thread imbedment in layered containment is a bit lower level
than my descriptions, but the descriptions reflect my use of them, not
their potential application.) Nevertheless, I decided to, rather than deal
with writing a caching/disk swapping system, rely instead on the OS
swapping, and on discrete object referencing. This mainly follows the
expectation that, while there is potential for the creation of new
objects, they will not actually _be_ created in large quantities, and all
new objects will be translated into hardcoded versions on the next
recompile and reboot, so no more than a week (they take the system down
once a week) will pass in which these softcoded objects might exist. The
softcoded objects are considerably more reluctant to swap cleanly under
the system swapping.

:Part of the key here is that my server actually knows nothing about the
:game it is representing, or in fact anything about any games at all. 
:Truth to tell, my server has no concept that it has anything to do with
:games at all (that was one of the design criteria).  What the server does
:know about is its databse, how to submit queries to that database, and
:that's pretty well all it knows.  Everything else, all the game stuff, the
:command parsing etc happens as code written inside of database records.

This code would be what, interpreted, partial (bytecode) compile, partial
(bundled pointer) compile, or full (dynaloaded) compiled?

:This is probably better understood from the inside oot, rather than trying
:to look at the server side:

:  Everything is an object.
:  Objects are defined in a database.
:  Objects have Unique IDs.
:  Objects may contain methods, attributes and verb templates.
:  Objects may inherit from other objects (multiple inheritance).
:  Methods may call other methods during their execution.
:  Everything that happens is part of an event.
:  An event is a grouped set of state-changes which occurs to the DB 
:    atomically as of a known time.
:  An event may log future events.  (ie A method, should its event 
:    succeed, may log future events)

What exactly do your states look like, if you don't mind answering? My
'states', insomuch as I have them, are themselves compound objects. The
only other approach I am really familiar with is *shudder* Merc style
"long state_holder" with the "#define A 1; #define B 2; #define C 4;"
bit container method... and I'm sure you use nothing like that.

:Essentially what happens from there is that the server determines that
:there is an event to be executed, and calls a specified method on a
:specified object with particular arguments.  That method then executes
:from there, calling other methods on other objects etc as needed.  At some
:point the event terminates, all the changes to the DB are commited
:atomically, and the server goes back to doing nothing.  

Can you kill an event if it is invalidated prior to ripening?

:Internally the DB, pr at least object ineractions, may be viewed as a
:message passing system.  Methods send messages to other methods, which in
:turn acknowledge/respond with messages (possibly after calling other
:methods).

Hmmm. I wonder... this sounds an awful lot like my impulse system, except
that impulses have to travel through existing channels in the target
object, or they bounce.

:  An object consists of an inheritance tree (multiple inheritance), 
:    methods (code), attributes (values), and verb templates.
:  Verb templates conditionally match and auto-parse user commands, 
:    matching them to methods on the defining object (see ColdX).
:  Any object's method may call any other object's method, whether or 
:    not it knows that method exists or is defined on the target 
:    object.
:  Such a call is actually a message, and may be handled in any manner 
:    by the receiving object.  As such, it is up to the receiving object 
:    to respond appropriately to the message with its own message back to 
:    the caller.
:  In this manner the receiving object can reply that it doesn't support 
:    the method called for, does support it but its internal security 
:    processes prevent it being called, a standard return value from the 
:    call, etc.

OK, yours bounce too... but after the entire message has been passed, even
if there is no channel for dealing with the input. I really am surprised
how many parallels exist here... considering that we are running radically
different systems, and the supposedly similar systems to my own have no
parallels whatsoever.

:>I did that for a while, but I couldn't see 
:>why a jar needed to have a sex value... 
:
:The difference is that I don't require anything to have a sex value.  If
:someone wants to insert one at the appropriate place in the inheritance
:tree, then a bunch of objects will suddenly gain one (can be done at
:runtime).  You could ask a jar on my system for its sex, and it could well
:respond with a stated value, a "Huhh what?", raise an exception, or do
:anything number of things.  The real point is that I don't prevent
:anything from _asking_ the sex of anything else.

I suppose I do, in a sense... you cannot ask the sex of something
without that attribute object in hardcode, and the dead code produced by
attempting to do so in softcode is simply trimmed by the pip2C++
translater.

:>I treat liquids as independant objects.  I've got an update pulse 
:>(modeled after dikumud pulses) that will have the liquid check to see if 
:>it is in a watertight container.  If it isn't, some of it "leaks" out.  
:>The liquid object has an "amount" variable, and this is decreased when 
:>some leaves the container.  I've also got one function for moving things 
:>around, and it checks to see if the liquid has all been spilled (move 
:>whole object to outer container) and checks to see if there is a liquid 
:>of similar type in the outer container (sum the amount variables, and 
:>recycle one object.)
:
:Ahh, minus the update pulses (mine is a totally event driven server) I
:pretty much do the same here with my mana flows (mana flows about the land
:much like a liquid (actually more like a gas)).  An area I'd really like
:to crack is liquid flow such that free liquids would puddle, flow in
:streams, form rivers etc.  

I think I might be able to help you here. Give me a while to strip out all
of my prejudices on the basis of my code, and I'll get back to you with
how I do it, generically. Right now, fluidity is inherent in all
materials, in my code, in several forms, and I have state changes for
several materials. In the context of my code, an object with physical
attributes has a material composition. If it is made of multiple
significantly diverse materials, the object is composed of layered
component objects. A material responds to external states (static
impulses) by recalibrating state change events every time external
conditions change (this is also the key to my solution of the crystaline
tree... I'll explain later, as that tree is a perfect example of this) A
liquid, in response to gravity, a static impulse, schedules an incomplete
interuptable event for a later date in which it has traveled downhill,
possibly also fusing (I allow several degrees of chemical and non
chemical fusion of substances... water on dust becomes mud, dirt on
pressure becomes dust, water motion creates pressure on dirt, etc), but
this state change is marked on scheduling with an alert. Any reference to
the water, or the traversed region, in the time of traversion, generates
an instant event evaluating current state, and displays that. The only
problem: if there is a static impulse condition on, say, something that
might be worn away by the water, the calculation of water movement will
note this (or, should something come to exist within the region while the
water flows, this will create an interupt/immediate event recalibration)
and the event that places the water in the critical position and wreaks
havok will be scheduled instead of the normal later date position of the
water. This allows such things as redirecting streams to use water flow to
undermine an enemy fortification. Yes, creating water flow does involve a
source/rate and destination... rate handled for you on destination. So...
that fountain of midgaard would probably, if not designed with an outflow
or autostop, result in the mud puddle of midgaard. Especially with the
pressure impulses created by all the feet passing by on the hard dirt. (I
assume dust due to pressure up to a certain equilibrium, then the
reverse... but mud keeps the equilibrium from occuring... so the mud would
keep getting deeper... and the nearby stores or whatever they were would
start to cake with it after a time.)

Now, to the crystal tree...

There is a bucket with a sympathetic spell to something atop the tree,
correct? And the tree can only support so much weight, so adding water to
the bucket eventually overloads the tree and the tree crashes down. (nice
liquid problem, that... or fluid, at least... crystal units begin to
approximate sand) Bubba is a physical object, that exerts mass reaction to
gravity... in other words, he keeps track of the theoretically static
value of his mass. He has in his possesion an object that will be asked to
increase mass by the bucket, thanks to the spell on the bucket. When the
object agrees to increase mass, this is passed as a dynamic impulse to
bubba, who passes it in turn to his location... a tree that cares about
such state changes, and doesn't like them one bit. It collapses. Unless I
missed something here, this was never a problem with my impulse passing
method, as the only way for the bucket to increase the sympathetic objects
mass was by transmitting an impulse to it, and impulses always go merrily
down the line.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu