I have an Adafruit (Gemma) / Arduino and a Neopixel LED ring that I would like to control from World of Warcraft in-game events. This part is soldered and working.
Question:
Is there any way to send communications between World of Warcraft and some sort of listener on the PC that can then in turn send messages over USB to the Arduino/Gemma device?
My aim is to create an on-desk LED indicator e.g. if I'm a healer, then I want green/yellow/red light to represent the health of each raid/party member - so refreshes would be required at a high rate (0.5 / sec).
Thanks for your feedback in advance and welcome any future possibilities with the soon to be released Warlords of Draenor.
Is there any way to send communications between World of Warcraft and some sort of listener on the PC
Not directly via the WoW API. I came up with a way which I've never shared, because my usage broke Blizzard rules. But I haven't played in years, so here ya go. :)
I used an addon to create a one pixel frame in the top-left of the WoW window. I manipulated the color of this pixel to send data to the outside world.
The "listener" app can read this pixel with three Win32 calls:
HWND hwnd = FindWindow(NULL, "World of Warcraft"); // find WoW window
HDC hdc = GetDC(hwnd); // get the device context (graphics drawing abstraction)
COLORREF color = GetPixel(hdc, 0,0); // read the pixel at x 0, y 0
I then interpreted the bits of the color like this:
4: sequence number
7: checksum: (sequence + key code + ctrl + alt + shift + win)/6
8: key code or ASCII character
1: 1: virtual key code, 0: ASCII
1: CTRL key pressed
1: ALT key pressed
1: SHIFT key pressed
2: WINDOWS key pressed
The "sequence number" was just means of detecting that a new message had been posted to the pixel. The checksum was to prevent bogus reads when my special pixel was not active, like during loading screens. The rest was keystroke information. This allowed me to generate keystrokes from an addon. The entire watcher app is about 100 lines of C. Very simple.
I wrote an in-game script editor and used this with "pixelbot" to automate things in game. Towards the end of my WoW life I had more fun coding for Wow than playing it, which is saying a lot, because it's a fun game. :) One upon a time I knew everything there was to know about WoW addon programming, but I'm several years out of date now. I'll see if I can dig up some pixelbot Lua code for, though.
Anyway, you can adapt this scheme to send any messages you like. For instance:
4: sequence number
7: checksum (sequence + player number + LED color)/3
5: player number
2: LED color (0: green, 1: yellow, 2: red)
6: *reserved*
As for speed, I never actually measured it, but it blows away your 0.5 second requirement. At most a few milliseconds of latency between writes and reads.
that can then in turn send messages over USB to the Arduino/Gemma device?
That's just writing to the serial port in the "watcher" app and using Arduino libraries for read from the serial port inside your device.
I have source code for the "listener" app (pixel watcher) and for the WoW side stuff that writes message to the pixel. Let me know if you're interested and I'll help you out of band or dramatically increase the side of this post.
After some research, I did not found any built-in functionnality to signal/pipe/communicate with an external software. I believe it is due to the anti-bot blizzard policy. Actually you could do this with a memory watcher ( just like CheatEngine ), but there is chances you'll be banned for using this.
The only thing you could do if you can't find anything, is to ask on official forum, and hope a technic-friendly blue poster will answer =)
If you find anything, update your post, your idea is pretty interesting =)
There are only two ways to communicate with the game client without breaking the ToU:
Saving variables between sessions. Meaning that you can have an addon read and write to its storage file but this requires you to either relog or to /reload the UI for this file to be written to and read from. In short this wouldn't be so viable.
Have an addon use a tiny space on screen to write colors and use said colors to communicate with your external software by reading the pixels on screen.
There are many ways to achieve the second suggestion. You only need to be able to write this addon for the game. Then write an external program to read pixels. Sending commands back to the game would require hotkeys or sending it in the chat window.
Note that you are still limited to the API in-game that require hardware events. So for those you'd have to push a button or use the mouse to buypass.
Related
I am using opencv and openvino and am trying to figure out when I have a face detected, use the cv2.rectangle and have my coordinates sent but only on the first person bounded by the box so it can move the motors because when it sees multiple people it sends multiple coordinates and thus causing the servo and stepper motors to go crazy. Any help would be appreciated. Thank you
Generally, each code would run line by line. You'll need to create a proper function for each scenario so that the data could be handled and processed properly. In short, you'll need to implement error handling and data handling (probably more than these, depending on your software/hardware design). If you are trying to implement multiple threads of executions at the same time, it is better to use multithreading.
Besides, you are using 2 types of motors. Simply taking in all data is inefficient and prone to cause missing data. You'll need to be clear about what servo motor and stepper motor tasks are, the relations between coordinates, who will trigger what, if something fails or some sequence is missing then do task X, etc.
For example, the sequence of Data A should produce Result A but it is halted halfway because Data B went into the buffer and interfered with Result A and at the same time screwed Result B which was anticipated to happen. (This is what happened in your program)
It's good to review and design your whole process by creating a coding flowchart (a diagram that represents an algorithm). It will give you a clear idea of what should happen for each sequence of code. Then, design a proper handler for each situation.
Can you share more insights of your (pseudo-)code, please?
It sounds easy - you trigger a face-detection inference-request and you get a list/vector with all detected faces (the region-of-interest for each detected face) (including false-positive and false-positives, requiring some consistency-checks to filter those).
If you are interested in the first detected face only - then it could be to just process the first returned result from the list/vector.
However, you will see that sometimes the order of results might change, i.e. when 2 faces A and B were detected, in the next run it could still return faces, but B first and then A.
You could add object-tracking on top of face-detection to make sure you always process the same face.
(But even that could fail sometimes)
I'm pretty new to using GNURadio and I'm having trouble recovering the data from a signal that I've saved into a file. The signal is a carrier frequency of 56KHz with a frequency shift key of +/- 200hz at 600 baud.
So far, I've been able to demodulate the signal that looks similar to the signal I get from the source:
I'm trying to get this into a repeating string of 1s and 0s (the whole telegram is 38 bytes long and it continuously repeats). I've tried to use a clock recovery block in order to have only one byte per sample, but I'm not having much luck. Using the M&M clock recovery block, the whole telegram sometimes comes out correct, but it is not consistent. I've tried to adjust the omega and Mu values, but it doesn't seem to help that much. I've also tried using the Polyphase Clock sync, but I keep getting a runtime error of 'please specify a filter'. Is this asking me to add a tap? what tap would i use?
So I guess my overall question would be: What's the best way to get the telegram out of the demodulated fsk signal?
Again, pretty new at this so please let me know if I've missed something crucial. GNU flow graph below:
You're recovering the bit timing, but you're not recovering the byte boundaries – that needs to happen "one level higher", eg. by a well-known packet format with a defined preamble that you can look for.
I'm pretty much a noob when it comes to this kind of thing, so if you guys could either help me or direct me to a place to learn what I need to know, I would greatly appreciate it.
Basically my problem is that I am using the libpruio library to continuously sample analog values from the board. 2 things are going wrong here.
The first is that whenever the BB is sampling the voltages, the voltage of the wire that is hooked up to the AIN pin goes up. I've observed this through hooking up an oscilloscope to the same wire the pin is sampling. What I see is that whenever the BB starts sampling, the entire signal (just a sound wave from an amplified mic) is shifted up .8-.9 volts. This is also reflected in the values that I get from the BB, which are around 30,000 (when they should be 0). Hooking the pin up to ground gets me 0, which is correct, and hooking it up to 1.8 volts gets me something like 65520, which is also correct. So maybe it has something to do with the signal being weak?
The second issue is that even though I am receiving values at a rate of like 500khz-900khz, the actual rate seems to be around 11khz. What I mean by this is I only get a new value every 88us, and the rest of the values I get are stay the same as the new value until the next 88us passes, when I get a new value. These times correspond to the voltage shift up, which I mentioned in the previous paragraph. So actually what I see on the oscilloscope is that whenever I sample with the BB, there is a saw wave, with the frequency at the 11khz I was mentioning earlier.
In conclusion, whenever the BB samples, it first increases the voltage at the pin by .9volts, takes a sample of that voltage, and the voltage dies down for the next 88us, all the while the BB spits back the sample it took at the beginning of the period. I do not want this. I want it to not affect the voltage significantly, and take new samples every time the code runs.
As for the code I'm using, it's basically a slightly modified version of the IO_Input example in the libpruio library, with the values being stored in an array for later use instead of being printed immediately.
If you guys need any more information, I will gladly post it here, but for now I'm wondering if it is something super obvious that I'm missing.
Hooking the pin up to ground gets me 0, which is correct, and hooking
it up to 1.8 volts gets me something like 65520, which is also
correct. So maybe it has something to do with the signal being weak?
The BBB and libpruio seem to work OK. Check your wiring.
Regarding the sampling rate, the io_input example uses IO mode. If you need accurate timing for the samples use MM mode or RB mode.
Your target isn't very clear, so I cannot give detailed advices. (Some code also would help to understand what you're trying to do.)
BR
We have an application that prints 2 invoice copies - 1 on white (for the cust) and 1 on blue (for us).
We print a LOT of these so we are getting a printer with 3 big trays. One tray (tray 5) holds 4000 sheets and the other two (trays 3 and 4) are a tandem set holding 1600 and 2000 sheets. The application automatically generates the invoice and sends one document to the tray with the white paper and one to the tray with the blue paper.
The user has no input in this process.
Now, my problem is this - if I specifically send the blue copy to tray 3 and there is no paper in tray 3, the job will go on hold until someone loads it up even though tray 4 has 2000 more sheets ready to go. On the other hand, if I tell the printer to print on Blue 8 1/2x11" paper, it is smart enough to know that that type of paper is in both trays and to pull from either one until they are both empty. So, I want to change our application to select a paper type/size and color instead of a specific tray.
The program is written in Delphi and I have been looking at the DEVMODE structure returned by TPrinter.GetPrinter. The DEVMODE structure has a memory size in dmDriverExtra that indicates how much extra data the print driver is adding to the structure for its own storage.
Does anyone know of anyway to access this data and make changes to it? If you have examples in other languages, I can probably adapt it to Delphi so anything will help.
There are actually two different items in the questions:
How to set the pater size and type:
PaperSize would be stored in dmPaperSize (value DMPAPER_LETTER)
PaperType is a bit more difficult. I'd guess that it's in dmMediaType (use DeviceCapabilities to retrieve available media types and their names)
How to access / edit "DriverExtra" data:
In short: don't!
A bit longer: dmDriverExtra is described as "Contains the number of bytes of private driver-data that follow this structure". So this data is private to the driver (which means that you need very good documentation for the driver to actually know the format and content of this data. It's not guaranteed that different versions of the driver use the same format).
So the only thing you can do is to use a print dialog, retrieve the DevMode structure and store it for further use (however as I said: If the driver changes, this data may become invalid...)
looking for a little help.
I'm familiar with PIC Microcontrollers but have never used Atmel.
I'm required to use an ATMEGA128 for a project at work so I've been playing around in Atmel Studio 6 the last few days.
I'm having an issue however, I can't even get an LED to blink.
I'm using the STK500 and STK501 Dev boards and the JTAGICE_MKII USB debugger/programmer.
The ATMEGA128 chip is a TQFP package that's in the socket on the STK501 board.
I'm able to program/read the chip no problems, and my code builds without error (except for when I try to use the delay functions used in the delay.h library - but that's another issue).
For now I'm just concerned with getting the IO working. I have a jumper from 2 bits of PORTD connecting to 2 of the LEDs on the STK500 board.
All I'm doing in my code is setting the PORT direction with the DDRx ports and then setting all the PORTD pins to 0. The LEDs remain turned on.
When I'm in debugging mode and I have the watch window open, I can break the code and the watch windows shows me that the PORTD bits are indeed all 0's, but the LEDs remain on.
So far, I hate Atmel. :)
Any ideas?
Thanks
Have you tried setting them to logic 1? It is common for LED circuits to connect the LED to Vcc via a current-limiting resistor, which means the output port has to be 0 to turn on the LED.
If you set it to 1 and the LED goes off, then that'll tell you it's an "active low" signal and you can reverse your logic accordingly.
Have you read the STK500's doc? It is likely, that the LEDs are driven active low.
There are two steps to follow. First you set the "direction" of the pins, because they can be used as input or output. To make the D register pins output pins:
DDRD = 0xFF;
This will set all pins on the D register as output pins. Do this first. Then code like:
PORTD != 0x01;
will set the D0 pin high. And code like
PORTD ^= 0x01;
will toggle the pin.
See this tutorial for a little more info or visit in with this community. The Atmel community is vibrant and helpful.