Re: CF: object structure layout.

[Steve Fink <>]

> >    You probably need to add the map pointer to the above.  The main
> >   object traversal is each tick when it goes and sees what objects
> >   need to do something.  At times, that traversal needs the map
> >   object.
> >
> >    Another issue is that for the objects that do need to do
> >   something, the rest of the object structure is going have to get
> >   loaded anyways.  So if you wanted to get more clever, you could
> >   have various run queus - ie, the 1 tick away run queue, the 2 tick
> >   away, 3 tick,.. to 5+ tick away.
> 
> Very interesting idea!  It needn't complicate the code much, either.
> This removes the need for a wakeup attribute, since it is implicit if
> you have enough queues. The penalty for having many queues is very low
> (it's just a pointer per queue), so that's OK.  The slowest object in
> Crossfire right now is the Skull generator with speed 0.0002.  That's
> 5000 ticks, though.  Hmm.  Does it make sense to have objects which
> only do something every 10 minutes?  The slow objects are currently
> generators and diseases.

Hmmm.... ok, so maybe I'm confused, but wouldn't 1..5 tick away queues
require a total of 15 queues? Or for 1..5000, 12.5 million? (The
every-tick queue, the every-other-tick queue that started at t0, the
every-other-tick queue that started at t0+1) And how to you keep track
of which 5 queues to look at each tick?

I guess it's not so bad, as long as you don't have too many ticks away
(total #queues is n(n+1)/2). And management is fairly easy. Put the
queues in a 2-d array and run q[1][0], q[2][tick%2], q[3][tick%3], ...

> >    In some sense, I would like to keep things simpler for now - at
> >   current time it doesn't seem to be stuff like the object traversal
> >   being a limiting time factor/causing slowness on the server, but
> >   other tasks like map loading/saving.
> 
> Very true.  I don't have any clever ideas, there.  As long as people
> are running the server off NFS, there will be problems with loading
> times, no matter what optimisation we come up with.  Well, actually
> one very simple approach is to stop saving to disk and rely on the OS'
> paging/swapping instead.  If nothing else, this saves spending CPU on
> converting object data to/from ASCII.

If you're talking about multithreading, then you might as well combine
the two -- never save a map, just tell a thread to go save it. Then be
sure to not throw it out of memory until the thread says it's done.

> >    I know in one of my mail messages a while back following up on
> >   David's idea of a more unified scale would be to only process
> >   objects in the vincinity of the player (so if you had a 50x50 map
> >   for example, only objects with 10 spaces of the player gets
> >   processed).
> 
> My hunch is that the code for this will be complex.

I don't think it would be horrendous, but you're right. Though I'd be
more worried about confusing map makers -- any fixed distance from a
player will cause weird fringe effects, particularly with a fancy
scripting language. As a map maker, I'd find it much easier to deal with
if I could specify areas where either everything or nothing is
guaranteed to be processed. And that looks a lot like the current notion
of a map. Well, maybe with an edge area that is processed whenever a
player is on an adjacent map, anyway.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]