[PATCH] Multiplayer lobby

[Badmadblacksad-]

Hello, the multiplayer lobby is back, more than 6 months late. Sorry about that. The patch attached adds an in-game multiplayer lobby and a tool (XpartaMuPP) to manage created games. It uses the XMPP protocol.

After applying the patch, you will find a README in source/tools/XpartaMuPP/ which explains how to install and configure the XMPP server (ejabberd) and XpartaMuPP.

To build the game you will need to install the gloox library (cpp XMPP library). svn co ​svn://svn.camaya.net/gloox/branches/1.0 gloox-1.0 ./configure make make install

Let me know if you have any issue building / running the game with this patch, it will help me to improve the documentation.

The patch is not ready to be committed yet, I'm just asking for a review, and at the same time if anyone is willing to help me to improve the UI (there are great artists among you!), it would be much appreciated. Thanks.

[picobyte]

Installing gloox:

# change as appropriate:
DIR_0ad=/home/$USER/development/git/0ad

cd $DIR_0ad/build
svn co svn://svn.camaya.net/gloox/branches/1.0 gloox-1.0

Sidenote: gloox needed libtool so I've installed it, with `sudo apt-get install libtool' but that's distro specific - and I wonder why it isn't installed yet.

./configure --prefix=$DIR_0ad/alien/gloox-1.0/
make; make install

# gloox/jid.h is missing, so ...
cd $DIR_0ad/source
ln -s $DIR_0ad/alien/gloox-1.0/include/gloox 

# Since I didn't install gloo system-wide I have to add some links:

cd $DIR_0ad/binaries/system
for f in ../../alien/gloox-1.0/lib/lib*; do ln -s $f; done

building 0ad, from $DIR_0ad/build/workspaces:

./update-workspaces.sh; cd gcc;make -j5; cd ..

Now I'm getting complaints about redefinitions, however.

NetServer.cpp
../../../source/lobby/XmppClient.cpp:593:13: error: redefinition of ‘XmppClient* g_XmppClient’
../../../source/lobby/XmppClient.cpp:22:13: error: ‘XmppClient* g_XmppClient’ previously defined here
../../../source/lobby/XmppClient.cpp: In function ‘std::string StanzaErrorToString(gloox::StanzaError&)’:
../../../source/lobby/XmppClient.cpp:603:13: error: redefinition of ‘std::string StanzaErrorToString(gloox::StanzaError&)’
../../../source/lobby/XmppClient.cpp:32:13: error: ‘std::string StanzaErrorToString(gloox::StanzaError&)’ previously defined here

... and so on

[Badmadblacksad-]

Hi Picobyte, Did you paste the code two times in XmppClient?.cpp? This file should be 571 lines long, not 593+. If you are not already familiar with it, you could just use the patch command.

patch -p0 -I file -d $DIR_0ad

[Badmadblacksad-]

improve user interface

[historic_bruno]

I tested this on Windows. Here's how the process went :)

gloox:

• Indeed I had to use SVN, there are files missing from the 1.0 package so it fails to build. Note: we'll need to make sure the SVN is compatible with other 1.0 packages, I know at least Ubuntu has ​libgloox-dev.
• Opened in VC 2008. There's a problem with the release build configuration, it's set to target an EXE instead of DLL. After changing that, DLL_EXPORT needs to be added to the preprocessor definitions (Configuration Properties > C/C++ > Preprocessor)
• src/atomicrefcount.cpp is missing from the source files, need to add that
• I changed the project name from "gloox 1.0" to "gloox-1.0", so the output files wouldn't contain a space...
• I left out the dependencies for simple testing (config.h.win defaults)
• Build succeeded. So I copied gloox-1.0.dll to binaries\system. Made a new folder libraries\gloox\ and copied gloox-1.0.lib into libraries\gloox\lib\ and all the src\*.h headers into libraries\gloox\include\gloox\.
• (Can repeat the process if debug libs are required, just add a d to the end)

