Jump to content

Running multiple clients simultaneously (multiboxing)


Recommended Posts

  • 2 years later...

Hi i am new to this little program but loving it and yes i see that this thread is old so bumping it?  Just a thought would one be able to add password box to this ? 

Would that be hard to do or not really?

Link to comment
Share on other sites

Hi, glad you like it.

I wrote this without much interaction with the game client, meaning I do manipulate the position of the window, but that's about it.

Doing login/password is most likely possible, but I never planned/intended for that to be added.
That being said, I made the source code of this freely available on github, so anyone is free to fork and alter it.

Link to comment
Share on other sites

if i knew how to add the password box that would be so helpful to us that use multiboxes for this game..but great work on it Huron.  Wonder if we could work together to figure it out perhaps?  I am not a computer programmer but i have a nephew that might be able to help if needed.  I see something on EnB gearlist site that has the review idea for it not sure u were involved with that though??

Link to comment
Share on other sites

Hi Teddy, I'm not actively playing EnB atm and I am swamped with other projects/hobbies, so I don't have any plans to work on anything atm.

I had not seen the EnB gearlist site yet, so I looked at it, seems they have a tool similar to this, but including login/password indeed, perhaps you can use their tool instead of mine? Since it already has it.

I have never been involved with anything else but this tool in this thread, so no affiliation with EnB gearlist or any other site for that matter.

Link to comment
Share on other sites

As has been mentioned earlier in this thread, the "unlocker" functionality of the unlocker is no longer required:

 

https://forum.enb-emulator.com/index.php?/topic/8349-running-multiple-clients-simultaneously-multiboxing/&do=findComment&comment=98815

 

As a result this tool is now exclusively used for launching and positioning clients.

 

@TeddyZ77 as another alternative for that you might want to take a look at the AutoHotKey scripts from @wolfie and more recently @Doctor in this thread:

https://forum.enb-emulator.com/index.php?/topic/12050-ahk-and-multiboxing/

 

I also created a more generic AutoHotKey v2 version of the login portion of Doctor's script to replace the awful bash script using xdotool that I had been using on Linux as it was extremely flaky.  I posted the new AHKv2 login.ahk to GitHub here if you are interested:

 

https://github.com/ciphersimian/enb-ahk/blob/master/login.ahk

 

This might be an easier option for what you're wanting to do than trying to wrangle Visual Studio, get a C# project working, and then modify it.  :)

Link to comment
Share on other sites

Thanks for your response and your help to Teddy  @Codemonkeyx 
Very helpful to know someone created AHK for the login part, should come in handy for Teddy for sure.

And you are right, this tool is now only used for positioning since the unblock seems to be no longer needed.

Technically I still don't understand why it's not needed anymore, as I don't understand how the change for the port in the launcher could solve the already running error. But as long as it's working it's fine for me :D

Speaking of that C# project, I'm not even sure what the code was like for this, I know I slapped it together in very little time and it was some years ago, so I will probably be disgusted by what I wrote myself haha ;) 

Link to comment
Share on other sites

Well @Huron apparently your instincts were good... oh the irony.  I've literally never seen this error before (and I've been playing pretty consistently since September) and now mere days after pointing out @Zackman's post and declaring confidently incorrectly that the "unlocker" portion of the unlocker is no longer required, I get this today:

image.png.9456c4aee34ce576f389a8a41819488d.png

That is very strange indeed.

 

I changed over from using my tried and, well, not true, but serviceable bash script to the AHK script I posted and somehow that difference in launching things seems to be responsible.

 

One possibility is that launching everything from the Run function in AHK results in the processes somehow being associated with one another whereas launching them from the bash script did not.  In my environment that is the difference between launching them all from an application already running under wine (AHK) to launching them separately but all inside the same wine prefix. They all end up using the same wineserver instance either way (which is what I would think would matter for something like a mutex as you described that is across processes).

 

Another possibility is that this somehow depends on the Window's WM_CLASS or classname.  One of the other things that changed between what I was doing before and what I'm doing now is that I'm starting all the processes up first, then going through and changing all their names rather than doing it as I go. I have to do this twice on Linux, once internally to change the WM_NAME that applications that think they're running under Windows are using to identify one another, and again to change a "leader" process that is used by wine to make processes running under wine show up on the taskbar, etc. which requires changing the WM_CLASS (which normally never changes under Windows) because for some reason wine chose that as the value to display on the taskbar rather than WM_NAME (??? probably a bug).

 

