As far as I see, there's just a single thread locking and unlocking for 5 seconds. Search for the word ''timeout'' to find the timeout message buried among the locks/unlocks.
I've spent hours compiling old commits and all of them are failing in the same way. I've tried some of the commits from late april and early may, about what the files are dated from the Gary 1 release, and yet they still aren't working. Do you have any suggestions on an old version I should try to build to see if that works for me?
So it could certainly be a problem with my build environment, which would be weird, but obviously not impossible. Aside from CodeBlocks and MinGW, which I'm fairly certain I both have the correct versions of (after you pointed me to the correct versions, that is) and am using correctly, I grabbed the boost.org libraries that VaultServer is dependent on, got the correct iniparser commit, and CodeBlocks has been having no problem compiling and linking the projects without me having to change any build settings (or any code or other settings for that matter), so I'm sort've at a loss as to where my build environment could be wrong at this point.
Could you upload just the minimal executables necessary for me to test ones you've compiled? Namely, vaultmaster.exe, vaultserver.exe, vaultmp.dll, vaultmp.exe, and vaultgui.dll (unless you comment out the chat code)? If it's a problem on my end, I'd prefer to not waste any more of your time while I get things sorted out, but if the binaries you build also cause me trouble, then it'd likely be worth pursuing further.
I've been looking at your uploaded log file and I'm very confused to say the least. Not a single game function call returns to the application, and the locking is weird too. There should be locking of the other object (005C73D8) too, but there is none (which is actually impossible as thread 6 can't lock 005C73C8 without having locked 005C73D8 first).
Attached are binaries I compiled (latest commit). Really interested if they will make a difference. They work fine for me.
The binaries you uploaded work for me. Also, I can rebuild any of the files EXCEPT vaultmp.exe and still have everything work, so my vaultmp.dll, vaultmaster.exe, and vaultserver.exe are all working (well enough to not show problems).
That said, my binaries are also about 10% larger in file size than yours. I haven't been changing any compiler settings set in the project files; I download the source, open the project in CodeBlocks, and Build. For the server and client, I change them to the Release build before compiling, but that's it.
In CodeBlocks, do you have any global compiler settings changed away from default? For me, everything is unchecked, ''Other options'' is empty, I have no global defines set, no additional linker settings; it's all default.
g++.png
Not quite the same build. I'd grabbed the release build of 4.7.0 (which was the newest). Looking at the list of MinGW downloads, I don't see one that's obviously 20120311.
XP 32-bit on the computer I've been messing around with VaultMP; none of my home computers run a 64-bit version of Windows.
Edit - I misunderstood what you linked; the w64 in the file name made me think it was 64-bit executables. Anyway, downloaded it, set it up, now recompiling and I'll let you know how it turns out.
EDIT:
OK, ruben's 4.7.1 build doesn't support std::thread. I tried nixmans 4.7.1 but it has the same problem you had. So we'll have to stick to 4.7.0-3 / old by ruben until I found a working build.
EDIT2:
Tracked the problem down to the use of https://github.com/Foxtacles/vaultmp...ection.cpp#L41
which in nixmann's build seems to immediately return false. I changed that to a simple lock() call, which apparently works.
Posting Permissions
