Running multiple clients simultaneously (multiboxing)

[Huron]

You're welcome, glad it worked!

[TeddyZ77]

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?

[Huron]

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.

[TeddyZ77]

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??

[Huron]

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.

[Codemonkeyx]

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. 

[Huron]

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

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  

[Codemonkeyx]

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:

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.

[Codemonkeyx]

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?

[Huron]

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

[Huron]

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.

[Codemonkeyx]

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!

[karu [WDL]]

@Huron, @Codemonkeyx

net7proxy overwrites enb mutex name with value from GetTickCount() before client.exe process is resumed (its launched/created in suspended mode). So ~16ms delay between launching multiple proxy instances should fix client mutex issues.

[Huron]

@karu Wonderful information, thank you for sharing that. Makes total sense to me.

[Codemonkeyx]

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

 

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.

[Codemonkeyx]

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 February 12, 2024 by Codemonkeyx
removed dead link (I had copied from a search result and hadn't checked the link)

[Huron]

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

Cool read, thanks for sharing.

[Freakshow]

Well the error i get is

 

[Codemonkeyx]

5 hours ago, Freakshow said:

Well the error i get is

 

 

Can you provide a link to the AHK script you're trying to use?  This doesn't appear to be the one I posted (login.ahk, where line 54 is a blank line) but perhaps you renamed and substantially modified it?  Please be careful not to post a version with your password in it!

[Freakshow]

Got it resolved used the launcheb.ahk script form Wolfie post

[Codemonkeyx]

@Huron it seems your links are dead again, e.g.:

 

http://www.rmkrs.nl/download/Net7MultiClientUnlocker.zip

Any chance you could just upload the latest release to the github as a release and post that link?

[Huron]

Heya @Codemonkeyx of course I can re-host them elsewhere as well.

But for me the download link is working, the files are on my webserver. And my website monitoring tools report no problems.

 

So I wonder why the links would appear dead to you.

[Codemonkeyx]

It's funny because I was thinking the same thing, but it was because my browser was caching the downloads.  When I tried to download via wget, it failed.  Sir Tikon on discord shared a screenshot from CloudFlare showing the site is having issues:

[Huron]

I don't know what to say. Just tried down for anyone or just me and you are absolutely correct...
None of my monitoring picked this up so that's even worse.

Going to see what's going on, thanks for reporting it.

[Huron]

@Codemonkeyx Well that's embarrassing 😅
I beefed up security on my firewall rules a while ago (some months) and in doing so I was actively denying traffic from cloudlfare coming in 🤣

The million dollar question is, what is a better monitoring platform for automatic monitoring of my sites that -does- report issues to me. Because it seems the one I have now was also using some cached version for some reason.

 

So while I search for a replacement, meanwhile the site should be reachable again. Sorry for the interruption.
Could you verify and let me know if it's ok for you as well now? Thanks!