Then a Windows-specific change was needed to extern_libs4.lua so it picks up the bundled libs:

	gloox = {
		compile_settings = function()
			add_default_include_paths("gloox")
		end,
		link_settings = function()
			if os.is("windows") then
				add_default_lib_paths("gloox")
			end
			add_default_links({
				win_names  = { "gloox-1.0" },
				unix_names = { "gloox" },
			})
		end,
	},

XmppClient.cpp is missing #include "precompiled.h" at the beginning.

Now a clean build of the game brings a few errors:

1>  precompiled.cpp
1>  source\lib/pch/pch_boost.h(21): fatal error C1083: Cannot open include file: 'boost/version.hpp': No such file or directory

2>  ScriptFunctions.cpp
2>  source\lobby/XmppClient.h(5): fatal error C1083: Cannot open include file: 'gloox/jid.h': No such file or directory

3>  GameSetup.cpp
3>  source\lobby/XmppClient.h(5): fatal error C1083: Cannot open include file: 'gloox/jid.h': No such file or directory

The first error was fixed by adding "boost" to extern_libs for the lobby project (in premake4.lua).

I tried to fix the other two errors similarly by adding "gloox" to "gui" and "engine" projects. It seems to cause some namespace problems:

2>..\..\..\source\ps\GameSetup\GameSetup.cpp(403): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(403): error C2059: syntax error : '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(406): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(406): error C2059: syntax error : '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(409): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(409): error C2059: syntax error : '::'

and even more puzzling errors like the following:

1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(30): warning C4005: 'WINGDIAPI' : macro redefinition
1>          C:\Users\Ben\devel\ps\source\lib/sysdep/os/win/wgl.h(36) : see previous definition of 'WINGDIAPI'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624): error C2732: linkage specification contradicts earlier specification for 'wglCopyContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624) : see declaration of 'wglCopyContext'

[historic_bruno]

Reported the gloox problems upstream: ​http://bugs.camaya.net/horde3/whups/ticket/?id=197

[Badmadblacksad-]

Oww, that's not good :( Cool that's you managed to build the library despite these annoying issues. Hopefully we will only have to do that once. About the other errors, I just saw a nasty 'using namespace gloox' in XmppClient?.h, which is more than likely the cause. (Camaya.net seems to be down by the way)

[Badmadblacksad-]

This patch should fixes the namespace issues. It also includes Ben's changes to extern_libs.lua & premake4.lua and the missing precompiled.h header in XmppClient?.cpp.

[historic_bruno]

Thanks for the quick update :) I tested the new patch.

• COList.cpp is also not including precompiled.h at the beginning (MSVC is very specific, it must be the first line of every .cpp file in the project)
• XmppClient.cpp includes precompiled.h twice

