Kaiochao wrote:

I'd imagine what Lummox meant for MouseMoved() is that it would called whenever the mouse is moved and is over an atom ...

If this were the case, I would be done with BYOND almost instantaneously.

It would be really nice if we didn't have to parse a string every time.

I agree, but that's not going to happen.

Hiro the Dragon King wrote:

Kaiochao wrote:

I'd imagine what Lummox meant for MouseMoved() is that it would called whenever the mouse is moved and is over an atom ...

If this were the case, I would be done with BYOND almost instantaneously.

Not sure I understand why. That would be an extension of the existing functionality. If you're looking for mouse functionality outside of map/statpanel/etc. contexts, that's really a separate issue. And there's no reason they couldn't be combined, but one doesn't require the other.

Hiro the Dragon King wrote:

I have no idea what you want from us when it comes to these requests, as you continually ask for discussion (if you say anything at all) on the topics and the discussion is never good enough or usually ignored.

I'm sorry, I don't mean to seem argumentative on this at all; it's just that to me, this is a shifting topic. I commented on this topic again because I saw there was continued interest in it. To be honest, I really had no idea until just recently you were more concerned about general tracking outside the map, because I was looking at everything through the lens of the request.

I do want to stress that I think general tracking is worthwhile.

The initial request here was for updating the mouse within the tile. Every single response has been about implementing some sort of tracker for the mouse. They are the same issue. We have no ability to track the mouse at all. Why would we restrict the conversation to the confines of such a small portion of the functionality when we have no functionality?

I'm really fine with free-range brainstorming in a feature thread to a point, but when the initial post gets obscured it starts to get confusing. Calus posted about updating within the tile; that's well in-line with current functionality and would just be making a small adjustment so that some games could benefit from mouse updates when the mouse doesn't change to a different atom. General tracking is a much broader topic, and takes the request from a small tweak to a more substantial change.

I don't disagree on the merits of that change, but I don't think it's unfair to pick at the low-hanging fruit first, especially when I see a clear implementation path to it. I suspect I can satisfy the initial request, though I haven't looked into the atom/client flags situation yet. The topic of general tracking, while I agree it would be useful, is more involved.

Just to clarify what I mean: We're already tracking mouse moves within the map. We only generate an event when the atom hit test changes, or when the mouse leaves or enters the map. Generating an event when the hit test doesn't change, but the icon offsets do, is relatively simple. I see this as being pretty useful for games where you point and shoot, in that a turret can track the cursor more readily before you click. Tracking the mouse outside of the map (or statpanel or grid) requires a more comprehensive solution, ensuring we catch mouse events at a high level and can respond appropriately. For consistency, it seems we would also want to generate mouse events for click interactions with other interface controls, since it's more than about tracking, and that complicates the issue a lot more.

Should I seriously make another ignored feature request asking for mouse tracking in general? Is that what you've been waiting for?

I understand your frustration, really; a lot of requests never do see any action, and largely it's because of time constraints. I do think it's a separate discussion; but I agree it's one worth having. I'm not really saying yet that it should spin off to another thread, but I don't think it's unfair of me to still keep the original request in mind and give it first priority.

Personally, I wouldn't mind throwing in some kind of general tracking along with this (it could be triggered the same way, via the presence of a MouseMove() proc), but I do think if we didn't support up/down/click/drag events outside the map that might be a little inconsistent. Tom's position on new features has always been that they should be clear, easy to use, and consistent. Just tracking seems like it would be halfway between the easy response to CC's request, and the full monty. But is just tracking enough, if we go there?

Just for clarification, I assume--because I don't see the alternative as feasible--we're strictly talking about tracking within BYOND windows. It does raise the question of how the coords would be presented (relative to a map, and if so which one?).

Perhaps a new thread might not be a bad idea. As much as I think there's been some helpful discussion in this one, it was kind of muddied by the context. I'm not sure everyone was on the same page here.

Being honest, because I don't want to overpromise, I want to look into the original request in this thread as a possibility for 500 because I think it's likely something I can readily do. More in-depth mouse tracking outside the map is a bigger project however, and may not fit my timetable at this time. (I actually wanted to get BYOND 500 out to users a lot sooner than this. However I got sidetracked on a couple of potential features that didn't work out. This is particularly why I'm so interested in low-hanging fruit right now: I want to pack maximum punch in this release, preferably with minimum new-bug potential.)

IIRC you've done some mouse-heavy projects, like ones with turrets that track the cursor. Although I see some merit in continuing that tracking outside of the map control (but not necessarily outside of the window, which is another ball of wax entirely), I do think being able to track in-tile changes would be a huge leg up for such projects. Applying mouse stuff more generally to the rest of the interface would open up some other things, but its uses would seem to be more for the interface itself rather than tracking, IMO. I'm not sure exactly what you had in mind for it, but I'd like to think that the smaller first step at least puts things on the right track and makes things possible for you that weren't before.

The current implementation of MouseMove() is not going to work for me. It only updates the mouse while no buttons are held. I pretty much need the exact opposite of that. I want to track the mouse only while the left button is held. Tracking the mouse is useful for more than just moving turrets around.

I was hoping to improve my pixel precise selection box system with this. It currently relies on something similar to Forum_account's grid solution. However, I'm glad that I can speed it up significantly with the new animate() system, but that's just the visual side of things.