Obtaining mouse parameters with a user defined proc?

ID:155198
 
Aug 20 2011, 4:52 pm

Hello there everyone, I was wondering, is it possible to define your own procedure that will grab parameter data from the mouse?

Here's an example of how the mouse parameters are generated.

client
    MouseEntered(object, location, control, params)
        ..()
        src<<"[params]"
        params=params2list(params)
        for(var/v in params)
            var/a=params[v]
            src<<"[a]"



This will output the position of the mouse to the world. I can use this, but the issue is: I want it to update/generate this information when I need it, instead of only when any of the mouse procs are called.

Is there any way to grab this data outside of the mouse procs?
Aug 20 2011, 9:54 pm
Not with DM.
Aug 20 2011, 10:03 pm
In response to Zaoshi
Well, couldn't you essentially fill the screen with thousands of screen objects and use their MouseEntered() to generate more exact positions?

I mean, I don't see why a proc that already returns the mouse position from within DM can't do it repeatedly under a user defined proc.

I know I could use Javascript, but apparently that's been causing big issues recently and it's turning out to be a dead end as a viable way to get the mouse position
Aug 20 2011, 10:17 pm
In response to Bravo1
That's right, you could fill screen with 1 pixel objects, however that would generate extreme amount of network communication.
Aug 20 2011, 10:25 pm
In response to Zaoshi
I'm just using it as an example, it's a terribly inefficient way to go about it, overriding any of the mouse procs as it is just asks for network lag, but if DM can return a mouse position by itself then why do I have to use javascript to grab it when not using one of the built in procs?

I'll probably put up a feature request for it. Being able to call something like MouseInfo() to get it's position and relational parameters would be incredibly helpful.
Aug 21 2011, 1:59 am
In response to Bravo1
Probably not high demand in such function, so they don't make it.
Aug 21 2011, 2:40 am
In response to Bravo1
There's already a couple feature requests for this.
Aug 21 2011, 4:03 am
I'm not sure how well it'd work but you could, as others have mentioned, put objects on the screen to detect more mouse events. You don't need to fill the screen and they don't need to be 1x1 objects.

I don't use the mouse procs much, but maybe you can make screen objects that represent rows and columns. You check both and based on which row and column you enter, you know the overall mouse positions. You'd need screen_width + screen_height objects instead of width*height objects. I'm not sure the mouse events would work for this.

You can create a small number of objects and have them follow the mouse. You only need these additional objects near where the mouse is, you don't need them to cover the whole screen.

You also might not need them to be 1x1. Unless you need absolutely perfect coordinates, using 16x16 or 8x8 objects would give you much better resolution than you currently have and would use 4 or 16 objects per 32x32 tile instead of 1024.

There's also this feature request: http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=1136
Aug 21 2011, 5:23 pm
In response to Forum_account
Forum_account wrote:
> I don't use the mouse procs much, but maybe you can make screen objects that represent rows and columns. You check both and based on which row and column you enter, you know the overall mouse positions. You'd need screen_width + screen_height objects instead of width*height objects. I'm not sure the mouse events would work for this.

With width+height objects they'd overlap each other, wouldn't work exactly right.

However this gave me an idea... Dream Seeker uses per-pixel precision for icons, not rectangles like tiles are. So it can be as low as 2 objects per tile. Here's the demo: download

Network usage goes up to 1 kb/s with single person constantly moving mouse, however it doesn't update often enough because of tick lag. Setting world.tick_lag to 0.01 makes updates instant, but raises network usage too.
Aug 26 2011, 4:58 pm
In response to Zaoshi
Zaoshi wrote:
However this gave me an idea... Dream Seeker uses per-pixel precision for icons, not rectangles like tiles are. So it can be as low as 2 objects per tile. Here's the demo: download

I went ahead and made a library out of this.

I tried using just one icon and catching the entered and exited events, but for some reason that didn't work well. You'd think it'd be the same as using two objects and catching only the entered events (since every entered event would correspond to an exited event with the 1-icon mode), but it wasn't.