You include lobby/XmppClient.h in several projects (engine, gui) and that header includes gloox stuff in turn, so if gloox isn't explicitly added to premake4.lua for those projects, the header files won't be in the include path (it may work currently on Linux because you installed gloox to a standard location that's already in the include path).

Unfortunately most of the errors/warnings are unchanged:

1>  ScriptFunctions.cpp
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(126): warning C4005: 'APIENTRY' : macro redefinition
1>          source\lib/sysdep/os/win/wgl.h(42) : see previous definition of 'APIENTRY'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\winnt.h(519): warning C4005: 'DECLARE_HANDLE' : macro redefinition
1>          source\lib/sysdep/os/win/wgl.h(71) : see previous definition of 'DECLARE_HANDLE'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(232): error C2373: 'PROC' : redefinition; different type modifiers
1>          source\lib/sysdep/os/win/wgl.h(63) : see declaration of 'PROC'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(267): error C2371: 'HDC' : redefinition; different basic types
1>          source\lib/sysdep/os/win/wgl.h(72) : see declaration of 'HDC'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(269): error C2371: 'HGLRC' : redefinition; different basic types
1>          source\lib/sysdep/os/win/wgl.h(73) : see declaration of 'HGLRC'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(325): error C2371: 'RECT' : redefinition; different basic types
1>          source\lib/sysdep/os/win/wgl.h(65) : see declaration of 'RECT'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(30): warning C4005: 'WINGDIAPI' : macro redefinition
1>          source\lib/sysdep/os/win/wgl.h(36) : see previous definition of 'WINGDIAPI'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624): error C2732: linkage specification contradicts earlier specification for 'wglCopyContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624) : see declaration of 'wglCopyContext'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5625): error C2732: linkage specification contradicts earlier specification for 'wglCreateContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5625) : see declaration of 'wglCreateContext'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5626): error C2732: linkage specification contradicts earlier specification for 'wglCreateLayerContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5626) : see declaration of 'wglCreateLayerContext'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5627): error C2732: linkage specification contradicts earlier specification for 'wglDeleteContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5627) : see declaration of 'wglDeleteContext'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5628): error C2732: linkage specification contradicts earlier specification for 'wglGetCurrentContext'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5628) : see declaration of 'wglGetCurrentContext'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5629): error C2732: linkage specification contradicts earlier specification for 'wglGetCurrentDC'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5629) : see declaration of 'wglGetCurrentDC'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5630): error C2732: linkage specification contradicts earlier specification for 'wglGetProcAddress'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5630) : see declaration of 'wglGetProcAddress'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5631): error C2732: linkage specification contradicts earlier specification for 'wglMakeCurrent'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5631) : see declaration of 'wglMakeCurrent'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5632): error C2732: linkage specification contradicts earlier specification for 'wglShareLists'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5632) : see declaration of 'wglShareLists'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5633): error C2732: linkage specification contradicts earlier specification for 'wglUseFontBitmapsA'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5633) : see declaration of 'wglUseFontBitmapsA'
1>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5634): error C2732: linkage specification contradicts earlier specification for 'wglUseFontBitmapsW'
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5634) : see declaration of 'wglUseFontBitmapsW'
1>source\lobby/XmppClient.h(115): warning C4512: 'XmppClient' : assignment operator could not be generated
1>          source\lobby/XmppClient.h(32) : see declaration of 'XmppClient'
1>source\lobby/XmppClient.h(69): warning C4373: 'XmppClient::handleMUCParticipantPresence': virtual function overrides 'gloox::MUCRoomHandler::handleMUCParticipantPresence', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
1>          libraries\gloox\include\gloox/mucroomhandler.h(107) : see declaration of 'gloox::MUCRoomHandler::handleMUCParticipantPresence'
1>source\simulation2/system/Components.h(23): warning C4005: 'INTERFACE' : macro redefinition
1>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\commdlg.h(948) : see previous definition of 'INTERFACE'


