With the change to 64bit, multiplicity is completely screwed for me. If I click or use mouse look or mouse to drive on a secondary PC, it takes the same actions on the primary PC. I was hoping somebody had a fix for this or knows of a program that will still work in 64bit EQ. I’m on a truebox server and prefer to not have multiple sets of mice/keyboards. Thanks!
-
You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋
Problem - Multiplicity in 64bit EQ
- Thread starter prion42
- Start date
- Joined
- Dec 26, 2017
- RedCents
- 3,330¢
Are you a time traveler? Servers are still locked.
Not using it to key broadcast. i have keybinds setup to change controls of mouse/keyboard between the PCskey broadcasting to play multiple accounts on truebox servers is cheating! you gun get the bans!
it has always done that for me with input director. You can't have an active window on the host PC or the mouse commands go to both. Specifically scroll or right click.
I believe it will do that with any game you run its not just EQ. It does not happen with any other app like chrome etc Just ones that use directx.
I believe it will do that with any game you run its not just EQ. It does not happen with any other app like chrome etc Just ones that use directx.
Not to necro this thread, but it seems like the question as to why this happens was never really answered and the original poster is still active on here so I figured I'd shed some light as to what is actually happening.
When you're controlling other PCs with Multiplicity, whether seamlessly or not, your hardware is still processing those inputs on your primary machine. All Multiplicity does is block the callback on the hardware input and use something akin to the p/invoke ShowCursor to hide the mouse on your primary screen while sending the inputs over a TCP network to be processed on your other local machines.
For normal applications that don't use DirectX, this will work fine. But if your foreground window is a DirectX game that is utilizing DirectInput functionality, like EverQuest, mouse hardware inputs will still be processed due to how DirectInput handles hardware inputs independently of Window's own input handler.
I'm not sure if Multiplicity themselves have a programmatic solution to this as I haven't looked in to how to solve the issue, but this is more of a problem with DirectX, or more DirectInput, than it is Multiplicity. They could, theoretically, block callbacks specifically to DirectInput, but I have no idea what language Multiplicity is programmed in (probably C codebase in some regard) so whether or not this is possible for them, or if they even care enough to do so, I am unsure.
Either way, I hope this sheds some light on why this is happening exactly!
When you're controlling other PCs with Multiplicity, whether seamlessly or not, your hardware is still processing those inputs on your primary machine. All Multiplicity does is block the callback on the hardware input and use something akin to the p/invoke ShowCursor to hide the mouse on your primary screen while sending the inputs over a TCP network to be processed on your other local machines.
For normal applications that don't use DirectX, this will work fine. But if your foreground window is a DirectX game that is utilizing DirectInput functionality, like EverQuest, mouse hardware inputs will still be processed due to how DirectInput handles hardware inputs independently of Window's own input handler.
I'm not sure if Multiplicity themselves have a programmatic solution to this as I haven't looked in to how to solve the issue, but this is more of a problem with DirectX, or more DirectInput, than it is Multiplicity. They could, theoretically, block callbacks specifically to DirectInput, but I have no idea what language Multiplicity is programmed in (probably C codebase in some regard) so whether or not this is possible for them, or if they even care enough to do so, I am unsure.
Either way, I hope this sheds some light on why this is happening exactly!
Last edited:
whichjohnny4
New member
- Joined
- Jun 3, 2022
- RedCents
- 20¢
OK so the actual fix for this is documented in Stardock forums. https://forums.stardock.com/510351/page/1
You need to do a complete uninstall, reboot, (I think I even deleted registry entries) and install the patched version which they released for this.
Link is here: https://cdn.stardock.us/support/uploads/Multiplicity_3.57-j68-Setup.exe
Once its installed, it should show version 3.57 Build 00104.kvm
After that, reconnect everything and the mouse "echo to main screen" thing should be done. That is how I fixed it.
You need to do a complete uninstall, reboot, (I think I even deleted registry entries) and install the patched version which they released for this.
Link is here: https://cdn.stardock.us/support/uploads/Multiplicity_3.57-j68-Setup.exe
Once its installed, it should show version 3.57 Build 00104.kvm
After that, reconnect everything and the mouse "echo to main screen" thing should be done. That is how I fixed it.