In our speech code, we frequently want to obtain a list of not just the mobs that are in view of a source atom, but also the mobs that might be contained within atoms in view.
Unfortunately for us, doing a recursive search for mobs is out of the question. Since speaking is one of the more frequent actions players take, our speech code is fairly performance-critical and a recursive search is far too costly.
We have a workaround that works for mobs nested one level deep, occasionally that's not enough. We also have a similar problem with viewing actions. Right now I'm working on an issue related to people in vehicles not being able to see emotes or certain messages.
I'm wondering, how feasible would it be for BYOND to support a fast builtin version of range() and view() that returned mobs in range/view as well as any mobs contained in atoms in range/view, recursively? Is it something that we might see in the future?
What I did for extra performance from my "Say" verb was to give every area a player_list variable which every player entering that area registers itself with.
If you have a mob in another mob's contents, mob.loc will be the mob they are in, so just place that mob in the same area as the mob they are in. Then make your own view-like function, for example Say_view(), that loops through the area's player_list, and returns any mobs in the list which are within range of and viewable by the center mob. To check whether the mob is viewable, I made my own proc too called Is_viewable(), which performs much faster than view(), and using view() in this code would defeat the purpose anyway. Is_viewable() just draws a line of turfs from the center to the target, and returns false if it finds an opaque turf, indicating the target is not viewable. Otherwise it returns true. I had to make these changes because player communication caused a major slowdown on the server when it used view() and after these changes it is of no concern at all. The cpu usage in the profiler from player communication has decreased to 1/20th of what it was. | |
I wonder if this thread is better suited to the design philosophy forum? I'm expecting more of a discussion rather than content-less posts like Kaiochao's.
Anyways, We already do something like this where we go through the player_list instead of searching through the results of view. The problem is that it only works one level deep. Using custom LOS code instead of checking the mob's loc seems innovative though, although I'm not sure how receptive our devs would be to that. I'm honestly not sure how far we can get with this problem without builtin support (I might be wrong though). That's sort of what I wanted to discuss. It seems like a general enough problem that such support might be of value. | |
Just discovered the call()() proc.
I wonder how feasible it would be to offload expensive processing to a native library... Is there an API for manipulating BYOND objects? | |
The solution I'd use is to keep a global list of all hearers and then loop through that list to see the distance between that hearer's turf and and the talker's turf. If it's within a certain distance, only then you can do the expensive view()/viewers()/in_view()/whatever check.
| |
world // or world.contents