This is my first question to stackoverflow. Helped me a lot in the past whenever i was stuck. Anyway here is the problem:
I was using Java Robot in my PC. Everything was fine like i could type in notepad move mouse around in other applications like games etc. But there was only this one game which the java Robot did not work on. Nothing was detected on this game not even mouse movement. I tried to do some research on this and came to a conclusion that maybe that game has some sort of anti-bot system. Keep in mind this was in my PC which is windows 7 64bit. Then i thought to use the same code in my laptop(which is also windows 7 64bit) on the same game and it WORKED!
So my question is why did this happen? Why did it work in my laptop and not my PC?
here is the code:
package test_bot1;
import java.awt.Robot;
import java.awt.event.KeyEvent;
public class test_BOT1 {
public static void main(String[] args) {
try{
Robot bot = new Robot();
bot.delay(3000);
bot.mouseMove(500, 0);
for(int i = 0; i < 10; i++){
bot.keyPress(KeyEvent.VK_A);
}
bot.delay(100);
bot.keyRelease(KeyEvent.VK_A);
bot.delay(100);
bot.keyPress(KeyEvent.VK_TAB);
bot.delay(200);
bot.keyRelease(KeyEvent.VK_TAB);
bot.delay(159);
bot.keyPress(KeyEvent.VK_1);
bot.delay(179);
bot.keyRelease(KeyEvent.VK_1);
}catch(Exception e){
}
}
}
K Out!
Surely the simple answer to this is not to cheat at games?
Try adding e.printStackTrace() to your catch block and look to see if there are errors on the pc version and not on the laptop.
Related
I've been reading up on this and haven't found an answer that has made sense to me.
I'm trying to write a program in Java to interact with an application to see if I can write a program to play a video game for me. The game is on my computer.
Here is an excerpt of code:
public static void main(String[] args) throws java.io.IOException {
Runtime run = Runtime.getRuntime();
run.exec("open /Applications/OpenEmu.app");
try {
Robot robot = new Robot();
System.out.println("Waiting 5 Seconds");
//robot.delay(5000);
System.out.println("Pressed X");
robot.keyPress(KeyEvent.VK_X);
robot.keyPress(KeyEvent.VK_X);
robot.keyPress(KeyEvent.VK_X);
robot.keyPress(KeyEvent.VK_X);
//Starts an easy mode game
It opens the application fine, and in something like notepad, it will type XXXX, but it won't do so for the game?
I've assigned the 'x' key on my keyboard as a command button for the game. My guess is that the 'x' press is internal. All help is appreciated!
If you are trying to simulate input, try add robot.keyRelease as well. Javadoc for robot says for keyPress "Presses a given key. The key should be released using the keyRelease method."
System.out.println("Pressed X");
robot.keyPress(KeyEvent.VK_X);
robot.keyRelease(KeyEvent.VK_X);
...
Also remember this:
https://docs.oracle.com/javase/7/docs/api/java/awt/Robot.html "Note that some platforms require special privileges or extensions to access low-level input control. "
So, while programming in Java and LWJGL I was working on a simple game for fun.
And everything worked, I could run the game, and play. But then I leave my computer alone for about 30 minutes and come back to run the game again, and I get the Pixel format not accelerated error. I don't know where it came from, but I assure you it worked earlier. I thought maybe restarting the engine and game to see if I could fix it again.
Here is my code after restarting:
`
package engine.dungeon.core;
import org.lwjgl.LWJGLException;
import org.lwjgl.opengl.Display;
import org.lwjgl.opengl.DisplayMode;
public class Window {
public static final int WIDTH = 640, HEIGHT = 480;
public Window() {
try {
Display.setDisplayMode(new DisplayMode(640, 480));
Display.create();
} catch (LWJGLException e) {
e.printStackTrace();
}
}
}
`
A Pixel format not accelerated error has to do with your graphics card.
Some video cards are too old, and should either be updated with drivers, or replaced.
Some times GPU drivers could crash so a computer restart may solve your problem
I figured it out! There was an update for my graphics card that I got after restarting my computer for a second time.
This is a known issue with the Nvidia driver 378.49. This driver is simply broken.
See for more detail:
http://forum.lwjgl.org/index.php?topic=6447.0
http://forum.lwjgl.org/index.php?topic=6439.msg34284#msg34284
or simply google "LWJGL Pixel format not accelerated" and you'll find hundreds of posts mostly from Minecraft users.
I have a reproducible problem with the Mint Cinnamon desktop locking up when hitting a breakpoint debugging with Eclipse. When I say it's locking up, I mean mouse clicks are completely inoperable (even on the Mint panel), but the mouse cursor still moves. Keyboard is unresponsive, except for some OS-level shortcuts like Alt-Tab. Alt-Tab looks like it's working, but selecting another window doesn't actually focus or activate the window (only the Alt-Tab selector popup works). I can only recover using Ctrl-Alt-ESC to restart Cinnamon. Everything proceeds fine after that.
Debugging and breakpoints work fine everywhere else as far as I can tell except when the breakpoint is inside an anon inner class or lambda.
Public git repo with a fairly simple example project causing this:
https://bitbucket.org/jfxexamples/eclipseminttest
Linux Mint 17.3 AND a totally new install of Mint 18 on a different PC - both behave the same
Eclipse Neon 4.6.0
Java 8 (1.8.0_92) - Oracle JDK (Using JavaFX)
Code below (you'll have to grab the project files to run it though):
package application;
import javafx.application.Application;
import javafx.fxml.FXMLLoader;
import javafx.scene.Scene;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;
public class Main extends Application {
#Override
public void start(Stage primaryStage) {
try {
BorderPane root = (BorderPane)FXMLLoader.load(getClass().getResource("Sample.fxml"));
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource("application.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
launch(args);
}
}
package application;
import javafx.event.Event;
import javafx.event.EventHandler;
import javafx.fxml.FXML;
import javafx.scene.control.Tab;
import javafx.scene.control.TabPane;
public class SampleController {
#FXML
private TabPane tabPane;
public void createTab() {
Tab tab = new Tab("New tab");//Breakpoint here does NOT freeze desktop
// tab.setOnCloseRequest(e -> {
// System.out.println("bleh");//Breakpoint here, freezes desktop
// });
tab.setOnCloseRequest(new EventHandler<Event>(){
#Override public void handle(Event e){
System.out.println("bleh");//Breakpoint here, also freezes desktop
}
});
tabPane.getTabs().add(tab);//Breakpoint here does NOT freeze desktop
int index = tabPane.getTabs().size() - 1;
tabPane.getSelectionModel().select(index);
}
}
Using Win10/IntellijCE/JDK1.8.0_92 there is no problem. Try using IntellijCE on Mint. If it works the problem is most likely with Cinnamon.
Cinnamon is on Github, so use their Issue Tracker there to report the bug.
Browsing the issues, there is even something maybe related to your issue: Check out https://github.com/linuxmint/Cinnamon/issues/1084.
I have had exactly the same problem in Linux Mint 17.3 Mate, with JDK 1.8.0_101, Eclipse Neon and a JavaFX application.
When debugging the application, the system freezes completely and I have to kill the process manually.
It seems a problem related with the X display. It should work if you set, in the VM arguments of your application, the flag:
-Dsun.awt.disablegrab=true
At least that worked for me...
This is a known problem on Linux. It is related to the XGrabPointer and XGrabKeyboard API calls (see X Pointer Grabbing). This API can be used by screensavers, so it is intended to make the keyboard and mouse unusable (apart from moving the mouse cursor).
During debugging, it is a problem. In the past, a workaround was to configure AllowDeactivateGrabsin xorg. That allowed to break the "grap" by a keyboard shortcut, by default CTRL+ALT+/. Since it was possible to bypass screensavers, it was disabled around 2012 because of its security implications.
On a modern Linux system, you can enable enable grab break actions:
setxkbmap -option grab:break_actions
Now, you can trigger a grab break by executing:
xdotool key XF86Ungrab
Once your keyboard is frozen, you might be not able to run it, so during debugging, I am calling it every two seconds:
while :; do sleep 2 ; xdotool key XF86Ungrab ; done
Notes:
setxkbmap is part of xorg-setxkbmap
xdotool is part of xdotool
While testing the setup, it is useful to have a ssh connection from another machine. Thus, if mouse and keyboard freeze up, you can always kill the process that grabbed the mouse and keyboard.
I am writing a Java application for image analysis which at one point opens ImageJ with
ImageJ ij = new ImageJ();
and also opens a Windows containing an ImagePlus.
Now, whenever one closes ImageJ first, the ImagePlus will not close when pushing the close button. The other way around works, however in both cases an exception is thrown after closing ImageJ:
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1288)
at java.awt.Window.doDispose(Window.java:1209)
at java.awt.Window.dispose(Window.java:1147)
at ij.ImageJ.run(ImageJ.java:784)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:56)
at java.awt.AWTEvent.<init>(AWTEvent.java:337)
at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:285)
at java.awt.event.InvocationEvent.<init>(InvocationEvent.java:174)
at sun.awt.X11.XBaseMenuWindow.dispose(XBaseMenuWindow.java:907)
...
I don't know whether it is related as it happens in both cases.
Any suggestions on how to force ImageJ to close all its windows?
The exception
This happens when using OpenJDK 7 on Linux. The exception is fixed in Java 8.
Also: note that that exception is not the actual cause of the quitting issue you are seeing.
The disposal problem
ImageJ 1.x's application disposal is a convoluted mess. (See this news post for some technical discussion.) It was really intended primarily to run as a standalone application, and is mostly tested with the exitWhenQuitting flag set to true such that the JVM shuts down upon closure of the main window. So it is not surprising that using ImageJ in a different fashion results in hanging image windows.
I have tested various workarounds—e.g.:
ij.addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(final WindowEvent e) {
// dispose all image windows
for (final int id : WindowManager.getIDList()) {
final ImagePlus imp = WindowManager.getImage(id);
if (imp == null) continue;
final ImageWindow win = imp.getWindow();
if (win != null) win.dispose();
}
// dispose all other ImageJ windows
for (final Window w : WindowManager.getAllNonImageWindows()) {
w.dispose();
}
}
});
But none of them work as one might hope. It cost me weeks of development and experimentation to make quitting work as we wanted in ImageJ2, according to the news posted linked above.
Here is some code using ImageJ2 that almost behaves the way you want:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.WindowConstants;
import net.imagej.ImageJ;
public class IJDispose {
public static void main(final String... args) {
final ImageJ ij = new ImageJ();
ij.ui().showUI();
final JFrame frame = new JFrame("Hello");
final JButton b = new JButton("Close ImageJ");
b.addActionListener(new ActionListener() {
#Override
public void actionPerformed(final ActionEvent e) {
ij.getContext().dispose();
}
});
frame.getContentPane().add(b);
frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}
After launching it, press Shift+B to open the Blobs sample image. Then click the "Close ImageJ" button from the non-ImageJ frame. You'll see that the ImageJ main window and the image window dispose as desired (using this code from ImageJ Legacy).
However, there are (at least) three problems:
This example does not hook up the ij.getContext().dispose() call to the actual ImageJ1 UI window closing event. And doing that would not be trivial (I say without having dug deeply in this code recently).
After disposing ImageJ, as well as the extra JFrame, the JVM is supposed to shut down. We put a lot of effort into making it do so, actually. But it actually doesn't with the current version of ImageJ, presumably due to some undisposed resource(s) somewhere. This is a bug.
Clicking the X on the main ImageJ window shuts down the entire JVM, because ImageJ1's exitWhenQuitting flag gets set to true. You could toggle it back to false yourself, but this is actually tricky due to class loading issues relating to the fact that ImageJ2 patches ImageJ1 at runtime using Javassist.
The next question is: How badly do you really need this to work?
So I decided i wanted to learn about image processing and vision tracking and such so installed opencv and got it working in eclipse for Java. However, when i try to take an image all I get is an image that says "Please start Manycam or choose another video source"
Here is the code i am using:
package testests;
import org.opencv.core.Core;
import org.opencv.core.Mat;
import org.opencv.highgui.Highgui;
import org.opencv.highgui.VideoCapture;
public class Hello
{
public static void main(String[] args)
{
System.out.println(System.getProperty("java.library.path"));
System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
VideoCapture cap = new VideoCapture(0);
if (!cap.isOpened())
System.out.println("Not connected to webcam ):");
else
System.out.println("Connected to camera: " + cap);
Mat frame = new Mat();
cap.retrieve(frame);
System.out.println(frame);
Highgui.imwrite("test.jpg", frame);
cap.release();
}
}
any help would be greatly appreciated!
Edit:
I got it working with manycam. However, i would like to use it without manycam and i cannot figure out how to. each time i try that image comes back up
So to get it working i captured camera index 1 instead of 0. I'm not entirely sure why that worked, but it worked.