[crossfire] Map cache

[Mark Wedel]

Brendan Lally wrote:
>
     
      On 8/27/05, Mark Wedel <
      
      mwedel at sonic.net
      
      > wrote:
     
     
>
     
     
     >
     
      You are probably correct, it is certainly easier to let Moore's law do
     
     >
     
      the work instead. It is likely that if there ever were a compelling
     
     >
     
      reason to split load across servers it would be to reduce bandwidth
     
     >
     
      usage from each server.
     
     
  But that then requires a fair amount of client logic (move from server A to 
server B for all communication).

  Something like that could almost be easier - you could for example have pup 
land all operate on one server, and so on.  When a player moves/leaves pupland, 
data is tranfered to the other server (player file) as well as telling the 
client to talk to the other server.

  In this mode, the amount of work is less - each server pretty much operates 
independently - what is needed then is code for things like chats/shouts/tells 
to get passed across servers.

  but still not convinced if that is necessary.

  Leaf/Basic - is it possible to set up some form of cpu usage monitoring on 
metalforge?  I know solaris has 'sar'.  I'd mostly be interested in seeing on a 
whole what percentage of the cpu is actually being utilized.

  Because I think, with current number of players, on the whole, cpu is probably 
still mostly idle.  Exceptions abound - I'd imagine map loads/save generate a 
small spike, and various 'hundreds of spells' also spikes the cpu, but those are 
exceptions and not general case.

  Only if the cpu was actually operating at a high percentage of use would 
distribution of servers actually make sense (and/or server generating enough 
traffic to saturate its link, but then a different server only makes sense if 
that server is on a different link - hosting 2 servers at the same ISP wouldn't 
help out)


>>
     
       Putting objects into misc containers adds a bunch of complication and not sure
     
     >>
     
     it really helps out.  If another axe is dropped, then presumably you have to
     
     >>
     
     check all the objects in the 'axe container' to see if it merges with anything,
     
     >>
     
     so loose any efficiency by having fewer objects.  Also, having that pseudo
     
     >>
     
     container would seem to result in other oddities, like special handling when
     
     >>
     
     player tries to pick it up, etc.
     
     >
     
     
     >
     
     
     >
     
      Well, there was a reason that I did specify that these would have to
     
     >
     
      be no_pick, so that there is no concern with picking it up. (you don't
     
     >
     
      pick up a pile of things, merely the individual items in it.)
     
     
  Ok - but I'd say that makes the user interface a little clunkier - containers 
now magically show up that the player has to open/close to get the items in/out of.

>
     
     
     >
     
      The merging would have to be done anyway, but it may be easier to do
     
     >
     
      it on opening the container, especially if items are often dropped
     
     >
     
      there but rarely retrieved.
     
     
  But presumably any item dropped should merge with the object in the container 
(that was the point of that container in the first place).  In that case, logic 
is still basically the same - have to examine all objects on the space to see if 
any of hte right type exist, as well as any containers.  If we get any of these 
special containers, then have to examine objects in that.

  This also creates a complication that at some point, the code has to decide 
'there are 15 different axe like objects here - lets create a container for them'.

  I think it'd actually make more sense to make this an in game feature.  EG, 
you can buy weapon cabinets at the store, and perhaps have different types 
(sword cabinet, axe, etc) so item would go in right cabinet.

  One thing that would probably need to be coded is being able to drop the 
weapon on a space with all those cabinets and have it go in the correct one 
(this works for inventory since you can have active containers in your 
inventory), but not on the ground right now.  Maybe using the walk_on flag could 
be used for this - if set on a container, do appropriate checks and insert 
object in container if appropriate.


>
     
     
     >
     
     
     >
     
      It might be possible to 'compile' maps, to take the map files, and run
     
     >
     
      a seperate program on them which would 'load' the maps like the server
     
     >
     
      does currently, and output the raw values of the object structs with
     
     >
     
      the relative place of pointers so that the server on loading the maps
     
     >
     
      can merely dump the items into an appropriatly size array of structs
     
     >
     
      and offset the pointers properly.
     
     
  The problem is that a recompilation of the server (or even new objects) 
results in those pointer locations being different.  So that doesn't work well.

  My thought for a binary form would be something like:
<2 bytes> - describes variable/field (eg, hp, sp, etc) - this is basically 
handled by a table/nice long switch statement.
<1 byte> - describes type of value (1=8 bit 2, 2=16 bit int, 3=32 bit, 4=float, 
5=string, etc)
<data itself - variable number of bytes determined from above.  For strings, 
length is prepended so loading string is very efficient)

  Some fields could also be collapsed.  For example, the FLAGS could just be 
saved as the 32 bit values isntead of all the individual flag values, etc.

  That said, that is a pretty big change - I'd rather try to just thread the 
loader (even though we'd have to limit to one load at a time) and freeze the 
player - IMO, that is probably a smaller change, and probably easier to also 
analyze for what functions the loader calls (so those can be made thread safe or 
locks added).

  That said, a non lex loader could be made thread safe.  there may actually be 
ways to make the lex loader thread safe also - probably just calls to say 'use 
this buffer' and not your own.

  That's basically the way all functions that have static strings values they 
return have to get fixed - they'd need to be modified for the calling function 
to pass in the string value that the function then modifies (look at all the _r 
functions on unix, eg, asctime vs asctime_r, done just for that reason)


>>
     
     2) objects with huge number of spaces isn't efficient - that is because for each
     
     >>
     
     object loaded on the same space, it has to compare with all the other objects on
     
     >>
     
     the space to see if any merge.  
     
     >
     
     
     >
     
     
     >
     
      This is why I suggested it should be primarily for floors (maybe also
     
     >
     
      walls...), these shouldn't ever need to stack, and adding a QUERY_FLAG
     
     >
     
      check would be comparitively fairly quick.
     
     
  The CAN_MERGE function is written so that once it knows an object can't merge, 
it returns.  So other than function overhead, it should also be quite efficient.

  One thought also is to just disable merging when loading maps - object should 
have merged before, so disable that portion, thus reducing load times.