Preston Crow wrote: > On Thu, 2005-08-25 at 18:57, Anton Oussik wrote: > >> When the server comes across maps containing large amounts of items it >> takes a long time to load. While it is loading the whole server >> freezes for other players, and on very large maps (like the scorn sale >> shop or some apartments) this can take in excess of 10 seconds on >> metalforge. > > > The way I would solve this is to have the map loader count how many > objects it has loaded. After some fixed number, it would stop until the > next time tick. There would be no processing of objects, including > players, on a partially-loaded map. > > This would eliminate the lag for everyone except the player entering the > cluttered map. > > I'm just not sure if this is less work than the other approaches to > solving the problem that have been suggested. the problem is that the loader itself stores state information. So, while unlikely, you could get this case: Player A enters some exit. Map starts to load, gets to point, and returns expecting to continue next tick. Player B enters map, laoder kicks in, this map finishes. Next tick, when it tries to resume loading map A, the lex state is messed up, so the load fails or you get weird results. Now this can obivously be fixed (is any map in proces of being loaded but not finished, etc). Many years ago, I tried this approach, but never to it stable enough. I'd still be more tempted to just go the threading approach - to cover the above case, its probably not too far from getting a threaded system anyways. Its how well you want a threaded server to scale that becomes an issue. One coud just set some very broad thread locks - easier to do, but means it wouldn't scale as well. But at a first pass, and given current loading, that may be good enough. > > --PC > > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire