Mouse_hover event

Please add this, basically it queues an event when the mouse moves over a pixel, then returns x and y

…. No…. Just, no..

Do you know how many times your mouse "hovers" over a pixel in computer craft? You'd be spamming so many events to the computer/thread.

Jiloacom, on 07 November 2014 - 03:16 AM said:

…. No…. Just, no..

Do you know how many times your mouse "hovers" over a pixel in computer craft? You'd be spamming so many events to the computer/thread.

Fine, add a default time delay.
If your mouse is over a pixel for 4-6 seconds

Firstly, as Jiloacom stated, you'd be spammed with events, it would take forever for event loops to come to the events they want.
Secondly, this poses problems within multi-user environments… if a player clicks 1,1 and a player is hovering over 4,5 and another player is hovering over 34,40 what do you do? also, what happens if a player is hovering over 14,23 and then closes the GUI, should there be a de-hover event too? there are just too many variables that come into play, the feasibility of this once implemented wouldn't be great, it would cause problems, and not at all be reliable.

Multi-users is easy; you just spam more events and let the scripter work out the rest from there. ;)/>

I don't think a mouse_enter and mouse_exit event would be spammed too much. Rather than a mouse_hover event every tick, which would be ridiculous, an event that fires when the mouse moves an in-game pixel. Like from pixel 1 to pixel 51.
Many people use computers and turtles for automated tasks, and don't use the GUI often.
The ones that do use the GUI could benefit hugely from thinks reacting to them moving their mouse around.
I'm not sure how well this would work, but there could maybe be a config option that enables/disables this (disabled by default), which would allow people to send feedback, and results to be gathered as to whether it does spam events too much.

I feel I should also mention the network bandwidth/resources implications… as it currently stands whenever a key is pressed, or the mouse is clicked, an event is sent from your client to the server, so that the ComputerCraft computer may know what you're doing, this is fine-ish. However, if you were to add the mouse hover events, this would mean that your client is constantly sending data to the server, multiply this across a server of people doing this, and the bandwidth implications could be immense, not to mention the impact on TPS that i could cause due to the server requiring a bunch more processing.

I think that term.getMousePosition() will work better. It would return a table where each element is a diferent user. like {[User1] = {x, y}, [User2] = {x, y}]

As I understand it each User is considered "looking only" as far as no buttons pressed.
And I think it should remain so.
So no way computer should sense anyone without key pressed.

theoriginalbit, on 07 November 2014 - 02:17 PM said:

I feel I should also mention the network bandwidth/resources implications… as it currently stands whenever a key is pressed, or the mouse is clicked, an event is sent from your client to the server, so that the ComputerCraft computer may know what you're doing, this is fine-ish. However, if you were to add the mouse hover events, this would mean that your client is constantly sending data to the server, multiply this across a server of people doing this, and the bandwidth implications could be immense, not to mention the impact on TPS that i could cause due to the server requiring a bunch more processing.

I understand it would be more resource intensive, but surely mouse_drag events work in roughly the same way? The way I see it, there would probably be around 1 or 2 events per second per user on a computer on average. I don't know how bad that is for a server to deal with, so I won't say it definitely is possible, but maybe it's not quite as bad as people think. I can understand that for multiplayer servers with hundreds of people on, it wouldn't work, but I haven't yet joined a cc server with more than about 20 people on, let alone all using a computer GUI at the same time.

Drag events are tied to the mouse moving, and even then, only when the button is held.

Granted, done correctly, you'd only get one "hover" event per mouse movement anyways - but there's a large difference between how often you simply move over your display and how often you specifically drag over it. At least it shouldn't be any more resource intensive than usual if the mouse isn't actively being used, but it's still a bit of a load (especially given that every movement would require data to be sent from client to server, whether or not your scripts take advantage of the resulting events!).

As for a function for getting positional data… that would end up revealing data the computer really shouldn't know, such as how many users it currently has. The systems are supposed to be "blind", but given the new turtle.inspect() command in the later versions of CC1.6, I suppose I can't say that providing that sorta info goes against Dan's mindset.