Bloody Software Mouse

[Ellyn Krucke]

Iuse a4tech bloody j90s mouse. A4tech mice have a problem on linux, in the form of strange cursor behavior. It behaves like I'm using a gamepad or something. That is, if I move the mouse a little bit, the cursor doesn't move. It's like the computer thinks it's a gamepad dead zone. What is happening is that the mouse is getting two event files. The solution to this problem is to merge the two event files using evsieve as shown here.

Now let's move on to the problem on arch linux. The event file numbers change after every arch linux reboot (the kernel kind of changes them but that is not the point). And the solution described above does not work because the event file numbers change.

Actually, the question is as follows. Is there any solution to this problem so that the mouse doesn't behave like a gamepad stick? Save the event file numbers so that evsieve merges them when running the .service file or something else?

Yes, I understand. But the problem is that when I look at the link target of these files, one of the event files that I "merge" with evsieve is always missing there. That is, if I have event files with numbers 17 and 19, the link target of those files will not have an event19 file

So, since I couldn't get the path to the second event file using udevadm (or maybe I just couldn't find the solution), I wrote a little bash script. The script takes the path to the first event file, and since the difference in numbers is always 2, the script adds 2 to the number of the detected event file and then runs evsieve. Code:

The rest of the problem - I should not touch the mouse until I'm not in the system, otherwise I'll have to run the fix manually using systemctl. But for now it's fine for me, I mark the topic as solved.

If someone is interested or need complete solution to the problem - here's the full code. I'll finalize it there.

Yeah, I know. udevadm event19 (which I do with eventNumber+2) has shows in the propertys the file that creates 3 event files. And if I look at the properties of that file through udevadm info or monitor, it only outputs mouse0 link. I could never get event19 or the links list.

When I boot, I have to select the user and enter the password. If I make a mouse move before doing this, (from what I understand) there will be an error in systemctl status and I have to use systemctl start mouseFix. I am not quite sure how the Linux event files are created and systemd units are called to say exactly what the problem is.

After several reboots, I noticed the following pattern:

If I turn off and then turn on the system, making mouse movements before selecting a user and entering a password - the script doesn't work, and the systemctl status mouseFix gives the following:

I use. The .service file calls this bash script. As I understand it, describing all the logic in a .service would be problematic. So I do everything necessary in the bash script and the .service file calls it.

So, I tweaked the systemd unit and now it is called after creating the .device file of the mouse. And just in case, I added a restart after on-failed (although I noticed the script never restarted after that time if it failed). And I also removed sudo from the bash script.

I couldn't really find any info on this and not sure if I should annoy support with this. I recently got a Bloody gaming mouse mostly because it looked so dang cool and downloaded the software to see if I can do some interesting things with the buttons. It has a bunch of macro functions and whatnot and a bunch of ridiculous setting that half of it I don't even understand. ? When I tried looking up tutorials and stuff I ended up in a bunch of cheating focused forums and that got me super worried. Is it cheating? Should I be worried when I'm running the software while playing? The only feature that I really liked that you can get the mouse sensitivity very low to help with aiming with a button press, but you still have to aim for yourself so dunno. Should I just delete it and forget about the shiny functions?

it should be chill unless your just getting it to do functions of the game for you. for example, i mapped WASD to the side buttons on my mouse, so i can play one handed when i broke my arm. id say remapping buttons and changing sensitivity is fine, just dont do anything that seems like it would get you banned

You are allowed to use macros as long as they don't play the game for you, a good chunk of people have macros for spamming melee and semi auto guns or recasting abilities, so as long as you're still playing the game I wouldn't worry about it. you can read DE's official stance on macros and such here

DE draws the (somewhat unspecific) line by what you already can do in the game. So, if you need to press two buttons to do something it is probably ok to use a macro that allows you to do this with one button press (instead of two). In other words, a macro that sends two keyboard codes from a single key press.

However, automating button presses, like using an "on-off" function for your melee key, can definitively lead to banning. That is because such a "melee on" (and "melee off") function doesn't exist in the game. The same is true for an automated "afk-dance", where you have a macro sending recorded/coded movement to the game in order to avoid the built-in afk-check kicking in. There is no official line or statistics on how many and what happens if you are caught, but there is a general misconception that this is ok just because someone gets away with it. I would never risk it myself, since players have been banned for such "on-off" automation.

