Introduction

Glitchfinder's Mouse Input Module is an advanced scripting tool that provides full scripted access to to check various attributes of the mouse, from location to the key status. It is useful in the sense that it will not break the default Input module, and because it allows you to use the mouse, which you cannot do with default RMXP. It is more accurate than AWorks, which has several logical errors in its mouse related programming. It also does not need to be updated, aside from the default call to Input.update that is used in most cases. Finally, it does not break default scripts or events that use key input.

Features

• Check the mouse location!
• Check the mouse keys!
• Includes double clicking support!
• Includes dragging support!
• Doesn't break the default Input module!
• Does not break events or scripts that call the default Input module!
• Automatically updated by the default Input module!
• Allows you to check to see if a key has been released!
• Doesn't crash on F12!
• Can check more than one button at a time!
• Allows you to hide the mouse!
• Uses the famed Any key!
• Used the Any key's little brother, the Any button!

Screenshots

Since this script has no visual elements, a screenshot cannot be taken.

Script



Instructions

Place this script above Main, and below the default scripts. This script must also be placed below Glitchfinder's Key Input Module.

This script requires Glitchfinder's Key Input Module. This can be found at his site, which is located at http://www.glitchkey.com

This module is automatically updated by the required Keys module, which means that the only time you need to call the update method is in a scene that does not update the default Input module.

This module does not break the functionality of the default Input module.

To use this module, simply use one of the four methods (press?(key), trigger?(key), repeat?(key), or release?(key)), where key is the index of the key you want to check. Key may also be used as Mouse::KEYNAME. For a list of acceptable key names, look below the header.

There is a key named ANYKEY. This can be used like any other key, with the exception that, instead of corresponding to any one key, it reacts to them all. If you use it, and any other key would cause the same method to return true, then the ANYKEY will also return true. This takes into account all keys on the keyboard, as well.

There is a key named ANYBUTTON. This can be used like any other key, with the exception that, instead of corresponding to any one key, it reacts to them all. If you use it, and any other key would cause the same method to return true, then the ANYKEY will also return true. This only takes into account keys on the mouse.

This script has several additional methods, details of which are in the method list below.

Requirements

Glitchfinder's Key Input Module.

Method List

Mouse.update

Updates mouse input. Calls to this method are not necessary unless the default Input module is not being updated.

Mouse.press?(key)

Determines whether the button determined by key is currently being pressed. If the button is being pressed, returns true. If not, returns false.

Mouse.trigger?(key)

Determines whether the button determined by key is being pressed again. "Pressed again" is seen as time having passed between the button being not pressed and being pressed. If the button is being pressed, returns true. If not, returns false.

Mouse.repeat?(key)

Determines whether the button determined by key is being pressed again. Unlike trigger?(), this takes into account the repeat input of a button being held down continuously. If the button is being pressed, returns true. If not, returns false.

Mouse.toggle?(key)

Determines whether the button determined by key has been toggled. This functions like Caps Lock, Number Lock, and Scroll Lock, only for all keys.

Mouse.array_press?(keys)

Functions in the same manner as Mouse.press?(), only it takes an array of keys as input.

Mouse.array_trigger?(keys)

Functions in the same manner as Mouse.trigger?(), only it takes an array of keys as input.

Mouse.array_repeat?(keys)

Functions in the same manner as Mouse.repeat?(), only it takes an array of keys as input.

Mouse.array_release?(keys)

Functions in the same manner as Mouse.release?(), only it takes an array of keys as input.

Mouse.array_toggle?(keys)

Functions in the same manner as Mouse.toggle?(), only it takes an array of keys as input.

Mouse.release?(key)

Determines whether the button determined by key has just been released. If the button has been released, returns true. If not, returns false.

Mouse.in_screen?

This method returns true if the mouse is over the RMXP game window, and false if not. (The function returns false if the mouse is currently over the window title or edge, instead of the client area)

Mouse.pos

This method returns an array containing the current mouse position, in the following format: [mouse_x, mouse_y] (If the mouse is not over the RMXP Game Window, the coordinates returned will reflect the nearest edge. So, if the mouse is above and to the left of the window, both coordinates will be 0)

Mouse.real_pos

This method returns an array containing the current mouse position, in the following format: [x, y] The position returned by this method is the exact position of the mouse on the monitor.

Mouse.relative_pos

This method returns an array containing the current mouse position, in the following format: [x, y] The position returned by this method is similar the position returned by Mouse.pos, only it will return offscreen coordinates as well.

Mouse.tile_pos

This method returns an array containing the current mouse position, in the following format: [x, y] The position returned by this method will be the position of the map tile the mouse is currently hovering over.

Mouse.x

