MouseOver ideas

ID:259419
 
Nov 17 2001, 8:09 pm
The new mouse functions in 306 are great. But obviously the one thing that is missing is some sort of mouseover functionality. Not only would it instantly add to the "glitz" factor of many games (although unnecessarily in most cases), it is also fairly important to a couple of upcoming games I'd like to do.

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:

turf/MouseEntered()
turf/MouseExited()

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.
  1. 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.
  2. 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?
Nov 17 2001, 9:06 pm
Comments?

Better than my old MouseOver() suggestion.
Nov 18 2001, 5:37 am
Air Mapster wrote:

So there it is. Comments?

Yes, please!

flick()
Nov 18 2001, 5:37 pm
In response to Flick
I like that idea. It seems like it would work more like the onMouseover() and onMouseout() procs that JS uses.

I eagerly await these things!
Nov 18 2001, 9:04 pm
Air Mapster wrote:
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 realize there is danger in this, but I'd like to encourage the willingness to add some features that may well be too laggy for online play. Many games are likely to be offline games (or email-based), and it would be a shame to not have some basic features that help those because of network lag issues.

The danger of course is that once you add something, people will insist it work flawlessly in a multi-player environment...perhaps putting a clear indicator that something is intended for single-player games only will help.
Nov 19 2001, 4:10 am
Air Mapster wrote:

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.

Your suggestions are sensical enough. It would be trivial to just provide MouseOver() (or MouseMove()) for all objects; like you guessed, our concern was just the haphazard abuse of such functions in network games. None of the Mouse() network events are triggered unless the functions are specifically overriden in the code, so this isn't really an issue for most games. One caveat though: because of the possiblity of client events (client.MouseMove()) and other overhead concerns, there isn't a reliable way to detect this on a per-object basis, so if you override one MouseMove() it'll check it for all objects. I think that was our big gripe with it all. I suppose it could be handled with another object var, or we could just assume the designer is trustworthy. Hmf.
Nov 19 2001, 4:50 am
In response to Tom
Tom wrote:
... we could just assume the designer is trustworthy. Hmf.

A cold shiver is felt throughout the BYOND community.