When working with Mouse procedures, I would like to be able to grab the current mouse pixel_x and pixel_y from the params, while staying in the same tile.
Right now, for an example, if I use MouseDrag(), it will tell me the pixel_x/y once MouseDrag() has been initiated. But if I move within the tile, I can not grab the new pixel location. The only time pixel_x/y updates is when you move into a new tile.
ID:92356
 Mar 2 2010, 5:31 pm
|
|||||||
Resolved
| |||||||
|
Mar 3 2010, 4:25 am
|
|
Lummox JR
   |
I'm not sure how feasible this would be because the sheer number of messages it could send would be staggering, but it's something that can be considered. We would need to make this behavior optional however because it could potentially break existing games and would definitely use much more bandwidth.
|
I would fully support this feature. I wrote library, terribly, I might add, that has a function that uses JavaScript to grab the mouses coordinates at any given time. Unfortunately, it is as slow as every other mouse function because it grabs the absolute position of the mouse on the screen and I have to compensate for where it is on the map judging from the map's size, the world's icon size, and a bunch of other variables.
| |
Wouldn't it be possible to just add some sort of client/proc (MousePos?) that can be called to retrieve this information?
That should prevent it from breaking existing games, or even effecting them at all, and should give the desired functionality for new projects. I could definitely use something like this in a couple of the "shooters" that I'm currently working on. | |
I think that I'm going to give this a little nudge, a bump, you might say. MousePos() would be a great addition and would greatly reduce the amount of work that I've done and that my library needs to do.
| |
What else needs to be discussed? It would probably work best as a procedure, MousePos() that returns a string equal to that of the parameters of the general mouse procedures.
| |
Please don't add gratuitous comments just to react to a status change. "Needs Discussion" means the feature needs more fleshing out before it can be considered, but this is still a step up from "New". I laid out some of the more readily apparent concerns in my initial comment. Those concerns have not yet been addressed; therefore this needs more thought.
A proc would definitely not be the best choice to handle this kind of thing. That would require a network call to the client and waiting for a reply, which would basically make it impossible to have accurate coordinates due not only to network lag but also to the way those kinds of procs are handled. Something closer to Calus's initial suggestion would be a much better way to go, since it would work with the existing mouse procs and require relatively few changes on the frontend. The question remains whether this would really be all that desirable because it could impart considerable network overhead, and if so we'd still need a way to make it available only for games that needed it. | |
I didn't mean to make an erroneous comment. I just found it a little annoying to get a "Needs Discussion" without anything being added to the actual discussion.
I have a procedure I made myself that gives me perfectly accurate coordinates, on command. I know that I haven't any idea what I'm talking about. I don't know much on the programming side of BYOND itself, or anything else for that matter. I only go by what I've learned from experience. I'm just gonna fade back out now. | |
Hiro the Dragon King wrote:
I didn't mean to make an erroneous comment. I just found it a little annoying to get a "Needs Discussion" without anything being added to the actual discussion. That means it got upgraded from "New" but it still needs further brainstorming. It's not necessarily the case that when an issue gets upgraded to "Needs Discussion" that the person upgrading it has something to add right away. This is not anything to get annoyed about. | |
Bump!, mainly because of this problem.
I do agree that this needs more discussion, considering there's a lot of different "mouse coordinates" that you could want to extract. Found in HDK's library are actually a few different sets of coordinates that you have the option of processing. The mouse's position is given in the form of: -screen_loc(x:px,y:py) -the exact position on the screen(based on resolution) -the map position(x, y, and pixel_x, pixel_y) and each of these can be activated/deactivated, removing that extra communication. The question here now is, how should the developer be reading this information? One way would be to have it like the library does; as client variables. Another is to just have a few procs (MouseScreenLoc("screen_loc" or x, y, px, py), MousePos(x, y), MouseLoc(x, y, px, py)). I counter comment #1 with this snippet in every mouse proc from the DM Reference: "Don't define this unless you need it, because it generates extra communication that is otherwise avoided." The extra overhead caused by this is a design choice so the proper sacrifices will be made, such as a player limit or something. If this isn't implemented as a set of procs, you'd definitely want it to be like HDK's library with matching const client vars or a single flag var. I really want to see this in, mainly because it would be completely awesome. With more projects being worked on with Forum_account's Pixel Movement and the pixel movement optimizations being made, it seems like BYOND's delving deeper into the smooth, pixel-based interaction that a lot of non-BYOND games are like. I don't know how long this trend will last, but I really do hope things can only get better. If I could think of anything else to type to get this feature pushed further, I'd definitely throw it out there. Go mouse! | |
I counter comment #1 with this snippet in every mouse proc from the DM Reference: The concern of comment #1 isn't just that this would cause lag issues for people who aren't using the feature, but that there's no way to make this run efficiently enough for the people who would use it. That being said, I do think its possible to make it efficient. The client can already determine this information, it just needs to know to send it to the server every tick. I'd make it a new proc (MouseUpdate, or something like that) that is passed the same values that other mouse proc get, but instead of being called when you do something with the mouse (click, drag, cross an object boundary, etc.) its just called every tick. If the DM program doesn't override the MouseUpdate proc, the client won't send these updates to the server. It'll be called every tick which shouldn't be any worse than having a client call a verb every tick (and its identical to a client clicking every tick. I'm sure someone has done that, so if the results were catastrophic we'd have heard about it by now). I assume that macros that make use of the key repeat rate send commands to the server every tick. The default movement system uses this, so if that doesn't cause problems, this shouldn't either. It could skip sending the message if the information hasn't changed. If the mouse is at the same position over the same atom, no information will be sent to the server. When this happens, the server will still call the proc and just pass it the same values it passed it the last time. | |
Forum_account wrote:
If the DM program doesn't override the MouseUpdate proc, the client won't send these updates to the server. That's kinda what it already does with the other mouse procs. I guess I just forgot to mention the importance of if this feature was in the form of procs instead of variables. | |
I approve this feature and I would give it votes if I could.
| |
With the advent of the Flash client and native pixel-based movement, isn't it kind of silly to lack mouse coordinate detection?
P.S. Bump. | |
Bumping because I feel like this is a feature worth bringing up once more; the summer is coming to a close and the flash client release is supposed to be around the corner but no progress has been made on this feature request.
Games that need Hiro's library (Bravo1's Darkness, my last project, Kaiochao's shootah, and a few others) are automatically incompatible with the flash client simply because they need to be able to access the mouse coordinates, regardless of whatever interface controls they may or may not use. As it stands, I would be willing to accept a MousePos() proc that retrieved the mouse coordinates via network call to the client, despite the network lag. I'm certain that HiroTDK's library generates the same, if not more, network overhead than a native proc would; any sort of native implementation for this feature with flash-client compatibility would be a vast improvement over all other available alternatives at the moment. I think it's unavoidable that network lag will heavily affect the solution since client-side processing, the antithesis of BYOND, would be required for any speedy and precise mouse-based game interactions. Onto the specifics I suppose. MousePos() should have the following forms: //To a dreamseeker client: MousePos() returned format should be a string: "[mouse_x],[mouse_y]". Perhaps different MousePos() parameters can change the returned format, maybe one version can return tile-based coordinates with pixel offsets. Maybe something like client.MousePos(elementName, returnFormat) | |
LummoxJR has already posited the issue with this implementation.
LummoxJR wrote: A proc would definitely not be the best choice to handle this kind of thing. That would require a network call to the client and waiting for a reply, which would basically make it impossible to have accurate coordinates due not only to network lag but also to the way those kinds of procs are handled. I've been thinking of this recently and thought of a proposed solution. What if we could use a call to winset() to determine whether a client should track it's mouse and relay that information to the server. Then, instead of using of associative lists, convoluted variables, or carrier pigeons call for coordinates, you could use Darke's idea of client procedure to simply translate the information into usable values. The issue is, the client would either have to keep the server updated of the position and size (because maps y-axis is inverted compared to the interface) of every element in order to translate correctly, -OR- the winset() call would have to specifically mention which element to keep updated position and size values updated for. You could even do both, having the winset() call have an ALL function. Then you could make this call: client.MousePos(elementName, returnFormat) | |
So it's not possible to have this feature because of network lag? I use Forum_account's Mouse Position and the only problems I've had with it was that you can only click on the dithered tracking HUD (which can be toggled and have objects layered above it, so that's not terrible). I think that was a pretty good solution and is better laggy than nonexistent. Just make it less obstructive.
But that's just for the map. Skin controls should just use JavaScript to do its own client-sided actions. Maybe give windows a scripting tab with events to fill in with skin changes based on user interaction. | |
I need this feature.
| |
As do I.
| |
Bump~
I'd rather have this than browser embedding for games. | |