Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. This is just me throwing out suggestions, from me brainstorming over the last 3 years about control interfaces for gaming purposes that I wish existed. Considering what they tried to do with this mouse. Maybe you are the best candidate to make it happen. Point Number 1 I'd like to make after just 24 hours with your mouse. Replace the gyro with a thumbstick. Gyro's suck. The Tilt activation during lift off is evidence enough of that. I'd get a refund on it if I could. The gyro sensors and anything binded to them get in the way of normal mouse usage and activate just from repositioning the mouse to get another swipe on the mouse pads. It's a dead end. A Thumbstick doesn't activate unless you want it too. Vertical mice. Have you seen them? Supposedly more ergonomic, haven't tried one myself to verify that though. Keep this is mind for later. With games like Star Citizen, Elite Dangerous, Overload, Descent, etc. I would argue that the best feeling control method to play these games is a HOJAJ (Hands on Joystick and Joystick (& Pedals)) setup. The only problem with this though is trying to aim with a joystick vs a player using a mouse, even in flight games, is painfully obvious the joystick cannot compete with the mouse. Which led to me attempting to adopt a HOJAM (Hands on Joystick and Mouse) setup. But this leaves the problem of trying to implement roll onto the mouse, preferably analog roll, instead of digital. But again.. a HOJAM doesn't feel as good as a HOJAJ..... so... A Vertical mouse, with an analog thumbstick on it. But this mouse should stand up more like a joystick for the feeling of it alone, but move around and aim like a mouse. A Joystick mouse. And on top of it, will be the thumbstick and pressure sensing ABXY buttons. On the stock of it, it should have a Bumper, Trigger, (Like an Xbox controller) and further down the stock, a pinky button and lever, similar to those on the X-52, x-55, x-56 Yes, it's going to hybridize into existing console controller button labels and layouts and nothing more, for simplicity sake. This is an important part of it. Because I never used half the hat switches on any of my HOTAS controllers. The pinky button, and lever, would bring it up to par with the equivalent of the paddles on the Xbox Elite controllers. If the paddles were completely separate buttons (Which can be accomplished via a program called reWASD if anyone was interested in expanding the functionality of an Xbox Elite controller, for PC gaming purposes). That's the right hand. The Left hand is for another day.
  3. Today
  4. Sorry to necro the post. But I'm looking for information in regards to disable the tilt binding during lift off. TL:DR Tilt bindings are interfering with normal mouse usage during lift-off repositioning. Attempting to play a 6dof shooter where I use the tilt function of the mouse to handle roll. Well, every time I lift the mouse from the pad during aiming to reposition the mouse (because mouse pads only have so much real-estate). The tilt activates and causes the ship to roll. Considering the amount of degrees you have to work with, the best I can do is put a deadzone of 1 degree on it. But under normal usage, the mouse will tilt in excess of 2 degrees during lift off repositioning. On the other side of things. The most I can get out of tilting and still accomplish cursor control is about 4 degrees max, but even then cursor manipulation can become intermittent at that angle. So more like 3 Degrees maximum, which gives a total of 1 degree to work with to control analog til, if I was to put a 2 degree deadzone on the tilt. And even then I still get tilt activation during lift off. I need something to happen, that if it detects Z movement (Lift off) it immediately disables tilt binding, until it detects cursor movement again. Cursor movement being detected would mean the mouse as been reintroduced to the mouse pad and ready to activate tilt bindings again.
  5. Yesterday
  6. Seems like three identical devices to me. If they are different, it might be worth adding a "compare features" on the main website. On a side note, I'd love to see SwiftPoint focus on different devices. Personally I'd love a gaming keypad to pair up with the Z. Looking at utilising the tilt / pivot, deep clicks and vibration feedback features and seeing how you could create a device to innovative movement in-game. At the very least create a survey and ask the community what they want.
  7. Last week
  8. I was faced with the same problem a couple of times and found a solution. 1) Close the Swiftpoint configuration software; 2) Open your Taskmanager with administrator rights and find SwiftpointDriver.exe task and terminate/end it. No restart of Windows required. 3) Restart your Swiftpoint configuration software and activate Connect to Mouse. Done that successfully a couple of times with previous and just now with the latest version 1.2.56.0 under Windows 10 Pro x64. BTW the unplug and reconnect USB cable while holding L + R buttons did not work for me either.
  9. I absolutely love this mouse but this is my second one with this problem. I have it set to press W and the release set to stop all loops but occasionally when I let go it won't release. I've tried both kinds of buttons, the long and short caps, but it still does this. Has anyone else had this issue? If so, how did you fix it? Edit: I fixed it by switching the commands back and forth between the fingertip buttons and the other ones. I don't know why because it was working all last night and I didn't actually change anything, just switched them back and forth.
    I would utilize the edge buttons for something other than DPI switching as tilting the mouse >25% and using the scroll wheel with do the same thing. Other than that, very well done with taking time to share your profile instead of keeping it for yourself to stomp us in the battlefield 😁
  10. BWT, thank you @Skip for your detailed post, I'm using Ubuntu 18.04 & Windows 10 (1903) dual boot
  11. Oh my, this is really annoying. I'm sorry to say but I'm back to Logitech after I switched over to Ubuntu. Damn I miss "the Z" but it's just not usable due this scroll wheel problem. Any news how to fix this problem ?
  12. Earlier
  13. Some don't, a lot do. I use them - I don't treat them like something I should be scared to touch. I use them as the tool they were designed to be. Of course, I keep my hands super clean around my equipment though - that's one thing I can't stand is people eating, having fingers full of chip grease, etc... and then touching keys on a keyboard or mouse.
  14. Could it be browser related. On mac you have to download to the driver with Safari of Chrome, it does not work in Firefox. Could this be the same on Windows?
  15. Actually the driver of the Z Mouse does not use any keyboard layout at all. The driver registers keycodes, in other words it only cares which fisical key was pressed, not which character is linked to it. I recommend to use 'record keystrokes" function, then you wont have to lookup a keyboard layout to figure out which character to use.
  16. Not that I'm aware of. But no, when installing current Mac driver, you will not 'see' anything being installed. At the moment there is no GUI available. That's why you have to install BetterTouchTool to get a GUI. There are issues with current mappings: some buttons not mapped, shift click to select multiple items not working, wrong buttons mapped, etc So it's a work in progress. Do you have Access to a Windows PC? Recommend to connect you mouse first to a Windows PC to update the firmware. But before you do that download the mac driver on the PC so you have access to the default Mac profile for the mouse. After firmware update you will need to apply the profile to set the mouse back to the default Mac configuration. Is there a newer Mac driver available? Yes, but it's beta. Nonetheless I do recommend to try it out, see: https://www.swiftpoint.com/customer-support/download-z-drivers/swiftpoint-z-mac-driver-download/ Even with the beta I still use BetterTouchTool to get even more out of the mouse.
  17. you mean something like a perfectly fitted mouse for your hand? Well that would cost a bit And I dont know what you do with your mouse, but I have a hell lot of old mouses and none of them shows any wear on the coating
  18. Bind tilt left / right to do nothing. Add tilt left / right within to do the analog from 0 to x depending how far you can, then you should be able to output as joystick axis 0 to 100% based on the input range of 0 to 2 for right and 0 to -2 for left, or so... Or different ranges if you want to tilt it further.
  19. I'm not a fan of the rubberization mouse companies use, or car companies... They end up melting, and getting super sticky and slimy... Even normal plastic coating wears off to a shine after use. It adds up in cost to apply it, make these inserts, etc... and they basically do nothing other than introduce timebomb defects. It'd be better to indent the sides more for the fingers to fit within better - then there isn't any need for any type of grippy stuff, and it makes it more usable for those of us with deficits.
  20. Macros are accessibility features.. Those of us with deficits may need them in order to enjoy a game.
  21. Version 1.0.0

    0 downloads

    This was an example made for someone who asked about the idea on the forum. There are a lot of issues with this type of system - had I been able to bind press-strength with wait time I would've only needed to add a clause for above x to hold and it would've been a very short function. If functions were allowed, I'd still need a lot of the elements, but instead of repeating the same stuff over and over, I could've had the wait time as a variable / argument... Also, I could've had the key as an argument, and made this entire system as a function too - which meant this could be applied to every single key you would want... This setup, since you can't move anything around, has a lot of un-used elements.... The ones which are used are 1% ( as Left click down ) Down, < 1% as Left Click up, 10%, 25%, 50%, 75% and 85%. All of the Stop loops have been placed first to execute first. This allowed me to group all of the up cycles, and down cycles together. So 50% down will engage 50%... 75% Up will engage 50% Down by repeating the exact stuff - so if you want to edit wait times, then edit for x% Down, and x% + 1 used-slot UP.... If you want to add additional speeds to make it more fluid, copy the up / down methods and link them together. ie: To add in 35% do the following: --- Do not edit the top section with the looping data... Only use the top do nothing to stop all loop if you use it. The second instance of each value is where you add in the loops - this is so stop loop can be executed first ( there is a bug which stops new loops from being created as of 1.2.56.0 if you do stop loops, then you create a loop - that new loop is stopped too even if you do not execute that command in the loop... Which is why it has to be external... Copy 50% Press to 35% Press ( This is 50% Press with text to show you increased clicking frequency ) Copy 50% Release to 35% Release ( This should be 25% Press with text to imply you reduced clicking frequency ) Update 35% Press Wait time to be what you want, it should be between 25% and 50% wait times. Update 50% Release Wait time to reflect what you set 35% Press to Update 50% Release Text to reflect it going to new lower value, 35% Set 35% Press and Release - FIRST INSTANCE OF - to Stop all Loops from Do Nothing done... Unfortunately, you have to create the time, then you have to update the existing links, then you have to create the link in 35% Release...
  22. Unfortunately mouse movement can be used as a detector, not an output - which is unfortunate. You could use AutoHotkey to move the mouse, and activate the key-bind you use in that script with the key you set up for the mouse button in the software... You can have AutoHotkey also loop it - or you could loop it while held in the Swiftpoint software.
  23. Update: Here it is: That appears to work properly... I included 1% to 10%, 10% to 25%, 25% to 50%, 50% to 75% and 75% to 85% with different hold times. 85% upwards will hold the key down by pressing, and releasing when you lower below 85%. 1% is .1 seconds, 10 is 0.075, 25% is 0.05 seconds, 50% is 0.025% and 75 is 0 wait time, and 85% changes to hold instead of tapping. If you want to add new links for more variability, then the way to do that is in the file listing. I set the key to left fingertip... ------------ I don't know if this will work, but it is the only thing which looks like it could be what you want..... and to ship the mouse with the sensor without being able to output means losing a lot of functionality.... However, with what you are asking, there may be another method to use... First method - use the actual analog input as output.... You may be able to do Left Button Press > Left Button 5% to 100% type Analog Range for input - which hopefully shows up as output since I can't add any outputs under it. Left Button Press > Do nothing + Left Button 5% to 100% > Controller Type, Joystick Slider Control, Action Slider Position - Slider range 0.0 to 100%.. Meaning the joystick slider is 0% until you are at 5% press strength. You are at 100% joystick slider at 100% button press. You are at 50% joystick slider at 47.5% button press force... Left Button Release > Do nothing Unfortunately, this seems to be broken for Left click, but does appear to work for right click... The do nothing part... That way only the level of force does an action. If you have it press the key on press and release on release, then you hold click while trying to do something else... That should work if you use an axis... If an axis isn't possible to bind in the game, you can use third party software to emulate an Xbox 360 controller, right trigger, which will work. But can be slower through emulation like that. Another option you can use, is looping... Left Button Press > Do Nothing Deep Click 1% Press > Loop 0 times | W Press W every 1/3 seconds Deep Click 1% Release > Stop Looping ( I don't know if it let's you target specific loops, so you could add this at the lowest value... ) There may, in the future, be a way to use the press value for loop speed which would be fantastic. Deep Click 5% Press Press W every 1/4 seconds Deep Click 1% Release > Stop Looping Deep Click 10% Press Press W every 1/5 seconds Deep Click 1% Release > Stop Looping Deep Click 80% > Press W Deep Click 80% Release > Release W Left Button Release > Do Nothing Note: If you don't stop looping that instance, they will compound as you add so 1% you'll have 1/3 presses, for 5% you'll have both 1/3 and 1/4... and so on... But stopping the loop appears to stop all, need to figure out how to assign id's so only that particular loop is stopped... In short, this type of setup will TAP w at faster and faster intervals, until you get to the percentage in which you hold down the W key for full-throttle. Another option, since I don't know how long tap is - is to use press and release commands and hold the key for different times. I'd recommend determining how many times per second you have to press for various speeds and use that as a range if this doesn't work.. Instead of using tap, I'd recommend doing press and release after x seconds... This will give you more control... Another way to do the same thing - is , instead of adding the loop one after the next... Nest them... so you end up with Deep Click 1% Press Deep Click 5% Press Deep Click 10% Press Deep Click 20% Press Deep Click 1% Release Deep Click 5% Release Deep Click 10% Release Deep Click 20% Release and, if the loops stop when not active - then you wouldn't need it, but I haven't played with the software enough to see... But using this nesting method you could stack the looping together... The max one should probably be separate, and it should probably stop loops and then press W... That could be another thing.. Stop all loops when you enter a range, and when you exit, re-start from the previous. So starting the loop as you enter... Stopping when you exit and starting the one below, if one exists... It would be more work, but depending how the software handles things, it would be another way to hack it... I still think one of the first ideas was the best - use the slider value. Hope this helps.. Also, just because not everyone plays a certain game, doesn't mean that someone can't help with a generic question. Since a key-press is a simple on / off state, or off throttle / full throttle, you could use a loop method to attain different speeds... You could also EDIT: So it seems you use the loop as a do while loop where the logic is at the end... So, STOP ALL LOOPS, press W, Wait 100 Milliseconds ( or however long for you tap, 100 is a decent number ), Release W ( or TAP but I don't know how long their tap is ), wait x milliseconds ( or if they support decimals in seconds, then you can use that instead, but it is unlikely to be supported since milliseconds is there, even though retaining it would be really easy in the code side of things ), Repeat from step 0 ( the first step )... That'll loop everything, it just has to be placed LAST. The stop all loops setting may be important... It may also break it... If it is first, I'm hoping it'll stop other loops.. I'm hoping it doesn't act like a break from within the loop... If it does, then it won't work... On release you can do stop... I'll do some tests. Edit: Repeat from number 2... So it starts on number 2 when it loops... On release, stop loops... On next stage, the same logic but different timing for the wait between loop... That should allow you to set up differing presses of w to be faster and faster until you hold it down, until you exist that range of press strength. I'll take a screenshot of an example, like the one above. By doing some tests - it doesn't matter if you are nesting them, or not. If you stop loops, it will stop a future loop ( bug ) before it has started. So that's an issue I will report. This bind will actually take a lot of work because of the lack of functions, being able to bind pressure to pressing a key repeatedly, binding that then to a curve... etc... And, the fact that as you release the key, you have to duplicate the x% range... If you did this for every 1 percent, it would be hell, so I'll make one with 10, 25, 50, 75, and a 90% hold. You'll get a vibration per change so you know going up / down. The wait, you'll have to adjust in 2 places per ( the x% segment which is not the stop all loops version... The one which has pres > Stop all loops - you'll edit the Release > for the % before it, ie 25%... I'll post it later today. This would be so much easier in AutoHotkey, or any scripting or programming language - I added some suggestions to help fix this such as functions, copy / paste, and more.
  24. You could also bind it so when you hold any button, you can scroll using mouse movement. If you exceed x amount, it could use page up / down instead. Or use the button as a shift for the scroll-wheel... Ie holding it uses page up / down for scroll-wheel... And, the movement of the mouse scrolls up / down / left / right based on movement speed.
  25. Having Linux drivers, and some UI to configure the mouse, would be very appreciated.
  26. I hope this feature can be implemented too. If this feature is implemented, I can do a lot of great setups.
  27. Hi @Bryce! Thanks for the response and I'm sorry for taking so long to respond myself, and dragging this out further but I would like to take the chance to make the argument in favor of Open Sourcing the firmware which seems to be where the IP issues would come in. It seems it's been requested but not a lot of people have explained what it would be or why they want it. I think to start with I'll explain my understanding. It seem that it'd be fine to give us the protocol if it didn't expose information about the firmware, which would expose sensitive IP. I'm biased towards Free Software so maybe this is me assuming what I'd like but seems to me it would be a big deal to open source the Driver if it didn't have information about the USB protocol. Even though it took a lot of time and resources to make no one paid for the driver, it's unlikely to move to a subscription model, more people having the driver than bought the mouse isn't a problem and assuming you open sourced it with the GPL License (my preference were I choosing) anyone who forks it would be required to provide the source, including modifications to customers when requested so you'd be able to get the modifications and improvements other companies or the community make to the driver. So it doesn't cost anything and there might even be room for gains. I'd argue the same is true for open sourcing the firmware. To start with I think that anyone who could gain enough information to cause IP issues from the USB protocol could probably dump the firmware or monitor the USB hub and reverse the protocol. Even if they did get info about the protocol, or the firmware itself and ripped a mouse open to reproduce the hardware too, I imagine it'd take quite a long time and resources to design, fabricate, assemble market and ship a product even after all that something with a feature set identical or substantially similar to the Swiftpoint Z seems like it would stand out. I don't know too much about hardware IP but I also imagine there's a number of patent and economic protections to stop people directly or too closely ripping off existing products. That being said if you GPL License the firmware it may seem like you're practically asking people to rip off your design. That could be a worry but the firmware is probably fairly specific to the hardware, and they still need to design, build, market and ship that hardware. Chances are that they'll have to abstract away the hardware or modify it to use their specific hardware. So they saved some time and resources in the development but they're required in the terms of the GPL to release the changes to customers on request. So you can take advantage of those changes (hopefully improvements) and reduce your development burden in the future. That being said the majority of the time when stuff like this is opened it just make a bunch of enthusiasts on the internet happy because they can change their mouse firmware and know it'll still work even if swiftpoint drops support at some point. All that being said to argue there's probably no downside and potentially an upside, I'd personally like the firmware open sourced so that I can write my own linux client and program my own macros or make my own image to display on the screen or my own color patterns, maybe use the color to tell me if I have waiting email who knows. All things that I would release back were it open sourced and also might not be a priority for swiftpoint devs. I'm definitely on the side of open sourcing all the things but it seemed people asked for open drivers but didn't really make the case for it. There's a bunch of different licenses with different rules about copying, integration and special commercial clauses too. It might seem weird to give away something a lot of time and resources were spent on but I think it's worth pointing out that you're already giving it away for free, anyone can download the driver and the firmware, it just doesn't benefit them without the mouse. Throwing the source up on github doesn't benefit anyone who doesn't have a compatible mouse, and if they did have one, you give the software away on your website anyway. Anywho thanks for reading I appreciate it and I really like the Z and the improvements to the driver have been great.
  1. Load more activity
×
×
  • Create New...