Various mouse issues with certain programs.

Hello,

I have forwarded your report to the Stardock support team for their review and recommendations.

Please keep an eye on this thread for any updates.

We really do appreciate your feedback, thanks.

AzDude
Stardock Community Assistant

Hello,

Sorry to hear you are having trouble.

You have a lot here, and some of it not clear (not on your part, just hard to imagine).  The 2 things I want to address is:

Purge and reinstalling on each PC:
Burning it, rebooting, reinstalling, solves so many things, especially if you say you are still on 

Pressure on pen:
Make sure the software for any devices, even if they dont exist on each PCs, is installed (and configured the exact same) on each PC.

Wireless vs Wired:
If at all possible, even to test, use ethernet for all connections.

----------------
Sean Drohan
Stardock Customer Service Manager

Hi, sdRohan.  Thanks for the quick response.

Ya, sorry, I always forget to mention I am not using any WIFI... It's all hard-wired via Ethernet cables.

I guess I can try reinstalling, but as I said, it's working great for 80%(?) of the software... and even within those 'problem' software, the mouse is working in most aspects.

For example, most of my games (on a secondary) are working just fine... including ones that have situations (ex. camera orbiting via mouse movement) similar to those having issues in other games.

That's the weird thing...  it's only happening in certain programs, and only certain parts of those programs.  The mouse (for example) will behave fine moving the in-game mouse pointer... clicking on menu items, etc... yet something like the camera orbiting (for example) may not work... and even the behavior is different between the troubled software...  In some, the mouse movement does nothing (ex. Humans Fall Flat, where it should rotate the character)...  In others, it seems to battle a tendency to snap back to the center (ex. Rebel Galaxy)... In others, the pointer movement is exponentially excellerated (and seems to be unable to notice drag direction changes, continuing to move the initial direction, despite the mouse drag direction changing)...(Modo)..... and then some games are a real mess (Star Wars Battlefront 2), where the mouse movement is extremely 'accelerated', causing the pointer to move really far with small mouse moves ( plus having TWO pointers on screen!).  In that last case, it's like you have the 'game' pointer, as well as the 'Windows' pointer simultaneously....  I wanted to try adjusting some things in the game Options, but couldn't click the Options button, as the pointer would fire across the screen as I did tiny mouse moves!

I would normally think it's some mouse setting issue (in Windows), or Multiplicity not functioning properly... yet it is working fine in MOST of the programs, so it's not a global issue.

It's like there's something specific to the coding of the mouse reading in those particular programs (and SECTIONS of the programs) that is different (and incompatible) with Multiplicity... although I can't even guess what it would be.. especially considering similar games (and similar mouse tasks within those games) are working great (...ex. Saints Row 2's camera orbits just fine, via the mouse...as do all(?) of my other 3rd person open world games... yet Humans Fall Flat doesn't).

It's not the games/software itself, as they DO still work fine with a directly connected mouse.

FURTHER INFO: I just did another test in Modo, and I verified that the behavior definitely seems exponential... (If I move the mouse the same speed along the desktop, the resulting movement (ex. moving an object in the 3D viewport) moves increasingly more (accelerating).  Also, if I move the mouse up, then down, then left, then right, the resulting screen 'movement' DOES eventually move in each direction... but it's like there is a delay before it does so... almost like the object is attached to the mouse by an elastic band.  A very 'slippery' feeling, when manipulating things, like everything is on ice.  Very much like the object has mass, and accelerates to each direction, slows, and then accelerates to the next direction).  It would seem almost like some sort of network delay (aside from the acceleration), yet the mouse POINTER (when not manipulating an object) works just fine (doesn't accelerate or have any delay).  Oddly enough, even manipulating the numeric 'sliders' for the object translation ALSO have this weird 'kinetic' behavior, but all others do not.

I've written a similar post in the Modo forums, hoping they might be able to shed some light on how the mouse-reading within the 3D windows might be different (to Multiplicity) than the rest of the interface (which works great with Multiplicity).

Regarding the pen tablet pressure...  So, are you saying that Multiplicity SHOULD (technically) be transmitting the drawing tablet pressure?  (By that, I mean that it IS capable of doing that)

Lando,

I can can appreciate all that you are saying here in your lengthy and detailed examples for games, apps, and situations.  That said, it is harder for me to follow them as perhaps I should be able to (you are very thorough). 

If that fails, and reboots of your networking equipment does not help, perhaps you could supply a video of just 1 example and then we can move on to others?

What I can say (and I am on Ethernet too and typing this on my Seamless (not KVM) Secondary), if either PC is under heavy load, MP can suffer (odd mouse movements are what are mostly seen).  If you are doing a lot of things that tax either PC, MP very well may suffer some odd behavior - even more so if most of what you do is via KVM and not Seamless.

Again, if the reinstall fails, and your networking equipment is recycled, if you could make a video of just one of the things, we can start there.

Thanks for the feedback

