Courageous
Wanderer
Mentioned issue is associated with a MobileIncoming packet being sent after the RemovePacket. I've resolved that.
Progress Report
The LOS system is now working quite effectively under test. I've had a variety of false starts along the way, and finally have recently turned the corner. I still don't have a good estimate of the size shard that the system will support yet, because the recent optimizations I've put in are statistical in nature, and I haven't collected the facts from a real shard. Here's the scoop.
First, generating a LOS matrix is, on average, cheaper than actually doing just one Map.LineOfSight() test. In addition to the matrix creation being faster, once the matrix is created, it is nearly "infinitely" faster to calculate LOS with the matrix than with the old LOS algorithm. This is relevant. When you are lossing from a current location, you're quite likely to be doing it more than once if there are multiple mobiles and items in range, which there most often are. In this sense, this LOS system is about double the speed of the old for just one LOS check, but then goes up in performance linearly with the number of mobiles and items checked. IOW, if you check for 23 mobiles and items, the system is about 24X faster than the old one.
In any case, what this means tis hat this system, without any further modification, would be better for "true line of sight" than the standard algorithm (which is a line drawing algorithm, based on Bresenham's original line algorithm), without any further enhancments.
And it gets better, because there are enhancements.
Since establishing the matrices and protocol hooks, I've experimented with many optimizations. The thing that seems to work is a cache of the MRU variety (keep most recently used), sized according to the size of the map. For example, keep maybe the 250,000 most recently used posiitions on the map in a cache. There are some complexities to this cache; simply put: not all information about the world can be cached, for example non static items and what not, plus new houses that might be placed at runtime and so forth.
Now here's where the unknown comes in. I really don't know how often I'm likely to have cache hits in a server. It's probably true--probably very true--that the vast majority fo the player base is visiting no more than 5% of the map regularly. But I really don't know what the figures are, so I am just guessing here. My guess: we'll have very, very high hit rates. And high hit rates means "almost free LOS". So that's pretty exciting.
Things are moving along. It's been... more complicated than I anticipated. But things are looking quite good here. While I am not promising anything, there's some chance that this system might actually be usable on a large shard. That remains to be seen.
More soon.
I'm thinking it's about maybe two weeks before I'll start looking for alpha testers. This will require a core recompile, using DOTNET 2.0.
C//
Progress Report
The LOS system is now working quite effectively under test. I've had a variety of false starts along the way, and finally have recently turned the corner. I still don't have a good estimate of the size shard that the system will support yet, because the recent optimizations I've put in are statistical in nature, and I haven't collected the facts from a real shard. Here's the scoop.
First, generating a LOS matrix is, on average, cheaper than actually doing just one Map.LineOfSight() test. In addition to the matrix creation being faster, once the matrix is created, it is nearly "infinitely" faster to calculate LOS with the matrix than with the old LOS algorithm. This is relevant. When you are lossing from a current location, you're quite likely to be doing it more than once if there are multiple mobiles and items in range, which there most often are. In this sense, this LOS system is about double the speed of the old for just one LOS check, but then goes up in performance linearly with the number of mobiles and items checked. IOW, if you check for 23 mobiles and items, the system is about 24X faster than the old one.
In any case, what this means tis hat this system, without any further modification, would be better for "true line of sight" than the standard algorithm (which is a line drawing algorithm, based on Bresenham's original line algorithm), without any further enhancments.
And it gets better, because there are enhancements.
Since establishing the matrices and protocol hooks, I've experimented with many optimizations. The thing that seems to work is a cache of the MRU variety (keep most recently used), sized according to the size of the map. For example, keep maybe the 250,000 most recently used posiitions on the map in a cache. There are some complexities to this cache; simply put: not all information about the world can be cached, for example non static items and what not, plus new houses that might be placed at runtime and so forth.
Now here's where the unknown comes in. I really don't know how often I'm likely to have cache hits in a server. It's probably true--probably very true--that the vast majority fo the player base is visiting no more than 5% of the map regularly. But I really don't know what the figures are, so I am just guessing here. My guess: we'll have very, very high hit rates. And high hit rates means "almost free LOS". So that's pretty exciting.
Things are moving along. It's been... more complicated than I anticipated. But things are looking quite good here. While I am not promising anything, there's some chance that this system might actually be usable on a large shard. That remains to be seen.
More soon.
I'm thinking it's about maybe two weeks before I'll start looking for alpha testers. This will require a core recompile, using DOTNET 2.0.
C//