PDA

View Full Version : Idea that would be cool


dakota95
12-18-2011, 06:59 PM
what if there was a pre-programmed mouse control thing for fps stuff. Like something that you would just drag in instead of have to make. Something that would control the camera. Instead of just mouse orient camera, it would be neat if there was something that was mouse orient, and tilt camera ans do so without having to click on the screen.

Mr Kidnapper
12-18-2011, 07:32 PM
In all technicality, I could create a dummy object with the mouse movement method and all you would have to do is import it and it would work, however even so it isn't great. A native mouselock with camera rotation would be much smoother than what I have now. As it is, the camera often rolls when it shouldn't and at high mouse sensitivities it is very choppy. Default is 4, smooth is 2.
Hm. Arty doesn't seem to want that so nah.

dakota95
12-18-2011, 07:52 PM
In all technicality, I could create a dummy object with the mouse movement method and all you would have to do is import it and it would work, however even so it isn't great. A native mouselock with camera rotation would be much smoother than what I have now. As it is, the camera often rolls when it shouldn't and at high mouse sensitivities it is very choppy. Default is 4, smooth is 2.
Hm. Arty doesn't seem to want that so nah.

could you post how to make a "native mouselock"?

Mr Kidnapper
12-18-2011, 07:56 PM
Native mouselock is something Alice developers have to do.
It won't require a calibration object and will be able to find the center of the window relative to the entire screen actively, meaning the current mouselock's weakness (Of being screwed if the user moves the Alice window) won't be a problem.

dakota95
12-18-2011, 08:12 PM
Native mouselock is something Alice developers have to do.
It won't require a calibration object and will be able to find the center of the window relative to the entire screen actively, meaning the current mouselock's weakness (Of being screwed if the user moves the Alice window) won't be a problem.

meaning........

sorry if you explained it I just don't understand it.

arty-fishL
12-18-2011, 08:20 PM
Native mouselock, if I understand what you are talking about, is possible.
This issue of the user moving the Alice window can be solved even without scripting.

The get mouse distance functions under world have a relative to something or other parameter (don't know what it says, but when it is true it is mouse distance from left/top of window, when false it is the entire screen). Just do get mouse distance [relative = false] subtract get mouse distance [relative = true], there you have the window offsets.

dakota95
12-18-2011, 08:37 PM
Native mouselock, if I understand what you are talking about, is possible.
This issue of the user moving the Alice window can be solved even without scripting.

The get mouse distance functions under world have a relative to something or other parameter (don't know what it says, but when it is true it is mouse distance from left/top of window, when false it is the entire screen). Just do get mouse distance [relative = false] subtract get mouse distance [relative = true], there you have the window offsets.

sorry, I'm a noob when it comes to things like this, and what you said makes no sense. Do I make an if else statement? Say if mouse left<right then move right, else move left?

Mr Kidnapper
12-18-2011, 10:07 PM
When programmers talk about a feature being of "native" support, it means that it is a feature that is included in the program, no modifications necessary. So for example, you would be able to check a box and the feature would work, no strings attached.

Ah, the problem I meant with the user moving the window is that calibration is (generally) only done once. After that, I have to use the script to set the mouse every .08 seconds to certain coordinates. The coordinates used are relative to the screen and not the Alice window.
Unfortunately even so, this is still based on a calibration object and won't work.
However, if you ever manage to figure out to get the location of the window on the screen then we could solve the entire problem of mouselock and abandon calibration points altogether.
I have been trying for the past hour to figure out what calls I need to make to find the window location. It probably has something to do with PlayerApplet.java in edu.cmu.cs.stage3.alice.player

Edit: Found it. I figured it out when I looked in the .java files for Mouse Distance from Top Edge.
world.renderTarget.getAWTComponent().getLocationOn Screen()
It might be off by a few. I don't know if renderTarget refers to the window itself or just the render box. It's probably the render box.

Edit2: Calibration Point-less mouselocking works. My FPS is now resistant to both window resizing and window movement.

Edit3: Hoshit! I removed the stopRadius (I call it BoundRadius) variable because there would be no more magnanimity from mouselocking. Suddenly mouse movement became very smooth. The difference is noticeable even after many times the default mouse sensitivity.
Bah. Still a little magnanimous. Bound Radius of 1.

Edit4: Mouse-based camera movement is complete. I suppose. I don't think I could make it any less laggy. I fixed the "roll" problem by creating a dummy on the camera that moves to the camera's position, which is what the camera's horizontal rotation is based on, and I made rotating past 60-70 in either vertical direction impossible. Now it's pretty much the exact same thing as any other FPS.

arty-fishL
12-19-2011, 02:05 PM
A great discovery. This I already knew though, but never thought of using it the way you are.

As you discovered to get the exact render pane do world.renderTarget.getAWTComponent() .

To get the best usable container of the render pane do world.renderTarget.getAWTComponent().getParent().g etParent().getParent() , the only way I have used this so far is to change the cursor on only that part of the play window (I used it in my last release of mouse maze mania and some other things I think).

To get the usable entire play window do world.renderTarget.getAWTComponent().getParent().g etParent().getParent().getParent().getParent().get Parent().getParent().getParent().getParent()

I'm sure there's a neater way to do it, but this works fine for now.

I look forward to the result of your discoveries. Could I maybe use anything extra you discover, since you used stuff from what I discovered?

Mr Kidnapper
12-19-2011, 06:03 PM
Don't mind.