ID:2475859
 
BYOND Version:512
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 74.0.3729.169
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

When you drag/drop an element over another one, DreamSeeker doesn't recognize that the mouse has entered a new element until the next time you nudge the mouse. I feel that this is a flaw in DreamSeeker's mouse logic, as DreamSeeker should consider itself now mouse hovering immediately following a mousedrop action, regardless of the fact that the mouse has not actually moved since releasing the button.
MouseDrag was called when the mouse entered the other element, right? Only one of MouseEntered, MouseMove, and MouseDrag are ever called at a time, which is why my Mouse Position has to override all of them.

That's assuming there's an atom under the mouse in the new element for mouse procs to be called on. Either way, you're supposed to use the over_control argument of MouseDrop to tell where the mouse is.
Except MouseEntered is called the next time you nudge the mouse while hovering over the element. If this were intended behavior, MouseEntered would not be called at all after the MouseDrop.
In response to Ter13
MouseEntered isn't supposed to be called when you aren't moving the mouse (see MouseMove), which you're not when you're only releasing a mouse button.
So the server knows that the Mouse has begun hovering over the object, completely not needing extra communication from the client to trigger this hook, but it refusing to call that hook until the next time you nudge the mouse isn't a bug?

I get how the system currently works. I'd call how the system currently works botched to the point of bugged. The server already has all the information it needs to call this hook appropriately and prevent the MouseEntered() hook from being called on the next frame. Yet it elects not to despite the fact that this leaves the developer having to track that information themselves and filter redundant calls if they do choose to correct this oversight.

Just because you are fine with it being completely inadequate doesn't mean it doesn't warrant correction.

If the engine wanted me to track this information myself, it would not call the redundant MouseEntered() hook at all. If the engine was trying to be convenient, it would call the MouseEntered() hook upon release of the final mouse button.

Given that not only do we have to deal with the redundant call, we also have to deal with the lack of a call, it seems to me that it is inarguable that the feature is not functioning in a sensible way.
In response to Ter13
Mouse tracking is full of redundant calls, and it's awful, which is why we're all waiting for a miraculous overhaul to solve all our problems.

That MouseEntered is called when moving the mouse after already entering an object may be the real bug.

If you're dropping an icon underneath the mouse when you MouseDrop, then the mouse should legitimately be entering that as soon as you drop. When an atom appears or moves to be underneath the mouse, that should also trigger mouse events.

If you wanted to track the mouse entering the new control while dragging, you should have been using MouseDrag.
From the reference:

Don't define this unless you need it, because it generates extra communication that is otherwise avoided. Most operations can be done through Click(), DblClick(), and MouseDrop(). The other procedures are simply available for completeness.

You should not need to define MouseEntered(), MouseExited() and MouseDrag() to properly maintain the object a mouse is hovering over when no buttons are held. The added overhead of the unnecessary MouseDrag() is avoidable.

I'm sorry Kaio, but I just don't think your argument holds water.

It's counter-intuitive and bad logic that results in code being less straightforward.
In response to Ter13
The way mouse tracking is currently, when the mouse moves, only one of MouseEntered, MouseMove, and MouseDrag are called. They're never called unless movement is involved.

MouseEntered = the first movement onto an atom with no button(s) held.
MouseMove = every other movement with no button(s) held.
MouseDrag = any movement with any button(s) held.

I think this is a pretty straightforward and intuitive system.
I also completely agree, again, that it's awful and comes with a lot of unnecessary overhead.
I never argued that it should be this way, but this is literally how it is. It's not bugged, it's just bad design.

The reason you need MouseDrag is because the mouse has any button(s) held when it enters the destination you're after. That's the way it is, and I've never said that it's a good way.

If you want, you can post another mouse tracking overhaul feature request.
It's a spurious argument that the way it works is not a bug, given the fact that bugs are just unintended consequences of bad or flawed implementations that have undesirable effects.

This is an undesirable effect that is clearly not intended.

