Is there a way I can get an EsenthelEngine.pak compiled to target /MDd runtime instead of /MT? Alternatively, has someone in the community managed to get Connector/C++ to work with Esenthel Engine with runtime set to /MDd?

I'm having trouble converting my existing game (runtime library /MDd - multi-threaded debug dll) to work as an Esenthel project (requires /MT multi-threaded static).

The reason is that my existing game uses Boost headers and Connector/C++ libs, each come standard targeting /MDd runtime. I now have Boost working with standard Esenthel VC settings thanks to Kevin's post and wiki on luabind which requires boost...(key step: undef T and C, include custom headers like boost, then redef T and C). My game, now mostly Esenthelized, works with boost but not yet with Connector/C++.

Much of the Boost libraray only contains headers with inline functions - no need for precompiled binaries. However, Connector/C++ uses dlls precompiled to work with the more generic /MDd runtime. I found no way to get these dlls to work with runtime set to /MT (I searched high and low but found no detailed threads or community comments on a workaround except for the boost/luabind solution).

Before posting this thread, I obtained source Connector/C++, used CMake, then rebuilt Makefiles in VC++, targeting /MT runtime (Esenthel standard) hoping the new binaries would work with Esenthel. But I couldn't get there, as Connector/C++ Makefiles wouldn't even build to target /MT, giving debug errors that some string functions required DLL settings.

I did see the following post by Esenthel, and understand I may be able to abandon Connector/c++ at some point in the future, and instead look to use the Esenthel Connection and ConnectionServer classes. But I would like to initially see if I can get my game working with Esenthel using Connector/c++ as that is how my game is working currently:

---Posted by Esenthel - 10-21-2010 01:50 PM
"You have Socket and Socket::block, Socket is the low-level functionality.

I encourage looking into Esenthel MMO source's for more high-level functionality (Connection, ConnectionServer classes), but that's available after license purchase."

I just wanted to suggest recompiling the Connector with /MT but I see you have problems with it.

I'm not sure if EE can be linked with /MDd settings, never tried it, didn't have the need.

Maybe you can ask for help with compiliing Connector under /MT in Connector forum or something.

Hi,

I spent the last four days trying what you suggested (i.e. bring the application in line with EE's MT). I found that ConnectorC++ source actually links to dlls and libs from mySql C-API (Mysql Client library), and these in turn were by default pre-compiled and linked to MDd runtime. So...I obtained the source for the C-API, and tried to rebuild it targeting MT. I could build NMake Files, but it failed before I could install them and compile to DLL and LIB files. I tried many combinations, but the forum help for C-API source builds is non-existent, and for ConnectorC++ there isn't much.

So, I then tried to see how far I could get targeting different and dual runtimes in my Esenthel app (i.e. set Esenthel (MT) to MDd) adding my code functions and headers one by one until it broke. I had to add several libraries (as outlined below for any forum user who might be interested). The upshot is I got most functionality working. I haven't tried that many of the sample Esenthel source examples, but day/night cycle and cloth work OK.

If you are interested, after a lot of trial and error, I had to add Additional Dependencies of
mysqlcppconn.lib (MySql ConnectorC++)
libmysql.lib (MySql C-Api client)
libcmt.lib (Microsoft lib)
msvcprtd.lib (Microsoft lib)

I could not get the std library classes of strcpy or Microsoft's strcpy_s to build. Strcpy produced the build error:
error LNK2019: unresolved external symbol __imp__strncpy referenced in function "public: struct EE::Str __thiscall mysql_tut::doSomething(void)" (?doSomething@mysql_tut@@QAE?AUStr@EE@@XZ)

I made a workaround using EE Str and iterated through a char array, but perhaps another forum member knows how to fix that.

I also could not get Masterxilo-and-Zeroo's console window workaround going in MDd, even though I had it working fine targeting MT:
AllocConsole();
freopen("CONIN$","rb",stdin);
freopen("CONOUT$","wb",stdout);
freopen("CONOUT$","wb",stderr);

I made a workaround for console output by writing debug info to EE screen by returning Str to D.text in the Draw() function of EE. However, if anyone can see an obvious solution to making strcpy and stdin work, that would be appreciated.

-a