2>  GameSetup.cpp
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(126): warning C4005: 'APIENTRY' : macro redefinition
2>          source\lib/sysdep/os/win/wgl.h(42) : see previous definition of 'APIENTRY'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\winnt.h(519): warning C4005: 'DECLARE_HANDLE' : macro redefinition
2>          source\lib/sysdep/os/win/wgl.h(71) : see previous definition of 'DECLARE_HANDLE'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(232): error C2373: 'PROC' : redefinition; different type modifiers
2>          source\lib/sysdep/os/win/wgl.h(63) : see declaration of 'PROC'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(267): error C2371: 'HDC' : redefinition; different basic types
2>          source\lib/sysdep/os/win/wgl.h(72) : see declaration of 'HDC'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(269): error C2371: 'HGLRC' : redefinition; different basic types
2>          source\lib/sysdep/os/win/wgl.h(73) : see declaration of 'HGLRC'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\windef.h(325): error C2371: 'RECT' : redefinition; different basic types
2>          source\lib/sysdep/os/win/wgl.h(65) : see declaration of 'RECT'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(30): warning C4005: 'WINGDIAPI' : macro redefinition
2>          source\lib/sysdep/os/win/wgl.h(36) : see previous definition of 'WINGDIAPI'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624): error C2732: linkage specification contradicts earlier specification for 'wglCopyContext'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5624) : see declaration of 'wglCopyContext'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5625): error C2732: linkage specification contradicts earlier specification for 'wglCreateContext'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5625) : see declaration of 'wglCreateContext'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5626): error C2732: linkage specification contradicts earlier specification for 'wglCreateLayerContext'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5626) : see declaration of 'wglCreateLayerContext'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5627): error C2732: linkage specification contradicts earlier specification for 'wglDeleteContext'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5627) : see declaration of 'wglDeleteContext'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5628): error C2732: linkage specification contradicts earlier specification for 'wglGetCurrentContext'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5628) : see declaration of 'wglGetCurrentContext'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5629): error C2732: linkage specification contradicts earlier specification for 'wglGetCurrentDC'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5629) : see declaration of 'wglGetCurrentDC'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5630): error C2732: linkage specification contradicts earlier specification for 'wglGetProcAddress'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5630) : see declaration of 'wglGetProcAddress'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5631): error C2732: linkage specification contradicts earlier specification for 'wglMakeCurrent'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5631) : see declaration of 'wglMakeCurrent'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5632): error C2732: linkage specification contradicts earlier specification for 'wglShareLists'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5632) : see declaration of 'wglShareLists'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5633): error C2732: linkage specification contradicts earlier specification for 'wglUseFontBitmapsA'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5633) : see declaration of 'wglUseFontBitmapsA'
2>C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5634): error C2732: linkage specification contradicts earlier specification for 'wglUseFontBitmapsW'
2>          C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wingdi.h(5634) : see declaration of 'wglUseFontBitmapsW'
2>source\lobby/XmppClient.h(115): warning C4512: 'XmppClient' : assignment operator could not be generated
2>          source\lobby/XmppClient.h(32) : see declaration of 'XmppClient'
2>source\lobby/XmppClient.h(69): warning C4373: 'XmppClient::handleMUCParticipantPresence': virtual function overrides 'gloox::MUCRoomHandler::handleMUCParticipantPresence', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
2>          libraries\gloox\include\gloox/mucroomhandler.h(107) : see declaration of 'gloox::MUCRoomHandler::handleMUCParticipantPresence'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(403): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(403): error C2059: syntax error : '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(406): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(406): error C2059: syntax error : '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(409): error C2589: '(' : illegal token on right side of '::'
2>..\..\..\source\ps\GameSetup\GameSetup.cpp(409): error C2059: syntax error : '::'

[Badmadblacksad-]

Hum. Most of these errors seem to come from variables redefined in wgl.h (included from ogl.h). I don't know the reason of all this mess. I just saw in gloox/README.win32 that we must define GLOOX_IMPORTS when building the game. It can't hurt to try but I doubt it fixes all these issues. I will try to set up everything to compile it myself on windows, but it's obscure like black magic to me.

[Badmadblacksad-]

Fixes windows build, adds missing files and minor bug fixes.

[Badmadblacksad-]

Fixed! \o/

Gloox includes windows.h which create conflicts. I used the same workaround that we use in other part of the game : I define _windows_ to prevent gloox from pulling in windows.h, and I define the required datatypes / macros.

The linker had an issue to find the gloox::EmptyString? variable. I don't understand why, I ran dumpbin /EXPORT on gloox-1.0.dll and saw it in the list. I fixed this issue by defining it myself in XmppClient?.cpp.

So everything compiles fine on windows (msvc2010) as far as I can tell. Thanks Ben for documenting the gloox library compilation steps.

[historic_bruno]

Thanks, confirmed it does build now on Windows :)

I set up the server per your instructions on an Ubuntu VM, then managed to get a client running on the same.

However, I was unable to connect or register from a Windows client. I encounter a crash like the following. I changed lobby.server to the VM's IP, so I don't think it's a network issue, and it seems related to string manipulation in gloox:

 	msvcr90.dll!__crt_debugger_hook() 	
 	msvcr90.dll!__invalid_parameter()  + 0x1f bytes	
 	msvcr90.dll!_memcpy_s()  + 0x2d bytes	
 	msvcp90.dll!std::char_traits<char>::_Copy_s()  + 0x17 bytes	
 	msvcp90.dll!std::_Traits_helper::copy_s<std::char_traits<char> >()  + 0x16 bytes	
 	msvcp90.dll!std::_Traits_helper::copy_s<std::char_traits<char> >()  + 0x1a bytes	
 	msvcp90.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Copy()  + 0xa4 bytes	
 	msvcp90.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Grow()  + 0x26 bytes	
 	msvcp90.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign()  + 0x50 bytes	
 	msvcp90.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign()  + 0x11 bytes	
