I have been playing around with pyautogui before switching to pydirectinput in order to automate things in Minecraft. I'm making a mining bot and I'm running into some issues involving automated mouse movement in the game. I'm using the moveRel() function, although I have used move() and moveTo(), they produced the same result as moveRel(), to move the player's head up and down. However, even when I put the Offsets to a really low amount like 1, the player's head rotates in a full range of motion. To help you visualize this, in Minecraft, picture your character staring off into the horizon. Now imagine what would happen if you suddenly jerked the mouse back. The player would face down right? Well, every time I try moving the mouse a little bit using pydirectinput, the player always ends up facing down. What is causing the player to look down as if its camera were anchored when I use the mouse moving function in pydirectinput?
I Solved My Problem. It turns out that I need to turn on Raw Input so that the mouse wouldn't accelerate so much. Raw Input uses the raw mouse movement from your computer meaning that it does not accelerate or deaccelerate the mouse input to match the game sensitivity. I think that's how it works. By the way, raw input is in the mouse control settings in Minecraft. Anyway, because of the acceleration of my mouse input, the simulated mouse movement from my pydirectinput script was too sensitive for the game, so that's why the player always looked downwards no matter what numbers I put into the moveRel() function.
Related
I am trying to make a basic rhythm game in Godot, but with unique controls. A few years ago, I played a cool game called Fast Like a Fox. The controls were unique, because you tapped on the back of your device to move your character to move, not on the screen. I thought the controls were cool, and I want to try to replicate them in a simple one-button rhythm game for mobile. Does anyone know if it would be possible for Godot to take that kind of input, either in a built-in function or something else?
They read the accelerometer (and maybe other sensors), which Godot supports through accelerometer, gravity and gyroscope. Accelerometers are accurate enough to read passwords as they're being typed so you can even get a rough estimate on where the user is tapping, which is used in Fast Like a Fox use case where internally they poll the sensor and raise an event when particular changes happen in one or multiple axes. In your case, it might be enough to just treat any sudden changes as an event if you simply care about the user tapping anything.
Try writing an app that will display the delta of each axis measurement then tap your phone around, you'll figure it out. Remember to test on various conditions (device being held upside down while laying on a bed, sitting on a chair, laying on one's side, etc) since different axes will register the changes.
I have a mouse mouse from speedlink that is able to do a lot of things, like changing the colours of the leds, but I can only do those things with the provided software from speedlink.
Is it possible to code your own software that controls the led lights of the mouse?
Yes, but you would have to have the hardware specifications to know what needs to be sent to the mouse to accept the commands you're looking for. Usually these things are not published or readily accessible.
I bought two Microsoft Basic Optical mice, identical to the one which performed the functions I needed really well. The first one would grab and flip the grid with object in one position within the grid with a right click of the Mouse. The Blender 2.79 3D modelling app is what I am using the mice for, I plugged the two new mice into two computers, to try them out, they would NOT do the grid grabbing and flipping, though they would perform the other functions. the grid grabbing function is important so that You can move the scene and inspect the model, or appear to walk around a solid object in the real world.
There is a problem that multiple users of my model have noticed, namely that when you right click the model (here), the movements are hypersensitive. Orbit and zoom are fine and steady, but pan now more often than not results on the model rapidly shooting off into the distance. I've been playing with the camera controls to no avail and I don't want to simply remove the pan option for the client.
Also, is there any way to transition between cameras without a fade, just a movement of the camera?
Also, Verold not working on Internet Explorer 11... any news?
Thanks
Solved: problem was the focal point (white lined sphere). Had been set off accidentally far off into the distance (can be easily done without noticing and there is no undo). Just brought it back to the object.
I am using Kinect SDK 1.8, i am using default Kinect control. KinectRegion to display hand cursor of Microsoft.Kinect.Toolkit.Controls. But hand cursor is too fast and sensitive. i wanted it to be make it slow down, so that end user of my Kinect app can control that cursor easily on screen. i tried out with the AccelerometerGetCurrentReading() (Line No. 962) and also tried out with the KinectAdaptor.cs (Line No. 299) handPointer.X, Y, Z, but didn't get any success. can some one help on it.
I already gone through the Human interface guide and also tried Kinect interaction demo, but it is work with the same speed of hand cursor, as is it working in my app.
Is there any work around for this?
Or any property to control the speed of hand cursor in PHIZ, come in future release.
I am not aware of any built-in solution for this. However, there are a couple tricks you could do if you're willing to produce some code in the middle.
You say there are two problems
The Kinect Cursor is too fast (i.e. for the amount your hand moves in the real world, the cursor moves too much on the screen.
The Kinect Cursor is too sensitive. (i.e. the movements of the Kinect are hard to control)
For #1, I am not sure if the cursor->screen mapping is absolute. If you put your hand at the edges of the Kinect's vision, does it match the edge of your computer screen? If so, it could be hard to adjust the speed of the cursor (also called gain). One hack-y solution can just be to move your body farther away from the screen, so that your movements in physical space are larger.
For #2, you could implement a basic low-pass filter. This means that large motions "pass through" the filter, but small, jittery motions are ignored. The simplest way to do this is have something like a running average.
Point CurrentKinectPoint; //this is the filtered position of the mouse cursor
const double FILTER_FACTOR = 0.5;
void UpdateKinectControlPoint(Point NewPoint) {
CurrentKinectPoint.x = CurrentKinectPoint.x * FILTER_FACTOR + NewPoint.x * (1 - FILTER_FACTOR);
CurrentKinectPoint.y = CurrentKinectPoint.y * FILTER_FACTOR + NewPoint.y * (1 - FILTER_FACTOR);
}
I hope this is helpful, at the high-level at least.
For the past few months I've been looking into developing a Kinect based multitouch interface for a variety of software music synthesizers.
The overall strategy I've come up with is to create objects, either programatically or (if possible) algorithmically to represent various controls of the soft synth. These should have;
X position
Y position
Height
Width
MIDI output channel
MIDI data scaler (convert x-y coords to midi values)
2 strategies I've considered for agorithmic creation are XML description and somehow pulling stuff right off the screen (ie given a running program, find xycoords of all controls). I have no idea how to go about that second one, which is why I express it in such specific technical language ;). I could do some intermediate solution, like using mouse clicks on the corners of controls to generate an xml file. Another thing I could do, that I've seen frequently in flash apps, is to put the screen size into a variable and use math to build all interface objects in terms of screen size. Note that it isn't strictly necessary to make the objects the same size as onscreen controls, or to represent all onscreen objects (some are just indicators, not interactive controls)
Other considerations;
Given (for now) two sets of X/Y coords as input (left and right hands), what is my best option for using them? My first instinct is/was to create some kind of focus test, where if the x/y coords fall within the interface object's bounds that object becomes active, and then becomes inactive if they fall outside some other smaller bounds for some period of time. The cheap solution I found was to use the left hand as the pointer/selector and the right as a controller, but it seems like I can do more. I have a few gesture solutions (hidden markov chains) I could screw around with. Not that they'd be easy to get to work, exactly, but it's something I could see myself doing given sufficient incentive.
So, to summarize, the problem is
represent the interface (necessary because the default interface always expects mouse input)
select a control
manipulate it using two sets of x/y coords (rotary/continuous controller) or, in the case of switches, preferrably use a gesture to switch it without giving/taking focus.
Any comments, especially from people who have worked/are working in multitouch io/NUI, are greatly appreciated. Links to existing projects and/or some good reading material (books, sites, etc) would be a big help.
Woah lots of stuff here. I worked on lots of NUI stuff during my at Microsoft so let's see what we can do...
But first, I need to get this pet peeve out of the way: You say "Kinect based multitouch". That's just wrong. Kinect inherently has nothing to do with touch (which is why you have the "select a control" challenge). The types of UI consideration needed for touch, body tracking, and mouse are totally different. For example, in touch UI you have to be very careful about resizing things based on screen size/resolution/DPI... regardless of the screen, fingers are always the same physical size and people have the same degreee of physical accuracy so you want your buttons and similar controls to always be roughly the same physical size. Research has found 3/4 of an inch to be the sweet spot for touchscreen buttons. This isn't so much of a concern with Kinect though since you aren't directly touching anything - accuracy is dictated not by finger size but by sensor accuracy and users ability to precisely control finicky & lagging virtual cursors.
If you spend time playing with Kinect games, it quickly becomes clear that there are 4 interaction paradigms.
1) Pose-based commands. User strikes and holds a pose to invoke some application-wide or command (usually brining up a menu)
2) Hover buttons. User moves a virtual cursor over a button and holds still for a certain period of time to select the button
3) Swipe-based navigation and selection. User waves their hands in one direction to scroll and list and another direction to select from the list
4) Voice commands. User just speaks a command.
There are other mouse-like ideas that have been tried by hobbyists (havent seen these in an actual game) but frankly they suck: 1) using one hand for cursor and another hand to "click" where the cursor is or 2) using z-coordinate of the hand to determine whether to "click"
It's not clear to me whether you are asking about how to make some existing mouse widgets work with Kinect. If so, there are some projects on the web that will show you how to control the mouse with Kinect input but that's lame. It may sound super cool but you're really not at all taking advantage of what the device does best.
If I was building a music synthesizer, I would focus on approach #3 - swiping. Something like Dance Central. On the left side of the screen show a list of your MIDI controllers with some small visual indication of their status. Let the user swipe their left hand to scroll through and select a controller from this list. On the right side of the screen show how you are tracking the users right hand within some plane in front of their body. Now you're letting them use both hands at the same time, giving immediate visual feedback of how each hand is being interpretted, and not requiring them to be super precise.
ps... I'd also like to give a shout out to Josh Blake's upcomming NUI book. It's good stuff. If you really want to master this area, go order a copy :) http://www.manning.com/blake/