Returns the current mouse x position. If the mouse is to the left of the game screen, returns 0. If the mouse is to the right of the game window, returns the width of the window minus one.

Mouse.y

Returns the current mouse y position. If the mouse is above the game screen, returns 0. If the mouse is below the game window, returns the height of the window minus one.

Mouse.real_x

Returns the current x position of the mouse on the monitor.

Mouse.real_y

Returns the current y position of the mouse on the monitor.

Mouse.relative_x

Returns the current mouse x position. If the mouse is to the left of the game screen, returns negative values. If the mouse is to the right of the game window, returns values higher than the width of the game window.

Mouse.relative_y

Returns the current mouse y position. If the mouse is above the game screen, returns negative values. If the mouse is below the game window, returns values higher than the height of the game window.

Mouse.tile_x

Returns the x position of the map tile the mouse is currently hovering over. If the mouse is to the left of the game screen, returns 0. If the mouse is to the right of the game window, returns the x position of the tiles on the right edge of the screen.

Mouse.tile_y

Returns the y position of the map tile the mouse is currently hovering over. If the mouse is above the game screen, returns 0. If the mouse is below the game window, returns the y position of the tiles on the bottom edge of the screen.

Mouse.dragging?

Checks to see if the mouse is currently dragging. (The primary button is being held while the mouse moves across the screen) Returns true if the mouse is dragging, false if the mouse is not.

Mouse.drag_rect

Checks to see if the mouse is dragging, and returns the rect of the drag area. If the mouse is not currently dragging, returns an empty rect. If the mouse is dragging, returns a screen rect that covers the current drag area.

Mouse.drag_coor

Checks to see if the mouse is dragging, and returns the starting coordinates. If the mouse is not dragging, returns the current mouse position. The return data is in the following format: [mouse_x, mouse_y]

Mouse.in_area?(Rect)
Mouse.in_area?(x, y, width, height)

Determines if the mouse is within the specified area. You can input either a rect or the x, y, width, and height of the area. If the mouse is currently within that area, returns true. Otherwise, returns false.

Mouse.hide_cursor(reset_state)

Hides the mouse cursor while it is over the game screen. No arguments are needed. If reset_state is false, the mouse state will not be changed and it will remain visible. Reset_state is set to true by default.

Mouse.show_cursor(reset_state)

Shows the mouse cursor. No arguments are needed. If reset_state is false, the mouse state will not be changed and it will remain invisible. Reset_state is set to true by default.

Terms and Conditions

• This script is free to use in any noncommercial project. If you wish to use this script in a commercial (paid) project, please contact Glitchfinder at his website.
• This script may only be hosted at the following domains:
  http://www.glitchkey.com
  http://www.hbgames.org
• If you wish to host this script elsewhere, please contact Glitchfinder.
• If you wish to translate this script, please contact Glitchfinder. He will need the web address that you plan to host the script at, as well as the language this script is being translated to.
• The script header must remain intact at all times.
• Glitchfinder remains the sole owner of this code. He may modify or revoke this license at any time, for any reason.
• Any code derived from code within this script is owned by Glitchfinder, and you must have his permission to publish, host, or distribute his code.
• This license applies to all code derived from the code within this script.
• If you use this script within your project, you must include visible credit to Glitchfinder, within reason.

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

I just tested this in RMVX, and, to the best of my knowledge, it works perfectly in both VX and XP. I have changed the script header and post icon to reflect this.

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

Dude this really looks good. I wish I had a game that uses a mouse command, if I ever need it I will save it and maybe use it for a later project. It's also good that it works in both XP and VX. I'm surprised nobody has commented yet, I can't imagine why anybody wouldn't find this really neat.

Thanks for the great comment! As far as I know, this is the only mouse input module that is both cross-compatible between XP and VX, and that doesn't include a lot of other, unrelated stuff.

Anyway, I just updated this to version 1.10. It's mostly superficial, since I renamed the majority of the methods so that they would no longer include a mouse_ prefix. (This was mostly because I was trying to make it easier on those switching from AWorks, but that's pretty much a worthless feature) At the same time, I updated it so that, instead of adding a second alias to the default Input module's update method, this will now be updated automatically by my Keys module, since that module is required for this one to function properly. Anyway, enjoy. (And here I am, still hoping to see what Bluescope would have to say about this and my Key Input Module)

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

So, here I am... and unlike the keyboard module, I have lots and lots of stuff to complain about! (I so feel at home... )

First of all, you use a bunch of API calls, and while each of the variables get an appropriate name (such as @getCursorPos for the GetCursorPos call), GetSystemMetrics gets brutally chopped into @metrics... which is neither understandable to me, nor something good to do in terms of keeping a consistent style.


