[crossfire] map/player persistence wiki version 1

Blake Delaney blatnc at yahoo.com
Sun Sep 11 17:16:50 CDT 2005


Thank you everyone for your detailed answers to my
questions.

>
     
      On 9/11/05, Lalo Martins <
      
      lalo at exoweb.net
      
      > wrote:
     
     >
     
      > Can I ask that, when you collect answers to your
     
     >
     
      satisfaction, you put
     
     >
     
      > them together in a single document, and stick it
     
     >
     
      on the wiki?  These are
     
     >
     
      > very useful questions for new hackers trying to
     
     >
     
      understand the system.
     
     
I don't know how to use a wiki, but here is an alpha
version of the answers I have received so far.  I
compiled them into one document and made a first
attempt at merging the answers from various people
into one answer for each question.

I am still no expert on the material discussed. I
suggest that anyone interested here tweak this
document and increment the version number in the
subject line until everyone is satisfied, and then
someone post it to the wiki. If you do this, make sure
to copy, edit, and paste instead of hitting "reply" to
avoid introducing right angle brackets (>).

Blake

map and player persistence:

>
     
     How is it decided when to load a map into memory? 
     
     
Maps are loaded into memory whenever:
1) a player enters a map that is currently not loaded
2) A player comes near the edge of an unloaded outdoor
titled tiled map. A player may not be on the actual
neighboring map, but if a player can see some portion
of it, it needs to be in memory.
2) the weather code simulates weather on that map
(however in that case 
it's unloaded right away after, unless a player is on
it)
3) when a DM uses the "reset" command

The loading process is very fast, such that the player
probably 
won't notice the load time.

>
     
      Where is the source code that loads and unloads
     
     maps?

Most of this map related code should be in
common/map.c
Loading is typically handled in enter_exit(), which I
think is in 
server/main.c.  However, the tile maps I think are
handled in 
common/object.c, when code is called the references
the neighboring map.

>
     
     How is it decided when to reset a map? (And what is a
     
     reset anyway?)

After a certain timeout of inactivity on the map (I
can't remember what 
the default time is, and individual maps can set it
separately too), it 
is reset. Players entering the map when it tries to
reset, or just 
periodically when the player is in it, will cause this
timeout to 
be extended. It's done by unloading the map from
memory, and unless it is an 
apartment or guild type map, it is not saved to disk
when unloaded.

There are two things here - There is the case when a
map is swapped out from memory to disk.  If a player
revisits that map before it resets, it is swapped back
in.
There is the actual reset case, where this swapped map
is deleted and 
next time a player visits it, it is loaded back in
memory.

there are default timeout values for both of these, of
which the map 
can overried to some extent (various config options
can enforce min/maxes 
on these).

Reset is handled in two different cases.  Most maps
reset time is 
cleared if a player visits it.  But some maps, most
notably shops, have 'fixed' reset times - that is,
when first loaded into memory, its reset time is set,
no matter how many players visit it in the interim. 
Thus, you can get cases where a player exits the shop
and re-enters just a minute later to find it is all
different.

Typically, when a map resets, it is not in memory
(because a player 
being on the map would cause the reset time to be a
while away)

If for some reason a map expires while in memory, when
it is time to 
swap it out, that won't happen - it will just be
deleted from memory.


>
     
     Can a map ever reset with a player on it?
     
     No.


>
     
     Are there any maps that don't reset?
     
     Sort of, apartments and such do 'reset' in that they
are unloaded from 
memory like the rest, however their contents is saved
to disk and 
loaded again when the map is entered.
generally, the server/swap.c determines when maps are
swapped out and reset.  
Loading of maps is done as demanded.

In theory, highly used maps could also never reset
just by the fact 
that there is always players visiting them.  This is
the reason that fixed reset was added to shops
(visited so often they'd never get reset).

Right now, some of the towns may be pretty close to
that category - 
players always hanging around, thus not likely to
reset.

>
     
     Are there maps that never lose their changes? What is
     
     uniqueness?

If I go to a dungeon, and leave the dungeon, after a
few minutes, it 
is swapped out. Swapped out in the case means written
to disk (typically 
/tmp, which may not really be disk, but that is just a
configuration issue).  
The format here is exactly same as original file.

If I revisit that map in 2 hours (Default reset time),
it is loaded 
back in. If I don't go back, then it will reset.

Apartment and guild maps don't lose changes.

There are two relevant mechanisms for saving map
changes permanently, both referred to commonly as
"uniqueness".

Unique objects, determined by the unique flag, will
persist across map resets.  And if the floor is marked
as unique, then all objects above it are preserved.

An example of this is the old apartment map in scorn 
(maps/scorn/taverns/apartments).

Here, unique floors are used throughout to preserve
the contents of 
the apartment across resets.  However, the common
areas (except for the 
altars) are not unique, so stuff in the lobby area
would disappear

First, a map can be "unique" (by setting the unique
flag to true on the
exit object that leads to it).  Hmm, that's not
precise; an _exit_ can
be unique.  Yes, that's better.  (Although we refer to
this feature as
an "unique map".)

If an exit is unique, a player that goes trough it
will be taken to a
special version of the target map; this version is
different for each
player, and is persistent - when it resets, its whole
contents will be
saved to disk.  However, they are saved to the
player's directory.

The other thing in unique items.  When a map reset,
any cell that has
any items marked "unique" (except for exits... I
think) will be saved 
to an "overlay" map file, which is in turn saved to a
special directory.

The way this is usually put to use, is by marking a
few _floor_ objects
as "unique", so that those cells will always be saved.
 You may hear
people referring to this practice as "unique floor" or
"unique 
squares".
Guild houses (iirc) have a room or two with unique
floor, so that you
can keep your loot there.

That would be the entire interior, plus the storage
building.


>
     
     When is a character saved to disk? 
     
     
Players are saved to disk by one of four ways:
1) the save bed
2) periodic automatic save of character
3) the 'save' command
4) emergency save upon server shutdown
5) Whenever a player dies

The code for this is in various areas - some in
server/player.c, some 
in apply.c, depends on mechanism.  Look for
save_player()

>
     
     It seems that there is only one character allowed per
     
     >
     
     player.  Is that accurate?
     
     
For a given username, yes. However there's nothing
preventing you from 
getting multiple usernames, and this is a very common
practice, and no 
public server I know of disallows it. There is no need
for having an 
'account' style system where a single user has
multiple characters 
grouped together because there simply isn't need to
keep track of stuff 
like that, unlike commercial MMORPGs.
 And in fact, there is nothing preventing the same
person (computer) 
having multiple active players on the same server at
the same time.

This would typically not be that useful, but I have
done it a few 
times when I've needed to test player/player
interactions








	
		
______________________________________________________ 
Yahoo! for Good 
Watch the Hurricane Katrina Shelter From The Storm concert 
     
     http://advision.webevents.yahoo.com/shelter
     
     
    


More information about the crossfire mailing list