----------------
Sean Drohan
Stardock Customer Service Manager

Hi, ya, I can appreciate how confusing this can be to follow... especially since there's different behavior in each software.

I was just playing around in Modo, seeing if I can find something more specific in the behavior.  I also tried to see if there's anything I could capture on video, but again, without seeing the physical mouse movement, you don't see the discrepency between the mouse vs the pointer.

But, I may be able to remedy that my 'narrating' the video, so you know what the mouse is doing at the time.

I don't think it's a CPU load, as both machines are sitting pretty much idle, aside from Modo running.

One thing I did notice this time around...

I grabbed an object, and carefully moved the mouse (repeatedly) left and right, left and right... which should cause the object to follow along, also moving left and right.

What I witness, is instead of moving left, right, left, right, left right... what it will do is... left, left, left, left, left, then finally right.  The sync between the mouse drags vs the object moves is great (instant response, no delays).  The 'delay' appears to be in when the drag direction is 'noticed'...  So, the first few 'right' drags move left instead... but then (after a random number of drags drags) it recognizes the new direction, and the next drag is going the right way (again, totally in sync)... and (continuing the left/right mouse drags), the object will continue it's moves (in sync), but again moving in the new direction, until a random number of drags later, it recognizes the direction change, and does the next drag in the right direction.  So, the 'stuck in one direction' thing is an ongoing issue, not just once.

Again, it's like the MOVEMENT is totally in sync, but the direction change 'signal' has a delay... or is only transmitted on random drags.

I tried with a different mouse, as the mouse I'm using is one that has things like DPI settings, etc... which I thought might be interfering (and maybe causing the weird 'exponential movement' thing... but my other mouse (which is more simple) did the same thing.  I'll dig up a very simple mouse next, and see if that has the same behavior.  I should also see if my tablet does the same thing (going though Mutiplicity, rather than directly connected to the Secondary, as it is now).

I'll see what I can do as far as creating a screen recording.  I'll have to do some editing to it, and add a sync'd text 'narration', so you know what is going on.

So, for now, the summary (for Modo, at least), is:

-Multiplicity works perfect in Modo for everything except translation/creation (dragging to 'build') of objects.  The mouse works perfect as far as interacting with the rest of the interface.

-Dragging an object/item in the 3D view results in movement that accelerates, rather than staying at a constant move rate.

-Even though the mouse vs object movement sync seems perfect (no delay), it seems like the recognition of a change of mouse drag direction only occurs on random mouse direction changes (as opposed to all).

-No CPU strain.  This behavior happens consistantly, regardless of status inside and outside of Modo.

IMPORTANT CLUE:  It appears the issue is isolated specifically to mouse drags (mouse move WITH button pushed down).

I wanted to see if the issue was isolated to just the 3D windows, but it appears it is occuring in other parts of the interface (...it's just not apparent, as you don't usually DRAG in those areas).

One part of the interface has a text list (sort of like Photoshop layers... a vertical stack of items).  So, I grabbed one of those items (hold down mouse button), and moved the mouse up/down to change its vertical location in the list... and I found that it actually had a delay.

There were actually TWO 'copies' of the item visible... One that followed my mouse pointer perfectly (perfect sync, no delay), and a SECOND copy that followed it, as if attached by an elastic band... The faster the movement, the wider the discrepency between the location of the two copies.

So, we now know it is specific to dragging (button down mouse moves).

Everything else appears to be working great... perfect sync.

So, again, I'm trying to figure out what specifically is it about that which Multiplicity is having trouble with... or, reversely, what aspect of Multiplicities way of transmitting mouse drags is Modo having trouble with?

(At least this is something I can show you a video of, and doesn't require you to see the physical mouse, as the mouse pointer is actually visible in this task, as opposed to in the viewport, where it doesn't show up).

I'll make a video to show you next...

Multiplicity drag issue in Modo

Here's a video showing the 'mouse drag' issue that happens in Modo (but not other similar software) when using Multiplicity.

I am dragging a camera object with regular, repeating 'left, right, left, right' drags, with a brief pause in between.

I've included text indicating which direction I am dragging the mouse, as well as to show WHEN I am dragging the mouse, and when I'm pausing.

As you can see, the moves themselves are in sync with the mouse drags (and the regular non-drag moving around of the mouse pointer is fine).  But, when I drag the object, the first change in drag direction is not registered, and so on.

You can also see that the drag direction actually changes mid-drag in some cases.

Basically, the drags themselves are in sync, but the 'direction change signal' has a delay.... almost like the transmission of the DIRECTION is  going in slow motion, whereas the motion itself (when it stop and starts) is fine and in sync with the physical mouse.

There is also the issue of movement kind of 'accelerating', despite the moves being done at the same speed, but it's not really shown in this video.  It's kind of tough to illustrate it without seeing the physical mouse itself.

Please let me know if you have any questions, or would like me to try anything further.