I didn't wanna post this, but since it is starting to look like you are start to pull mod card to basically tell me to fuck off out of some misguided sense of: "I am used to it, so it doesn't constitute a bug"...



I'm not arguing there is no logic to how it works. I'm arguing that the result of how it works is so immediately and obviously poorly designed as to constitute a bug that requires zero heavy lifting to fix.

Waiting on a giant mouse overhaul is why things that can actually be fixed don't happen. I find small, targeted problems with the language, I reason out why they don't work as expected, construct an alternative, and chase at the minimal impact solution to find an agreeable, small fix that can be tackled in a reasonable timeframe, and have found better results than +1ing a vague thread about a huge gutting of how the engine works that probably isn't backwards-compatible and comes with a lot of poorly thought through baggage.

Yeah, I'd love a mouse overhaul, but I'd also like to see the engine actually improve in utility for myself and everyone who uses it. Massive overhauls wind up getting pushed off and have done for years, not that Lummox doesn't want to take them on, just that y'all never follow through with targeting and documenting your proposed overhauls to the point that the requests raise more questions than providing clear guidance to what developers actually want to achieve and how they want to achieve it.
In response to Ter13
It's a clear issue with the design, but nothing's actually "broken". At that point, it's only a "bug" if Lummox calls it one.

Whether it's a bug or a feature, we both agree that it needs to change.
In response to Kaiochao
Still, if you want the location of the mouse after a drag and drop, it's in MouseDrop. MouseEntered isn't relevant to the problem because there is no movement involved when releasing the mouse button; all the movement that could have happened prior was captured by MouseDrag.

The reason I think MouseEntered being called from a nudge after MouseDrop is the true bug, is because that's the actual extra overhead. It provides no new information about the mouse that MouseDrop didn't already provide. (Again, that is assuming you're not placing a new object under the mouse cursor in MouseDrop, such that the over-object in MouseDrop is different from the object in the nudge-MouseEntered.)

Calling MouseEntered immediately when dropping (which is your request in this thread, I think?) is the same:
1. it's unnecessary because the information was already just provided by MouseDrop as intended, and
2. it doesn't make sense because it's not in response to the mouse moving.
Except MouseDrop() is called on the object being dropped, not the object being dragged. Which means to reach your proposed ideal implementation for tracking entry/exit on a single element:

atom
proc
MouseDropped(atom/drag_object,atom/src_location,atom/drag_location,src_control,drag_control,params)

client
MouseDrop(atom/src_object,atom/over_object,atom/src_location,atom/over_location,src_control,over_control,params)
..()
over_object?.MouseDropped(src_object,over_location,src_location,over_control,src_control,params)

obj/hovertest
MouseDropped()
icon_state = "hover"

MouseEntered()
if(icon_state=="hover") return //prevent the duplicate MouseEntered() call in this case.
icon_state = "hover"

MouseExited()
icon_state = "idle"



Whereas the softcode fix for this problem, which is the hardcoded fix I'm proposing:

client
MouseDrop(atom/src_object,atom/over_object,atom/src_location,atom/over_location,src_control,over_control,params)
..()
over_object?.MouseEntered(over_location,over_control,params) //will pass irrelevant mouse button information

obj/hovertest

MouseEntered()
if(icon_state=="hover") return //prevent the duplicate MouseEntered() call in this case.
icon_state = "hover"

MouseExited()
icon_state = "idle"



Whereas if this problem is fixed and MouseEntered/MouseExited() are called by default at the end of a drop, and the client now knows that the last hovered object is the same one as over_object from MouseDrop(), we've just simplified the entire thing to:

obj/hovertest

MouseEntered()
icon_state = "hover"

MouseExited()
icon_state = "idle"


I just don't see any reason to prefer your suggested course, because it's harder on the developer down the line for no good reason other than to preserve warped expectations of how BYOND is supposed to work due to years of working with it in an undesired state.
In response to Ter13
It's Bumped() all over again. What an engine.

Login to reply.