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

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)

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.

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.

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.

That video link doesn't work either .

Make sure you have your setting for Public view .

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.

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.

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.

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.