Mouse Input Module 3.00 [XP/VX/VXA]

[Glitchfinder]

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
[rgss]cursor = Win32API.new("user32", "ShowCursor", "i", "i" ).call(0)
[/rgss]
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.

 

[Kingdom Ablaze]

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

 

[flowerthief]

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

 

[Zeriab]

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*

 

[superfanqui]

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

 

[flowerthief]

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*

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.

 

[flowerthief]

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.

 

[Zeriab]

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*

 

[Kingdom Ablaze]

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.

 

[flowerthief]

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.

 

[Zeriab]

Have you renamed you Game.exe file?
If you have changed to say MyGame.exe then you have to change this piece:

command = 'Game'

# Change to

command = 'MyGame'

@Vergessen:
There is an issue with RGSS Player where pressing F12 does not properly restart the game.
It just starts over from the first section. Not all pieces of code works when you run them twice.

 

[flowerthief]

I haven't renamed Game.exe.

 

[Glitchfinder]

Guys, what version of RM* are you using? I just tested this with both XP and VX, and neither of them crashed on F12. Would you be able to tell me what version you're using, along with what scripts you've got in the game? Potentially, the stack level too deep error could be a result of some other script aliasing the update method of the Input module (which would mean it's actually my key input module that is causing the issue, and not this script. That said, if you're using ACE, I have yet to try any of my scripts in that, so I have no idea as to how functional they are in that. (One thing to note is that the typical reason for a crash is the use of the Ruby alias method. If you go to your script console, and hit ctrl+shift+f, then search for "alias" (without the quotes), you might find that other scripts are doing the same thing. If a script simply aliases a method, without checking to see if the aliased name already exists, and it calls the aliased version in the replacement, then you ALWAYS get a stack level too deep error when that method is called after hitting F12, because then the replacement method is aliased and replaced with itself, so it forms an infinite loop of calling itself, which gets cut short and throws the stack level error.)

 

[flowerthief]

Thanks for replyling. I'm on RMXP version 1.02a. The only other scripts in my project that alias anything are Ccoa's UMS and NR_Kready's Audio encryption, but neither of these alias anything in the Input module. I tried commenting every line of code beginning with the word "alias" in every script not written by you, but I still get a crash on F12. I've also tried creating a brand new project adding nothing to it other than the Input and Mouse scripts, and I still get the crash.

 

[Glitchfinder]

Thanks for replyling. I'm on RMXP version 1.02a. The only other scripts in my project that alias anything are Ccoa's UMS and NR_Kready's Audio encryption, but neither of these alias anything in the Input module. I tried commenting every line of code beginning with the word "alias" in every script not written by you, but I still get a crash on F12. I've also tried creating a brand new project adding nothing to it other than the Input and Mouse scripts, and I still get the crash.

Would you mind uploading a copy of that blank project so that I can try it out myself? I'm rather curious about why the blank project I tried worked just fine, while the one you tried did not. I'm also curious as to whether you did anything before hitting F12, and whether or not you're using the version of this script that I have in the first post of this thread.

 

[flowerthief]

edit:
Aha, I was not using the latest version of your Input module! (FYI your website doesn't have the latest version) After updating, the problem is gone Thanks for the help! This is a wonderful script.

 

[Jeea]

Hello. Of all the mouse scripts I found yours to be convenient. I'm honestly a n00b and yeah, I read the advice, but how do I let the cursor show on full screen? It just disappears. Thank you!

 

[Xilef]

Hey Glitchfinder, since becoming a programmer I can read RGSS scripts properly and understand them, yours is a brilliant example of Win32 DLL calls, thanks for writing this!

Have you experienced and performance drops when polling for mouse input? Zeriab tells me that all Win32 API calls lock the RGSS player's threads until they are complete, it would be interesting if your mouse input suffers from this too.

 

[Glitchfinder]

Hello. Of all the mouse scripts I found yours to be convenient. I'm honestly a n00b and yeah, I read the advice, but how do I let the cursor show on full screen? It just disappears. Thank you!

It's been a while since I looked at this, but I'm fairly certain that you could do an event script call for Mouse.show_cursor() to manage that.

Hey Glitchfinder, since becoming a programmer I can read RGSS scripts properly and understand them, yours is a brilliant example of Win32 DLL calls, thanks for writing this!

Have you experienced and performance drops when polling for mouse input? Zeriab tells me that all Win32 API calls lock the RGSS player's threads until they are complete, it would be interesting if your mouse input suffers from this too.

Actually, one of the main reasons I made this script was because the input setup I considered to be the best at the time, AWorks, was slow and had several logical errors in the setup. (If you'll note, the actual function names are rather blatant rip-offs of it, as well) The last time I checked, this actually didn't have any issues in terms of a performance hit, but that's mostly because it uses user32.dll, which Microsoft has optimized beyond belief due to its use in the OS itself. I would imagine that it does lock the thread though, it's just a matter of the access time being entirely minimal. (The dll is, from what I can recall, constantly loaded into active memory anyway) That said, on computers that have inherent I/O issues, I would imagine this would have a performance impact, but that's to be expected in such a situation.

Actually, your posting here reminded me of something. I've been planning to nuke the limits in the T&C section of all my scripts for a while now. I really don't care if people use the scripts for whatever they want, so long as they don't claim they made it. But, finding all of them and modding them right now is a bit of a pain, considering it's after midnight. Tomorrow, maybe.

 

[Jeea]

It's been a while since I looked at this, but I'm fairly certain that you could do an event script call for Mouse.show_cursor() to manage that.

Ok. so I tried putting it and inside the parentheses, I placed "reset_state = true" ( or just "true") and what happens is that the event/common event freezes, may it be set on parallel, autorun, etc. I've tried disabling the event by self switch, exit process, or erase event, and still the same happens. Next i tried putting it on the script, specifically on Main, below or on top of the auto fullscreen piece. It runs normally, except for the problem being unsolved. Any ideas?