Next up is key assignment... now you quite cleverly check the OS' settings on the button swapping, which I haven't seen before in a mouse module, however, you seem to do something weird, being...

...while you could just as well do...

Also, the comments in there again seem to be redundant, as one should be able to figure out that PRIMARY within a mouse input script has somethign to do with the mouse's primary button ^^


Later on, you got a check for the cursor being in the screen, or not. It's located in update, which I don't quite understand, as putting that to a compact method will save you both the calculation of the cursor's coordinates each frame, as well as an instance variable, like so:



At this point, let me note that I expected you, as everyone else, to forget about the double click functionality. You included it, which I haven't seen before other than in a snippet I did some time ago, so yeah - nice ^^


Originally, I was going to complain about your @mouse_x and @mouse_y values getting falsified to ensure they're within the screen. On a later thought, that actually is useful for a bunch of occasions, including a script I'm working on at the moment... while I wanna thank you for that, I wanna add that some applications might still require something like @mouse_real_x, for example if a line's getting drawn from the center of the screen to the cursor - it'd have a different direction with your way than by having the real coordinates preserved.
Actually, writing this, I notice it shouldn't be a commonly used function... therefore, doing something like this should be sufficient:



Last but not least, something I noticed in the Keyboard script as well - you're using your nickname for alias names. I'm mentioning this purely for assuring people I'm still crazy about it, not because I actually think anyone will listen to me...


Overall, nice work definately... despite all the little things I mentioned (from which probably 50% are perfectly fine the way they are XD ), it's still a clean, non-lazy way of handling mouse input processing, and as you said, isn't weaved into some cluttery comprehensive scripts that also have keyboard input, gamepad input, a menu systen and a brush-your-teeth instruction manual ^^

Keep up the good work!

Thanks for commenting, BlueScope! I think I'll address what you said with this one, since some things really do need a bit of explanation.
Actually, this one was on purpose. Sort of. Specifically, I have this thing about lines extending onto a second line, and absolutely hate doing it. You're right, however, and I'll probably change that when I include several of your other suggestions.


The odd code is probably due more to the fact that I was writing it at around 1:00 in the morning, and it didn't occur to me to use the second type of statement. As for the redundant commenting, it's out of habit. I tend to comment everything, even when the comment provides very little in the way of illumination. I'm of the opinion that it's always better to have the comment, just in case it does help.


All right. I'm going to have to flat-out disagree with this one. While it might save me the calculation of the mouse's coordinates every frame, that's only if the script is not being used, which makes you wonder why it would be in the project in the first place. If they're using one of the majority of the methods in the script, it would be required to call this method. And if they're using more than one of the methods, or calling the same one multiple times, it would be recalculating these values every single time the method was called, every single frame. In other words, this would actually reduce efficiency, assuming that the script was actually being used.


I couldn't really call this a mouse module without double clicking, could I? I would also like to note that AWorks includes a double clicking feature as well.


Actually, this is an excellent idea, and one I'm surprised I didn't come up with on my own. Even if it wouldn't be used often, I will probably end up including both a method to read the position, and methods for the x/y of the mouse, just likee I did for the current methods.


This one has a very, very simple explanation. I learned my script formatting style by studying the guide in the SDK, which has very specific rules regarding the formatting of an alias, to prevent the same alias being used more than once.


Again, thanks for the great comment, since You did point out things I hadn't seen before. I would like to note that this script does require my keyboard script, since it uses that to keep track of the mouse keys, instead of simply checking them itself. (One thing to note is that, if you really wanted to be a weird scripter, you could route keyboard input checks through this script, since it isn't programmed to reject them)

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

Consider everything not addressed in this post as totally agreed with :p

