[CF-Devel] Large forest. Was: more proposals

[crossfire-devel-admin at archives.real-time.com]

David Seikel wrote:

>
     
      Currently, the weather system runs as part of the server, so it needs to do
     
     >
     
      it's work quickly to not slow down play.  My current project is to split it
     
     >
     
      off to another program that runs seperately and only bothers the server
     
     >
     
      when it is time to overlay snow and stuff onto tiles.  It would connect to
     
     >
     
      the server as a player with some DM style priviledges, I call it WG
     
     >
     
      (Weather God).  I already have a modified server and GTK client that has
     
     >
     
      the WG log on, become WG, vanish, and teleport to each big world map in
     
     >
     
      turn.  I am at the stage where I am getting relevant weather / map
     
     >
     
      information exchanged.  This project has stalled since my OS upgrade
     
     >
     
      because I can't get the damn python plugin to compile.  Note, my weather
     
     >
     
      code doesn't need python, I only want it for my Ice castle maps.
     
     
  I wonder if that is really more efficient.

  Being able to have a client/watch what it is doing can be neat, but I'd tend 
to guess that it is the loading/saving of maps which is going to be the major 
performance hit on the server site - and communicating what is on the map frm 
the server to client and back again.

  One could certainly only do these updates when no one is on the server - I 
think the current weather code tries to do that.  However, that doesn't help if 
the server is never complete vacant.

  If performance was really an issue, making a weather thread would probably be 
the way to go.  Only minimal amount of locking would be needed - all the weather 
values would be private, so it'd only need to lock access to a map level. 
Presuming the time it actually takes to process each map isn't that great, you 
could do something simple on the object level - if an object is active on a lock 
map, just skip its action for this tick.

  Eventually, I'd like to thread crossfire in this way - at a map level.  But 
not sure if it would fixtoo many problems.  It'd probably fix the biggest which 
is loading/saving a map may take more than one tick.



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel