[crossfire] map and player persistence question

[Mark Wedel]

  A few other notes/corrections.

  I don't have time either to hunt through for function names.  But generally, 
the server/swap.c determines when maps are swapped out and reset.  Loading of 
maps is done as demanded.


>
     
      Maps are loaded into memory whenever:
     
     >
     
      1) a player enters a map that is currently not loaded
     
     >
     
      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 (the cvs version had some changes a 
     
     >
     
      week ago or so that improved it further), such that the player probably 
     
     >
     
      won't notice the load time.
     
     
  A side case to #1 is the outdoor (tiled) maps.  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.

  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.


>
     
     
     >
     
      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 reset.
     
     >
     
     
     
  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 (variosu 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.

>>
     
      Is this done by simply
     
     >>
     
      deleting the changed map in memory?
     
     >>
     
     
     >>
     
     
     >
     
      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.
     
     
  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.


>>
     
      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.
     
     
  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.

>
     
     
     >>
     
      Is there any mechanism for state changes to a map that
     
     >>
     
      will not be cleared after a short amount of time? If
     
     >>
     
      so where is the source code that deals with that?
     
     >>
     
     
     >>
     
     
     >
     
      Well, if you're referring to the apartment style maps, you would want to 
     
     >
     
      look at the saving code in common/maps.c
     
     
  I'm not exactly sure when you say 'state changes'.  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

>
     
     
     >>
     
      Are changed maps ever saved to disk for any reason in
     
     >>
     
      crossfire?  By changed, I mean maps with items dropped
     
     >>
     
      on them, or generated monsters, or whatever.
     
     >>
     
     
     >>
     
     
     >
     
      Again, apartment/guild maps.
     
     
  Depends on definition of changed maps.

  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.

>
     
     
     >>
     
      Players:
     
     >>
     
      When is a character saved to disk?  Is it only when
     
     >>
     
      they go to bed?  Where is the source code that deals
     
     >>
     
      with this?
     
     >>
     
     
     >>
     
     
     >
     
      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 shouldn't be too hard to find the code for that, but I don't have 
     
     >
     
      time to do that at the second.
     
     >
     
     
     >>
     
      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