> 	gloox-1.0.dll!gloox::JID::setJID(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & jid)  Line 33 + 0x43 bytes	C++
 	pyrogenesis_dbg.exe!gloox::JID::JID(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & jid)  Line 43 + 0xa3 bytes	C++
	pyrogenesis_dbg.exe!XmppClient::XmppClient(ScriptInterface & scriptInterface, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sUsername, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sPassword, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sRoom, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sNick, bool regOpt)  Line 85 + 0xf1 bytes	C++
 	pyrogenesis_dbg.exe!`anonymous namespace'::StartRegisterXmppClient(void * cbdata, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sUsername, std::basic_string<char,std::char_traits<char>,std::allocator<char> > sPassword)  Line 578 + 0xaf bytes	C++
 	pyrogenesis_dbg.exe!ScriptInterface_NativeWrapper<void>::call<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void (__cdecl*)(void *,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >)>(JSContext * cx, unsigned __int64 & __formal, void (void *, std::basic_string<char,std::char_traits<char>,std::allocator<char> >, std::basic_string<char,std::char_traits<char>,std::allocator<char> >)* fptr, std::basic_string<char,std::char_traits<char>,std::allocator<char> > a0, std::basic_string<char,std::char_traits<char>,std::allocator<char> > a1)  Line 45 + 0x9c bytes	C++
 	pyrogenesis_dbg.exe!ScriptInterface::call<void,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&`anonymous namespace'::StartRegisterXmppClient>(JSContext * cx, unsigned int argc, unsigned __int64 * vp)  Line 104 + 0x2cd bytes	C++
 	mozjs185-ps-debug-1.0.dll!570de069() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for mozjs185-ps-debug-1.0.dll]	
 	mozjs185-ps-debug-1.0.dll!570f29bd() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	mozjs185-ps-debug-1.0.dll!570b6958() 	
 	kernel32.dll!_HeapFree@12()  + 0x14 bytes	
 	00163163()	
 	003de104()	
 	msvcr100d.dll!___set_flsgetvalue()  + 0x12 bytes	
 	msvcr100d.dll!__output_l()  + 0x1416 bytes	
 	msvcr100d.dll!__output_l()  + 0x112e bytes	
 	04c70078()	
 	0a952390()	
 	ffff0007()	
 	mozjs185-ps-debug-1.0.dll!57514198() 	

[Badmadblacksad-]

I just tested with a debian vm, it seems to work as expected. I can't reproduce this bug. Could you print these strings (line 85-86 in XmppClient?.cpp) to see what is going on?

Ps: when using an ip in lobby.server, Xpartamupp.py must be run with "--domain <ip>" and ejabberd configured to use it as its hostname (in /etc/ejabberd/ejabberd :

{hosts, ["<ip>"]}

).

[historic_bruno]

OK, I made those config changes and had to create the "xpartamupp" ejabberd user again on the new domain, but I still have the same problem. Did you test with a Windows client? I had no problem either with a Linux (Ubuntu) client.

Here's my config:

• Server - Ubuntu VM guest, Windows 7 host, NAT, 192.168.19.129
  /etc/ejabberd/ejabberd.cfg:

  %% Hostname
  {hosts, ["localhost", "192.168.19.129"]}.
  

  Server run with this command:

  ./XpartaMuPP.py --domain 192.168.19.129 --login xpartamupp --password ***** --nickname XpartaMuCC
  

  Oh and here's the console output of the server:

  INFO     Negotiating TLS
  INFO     Using SSL version: 3
  WARNING  Could not find pyasn1 module. SSL certificate COULD NOT BE VERIFIED.
  INFO     Node set to: xpartamupp@192.168.19.129/CC
  WARNING  Could not find pyasn1 module. SSL certificate expiration COULD NOT BE VERIFIED.
  INFO     xpartamupp started
  

  The SSL warning is one I got before when testing the Ubuntu client which worked, so it doesn't seem too serious. Not sure how to fix it yet.

