Link error

[warxander]

Hi, I'm trying to build it on VS 2019 and having a lot of unresolved external symbols mostly for ge_scriptadmin.obj and ge_scriptinit.obj. For example, it can't resolve bCMemoryAdmin::GetInstance() and I didn't find implementation too.

Could you tell me what I'm doing wrong, please?

[georgeto]

What is it exactly that you are trying to build?

bCMemoryAdmin::GetInstance() is implemented in the SharedBase.dll shipped with Gothic 3, we do not have access to the source code. The gothic3sdk dynamically links against these original Gothic 3 DLLs using the library files in the lib folder, they basically contain a list of all the methods exported by the original DLLs.

[warxander]

I copied Script_RemoteControt to use it as base, then I rebuilt all .sln with v142 toolset and updated paths in .props and project settings to use .lib files from build directory. Also I built them for both Debug and Release, but I guess it doesn’t make sense, right?

Also, there is suspicious line, public: using bCObjectBase::Write; in some headers, I guess it shouldn’t compile as it tries to inherit private overloaded function.

Sorry, I’m newbie with Windows development :)

[AdanosGotoman]

I copied Script_RemoteControt to use it as base, then I rebuilt all .sln with v142 toolset and updated paths on .props and project settings to use .lib files from build directory. Also I built them for both Debug and Release, but I guess it doesn’t make sense, right?

Also, there is suspicious line, public: using bCObjectBase::Write; in some headers, I guess it shouldn’t compile as it tries to inherit private overloaded function.

Sorry, I’m newbie with Windows development :)

Можешь заглянуть ко мне в репозиторий и если хочешь, можешь присоединиться к разработке геном сдк с нуля

[georgeto]

Let me start with a warning: I use Visual Studio 2013 with the v120 toolset to develop the gothic3sdk (see here for the reasons), and therefore cannot guarantee that after upgrading the projects to the v142 toolset everything works as expected. Today I tried building some of the solutions (Script_ModMe, Script_MouseDrag and Script_RemoteControl) with Visual Studio 2019 and the v142 toolset. Both Script_ModMe and Script_MouseDrag built successfully, but the build of Script_RemoteControl failed, because the static libraries libprotobuf-lite-2_6_1.lib and libzmq-4_0_8.lib the project relies are not compatible with v142 (they were built with v120).

I copied Script_RemoteControt to use it as base, then I rebuilt all .sln with v142 toolset and updated paths in .props and project settings to use .lib files from build directory. Also I built them for both Debug and Release, but I guess it doesn’t make sense, right?

Yeah, that does not sound right, and also building Script_RemoteControl with v142 is not possible at the moment. I don't know what you are trying to achieve, but if you do not need the specific functionality from Script_RemoteControl, my advice is to use Script_ModMe as a base project.

The process of cloning one of the Script solutions is a little bit fiddly. I usually do it in the following steps:

1. Make a copy of the Script_ModMe folder, lets name it Script_Example.
2. Rename all the files inside Script_Example from Script_ModMe* to Script_Example*.
3. Replace all occurrences of Script_ModMe with Script_Example in all files (.sln, .vcxproj, .cpp, .h) in the Script_Example folder (I use Sublime Text for that, but basically every tool which can replace text in all files in a folder will work, for example Visual Studio Code or Notepad++. Alternatively you can open the files manually one after another in your text editor of choice, and make the replacements.)

Also, there is suspicious line, public: using bCObjectBase::Write; in some headers, I guess it shouldn’t compile as it tries to inherit private overloaded function.

No, this is fine. If I remember correctly adding these public: using bCObjectBase::Write; lines was necessary in order to tell the compiler that we want to override public: virtual bEResult Write( bCOStream & ); and not private: virtual GEBool Write( bCOStream & ) const;, which would result in an error.

[warxander]

Thank you very much for such detailed feedback!

I solved my problem by switching back to using .lib files from \lib directory. Also, about this line - I was confused by IDE and didn't check if I actually had this error during compilation.

I'm creating a multiplayer prototype for learning purposes and for fun. Any general tips about game code architecture and flow?

Currently I'm planning to use eCEngineComponentBase for manipulating with game world.

[warxander]

Also, I spent a lot of hours trying to understand why I'm not able to link with enet.lib.

What I understood is that SDK is using __stdcall calling convention, while __cdecl is the most common and, unfortunately, mandatory for some sources including ENet.

Could you please comment this?

[georgeto]

What I understood is that SDK is using __stdcall calling convention, while __cdecl is the most common and, unfortunately, mandatory for some sources including ENet.

Could you please comment this?

The SDK uses the __stdcall calling convention because the Gothic 3 uses the __stdcall calling convention.

You have three choices:

• Either change the SDK to use the __cdecl calling convention, for that you probably have to explicitly add the __stdcall annotation to a lot of functions imported from Gothic 3.
• Or modify the enet.h so that all ENet functions are explicitly declared with the __cdecl calling convention. If you link against Enet as a static library you have to change this line to something like #define ENET_API extern __cdecl. If you link against ENet as a dynamic library you have to change this line to something like #define ENET_API __declspec( dllimport ) __cdecl.
• You build ENet yourself with __stdcall set as the default calling convention.

[warxander]

Alright, you already helped me a lot and ENet questions are definitely not related to the original issue. Thanks again!

P.S.: I solved the problem by modifying ENet sources to use __stdcall, it was quite easy (not one line though).

[georgeto]

Good look with your project :)