If you use any software that reads something from the screen (memory) and automatically adjusts the mouse accordingly, you will be banned. My guess would be even perma-banned (to 2035, or whatever it currently is).

I have a macro mouse but honestly I don't feel like macros are necessary and I would probably advise against using them in-game just in case. Remapping buttons is fine though as it is no different to remapping keyboard controls. I have buttons 1-4 mapped to my thumb buttons and 5 mapped to my scroll wheel. My Logitech software is always running and has been for about 3 years or so.

No real need for macros automating the game, and definitely not work the risk. Automating stuff would be cool from a nerdy-tech challenge viewpoint, but if one is not prepared to actually play the game, why bother with something that is considered cheating?

I recently purchased the Bloody a70 Matte Black mouse for a certain clicking method called drag clicking. To put it simply you drag your finger down the mouse to register multiple clicks. On Windows, Mac OS, and chrome OS, there are no issues with the mouse. On Manjaro, it only registers about 4 cps when it should be 25-50. I assume it is a kernel or driver issue, as it happens on pop!_OS also. I have no idea how to fix it. youtu .be/ GZeW8Sf4MEk (Remove spaces)

This A4TECH V3 Bloody Gun3 Multi-Core Gaming Mouse is an interesting device with a mouthful of a name. Like the last gaming mouse I reviewed, this one acts as both a pointer and a keyboard, and is built with on-board storage for macros and settings that carry between computers.

The Guide, as with many things in this package, could have done with a bit of proofreading. Throughout the materials and the driver software there are typos, as well as awkward and even missing translations.

The top is covered in a rubbery coating that resists fingerprints and smudges, and the sides are a glossy plastic with ribbing that makes it easy to grip. Shining through the palm rest of the mouse is a bloody red hand print: Its brightness throbs with a kind of breathing rhythm while the mouse is idle, and shifts to a solid red when the device is used.

This device also registers as a USB mouse and keyboard when plugged in. More about that in the next section, but in a nutshell: Macros and various settings are stashed into on-board RAM (all 160K of it) by the control panel software. The device can issue both pointer and keyboard events as part of macros, and those are still available when the mouse is moved between computers.

These Cores appear to be firmware that gets downloaded to the mouse itself: Changing the Core requires that the mouse be plugged in, and the changes carry between computers. When a Core is changed, the mouse and its lighting effects flicker and shut down. The device appears to reboot itself shortly after.

Core2 is more interesting: It has all the features of Core1, but the three buttons below the scroll wheel trade programmability for use as dedicated burst-fire mode selection for FPS shooters. Core2 also adds the ability to bind simple app switching to the thumb buttons.

This includes an extensive macro editing system, complete with some programming language features like loops, conditionals, and jumps. These macros can also be shared to and downloaded from the company website, where many other players have already contributed to a growing library.

Of course, those extra features might get you accused of cheating, depending on what and where you play. But, I played old-school shoot-em-ups on an NES Max controller with Turbo buttons and sometimes rocked an NES Advantage, so who am I to judge?

The site is secure.

The ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

The common spiny mouse (Acomys cahirinus) is the only known rodent to demonstrate a myriad of physiological processes unseen in their murid relatives. The most recently discovered of these uncharacteristic traits: spontaneous decidual transformation of the uterus in virgin females, preceding menstruation. Menstruation occurring without experimental intervention in rodents has not been documented elsewhere to date, and natural menstruation is indeed rare in the animal kingdom outside of higher order primates. This review briefly summarises the current knowledge of spiny mouse biology and taxonomy, and explores their endocrinology which may aid in our understanding of the evolution of menstruation in this species. We propose that DHEA, synthesised by the spiny mouse (but not other rodents), humans and other menstruating primates, is integral in spontaneous decidualisation and therefore menstruation. We discuss both physiological and behavioural attributes across the menstrual cycle in the spiny mouse analogous to those observed in other menstruating species, including premenstrual syndrome. We further encourage the use of the spiny mouse as a small animal model of menstruation and female reproductive biology.

3a8082e126