Anyway, I just wanted to offer a mea culpa and say that there is clearly more to the story of exactly how this works and when it manifests vs. when it doesn't.

Link to comment
Share on other sites

I've been trying to figure out what happened here and I think part of it is that I don't normally run the Launcher, I've just been launching net7proxy.exe directly and passing it the right params.

 

Somehow when that is done quickly enough and all of the clients are running from the same install directory, it results in that error about half the time.

 

If you either:

  1. Use LaunchNet7.exe
  2. Run each client from a separate install directory

it doesn't seem to have that problem.  I can't reproduce the issue in the AHK script I uploaded because it uses LaunchNet7.exe.  I also can't reproduce the issue after getting all of my clients using their own install directories again (which I was doing before with my bash script, but hadn't setup in AHK yet).

 

So perhaps there is something important about the LaunchNet7.exe launching of net7proxy.exe that was part of solving this?

Link to comment
Share on other sites

Hyea @Codemonkeyx thank you for your replies. I'm not sure what was implemented exactly in LaunchNet7 vs Net7Proxy, but I can tell you exactly what the mechanism is that is in the original enb client executable.

 

They make use of a so called mutex lock, you can read more about it here: https://en.wikipedia.org/wiki/Lock_(computer_science)

 

So basically you come up with a name, you use that name as a lock, next time a process tries to lock based on that same name, it will already exist and that's how they knew we were running multiple clients at the same time.

This also means that WM_CLASS name or WM_NAME don't matter.

 

What the unlocker feature of my tool does is Duplicate the lock with a special option that closes the source lock.

Which means now my tool is the "owner" of the lock, but my tool spanwed a new process to do this with. 

And then my new process lets itself die, taking the lock with it.

 

Admitted, not a graceful solution, but it does work like a charm.

 

The mutex name they came up with was: Mutant

Link to comment
Share on other sites

Oh I see you mentioned mutex in your post as well. I definitely need more coffee as I just woke up ;)

I think the difference in how you started them might have caused a change in how fast they are all started. Perhaps that has something to do with it, maybe if the processes are spawned fast enough, they don't get bothered by the mutex lock (yet) or something. I'm not sure.

Link to comment
Share on other sites

Yeah, I know all about semaphores and mutexes but typically those are for synchronizing threads, not processes.  There are IPC mechanisms like shared memory where you can allocate these things on *nix and I'm sure windows has its own version of them, but a mutex that is system-wide based on name only is a pretty weird thing (what if some other unrelated process happens to choose the same name? bad things©®™).

 

I didn't look too deeply at your code but thought they may have done something smarter like incorporate WM_CLASS into it to hedge against that.  Maybe the underlying API they're calling does that?  Or perhaps it's actually implemented with a file lock and the CWD is relevant which would explain why pointing them at different directories helps (but not why LaunchNet7.exe does unless one of the things it does is launch each client in a separate CWD or remove such a file lock after launching it?)

 

Anyway, still a bit of a mystery here!

Link to comment
Share on other sites

Thanks @karu, that definitely explains some things, may I suggest UuidCreateSequential() instead of GetTickCount()?  :D

 

I guess my bash script takes a little longer due to launching everything through wine start each time and the AHK script I published takes a little longer due to running the launcher and checking for updates, etc.  It wasn't until I started launching the net7proxy.exe directly from inside the wine prefix that things were fast enough to cause an issue.

Link to comment
Share on other sites

11 hours ago, Huron said:

The mutex name they came up with was: Mutant

 

I was curious about this seemingly odd choice and wondered if they just copied some example code and foolishly didn't change the name, etc.

 

That may well be what happened but I also learned some NT and OS/2 kernel history I didn't know:


 

Quote

The name mutant has a colorful history. Early in Windows NT's development, Dave Cutler created a kernel mutex object that implemented low-level mutual exclusion. Later he discovered that OS/2 required a version of the mutual exclusion semaphore with additional semantics, which Dave considered "brain-damaged" and which was incompatible with the original object. (Specifically, a thread could abandon the object and leave it inaccessible.) So he created an OS/2 version of the mutex and gave it the name mutant. Later Dave modified the mutant object to remove the OS/2 semantics, allowing the Win32 subsystem to use the object. The Win32 API calls the modified object mutex, but the native services retain the name mutant.

 

Edited by Codemonkeyx
removed dead link (I had copied from a search result and hadn't checked the link)
Link to comment
Share on other sites

Excellent find, I never looked into the origins of it, but that explains a lot. 

Cool read, thanks for sharing.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...