Compiling From Source

[Queue]

So, I'm attempting to build VaultMP from source so that I can potentially take a stab at either helping, or at the very least so I can try stuff out as changes are committed rather than waiting for public builds to be released.

I snagged CodeBlocks and the MinGW 4 upgrade as per instructions at the old VaultMP google code site:
https://code.google.com/p/vaultmp/wiki/CompilingVaultMP

The first issue I ran into was I had to set _WIN32_WINNT=0x0501 in the global defines otherwise compiling choked in utils.cpp on GetFileSizeEx.

After that, I got vaultmp.dll to build, but the other parts of VaultMP (master server, server, client, etc.) run into a mess of errors.
'recursive_timed_mutex' does not name a type
is particularly common, but the errors in general seem to my naive eye to be related to syntax differences between c++0x and the older standards. The projects tend to have these settings set, yet it's still clobbering my ability to build the projects.

Queue

[foxtacles]

Hi,

sorry, the google code page is outdated :)

You need GCC 4.7 for compiling (C++11 features). You can pick it up for MinGW here: https://code.google.com/p/mingw-builds/downloads/list

[Queue]

Thanks! So I snagged the newer MinGW, which got vaultmaster compiling (and vaultmp.dll still compiles), I grabbed the boost.org libraries for vaultserver, but now I'm hitting errors with iniparser (during the final link), which I tried to get from here:
https://github.com/Foxtacles/iniparser
but which is giving me errors like:
undefined reference to `iniparser_load(char const*)'

Queue

[foxtacles]

Please initialize the iniparser submodule in the main vaultmp repository; it points to this commit: https://github.com/Foxtacles/iniparser/tree/ce75430a13cdb6efcae21b0568bfa6ce8d28c95c

That should fix the linker errors.

(https://www.kernel.org/pub/software/scm/git/docs/v1.5.6/git-submodule.html)

[Queue]

I'm not familiar enough with the git tools (at least yet) to have succeeded at using the git-submodule program. I can use git to download the main VaultMP repository, or the iniparser repository on its own, and I did put the iniparser files in the iniparser folder of the VaultMP source, and CodeBlocks is compiling the iniparser code into .o files, it just all fails during linking. My first guess is that function export names are getting mangled during compile; I just don't know CodeBlocks or the GNU compilers well enough to know what to fix.

Queue

[foxtacles]

Yep, it's because of name mangling. The git submodule points to a commit of a branch in my iniparser repository which exports the functions as C functions.

You can follow the GitHub link I had in my last post. It is the correct commit; download it as ZIP or git clone / checkout, that will work ;)

[Queue]

Success! I had messed up with which iniparser branch (or whatever they're called) I had put in the VaultMP source tree. Got it all working (well, short of vaultgui, but I don't want to mess with that yet).

Thank you for patiently working me through that.

Edit - D'oh, forgot I'd need vaultgui.dll to be able to try the new version.

Queue

[foxtacles]

For vaultgui, you'll need Microsoft Visual Studio Express 2010 (at least the MSVC compiler) and the DirectX SDK files.

However it should be no problem to change the meaning of:

https://github.com/Foxtacles/vaultmp/blob/master/source/vaultmpdll/vaultmp.cpp#L576

to not set DLLerror to true. Then, as long as you don't use server-side script functions to send chat messages, everything should still work fine.

[Queue]

That's actually the first thing I tried (commenting out the vaultgui.dll loading code), but I'm getting the following error when I try and run New Vegas (through VaultMP):
Could not enter CriticalSection object 0051E330, timeout of 5000ms reached (15CriticalSection)
and then New Vegas crashes after I click OK. I have no idea if this is due to other vaultgui.dll code that needs to be disabled, or if it's some other problem. I'm just starting to poke around the code in earnest.

VaultMP works (well, aside from known issues) if I use the Gary 1 binaries, for what that's worth.

Also, I think there might be a problem with Utils::FileOnly. When I synchronize with the server, it cuts off the first character of file names, so ''The Mod Configuration Menu.esp'' becomes ''he Mod Configuration Menu.esp'' and so on.

Edit - Yeah, I peeked inside the vaultgui suo file and saw it was VS2010. I'd prefer to avoid installing that, or I may set up a virtual machine just to host that so I don't pollute my pretty optimized Windows install with all the baggage VS2010 includes.

Queue

[foxtacles]

The CriticalSection error is (likely) due to me having introduced some nasty concurrency problem in one of my commits in the last 1-2 weeks. I believe I fixed it (it works fine for me), but you never know with this kind of error. Do you have the up-to-date sources from the repository?

I've been struggling with CriticalSection errors for long times. It's extremely hard to track down that bugs (mostly, deadlocks => lock timeouts)

Yep, Utils::FileOnly has that bug. I always forget to fix it :D Thanks.

Oh, and I also have to mention that there is a bug with the EquipItem function in New Vegas.
https://github.com/Foxtacles/vaultmp/issues/56

So if you are using the default vaultscript, which equips the PipBoy on startup, the game might just silently "close" itself. That's the stack overflow. I wasn't able to find the cause for it yet :( - it's a side effect of the engine function and occurs in some other thread of the executable. The stack overflow does not occur if the player is in any in-game menu; EquipItem works fine then. In Fallout 3, this problem doesn't exist at all.

[Queue]

I actually tried compiling the three most recent commits (I happened to have downloaded each as you made updates) and all 3 fail in the same way for me (CriticalSection timeout) which is occuring basically as New Vegas starts up; it doesn't even have a chance to start loading the save file.

Queue

[foxtacles]

OK, I'll try to reproduce again tomorrow. Can you tell me what you did comment out in vaultmp.dll code?

Also, do you use the debug or release build?

[Queue]

I've been compiling the release builds.

In vaultmp.cpp I've been commenting out:

line 269 which is
AddToChat(data);

lines 573 to 586 which are
vaultgui = LoadLibrary("vaultgui.dll");
and then the entire if/else block below it

lines 681 to 692 which are
string chat(GetQueue());
and the if block below it

---

I'm going to compile the debug builds and see if that makes a difference.

Queue

[foxtacles]

Looks fine. Can you try the debug build? It will generate a log file, which might help me resolving the problem.

[Queue]

Vault-Tec Multiplayer Mod client debug log (0.1a snapshot "Gary 2")
Connecting to server: 127.0.0.1|1770 (name: Queue, password: , game: Fallout New Vegas)
Visit www.vaultmp.com for help and upload this log if you experience problems with the mod.
-----------------------------------------------------------------------------------------------------
[2012-06-23 16:08:43] Attached debug handler to API class
[2012-06-23 16:08:43] Attached debug handler to VaultException class
[2012-06-23 16:08:43] Attached debug handler to NetworkClient class
[2012-06-23 16:08:43] Attached debug handler to Interface class
[2012-06-23 16:08:43] Attached debug handler to Lockable class
[2012-06-23 16:08:43] Attached debug handler to Reference class
[2012-06-23 16:08:43] Attached debug handler to Object class
[2012-06-23 16:08:43] Attached debug handler to Item class
[2012-06-23 16:08:43] Attached debug handler to Container class
[2012-06-23 16:08:43] Attached debug handler to Actor class
[2012-06-23 16:08:43] Attached debug handler to Player class
[2012-06-23 16:08:43] Attached debug handler to Game class
[2012-06-23 16:08:43] Attached debug handler to GameFactory class
[2012-06-23 16:08:43] New actor object created (ref: 00000014)
[2012-06-23 16:08:43] Connection request accepted (127.0.0.1|1770)
[2012-06-23 16:08:43] We were successfully authenticated (127.0.0.1|1770)
[2012-06-23 16:08:43] Initiating vaultmp game thread...
[2012-06-23 16:08:43] vaultmp process waked up (game patched)
[2012-06-23 16:08:43] Threads 5 6 005c73c8 005c73d8
[2012-06-23 16:08:48] 033371E8 (6SharedIbE) has been shared with key 00000001
[2012-06-23 16:08:58] Thread 6 could not enter CriticalSection object 005C73D8, timeout of 5000ms reached (15CriticalSection)
[2012-06-23 16:08:58] Thread 1 could not enter CriticalSection object 005C73C8, timeout of 5000ms reached (15CriticalSection)
[2012-06-23 16:09:06] Send thread is going to terminate (ERROR)
[2012-06-23 16:09:06] Reference 00000014 with base 00000007 and NetworkID 166634042497513785 (type: 6Player) to be destructed (033206D0)
[2012-06-23 16:09:06] Player object destroyed (ref: 00000014)
[2012-06-23 16:09:06] Network thread is going to terminate (ERROR)
-----------------------------------------------------------------------------------------------------
END OF LOG




















Server debug log had nothing noteworthy since it worked as expected.

Edit - CODE tags kinda screw post formatting, at least when viewing this forum with Opera.

Queue

[foxtacles]

Hmmm, weird.

Can you uncomment lines 48 and 49 of Interface.cpp and line 40 of Game.cpp, then run and upload the debug log again? Thanks!

[Queue]

Vault-Tec Multiplayer Mod client debug log (0.1a snapshot "Gary 2")
Connecting to server: 127.0.0.1|1770 (name: Queue, password: , game: Fallout New Vegas)
Visit www.vaultmp.com for help and upload this log if you experience problems with the mod.
-----------------------------------------------------------------------------------------------------
[2012-06-23 16:38:06] Attached debug handler to API class
[2012-06-23 16:38:06] Attached debug handler to VaultException class
[2012-06-23 16:38:06] Attached debug handler to NetworkClient class
[2012-06-23 16:38:06] Attached debug handler to Interface class
[2012-06-23 16:38:06] Attached debug handler to Lockable class
[2012-06-23 16:38:06] Attached debug handler to Reference class
[2012-06-23 16:38:06] Attached debug handler to Object class
[2012-06-23 16:38:06] Attached debug handler to Item class
[2012-06-23 16:38:06] Attached debug handler to Container class
[2012-06-23 16:38:06] Attached debug handler to Actor class
[2012-06-23 16:38:06] Attached debug handler to Player class
[2012-06-23 16:38:06] Attached debug handler to Game class
[2012-06-23 16:38:06] Attached debug handler to GameFactory class
[2012-06-23 16:38:06] New actor object created (ref: 00000014)
[2012-06-23 16:38:06] Connection request accepted (127.0.0.1|1770)
[2012-06-23 16:38:06] We were successfully authenticated (127.0.0.1|1770)
[2012-06-23 16:38:06] Initiating vaultmp game thread...
[2012-06-23 16:38:06] Attached debug handler to CriticalSection object 005C73C8 (15CriticalSection)
[2012-06-23 16:38:06] Attached debug handler to CriticalSection object 005C73D8 (15CriticalSection)
[2012-06-23 16:38:06] vaultmp process waked up (game patched)
[2012-06-23 16:38:06] Threads 5 6 005c73c8 005c73d8

The following 2 lines repeat over and over for 24 megabytes worth of log file
[2012-06-23 16:38:06] CriticalSection object 005C73C8 (15CriticalSection) locked by thread 6
[2012-06-23 16:38:06] CriticalSection object 005C73C8 (15CriticalSection) unlocked by thread 6
The previous 2 lines repeat over and over for 24 megabytes worth of log file

[2012-06-23 16:38:12] Reference 00000014 with base 00000007 and NetworkID 126101647613529630 (type: 6Player) to be destructed (03320648)
[2012-06-23 16:38:12] Player object destroyed (ref: 00000014)
[2012-06-23 16:38:12] Network thread is going to terminate (ERROR)
-----------------------------------------------------------------------------------------------------
END OF LOG

























Not much new aside from thread 6 locking and unlocking over and over for 5 seconds.

Queue

[foxtacles]

Is the timeout error the same, too? Nothing else than those lock/unlock in the part you left out?

[Queue]

Yes, sorry, I missed pasting the timeout message from the log file because it occured in the middle of the repeated locks/unlocks.

Queue

[foxtacles]

Sorry, have to ask again: are there no other locks / unlocks (of the other object?). The deadlock should be reflected in the log, at least in theory.

[Queue]

Uploading one of the logs may be a better idea:
https://lh.rs/o6EItHBHHZEJ

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.

Queue

[Queue]

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.

Queue

[foxtacles]

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.

[Queue]

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.

Queue

[foxtacles]

Hm, no I don't have any global compiler settings. All is in the project files.

Can you run

mingw32-g++.exe -v
(the compiler executable you should have set in the compiler options)

and make a screenshot of the result? Here is mine:

116

[Queue]

117
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.

Queue

[foxtacles]

I believe I have this one:

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/old/4.7.0-3/i686-w64-mingw32-gcc-4.7.0-3_rubenvb.7z/download

Maybe try that... not sure if it makes a difference. What OS do you have?

[Queue]

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.

Queue

[Queue]

Success! So, using the Ruben build of MinGW did the trick; everything works now.

For anyone else reading this, as of 2012, June 24, to compile VaultMP you need:
https://www.codeblocks.org/downloads/26
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/old/4.7.0-3/

https://github.com/Foxtacles/vaultmp
https://github.com/Foxtacles/iniparser/tree/ce75430a13cdb6efcae21b0568bfa6ce8d28c95c
https://sourceforge.net/projects/boost/files/boost/1.49.0/

VaultGUI.dll requires Visual Studio 10; I haven't begun worrying about that yet; I'm just ecstatic to have VaultMP compiling and working correctly.

Queue

[foxtacles]

Note: due to a bug with variadic template specialization (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38543) vaultmp will soon require GCC 4.7.1.

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/release/

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/blob/master/source/CriticalSection.cpp#L41
which in nixmann's build seems to immediately return false. I changed that to a simple lock() call, which apparently works.

EDIT3:
To reproduce the problem:
https://codepad.org/7PjsrFLI

Expected output: a1b1 or b1a1
Real output: sometimes a1b1, sometimes a1b0

EDIT4:

Thank you for the bug report!
In the Rubben`s builds this error does not occur, because he uses the
win32 threading model, but I use posix.

The bug will be fixed in the nearest future.
I will inform you.

Thanks.