How feasible would it be to add a var, preferably a bitmask, that would control when events such as MouseEntered/Exited/Move/etc were sent to the server?
That way one could theoretically add the procs to atom and not have much performance loss if said var was set.
ID:1957327
 Oct 8 2015, 9:24 pm
|
|||||||
| |||||||
There actually is something like this built in already for the mouse procs. Appearances have flags that indicate the presence of these mouse procs (it occurs to me that I need to make sure they don't carry over when setting the appearance var), and there are .dmb-wide flags indicating the presence of the procs for /client.
If the procs are set for /client, then the corresponding mouse commands are always sent. If they're atom-specific, they're only sent when the right atom is involved. There isn't yet a way however to have the /client procs set and still be selective about the mouse commands, though. If that's what you'd like, I think I need some clarification on how that would look from a syntax standpoint. [edit] Correction: There appear to be no atom-specific flags for MouseUp and MouseDown. There are however flags for over/enter/exit (which are all the same command internally), move, and wheel. | |
Yeah I figure that mouseup/down are always called, but I'm talking about the rest. Not for /client procs because that'd just be too hard for you, hell anyone, to manage a proper implementation. (However, perhaps something like client.setInputMask?)
| |
The rest are already handled. There are flags in the appearance that tell Dream Seeker, if the global flags for /client aren't in play, that the atom uses those particular mouse procs.
I did however correct the appearance var in 509.1305 so it will not change those mouse proc flags when copying an appearance. | |
Give us a var for setting the atom mouse flags then. That should be the easiest solution that everyone would like.
| |
I'm not sure I follow, though. The flags are set automatically by the presence of the appropriate procs. Can you lay out a scenario for me where that's not the desired behavior, and what you'd prefer instead?
| |
Well, for instance, setting a MouseEnter/Exit on /atom to make it easier to implement a random feature, but not actually wanting it to be called on every atom.
| |
+1 for this, would be hella useful for some recent projects I've been fiddling with.
| |
It's nice just to know that the door is open for this. Technically speaking it doesn't enable more features, it just reduces the number of useless network messages sent.
| |
I ran into a situation needing this again, would it be feasible for 510?
| |
Perhaps also flags on client objects to determine whether or not their mousemove always calls? Hmhm
| |
But why wouldn't you simply define the mouse procs on the type you want to check, rather than trying to add them to all atoms (or a much wider subset of atoms) when they're not needed? The example you gave of how this would be used isn't really a good example, because it's indicative of a design flaw.
| |
Because what if you want to control whether or not some atoms get it called dynamically? Games are ever-changing at runtime, and ways to optimize it at runtime also would be a nice addition.
| |
In my case, I'm using /client/MouseMove to overlay a "cursor" on observers screens, but I only want to do that on specific clients at specific times(eg why do it if noone is observing that player, etc)
| |
Tom talked about doing this at one point.