I assume the primary reason is due to the potential network overhead incurred by players haphazardly moving their mouse pointers all over the map. MouseDrag() isn't so much of a concern because the developer would have to specifically code it in and presumably would be aware of the network issues if used.
I've been thinking off and on the past few weeks about implementations that might work relatively well. Finally got some decent ideas, so I figure I'd throw them out and see what anyone else (and/or Dantom) thinks. My understanding is that 307/308(309?) is late in the cycle and is intended to be the last major feature upgrade before the push for stability. I don't want to delay things any more than they are already, so if that's a big concern, ignore this.
Anyway, I think that the vast majority of developers won't need or want mouseover granularity to be finer than per map location. It's unlikely that anyone would need to distinguish from the mouse being over a mob or obj, for example, as opposed to exposed portions of the underlying turf. So perhaps only turfs would need mouseover procs. Developers could then always check the turf's contents to further refine what happens on a mouseover event. So, what if turf added these builtin procs:
Much like the Entered() and Exited() procs that already exist. Additionally, it would be good to have a way for mouseover events to be completely suppressed if unnecessary. I figure this can be achieved one of two ways.
- Have a global (perhaps world.) variable or define that toggles mouseover behavior. The default setting would be off, in which case the client would send no messages.
- Let the client know about which turfs have overridden the mouseover procs. Only those turfs will send mouseover events. Or perhaps have a turf variable that can toggle mouseover events on a turf-by-turf basis. Of course, this assumes the client is even capable of knowing this kind of information and I have no idea if it's possible in the current BYOND framework.
So there it is. Comments?