• Client - Windows 7, 192.168.2.2, default.cfg:

  lobby.server = "192.168.19.129"
  lobby.xpartamupp = "xpartamupp"
  

By the way, this same setup has worked in the past for regular multiplayer games and other things, so I'm pretty sure there is no network or VM problem (and anyway if there was, I would expect a more sane error).

Whether I try to register a new user or login with an existing one in the "Multiplayer lobby" of the client, makes no difference. It will always crash in the jid string creation. I forgot to include parameter values in the above stack trace, so here they are (password redacted):

> 	gloox-1.0.dll!gloox::JID::setJID(jid="ben@192.168.19.129/0ad")  Line 33 + 0x43 bytes	C++
 	pyrogenesis_dbg.exe!gloox::JID::JID(jid="ben@192.168.19.129/0ad")  Line 43 + 0xa3 bytes	C++
	pyrogenesis_dbg.exe!XmppClient::XmppClient(scriptInterface={...}, sUsername="ben", sPassword="*****", sRoom="", sNick="", regOpt=true)  Line 85 + 0xf1 bytes	C++
 	pyrogenesis_dbg.exe!`anonymous namespace'::StartRegisterXmppClient(cbdata=0x013b7ab0, sUsername="ben", sPassword="*****")  Line 578 + 0xaf bytes	C++
 	pyrogenesis_dbg.exe!ScriptInterface_NativeWrapper<void>::call<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,void (__cdecl*)(void *,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >)>(cx=0x045254b0, __formal=18446462607322775552, fptr=0x007681a0, a0="ben", a1="*****")  Line 45 + 0x9c bytes	C++
 	pyrogenesis_dbg.exe!ScriptInterface::call<void,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&`anonymous namespace'::StartRegisterXmppClient>(cx=0x045254b0, argc=2, vp=0x04ce00c8)  Line 104 + 0x2cd bytes	C++

I don't know if it's a bug in gloox, a problem in how it was built, or how we're using it. The crash is occurring at a very low level in the string libraries though. JID::setJID() seems a bit yucky, I haven't delved into its logic yet...

[Badmadblacksad-]

Yes I tested with a windows client and it worked. That's right, these config changes are not related to this bug, you will only need them if the client does not segfault About ssl, I ve got the same warnings, haven't try to fix them.

I don't know what's going on, the string you use in setJID is correct and I did not see anything obvious in thex code. I'm not sure what to try next, maybe using gloox in debug and stepping in the code from setJID? I m using the latest gloox 1.0 revision by the way (cannot get its number, my internet is not working..).
Could you send me your whole gloox directory, including the sources, the config files and the compilation output? I m running out of ideas, hopefully it will help.

[historic_bruno]

Sorry for the delay, I missed your comment :/ Which version of Visual Studio are you using to build A.D. and gloox? I used VC 2008 Express for gloox and VC 2010 Express for the game. I've seen some weird bugs in the past that affected specific versions.

Here's the entire zipped gloox project: ​https://hotfile.com/dl/164897387/7aab248/gloox.7z.html

I used the 1.0 SVN branch, looks like revision 4394.

[Badmadblacksad-]

Thanks! I'm using Visual Studio Express 2010 for both projects. It seems that you are building gloox in debug, if you build it in the release config this problem should disappear. (At least this is what happens here)
The bug remains weird, usually compiler bugs (I'm really tempted to say it's one, even if a config change may fix it) occur in optimized code, not the opposite.
Does it work ?

[historic_bruno]

Replying to Badmadblacksad-:

