Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

I guess this is why nobody was able to answer me why boost::thread related classes are dllexport'ed even though BOOST_THREAD_BUILD_DLL is never defined in our project but BOOST_THREAD_USE_LIB is.
The boost::thread stuff is from trying around until it works because a not really supported combination of linking statically (so no separate DLL needs to be added to the installation) and still linking to the right run time library version was needed.
 
The boost::thread stuff is from trying around until it works because a not really supported combination of linking statically (so no separate DLL needs to be added to the installation) and still linking to the right run time library version was needed.
I have built the object files (thread.obj, mutex.obj, etc.) into a boost_thread.lib using boost build system (bjam) from boost-1.32 source files and adjusted the makefile at the variable PROJECT_LIBS. Now my CvGameCoreDLL doesn't export boost::thread classes anymore.

Xerces objects could also be built into a .lib (prebuilt release version isn't usable)
No, still needs those .obj files.
 
Last edited:
I have built the object files (thread.obj, mutex.obj, etc.) into a boost_thread.lib using boost build system (bjam) from boost-1.32 source files and adjusted the makefile at the variable PROJECT_LIBS. Now my CvGameCoreDLL doesn't export boost::thread classes anymore.

Xerces objects could also be built into a .lib (prebuilt release version isn't usable)
Ah, good, that is the proper way to do it. The main problem I had when I tried around with it iirc (and I was not very experienced with build systems back then), was that the standard build options in that version only included building a static lib while linking to the static runtime or building a dynamic lib while linking to the dynamic runtime (which of course also exported the class symbols). What I needed was a static lib linked to the dynamic runtime so I just took the object files from the dynamic lib compilations and linked them to the CvGameCoreDLL.
Just make sure with your change that your lib is not built against the static runtime.
 
Ah, good, that is the proper way to do it. The main problem I had when I tried around with it iirc (and I was not very experienced with build systems back then), was that the standard build options in that version only included building a static lib while linking to the static runtime or building a dynamic lib while linking to the dynamic runtime (which of course also exported the class symbols). What I needed was a static lib linked to the dynamic runtime so I just took the object files from the dynamic lib compilations and linked them to the CvGameCoreDLL.
Just make sure with your change that your lib is not built against the static runtime.
I didn't understand that I can not link a static library inside a dynamic library. My last experiment turned out to be using dynamic library still, so it required adding a dll in the BtS base directory. When I tried again to link a statically built thread library, symbol clash happens. Static library has statically linked msvcprt symbols too, not dynamically linked ones. It clashes with dynamically linked msvcprt symbols in the rest of our project. So it still needs to be done in your way.
I notice that the .obj files you have included are the dynamic linked ones.

Another idea has struck me: if I edit the source config (thread/detail/config.hpp) to remove __declspec(dllexport) under the condition (BOOST_THREAD_BUILD_DLL), and rebuild dynamic linked objects afterwards, I should be able to get rid of exports.
Update: Yes, that has made the difference.

Thank you AIAndy. That way you included those objects was the real proper way. It was not a "dirty" hack at all as you might have thought. And you also taught me about the difference of static and dynamic libraries.
 
Last edited:
The Steam DRM doesn't allow it to run the game with a debugger attached. That makes that version useless for dll modding anyways.
I guess I would have to dig up my physical copy of BtS before even trying to set up VS for C2C.
The general discussion going on here lately really demotivates me from wanting to try my hands on dll modding all together. ^^

Oh well, the python side of C2C needs me more I guess, I'll keep to what I'm comfortable with. ^^
 
I didn't understand that I can not link a static library inside a dynamic library. My last experiment turned out to be using dynamic library still, so it required adding a dll in the BtS base directory. When I tried again to link a statically built thread library, symbol clash happens. Static library has statically linked msvcprt symbols too, not dynamically linked ones. It clashes with dynamically linked msvcprt symbols in the rest of our project. So it still needs to be done in your way.
I notice that the .obj files you have included are the dynamic linked ones.

Another idea has struck me: if I edit the source config (thread/detail/config.hpp) to remove __declspec(dllexport) under the condition (BOOST_THREAD_BUILD_DLL), and rebuild dynamic linked objects afterwards, I should be able to get rid of exports.
Update: Yes, that has made the difference.

Thank you AIAndy. That way you included those objects was the real proper way. It was not a "dirty" hack at all as you might have thought. And you also taught me about the difference of static and dynamic libraries.
A bit more of an explanation:
It is quite possible to link a static lib into a dynamic lib (DLL) but it is important to have only one runtime in the process. Otherwise you would have multiple memory allocators and similar stuff which might cause weird effects (or not work at all). That is why Microsoft allows you to link to either a dynamically linked or a statically linked version of the runtime (that is done via compiler switch).
In a normal completely statically linked program you would use the static runtime and also link any library statically (which in turn must then link to the static runtime).
In a program with DLLs you would use the dynamic runtime (which is a DLL itself) and can then link libraries dynamically as DLL (which in turn must link to the dynamic runtime).
Those two cases are supported in Boost 1.32, but our case is different. We have the second case but also want to link Boost Thread statically into the DLL. This means it still must use the dynamic runtime as we want to statically link it into a DLL that has to use the dynamic runtime.
I think newer versions of Boost support that case but 1.32 does not and even tests against it in code (as it thinks this is not a valid configuration).
What I did was still a hack but the proper way is more involved. It would require modifying the Boost Thread code so the combination of dynamic runtime and building a static lib works (mainly removing the checks against that combination of defines).
 
  • Like
Reactions: Anq
I guess I would have to dig up my physical copy of BtS before even trying to set up VS for C2C.
The general discussion going on here lately really demotivates me from wanting to try my hands on dll modding all together. ^^

Oh well, the python side of C2C needs me more I guess, I'll keep to what I'm comfortable with. ^^
If it's any consolation, I'm completely lost by 99% of the discussion. Like what's a lib anyhow? (Please don't try to answer this btw... let me be in the dark with that stuff for now I beg y'all.) If the work they are doing cleans up all these errors the compiler is throwing, I will be ecstatic. Just relaxing and letting the masters do their thing. I can code but this... is computer science.

Edit:
@AIAndy: I'm thrilled to see you working with Anq to get things sorted out properly here! Thank you!
 
A bit more of an explanation:
It is quite possible to link a static lib into a dynamic lib (DLL) but it is important to have only one runtime in the process. Otherwise you would have multiple memory allocators and similar stuff which might cause weird effects (or not work at all). That is why Microsoft allows you to link to either a dynamically linked or a statically linked version of the runtime (that is done via compiler switch).
In a normal completely statically linked program you would use the static runtime and also link any library statically (which in turn must then link to the static runtime).
In a program with DLLs you would use the dynamic runtime (which is a DLL itself) and can then link libraries dynamically as DLL (which in turn must link to the dynamic runtime).
Those two cases are supported in Boost 1.32, but our case is different. We have the second case but also want to link Boost Thread statically into the DLL. This means it still must use the dynamic runtime as we want to statically link it into a DLL that has to use the dynamic runtime.
I think newer versions of Boost support that case but 1.32 does not and even tests against it in code (as it thinks this is not a valid configuration).
What I did was still a hack but the proper way is more involved. It would require modifying the Boost Thread code so the combination of dynamic runtime and building a static lib works (mainly removing the checks against that combination of defines).
I have found it was as easy as modifying the jamfile under lib/thread/build. In the section boost_thread_lib_base, change <runtime-link>static into <runtime-link>dynamic, then build the library again. (I've even undone my deletion of dllexport in thread/detail/config.hpp!) This new library libboost_thread-vc71-mt-1_32.lib, 818 Kilobytes, which I believe is a conglomerate of the individual object files, is a little larger than their sum (687KB).
 
Last edited:
revision: 10637
in messages related unit activities instead unit name I always get something like %1s (something with %... )
Civ4ScreenShot0001.JPG

How I can fix this?
 
Looks like a missing/incorrect localization entry for the German translation. I'm not able to find where it is in the game files though.
 
Looks like a missing/incorrect localization entry for the German translation. I'm not able to find where it is in the game files though.
hmm... where is the (german) text? what file(s)? I think it's a thing of false character or character set. If I know in what file(s) the english text with the variable is and an what files(s) the German text, I can compare it and maybe find the failure.
In BUG the variables look like ^ (in ingame BUG settings). If C2C does not process % but ^ instead, then a simle replacement of the character wol dfix it., probably. When I can compare the English and the German messagestextes and the variables in there, maybe I find it.
 
Translations are at best VERY incomplete.
Text are stored in various text xml files.
ok, what files have what content? What/how to translate it? If I know how to do it, I can have a look what is important and wha not and if I can do it.
 
Looks like a missing/incorrect localization entry for the German translation. I'm not able to find where it is in the game files though.
It's in Assets\Modules\Natural_Wonders\NaturalWonder_CIV4GameText.xml

Where:
<German>[COLOR_LIGHT_GREY]%s1 hat das Naturwunder %s1 entdeckt!</German>
should be:
<German>[COLOR_LIGHT_GREY]%s1 hat das Naturwunder %s2 entdeckt!</German>
ok, what files have what content? What/how to translate it? If I know how to do it, I can have a look what is important and wha not and if I can do it.
Most text is within this folder: \Assets\XML\Text

Use grepWin or notepad++ to search for text within a file to find the file that contains the text fast. ^^
Notepad can be used to modify xml files, actually, most text editors will do.
 
View attachment 528633
where are these messages text stored? would like to translate them to German, don't like mixed language in a game.
Assets/XML/Text/GlobalCIV4GameText.xml line 13047
(Be warned the file may be full of hundreds or thousands more text fragments requiring translation like this one - and there may be dozens of similar files)
Except for "The Green Man" (in the variable %s2_PlyrName) which it gets from Assets/XML/Text/NamesLeadersCIV4GameText.xml line 466
 
It's in Assets\Modules\Natural_Wonders\NaturalWonder_CIV4GameText.xml

Where:
<German>[COLOR_LIGHT_GREY]%s1 hat das Naturwunder %s1 entdeckt!</German>
should be:
<German>[COLOR_LIGHT_GREY]%s1 hat das Naturwunder %s2 entdeckt!</German>

Most text is within this folder: \Assets\XML\Text

Use grepWin or notepad++ to search for text within a file to find the file that contains the text fast. ^^
Notepad can be used to modify xml files, actually, most text editors will do.
I do use Notepad++, but it looks like translation ins not all to do, I also need to know the syntax and where I find such as %s2 (%1) to see what is wrong. I'm not familar with that (yet)

Assets/XML/Text/GlobalCIV4GameText.xml line 13047
(Be warned the file may be full of hundreds or thousands more text fragments requiring translation like this one - and there may be dozens of similar files)
Except for "The Green Man" (in the variable %s2_PlyrName) which it gets from Assets/XML/Text/NamesLeadersCIV4GameText.xml line 466
I do not intend to translate all, but when I understand what is to do and how and where to find, I can try to translate such sentence and words which are in message shown. I'll do it step for step, have free time next months (have been working translations for Skyrim mods, but that is pretty dfferent, technically more easy because a translation tool, in content and meaning of text more difficult. https://www.nexusmods.com/skyrimspecialedition/users/5872020?tab=user+files As there I'll be ready soon, no more mods on to do list, *maybe* I can do some for C2C, these mistakes are bugging me..)
 
I do not intend to translate all, but when I understand what is to do and how and where to find, I can try to translate such sentence and words which are in message shown. I'll do it step for step, have free time next months (have been working translations for Skyrim mods, but that is pretty dfferent, technically more easy because a translation tool, in content and meaning of text more difficult. https://www.nexusmods.com/skyrimspecialedition/users/5872020?tab=user+files As there I'll be ready soon, no more mods on to do list, *maybe* I can do some for C2C, these mistakes are bugging me..)
You could report these mistakes to @dsma_bell as he's our German translator.
 
Back
Top Bottom