emiln / cljck Goto Github PK

While clicking away, it is sometimes necessary to click slower or faster, depending on what the flash game can handle on the given machine you're using. It should be possible to change this without having to stop anything.

It would be neat to be able to save various routines in text files and have cljck process them. The format should be simple data, and EDN seems an excellent fit. It would be simple if the format could be precisely the same as the internal format passed to the event-channel A script could then look as follows:

[:repeat
 [:click]
 [:move-to 500 1200]
 [:click]
 [:click]]

To fit as a single command, I imagine composite events like :repeat will be needed. Repeating stuff over and over again seems to be my primary use case, anyway. This brings the sum total of tasks in this issue to:

1. Implement a :repeat event that has two function signatures: [& body] and [repetitions & body].
2. Write a function that processes an EDN file.

The idea is that you can write a script like

(with-killswitch "shift ESCAPE"
  ...)

which puts the choice of the killswitch key (combination) into the hands of the user.

Your library looks very cool, yet I would like to use it with Clojure to make a bot too.

Would you mind puting it on clojars so that I can include it in my project ? (Or tell me the step so that I can do it myself)

Thanks

The author seems to have released a new version, which should no longer print the GPL excerpt to system out.

The idea is that it'd be nice to tell Cljck about the border of the game window, which would enable relative positions rather than absolute positions. In this fashion people playing the same game on different monitors could share their scripts without having to translate all the coordinates.

I imagine something along the lines of:

(with-game-borders
  (move-to 10% 10%)
  (click))

This should make Cljck prompt the user to click the lower left and then upper right corner of the game window to log the coordinates. Any attempt to use relative coordinates outside of with-game-borders should be an error.

It should be possible to call

[:scroll-up 5]

to scroll five "ticks" up, and similar for :scroll-down. I think it'd be nice to have a no-argument default of 1 so you don't have to supply a 1 all the time, which I imagine to be the typical usage.

It's almost impossible to stop the robot if you've set up a lot of movement and clicking. It would be great to have a global keybinding that would immediately stop event processing.

It should be possible to have cljck repeatedly simulate a mouse click x times per second.

On the bright side I now recall why it's there.

I wonder if perhaps symbols would be easier for people to relate to for the EDN DSL. The current example in the README is

[:repeatedly
 [:if [:pointer-near 100 100 50]
  [:move-to 500 500]
  [:move-to 100 100]]
 [:repeat 100
  [:click]
  [:scroll-down 5]]
 [:when [:pointer-near 500 500 50]
  [:scroll-up]]
 [:wait 1000]]

but it could just as easily be

[repeatedly
 [if [pointer-near 100 100 50]
  [move-to 500 500]
  [move-to 100 100]]
 [repeat 100
  [click]
  [scroll-down 5]]
 [when [pointer-near 500 500 50]
  [scroll-up]]
 [wait 1000]]

or even

(repeatedly
 (if (pointer-near 100 100 50)
  (move-to 500 500)
  (move-to 100 100))
 (repeat 100
  (click)
  (scroll-down 5))
 (when (pointer-near 500 500 50)
  (scroll-up))
 (wait 1000))

It should be possible to call something (move-to 100 100) to move the cursor to the absolute position [100, 100]. It should work concurrently with clicks and you'd expect the move to happen in a sequence like the following:

Press button. Release button. Move mouse. Press button. Release button.

That is, movement should not happen during a click (which is both press and release).

There should be a boot task that creates an uberjar. This uberjar should be supplied a file name on the command line and should process this file as EDN commands.

It'd be great to be able to divide your scripts into multiple files and launch any number of them at once. They should interleave as you'd expect (which is to say chaotically) and no synchronization mechanism is intended just yet. The robot will attempt to queue the commands up and to the best of its ability process them as they arrived.

It would be great to have simple if-then-else conditionals in the scripting language. The first really useful condition could be something along the lines of:

[:when [:pointer-near 500 500 50]
 [:click]]

This would process the body if the mouse pointer is within 50 pixels of the point [500, 500]. There should be similarl functionality for :if, but taking both and if and an else branch.

It's not used for anything right now and I have no plans to change that. Removing it could help slim down the JAR slightly.

It would be great to be able to express flows like: If this region of the screen is similar to this old version of it, perform some command. One measure for similarity could be simple color histograms. Here's my thought on a first version:

Similarity is calculated by:

• Creating 8 buckets for each of red, green, and blue. The first is for values [0 31], the next [32 63] etc.
• For each pixel considered, increment the proper bucket for its red, green, and blue color value.
• Normalize all buckets relative to the number of pixels considered.
• Calculate the absolute differences in normalized buckets values between the two images.
• Sum up the differences.

Note that this means you can save a "fingerprint" of an image by saving its bucket values.

It would be great to have the bot locate the upper left corner of the Clicker Heroes window. This would allow movement commands relative to the inside of the game frame. I imagine the commands [:relative-move-to 100 100] and [:absolute-move-to 100 100] to replace the current [:move-to 100 100].

This would make it easier to control the aggressive clicking. A nice additional feature would be an input of some kind allowing you to choose the number of clicks per second.

It would be nice to be able to write scripts like:

(while-holding "Shift"
  (click))

I suggest the first argument for while-holding would be the same type as the existing key press commands.

It should touch upon topics like:

• What's this project about?
• How do I use it?
• How do I write script files?

In order to write logic for visual content on the screen, a simple start would be the ability to express a condition like:

Take a histogram of the area [x, y, width, height]. Is this within [distance] of [other histogram]?

As histograms were already implemented with #11 this is actually mostly done. A few tasks remain:

• Allow script authors to write literal histograms. Perhaps [:histogram 0xffff...].
• Allow script authors to generate a histogram of a portion of the screen. Perhaps [:histogram-at x y width height].

To use the abilities with cool downs, you need to be able to simulate key presses.

Using Escape to kill the bot only seems to work about 10 times on Windows, after which pressing the key has no effect and the terminal may start spouting error messages about being unable to bind... something.

As an angry wife to a hardened Clicker Heroes addict I'd like to be able to regain control of the computer, which is frantically moving and clicking the mouse cursor about.