You are not logged in.
I have a few questions regarding cd keys and playing on a ‘internet’ server from the same network. I have asked similar questions before but now have a bit more information and need clarification. Me and my family have played BF1942 for years. We have almost always played via LAN and so cd keys have never been an issue but we have also played many times in the past together on the same online server from within the same household (same network). Three of us used to play at once with no issues. To do this we each had our own legitimate copy of the game (own cd-key) as online servers would not allow duplicate cdkeys to play at the same time; you would get a ‘cdkey in use’ message when trying to join. Now when we play we set up passworded an internet server as not all of us are in the same house anymore (not all on the same network). I know we could use a VPN service like Hamachi to play but I want to try and get the ‘internet’ server working so that we could also open it up to the public if we wished.
The problem we are now having is that when we all try to join this internet server I am hosting, those within the same household (same network) are getting a ‘cdkey in use’ error. What is even stranger is that when playing the original maps it sometimes works (we all get in). It never works for RTR or SW expansions however.
I am hosting using the cracked dedicated server files. From my previous questions my understanding is that this server does not check that a cdkey is legitimate (not possible anymore) but it will still check for duplicates. This is easily solved; just each have our own cdkey. My understanding here is that the key does not need to be valid, just not collide with anyone else playing on the server. I ensured we each had a unique key but the problem persists when I host the server. I can only assume at this point that this is not a cdkey issue but rather an issue when two people within the same network try and join the ‘internet’ server.
The exact setup is this:
I host a dedicated server at home, all port forwarded correctly. Two of us within this same network then try and join the server. One of us gets in, the other will get a ‘cdkey in use’ message. Two other people joining from their own networks get in without issue. Other random online players are also able to join. We all have our own cdkeys set which I confirmed during one of those times we were all able to get in; our cdkey hashes were all different!
Can anyone confirm/explain what is happening here and even better does anyone have a solution?
Thanks
Last edited by fatfewl (2018-08-06 11:55:14)
If you are getting an error like that then it would appear that you have not changed the key correctly. Have a look at the connected players using BFRM and see if the keys are in fact duplicated.
I have done just this and the key hashes are different for each player. I will post the screenshot I took when I get home.
Are the same keys used for Bf1942 and its expansions. My understanding was that while RTR and SW have different keys, online the bf1942 key is only used?
I too would suspect that the Battlefield 1942 CD key information just isn't set uniquely across the machines. If you seem to have the expected key information saved under [HKEY_LOCAL_MACHINE] on these machines, maybe check whether you see different information under a corresponding subkey path in [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node] for 64-bit Windows, or simply under [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE] for 32-bit Windows.
This is where Windows would redirect an application that isn't running as "elevated" (Run as Administrator) and tries to write and subsequently read information from [HKEY_LOCAL_MACHINE]. i.e. If BF1942.EXE isn't running with the "Windows XP SP3" compatibility and "Run as Administrator" turned on for the game (or wasn't always running that way), maybe there is some different or "blank" information stored in here under the [HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942\ergc] subkey path which makes the running game read a different key that what you otherwise see under [HKEY_LOCAL_MACHINE].
I'm also unclear how one would be successful at "checking in Battlefield Server Manager that the key hashes shown are unique", if the players become kicked when a duplicate key is detected. I expect to see BFServerManager / BFRemoteManager log entries confirming why they were kicked when the duplicates WERE present, but what exactly are you seeing to confirm that they're NOT duplicates? Ostensibly, if you're in a scenario where you can see in Battlefield Server Manager that they're not duplicates, they're also not being kicked as duplicate.
Something about crashing comes to mind too. Like when someone had crashed and re-joined, the game would reconnect with a blank key hash instead of their original key hash. Which on its own wasn't an issue, except when we had another player who was intentionally playing with the blank key hash, and then the crashed user reconnecting ("playername_11", etc.) collided with the already-existing blank key hash player. Maybe two of your family's players both crashed and re-joined? Do either one have the "_xx" suffix on their player name when the log says they were kicked for duplicate CD keys?
Oh, I just realized maybe what I'm recalling wouldn't apply, because in my case it's actually Punkbuster kicking for "Duplicate GUID/CDKEY". I'm guessing you're probably not running Punkbuster for this server, and I can't really comment from experience on what the behavior would be from the Battlefield 1942 game itself regarding duplicate CD keys.
EDIT: An English.
Last edited by Trench (2018-08-06 21:04:54)
As a side note, in lan game mode the server doesnt announce its precense, but you can still join a lan game directly over internet if you wish. Just connect to the host IP and the right port number manually.
Oh and you still need to have the game port open (usually 14567) in the router.
edit: spelling.
Last edited by bud (2018-08-07 01:39:00)
txt
seems there is a bit of difference in between the linux and windows server files, depending a bit who made the changes back when the origin version was released.
There is tools for changing the RtR and SWII keys, but i havent tried them myself so cant say if they are any good.
If you have "Map Not Found" error message upon trying to join either RTR or SWII servers/maps - And you have the maps - then it means you don't have an active CD Key either for RTR or SWII respectively
Thanks Bud. Just like the non-Punkbuster server environment, I really skated right past the whole RTR and SW mod involvement too, which is something I don't have any experience with either. I wouldn't know if those mods actually perform their own game server connection CD key checks or not. (Versus maybe RTR and SW just being an installation time CD key ask; but for online play they just depend on / can only depend on the Battlefield 1942 game CD key and not some additional mod-specific game key.)
If those mods store their keys in the registry, the whole registry redirection discussion still applies; but perhaps with additional subkeys and values that are specific to the RTR and SW mods.
Ok thanks for the replies all. I hope that it is a case where I have not set the CD keys correctly. It makes the most sense and it also means I should be able to fix this.
I have done some more investigation and it seems that incorrectly set unique keys is the issue but I do have some very strange behaviour. When I am joining the server separately from the respective machines in the local network I can see that the key hash is the same. What is strange is that sometimes it changes (it cycles between two keys for my machines) which is why I have the situation I can sometimes manage to get on. The two key hashes are d41d8cd98f00b204e9800998ecf8427e and 38a26cf6f9d2d63fe46961581bd18cf3. Why they are not constant I am not sure but I have spotted a pattern where the key is d41d8cd98f00b204e9800998ecf8427e when first starting the game and joining the server. Upon map change the key changes to 38a26cf6f9d2d63fe46961581bd18cf3. I can't explain this.
I am on windows 10, having set the game to run as admin and set comparability mode for XP SP3. My CD key is set HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942\ergc
Ok I have fixed my issue. Key was in the wrong place. It needs to be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA Games\Battlefield 1942\ergc
To find the correct place I installed a legit copy of the game...I can now play with the portable copy of the game and I keep a .reg so I can easy insert a new key directly into the database on new machines, permissions permitting.
However this does not explain the strange behaviour I had before. Why could we play sometimes and other times not. At one time THREE of us with no cdkey set were playing on the server!
Last edited by fatfewl (2018-08-08 00:06:15)
Does the key change when you use a different mod i.e. RTR and then change to SW?
That is not the correct location for the keys to be stored the should be in:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942\ergc
or
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942 Secret Weapons of WWII\ergc
or
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Electronic Arts\EA GAMES\Battlefield 1942 The Road to Rome\ergc
and I can confirm that all of the keys are different.
Does the key change when you use a different mod i.e. RTR and then change to SW?
No the mod seems to make no difference but I do have different keys set for each in the registry (done while installing the game and its xpacks). I have tested just now on my server by changing the maps from standard to RTR, SW and back again.
Edit: I think you were writing your reply (BB)DinkW just as I was writing mine having discovered what you were about to tell me! I can confirm your locations are the same as mine.
Last edited by fatfewl (2018-08-08 00:19:41)
The two key hashes are d41d8cd98f00b204e9800998ecf8427e and 38a26cf6f9d2d63fe46961581bd18cf3.
The first key hash is what you should see when you don't have the CD key set in the correct location, or if you simply set a blank string as the key in the correct location. It's the MD5 hash of a blank/empty string.
That's the same hash I expect to see when a player crashed & reconnected, as described earlier. e.g. When they also had the "_xx" suffix added to their name because their old player was still connected too and hadn't timed out.
Don't know what the second one is, and would have to assume it's the hash of an actual key. Google says a player with that key hash was on BWT-Badewiese in 2015; if that's you, then maybe that confirms its the hash of one of your actual keys.
Try changing the key hash for one or both of the machines and see what happens?
Try changing the key hash for one or both of the machines and see what happens?
I have done but still don't know where 38a26cf6f9d2d63fe46961581bd18cf3 comes from. The other hash is the MD5 sum of NULL as previously stated. I still do not understand what was happening originally with seeing both those keys and sometimes being able to play together and other times not.
Don't know what the second one is, and would have to assume it's the hash of an actual key. Google says a player with that key hash was on BWT-Badewiese in 2015; if that's you, then maybe that confirms its the hash of one of your actual keys.
That was not me but I am not surprised to hear another player has this key set. I was able to get it on my 3 machines at home following my method described above.
Anyhow thanks to the help I have now fixed the problem and have just finished testing. I have had 3 machines on my network (all with their own key now set) all connected at once to my internet server. I have also tested it on original, SW and RTR maps and all works perfectly. The same key is used for all xpacks.
So that's it. Problem fixed although if anyone has any ideas about what caused the original confusion I am very interested.
Last edited by fatfewl (2018-08-08 20:34:53)