Thanks! I'm using Visual Studio Express 2010 for both projects. It seems that you are building gloox in debug, if you build it in the release config this problem should disappear. (At least this is what happens here)
The bug remains weird, usually compiler bugs (I'm really tempted to say it's one, even if a config change may fix it) occur in optimized code, not the opposite.
Does it work ?

I built both debug and release versions, or are you saying there is a problem with the release build configuration? The release should be gloox-1.0.dll while the debug version is gloox-1.0d.dll. Unfortunately it will be some time before I can test anything again, I'm out of town for 1-2 weeks.

[Badmadblacksad-]

I'm saying the opposite, there is an issue with the debug build configuration (when binaries are created in gloox/Debug). The problem is fixed if I select the release build configuration (binaries are then created in gloox/Release).
Whether I select the Release or the Debug build configuration, it creates a gloox-1.0.dll, not a gloox-1.0d.dll, so it should the same for you.

[historic_bruno]

That's true, at one point I had modified the debug build configuration to add a "d" to the output filename, but I must have reverted and lost that change. So I might have accidentally overwritten the release DLL with the debug version. When I get home I'll double check if that was the case. It's still annoying but much less serious if only the debug version of the DLL causes a problem.

[Badmadblacksad-]

Yes, the debug build of gloox is probably only useful to its developers. I hope it works.

[historic_bruno]

I tried this again making sure to use the release DLL which is the same size as before (~907KB), it gives the same error when trying to connect or register.

[historic_bruno]

OK there's good and bad news. The good news is I rebuilt gloox with VC 2010 express just for a test, and the crash is resolved! The bad news is building gloox with VC 2008 express leads to that crash :( The patch has two minor conflicts now.

I did some testing:

• Attempting to register a new user produces a "Registration forbidden" message for me (not sure if I need to allow registration somehow?) If I go into the eJabber web admin page and manually add a user, I can log in with those credentials, so that's good.
• I removed my user via the eJabber admin while logged into the client, and I was instantly disconnected and not allowed to log back in, so that's good :) I did still see XpartaMuCC and myself in the "players" list, so maybe that should be cleared.
• I also tried disconnecting the server (closing XpartaMuPP.py) while logged in the client, the XpartaMuCC user disappeared, but there was no message about being disconnected though presumably I was. I disconnected manually, upon trying to reconnect it said "connected" followed by "Service unavailable", so I assume it should not have said I connected :) The strange thing is I could even login through the main menu even with the lobby server not running, I get an instant "Service unavailable" message in that case.
• Next I tried to set up a game with one Windows client and one Linux client. I could host a game, but the IP shows up as "X" in the game list and when joining that game a dialog pops up with "X" in the IP field. If I typed in the actual IP, I was able to join but of course that defeats the purpose of the lobby ;) It made no difference which client hosted the game, the same behavior occurred.
• I think after a game, it should return to the lobby instead of the main menu.

Needs polish, but not a bad start!

[Badmadblacksad-]

Thanks for your feedback Ben.

Replying to historic_bruno:

• Attempting to register a new user produces a "Registration forbidden" message for me (not sure if I need to allow registration somehow?) If I go into the eJabber web admin page and manually add a user, I can log in with those credentials, so that's good.

Yes, registration must be allowed in /etc/jebberd/ejabberd.cfg (can also be allowed using the ejabberd web admin page) :

{access, register, [{allow, all}]}.

• I removed my user via the eJabber admin while logged into the client, and I was instantly disconnected and not allowed to log back in, so that's good :) I did still see XpartaMuCC and myself in the "players" list, so maybe that should be cleared.

Thanks, that was a bug.

• I also tried disconnecting the server (closing XpartaMuPP.py) while logged in the client, the XpartaMuCC user disappeared, but there was no message about being disconnected though presumably I was. I disconnected manually, upon trying to reconnect it said "connected" followed by "Service unavailable", so I assume it should not have said I connected :) The strange thing is I could even login through the main menu even with the lobby server not running, I get an instant "Service unavailable" message in that case.