Af for the in_screen? matter... right now, that method is called every frame, no matter if needed or not (which is also during the title screen, transitions, all that stuff where 90% won't ever use any input at all), while the downside obviously is that people using this multiple times will get more calculations. I guess it depends on how you use it (which ultimately comes down to if you use it in a single or multiple scenes), but yeah... I guess both methods have their advantages and flaws...

And yeah, interesting that the weird way of putting nicknames in aliases comes from the SDK... I was aware of Seph being one of the first to use it, however I didn't know he was spreading it like a virus :x

I'm glad I could help! :) I hope it'll do something for the script you PMed me, which I'm at right now ^^

All right guys, I have a new version! A lot of stuff was added in this version, so please enjoy!

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

I'll try it later, I hope its more accurate and responsive than the last mouse script I used

If that last mouse script was AInput, the answer would be a definite yes. I was using that script as the major comparison for testing and such when I made this one, and would never have released mine if it performed worse than AInput did.

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

when i get off work ill test it, about ten of my scripts use your old version :D

Well I forgot about testing this today, I'll do it tomorrow.

And I forogt which mouse script it was.

You've got in_rect, how about in_radius? Something to check if within a circle?

Or more specifically, be able to activate certain events if within their individually defined radius, including the mouse changing image when in that radius.

This actually being alive might make me tempted to work on my point-and-click game again.

Still, it's really cool to see an in_rect function there.

I'm no scripter, so I must ask, how do I implement this script?

Not install, if that is what you think. Its how do I put it to use.

My guess is that I put Mouse.press?(key) in the scripts that I want to call right?

Can you give me an example on how to implement this on the start screen so I can get a flow of it?

in_radius would be a bit tougher to implement, simply because dealing with circles would be tougher to deal with. That said, I'll look into it, I suppose.



Sure! Instead of giving you an edit to the title screen, I'll give you an edit to Window_Command, since that is both easier to do and more effective for what you wanted. I commented it to make it a bit easier to understand.



Just keep in mind that this mouse script does require my keyboard script as well, so it will crash your game if you don't have that in there too.

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

@Glitch
Thanks mate, and yeah I downloaded the keyboard input too...

sadly I don't think I'll use RMXP for a project anyway, I'll give this script a try though

I tried replacing my own mouse input with yours in my mouse implementation and it seems to work just fine :3
http://webgel.net/bb/files/GlitchMouseImpl.zip

*hugs*

No THAT is cool! I know it might be easier to make point and click events, as well, because of the new tile_x and tile_y methods. (As well as the tile_pos method)

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

Thankies ^_^
It was pretty easy converting to your script. Of course there may be some subtle differences which needs to be fixed, but overall it was nice and easy to use.
The idea behind the mouse system was to enable the mouse to control all the menus while leaving the map alone. It is also an experiment where I use an eventing concept for the mouse control which I have been very pleased with. It is way easier to manage than using a top-down approach.
You can indeed make point and click events, but that was not a part of what I intended with the system. There is nothing wrong with building on top of my system.

I do hope my implementation also helps people getting an idea of how much scripting is still required after adding your script to have the mouse feel fully functioning.
Lemme add a little disclaimer just incase: The parts I have scripted are free to use in commercial and noncommercial alike, but use are your own risk only.

*hugs*

ok, i tested it with all my scripts, it works like a charm, i like the new features(though i had added many of them myself to your old one) there is one downside IMO. i have my own little cursor i use in game. i use this to hide the real one

i had no problems with your old script doing this, but for what ever reason when i replaced it with your new version it isnt hiding the mouse any more. i didnt play with it much. just replaced your old script with your new one

My new script actually has a method to hide the mouse. It's made so that the mouse is only hidden while it is in the game screen, and it's also been set so that if the mouse is detected to be in the wrong state, it gets put to the right one. Check out the last two methods in the method list, hide_cusor and show_cursor.

╒╕▄╒■╕▀╘═█╕ Azthec ╒█═╛▀╒■╕▄╒╕

:D thanks glitch told ya i didnt play too much with it :D

What cure would you prescribe for the "Stack level too deep" error when resetting the game with the F12 key?

I would suggest using this snippet of mine: http://pastebin.com/KdBFd0Cn
Create a new section at the very top and put it there. It must be the very first code or there is a danger of still getting that error.

*hugs*

Nice Script! Ey men I will pay or Thanks forever if one could kindly put this script working with Zenith Tactical Battle System. I expect one of the experts could do me a favor.

I have uploaded a ztbs version, www.megaupload.com/?d=FRKVJJ81

thanks in advanced! see you ;)

That indeed solves the problem. But the newly created thread is not active by default. Is it possible to make it so? It's a small thing, but it matters to me. (my game normally takes a noticeable amount of time to load as it is)

Hmm, the part of the script that seems to be leading to the stack error is the key update for the input module.

I've been able to implement full mouse support for my game thanks to this excellent script. The only problem remains that it crashes on F12 unless I use Zeriab's code, in which case F12 launches a new (inactive) thread. But it sounds as if nobody knows of a better solution.

What do you mean by that it is not active? Does the game just exit when you press F12?

On a different note you can change the behavior of F12 so it pauses the game instead with this script: viewtopic.php?f=11&t=64701

*hugs*

i think flowerthief is having the same issue i always had with this script, when you are testing something over and over you often want to restart the exe, pressing f12 normally does that, with this script it crashes your game.

To the player it appears as if the game simply exited. In actuality, a new thread is launched, just as your code snippet is supposed to do, but the player doesn't automatically realize it. They see the old window go away.

I don't want F12 to pause. I want it to reset the game the way it did before I installed this script.