Leaderboard

<Rant> Hi, is there going to be a timeline for the MacOS compatible driver to be released? I understand that The Z works completely independent of the driver (it works on the firmware level, similar to my QMK equipped Ergodox EZ). So, my question will be, is it that hard to release a "configurator interface" that generates some kind of a compiled script that can upload to the MCU of the mouse for MacOS? Even my Ergodox has a MacOS compatible flash utility. I could care less if I need to open a configuration file of some kind, and edit it by hand, and then compile it, then flash it manually - just give me an access to the firmware so that I can modify my Z as I see fit without needing a Windows machine. Just a thought... </Rant> <Suggestion> Rant aside, the mouse is great. I would greatly appreciate if the configuration part of the firmware can be (somewhat) open sourced. The hardware it self is GREAT, the software is VERY WEAK. If only the firmware is partly open, it will alleviate many of my complains... Using QMK as an example, all my needs are everything within the "keyboards/[keyboard_name]/keymaps/[keymap_name]/" directory (or folder). For example, in my case, it would be "keyboards/ergodox_ez/keymaps/damir/" directory. I do not need access to the other directory or files OUTSIDE this scope to configure my keyboard properly, unless I want to do something within the core of QMK, - which most of the time are not needed - like to see how TapDance work. Judging from the "driver" application, I can tell if all it does is to generate some kind of a configuration file, and compile it against something then connect to the MCU, flash the firmware, and reboot/restart/reload the firmware/configuration. Learning QMK made me realize many strengths of the features within the original firmware for the Z. If only I can configure it to my heart content, that would be great. Open sourcing the [parts or all of the] firmware will help the product in so many wonderful ways. Users for Linux systems can have their own configurator. I can generate a web based configurator for the Z - imagine that you can configure a mouse using a web configurator, no need to install anything to configure the product if need be - and should I need to configure it quickly, just connect to the web, make (or change a configuration) save it in the cloud, then download the compiled firmware for later use. I'm pitching you guys an idea. If I were to be in your team, I'd use a fork of NGINX (or NODE.JS) to run a [heavily locked down] local web service that interfaces to a MCU controller/interface/flasher. These are the basic features of this kind of setup: The web service instance will serve a "local copy" of the user's profile created on Swiftpoint's user configuration repository. If the computer is online, then the local instance can connect to the public repository and synchronise. If the user is offline, or does not make use of the online repository, then run the service as local only and store everything in a local SQLite database for easy archive and/or retrieval. By making a public repository of configuration, you easily have a completely community run configuration repository that associates users to configurations, and you can easily manage/index/mine/whatever you want to do to it. The MCU controller/interface/flasher does not change a lot over time. You can patch it separately should there be any problem in the future. The web server part ran in an independent subsystem that you can update quickly should there be a bug or security hole (the beauty of using a publicly used code is this). You can have a multi platform configurator that can have different feature set on different platforms (you can synchronise it should you need it). You can update the "interface" part of the user facing configurator by updating a web based configuration repository template. All these subsystems can run in a very small, very optimised, very small memory footprint, and secure system. Easily patched/update/upgrade/secure in the future. The MCU controller/interface/flasher runs in the background waiting for events from the mouse and the web service (for automatic profile switching based on foreground apps). This should be very small because there is no assets to be loaded within it. Easily patched should there be a problem. The web service part (in my case, a local NGINX instance, or you can have NODE.JS) ran ONLY when the user is viewing the "driver" part is being viewed by the user. The interface it self, since it's working on HTML5 based instance, can be easily updated/overhauled/whatever you want to do VERY EASILY, without "driver" reinstallation even. A "traditional driver update" occurs only if the MCU controller/interface/flasher has any change or the web server is/are updated, other that these events, the update is VERY STREAMLINED. Want to add a feature to the configurator? Modify or add a new template to be synchronised by the end user. Want to port a feature to platforms other than Windows? Port the MCU controller/interface/flasher to that platform. The web service part is already multi-platform capable. The last idea, a big one: Want to make a new product(s)? Use the same stack for the new product(s)... All is well, everyone is happy, you sell many mouse, and be happy. One software stack to rule them all. </Suggestion> Well, just an enthusiastic user pleading to the company that made his favourite product to make his product to be even better... If you guys want to know more, send me an email :) Thank you, Damir.

From another thread reguearding the same issue from issues and bug reports section:

there is the checkbox

@Mick81 you'd need to download this profile: Editable LMB to be able to reconfigure the LMB.

@Oleg Girko If you (or anyone else) are still interested in creating Linux software for the Z, please find the specification for the Z's raw sensor events below. This should give you all the info you need to enable the raw outputs for all of the Z's inputs (they are disabled by default), and show you how to interpret that output. If you have any questions on the specifics they're likely to go over my head. But I can try to pass a few on to our devs if necessary. Z Raw Sensor Events Specification.pdf

I really like the grenade cook my man! Great minds think alike haha. I had exactly the same idea but couldn't get it to work until I checked out the forums for help and saw your post. Initially I thought there was desync with the in-game timer or the mouse/driver but I noticed after a while - in the driver, my vibration duration was set to continue (I never noticed there was a 'wait until' option in the vibration output) so my wait commands were "wait 0.7 seconds", vibrate "0.3 [continue]" instead of wait until vibrate has finished.. resulting in a few really short games in PUBG ? Quick fix though either changing the wait or vibration outputs. The pull trigger and mouse movements to change equips is quality man!. I'm a pleb when it comes to macros, I've always stuck to in-game bindings and hardware defaults so this is like a new world. I've got a pretty gnarly profile in the works that I've been destroying with lately, when I upload it I'll tag you bruh. GGs

i've totally abandoned this profile for one that's quite a bit more simple and better in my opinion. i'll post the revision after i clean it up a bit and try to make it play nicer with the default key binds it would be nice to come up with something like the bindED plugin for elite dangerous, which assigns a unique alias to each of the controls that a key can be bound to, then reads the user's local key mapping file from the game's config and replaces the alias with the corresponding inputs. not that i have a very good idea of how to do that with respect to way these profiles are written. it would be great to be able to swap profiles without having to synchronize all of our in game keybinds in order for the profile to work. they really aren't easy to share at all. that's pretty typical with this sort of thing, but i really love the way the elite dangerous community took it upon themselves and just went nuts on creating stuff to streamline the user experience. maybe if we could get the devs to donate a couple z's, we could steal some of that modding community because they were on point.