I already fixed an issue so that now a client can only log in if the server runs XpartaMuPP.py.
After being connected, if you kill XpartaMuPP.py, nothing happens. Then if you press "Update" (or when you are connecting) it fails to send a message to XpartaMuPP.py, and that's why you get an "service unavailable" error. The client is still connected to the jabber server, and you can still see the list of connected players. At least that's how I wanted the system to work, but let me know if there is a real bug.

• Next I tried to set up a game with one Windows client and one Linux client. I could host a game, but the IP shows up as "X" in the game list and when joining that game a dialog pops up with "X" in the IP field. If I typed in the actual IP, I was able to join but of course that defeats the purpose of the lobby ;) It made no difference which client hosted the game, the same behavior occurred.

Did you install the ejabberd module as explained in source/tools/xpartamupp/README ? The "X" is a placeholder, it should be replaced by the client ip. If it has been installed and added to the ejabberd.cfg you will see references to "mod_ipstamp" in /var/log/ejabberd/ejabberd.log.

• I think after a game, it should return to the lobby instead of the main menu.

I agree, but it would then also requires adding the status feature to the lobby ("available" / "busy" (aka "playing")). I will eventually implement that when I have some time :)

[Badmadblacksad-]

Minor bug fixes, displays minimaps.

[Badmadblacksad-]

Replying to Badmadblacksad-:

• Next I tried to set up a game with one Windows client and one Linux client. I could host a game, but the IP shows up as "X" in the game list and when joining that game a dialog pops up with "X" in the IP field. If I typed in the actual IP, I was able to join but of course that defeats the purpose of the lobby ;) It made no difference which client hosted the game, the same behavior occurred.

Did you install the ejabberd module as explained in source/tools/xpartamupp/README ? The "X" is a placeholder, it should be replaced by the client ip. If it has been installed and added to the ejabberd.cfg you will see references to "mod_ipstamp" in /var/log/ejabberd/ejabberd.log.

Sorry, my mistake. There is a real bug here, I harcoded some things including the domain name ("localhost") in mod_ipstamp.erl. I will fix that.

[historic_bruno]

Thanks, also it would be nice if there was no separate "Join" dialog, or at least it shouldn't show the host IP, that will only confuse people. I would expect both username and IP to be quietly passed to the join game logic. (I seem to recall that dialog came up, but I don't currently have the patch applied to test my memory :))

[sorcix]

Badmadblacksad-, are you still working on this?

[Badmadblacksad-]

Not really :( I just fixed a few things though. I forked 0ad on github : ​https://github.com/badmadblacksad/0ad

[Badmadblacksad-]

I just pushed two sets of changes on github. The first one contains what's necessary to build on windows (gloox header + binaries*). The second one adds various features, among them : run the lobby in background so that the player go back to it at the end of a game, handle automatic player presence {available, playing}, allow a player to see (hence to rejoin) a game in which he was when it started, display the list of players in the box that shows info about the selected game, hide ip address, allow the player to join a game in two click (one to select a game, another to press join), and some code cleanup.

for historic_bruno specifically:

• about gloox binaries : we had an issue with the debug build of gloox that was not working. It was caused by the fact that we built for the target gloox1-0.{lib,dll} for both release and debug and renamed the debug one to gloox1.0d.{lib,dll}. When we do that the symbol are loaded from gloox1.0.dll regardless if we link against gloox1.0.lib or gloox1.0d.lib. Changing the debug target name to $(ProjectName?)d fixes the problem. \o/

Properties > Configuration Properties > General > Change Target name from $(ProjectName?) to $(ProjectName?)d

[fabio]

Just a note: it appears gloox is under GPLv2 only, there is already some js code under GPLv3 (license are incompatible but it should not a be a problem if js code doesn't link to C++ code).

Anyway in the long term use of "GPLv2 only" software can lead to problems like this: ​http://libregraphicsworld.org/blog/entry/libredwg-drama-the-end-or-the-new-beginning

[Badmadblacksad-]

Interesting reading. We are safe as long as 0ad is not linked with any GPLv3 library though.

[historic_bruno]

Maybe we could convince the gloox author to change the license to something more appropriate?