The video shows unavailable, Ladlon....

Again, that is a response of over 1100 words (I don't mean to be flippant there, it's just very hard to follow it all landlon, especially with the video being unavailable).  Let me see if I can sum up what you are seeing and you tell me if I am right in a short response.

On your Primary, with its mouse cursor on the Secondary, you move the mouse but there is a delay or lag on the Secondary for it to register. Furthermore, you could quickly keep moving the mouse (say in circles), let the mouse go (let your hand off it) and the mouse would keep moving on the Secondary until it caught up with what movements you made with the Primary mouse?

Would that be accurate and sum up the problem (at least one of them)?

----------------
Sean Drohan
Stardock Customer Service Manager

Sorry that the video link doesn't seem to be working for you.  Works for me over here.  Standard YouTube thing.  Not sure what is wrong.  Is there an email address I could send it to?  I'll see if I can get a new link, as the video IS there.

No, your summary is actually wrong.  Sorry for the long posts, but there's a lot of info to cover, and a lot of important details that can't be missed.

Please refer again to the summary I made for Modo, in a previous post on this thread.

Basically (in Modo), Multiplicity is working perfect... except for mouse dragging.  With that, the actual MOTION of the thing being dragged is in sync with the mouse movement, but the CHANGE IN DIRECTION seems to have a delay.  The video shows it quite well, so I'm hoping we can somehow get that to you again.

In the video, I drag the mouse left, pause, then right, pause, then left, pause, etc.

The resulting on-screen motion has the pointer moving in sync with the mouse (no delay), but it doesn't recognize the direction change until a delayed time after... so, a 'left drag' can sometimes be a right drag (still thinking it's going right from the previous drag), with a change in direction mid-move.

I'll see what I can do about the video link.

https://youtu.be/i1sgoyOGBwA

Please see if this link works...

And again, this issue (with dragging) does not occur in other similiar apps (ex. After Effects, paint programs, etc).  So far, all my other 'work' software works fine with Multiplicity.  I have only noticed it (as far as non-games) in Modo.

There were different issues in SOME games, outlined in my earlier post.  The Rebel Galaxy issue MAY be something similar to the Modo drag issue.

That video link doesn't work either .

Make sure you have your setting for Public view .

I did some more tests, and here's what I found:

-Dragging a text item in Modo: Two copies of the item end up being displayed, one that tightly follows the mouse pointer, and a second copy that follows in a sort of 'attached by an elastic band' way.  It's hard to say if it overshoots the intended path (ex. in a circular move), or follows the mouse pointer's path exactly (but in a delayed way).  Both items seem to START movement at the same time, so it appears it's not so much a delay as it is the 2nd copy moving slower, so it ends its move later than the pointer.

-Dragging an 'object/item' in the 3D viewports behaves seemingly different, where the motion of the object is (seemingly exponentially) greater than the mouse movement... So, you move the mouse a little, and (often) the object will fire off the screen.  The video shows an additional issue, where even with left/right moves with a pause in between each, you get a delay in the change in direction (but seemingly not the actual motion).

-No other non-game app seems to have issues when used through Multiplicity.

-Some (minority) games show different mouse issues... Some recognize clicks, but not mouse movement (to change character's view/direction)... yet the mouse works perfectly fine in those same game's menu.  Again, the issue is not global across all programs (or Windows), and in some games, it works in one part, but (partially) not in others.  The simplest of these issues is in Humans Fall Flat, where the mouse works perfectly fine in the menus of the game, but in the gameplay itself, the mouse movement is not recognized, but mouse clicks are.  This is the only game I found where the mouse movement is not recognized (others have other issues).

Multiplicity mouse drag issue in Modo

Sorry...  I had set it to be not private, but YouTube seems to be a real rats nest as far as settings and navigation these days.  I changed the settings, and it SEEMS to work for me here, but please give it a try again.

The video is showing now , when you first upload a video there

the option to set to public is right there easy to find so look for it .

Yes, I know... I had set it properly, but for some reason, it appears it was set to private again.  I think there might have been a glitch.

ladlon, sorry to resurrect this post, but did you solve the issue with not being able to move your characters in game?   im having the exact same issue in kvm mode,  i can interact within the game menu but as soon as i try to control my toon, mouse clicks work but trying to look around ( by moving the mouse around ) does nothing.

if i just use the seamless mode, i can control my character ingame just fine.

Hello, @sarjunkie

I have forwarded your report to the Stardock support team for their review and recommendations.

Please keep an eye on this thread for any updates.

We really do appreciate your feedback, thanks.

If you enable this on the Secondary, does it then work?

If not, but you have a mouse plugged into the Secondary, does it then work?

Sean Drohan
Stardock Support Manager

the problem persists no matter what combination of fake pointer support and/or having a mouse plugged in.   the only difference having fake pointer support selected does is place a mouse cursor in the middle of the screen of the game that doesnt go away like its supposed to when playing in first person.