If I unpack a zip of my mod and try to run it, the game crashes before reaching the splash screen, with the error in the title: "Could not load library - client.dll" along with the path to steamapps/common/... (where the working client.dll file is located).

If I replace my client.dll with an older version that was released in 2006, it has the same error.

If I rename client.dll so there isn't a client.dll present, the game reaches the splash screen without error.

If I unzip my mod on a system that has previously installed an older version of the mod (using the installshield exe provided), the new DLLs work. I still don't know what the difference is to cause this, so I'm trying to just look at the problem ignoring this..

There are lots of google results for this, but they are for source mods and pre-steam versions of half-life. Any suggestions?

The text was updated successfully, but these errors were encountered:

Not sure - maybe file permissions? Is there any difference in the old and new versions' liblist.gam files? I think there a couple of client.dll-related keys that can be set.

The new liblist has a different version key and adds the 'edicts' key to prevent an awful crash.

I tried using the old liblist as well, with no luck.

I don't think it should be file permissions either - if I've already installed the old version, the new files are loaded just fine by hl. As I say, I still can't figure out what the old installer is doing to avoid this (that just unzipping the files is not).

Hm, any differences in the various .cfg files? And if you do a symbol dump on the client.dll files do they both export the same things? Probably a long shot as I think the engine will be specific if you're not exporting an interface, but it might be worth a check. Also, maybe try with a debug/release client.dll instead.

I have wondered if it's something in the way I build. Definitely tried both debug/release profiles, no luck there..

The weird thing is my DLLs can work (but only if you have run the installshield exe from 2006 to set up the old version). If I just paste in the DLLs from the old installer (without running it), I get the same error. I guess I need to see what the installer does (other than paste files) because it seems important? Hrmmm.

Now that is odd. Is the .dll from the installer identical to copy+pasted .dll (if you compare file sizes, contents and so on)?

I've been experimenting some more..

If I paste the new version over the old one on a Windows XP virtual machine, it doesn't work. Nothing seems to make my new binaries work on XP (and it seems like the installer isn't related, thank god!). They work on Windows 7..

It feels like this is something about my binaries/build process, as you were thinking. Can't quite place it yet but I'll keep looking..

And actually, without looking at symbol tables and stuff directly, you're on to something.

-Only with the new binaries- I get these errors in the console:

Can't find address: 647f385a Can't find address: 647f12d0 Can't find address: 647f385a Can't find address: 647f12d0 ...

Must be something we aren't exporting, that the old ones are. Maybe it can't run without these functions on XP but it can on W7? Something like that?

More on the same point: If I build with the source code from 2006 and my current build process, I get the exact same behaviour (missing functions on W7, startup crash on XP). So it's down to the build process now.

Are there guidelines somewhere about this so I don't have to just go and use some random visual studio version and project file?

I would have though the Visual Studio project was set up correctly - I guess you haven't gone and fiddled with any settings? I think I've seen a similar error to the "Can't find address", but in the server .dll - I think I'd done something wrong with LINK_ENTITY_TO_CLASS, though as I think more those may have been debug messages. Is "Can't find address" yellow or red? And if you search through the code is it there or in the engine? Maybe it's something to do with the message handler export macros?

@johnstt

I don't know about the can't find address errors, maybe you are having two different problems.

But appart from that, what is your project setting for Configuration Properties -> C/C++ -> Code Generation -> Runtime Library? It should be Multi-threaded (/MT) for Release and Multi-threaded Debug (/MTd) for Debug builds. At least unless you want to deploy the otherwise required Microsoft DLL files on the target system.

Please don't be angry if that idea is wrong :-) If it was right, then please check your other project settings against these, to avoid other problems.

Yeah, I have that setting. Checking against that project file is still on my 'to do' list... hopefully I get to it soon and update this :}

Thanks!

Oh :( Are you using any other DLL files in your client.dll that might depend on some CRT DLL files? (I recall some mods did that).

Ooh, lots of awesome ideas. Thanks very much! I'll try these shortly.

I highly recommend the usage of WinDbg as debugger for HL1 mods, when I was implementing the custom audio engine using FMOD Studio for ARRANGEMENT I had some memory leaks which VS2013's debugger wasn't helpful but WinDbg was.

Did you ever work it out?

Nope! Planning to work on it again soon.

I just tried patching visual studio with the link from ripieces. The binaries made with that magically seem to work! (without any setup after patching VS)

So I guess that's good! Maybe I'll learn the details later but this is great for now. Thanks, folks!

While that is great to hear, that could mean we will run into a lot of problems if we update the compiler version to 2012 or newer :-(

Are you sure those "Can't find address: %08lx\n" for debug builds are gone too? I would have thought those problems were unrelated.

@ripieces For our mod ARRANGEMENT, we use VS2013 compilers (v120) and we've got the same behaviour as if we were using VS2010 compilers (v100). XP compilers work too but they don't make much difference, so theorically, VS2012 compilers (I presume v110) should also work.

However, I tried to use VS2015 compilers (v140) on my Windows 10 VM and they fail compiling the source code.

The 'can't find address' stuff still happens, yeah.

Not sure about VS versions and stuff...it would be good to separate the build process from VS and just have some clear directions about a makefile and toolchain..

As said you can enable _DEBUG build to find the functions that miss the CBASE_DLLEXPORT / EXPORT macro.

@johnstt

I managed to compile Half-Life's source code in Visual Studio 2015 RC (community edition). You can find it here. Deprecation warnings have been removed, so the code should proficiently build. It works for all projects with dmc, hl, ricochet.

I might attempt to fix utilities (utils.sln) and get them to build properly. In the case of mdlviewer, this could be replaced by Chumbalum Soft's version.

Hope this helps.

I'm actually still looking at this because using the vs2012 patch didn't help (not sure why I thought it did...)

@malortie : Have you tested if your half life client DLL works on Windows XP?

edit: Here is my current problem (to reiterate) - if I have my client.dll in the proper path, I get the error "could not load library client.dll". If I have no client.dll whatsoever, the game starts up (and crashes when you try to join a server, because it's using the half-life client.dll)

So..what needs to be true about my client.dll for hl to load it? That's probably what I really need to know (VS versions and so on don't seem to be a direct cause).

You should really consider using WinDbg. It can even load symbols (.pdb) and source files, if you point it to the right directories (make sure to tick reload checkbox in case you are already attached to the process when setting them).

Are you sure you set v100 for both Release and Debug builds? Maybe you switched between release and debug and it's not set? (S.th. like that happened to me once.)

Also I suppose you are using a Release build for Windows XP, because debug builds usually only work in own environment where the Visual Studio is installed (because of missing DLLs)?

Edit: forget about that previous paragraph, since you / Half-life are compiling static libraries, meaning Debug should work too.

@ripieces: Debug builds should always work for people who don't have Visual Studio or any C/C++ related development/debugging stuff installed.

@johnstt: I recently had the Can't find address problem in my mod and I managed to fix it, please note that this solution may not work for you as your problem is related with the client DLL. But I'll share my solution anyways because you may find it useful and others modders may came accross the same problem.

Here's the context: I'm making a CTF (Capture The Flag) game mode for my mod, so I need to code 2 entities, the flag itself and the capture zone.

And now straight to the point, aka the Can't find address problem, how can it happen and how to fix it, take a look at this code which I simplified a lot so you can understand:

// CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

void Spawn( void );
void EXPORT Think( void );
void EXPORT Touch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

SetThink( &CCTFFlag::Think );
SetTouch( &CCTFFlag::Touch );

} void CCTFFlag::Think( void ) {

ALERT( at_console, "CCTFFlag::Think\n" );
pev->nextthink = gpGlobals->time + 0.1;

} void CCTFFlag::Touch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFFlag::Touch\n" );

} // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

void Spawn( void );
void EXPORT Touch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

SetTouch( &CCTFCaptureZone::Touch );

} void CCTFCaptureZone::Touch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFCaptureZone::Touch\n" );

}

When I wrote this, I told myself: "It will be fine", so I pressed the "Build solution", and no errors/warnings were shown, good so far. Then I start my mod, start WinDBG, attach WinDBG to hl.exe, start my local CTF server and I had no Think related spam for CCTFFlag. I tried to touch a CCTFCaptureZone and nothing. I opened the console and took a look a bit after the server started and I saw the Can't find address lines.

After 20 minutes of raging, tweaking something here, tweaking some there, I realize by looking 10 times at others entities within the same file (

// CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

void Spawn( void );
void EXPORT CTFFlagThink( void );
void EXPORT CTFFlagTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

SetThink( &CCTFFlag::CTFFlagThink );
SetTouch( &CCTFFlag::CTFFlagTouch );

} void CCTFFlag::CTFFlagThink( void ) {

ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );
pev->nextthink = gpGlobals->time + 0.1;

} void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );

} // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

void Spawn( void );
void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );

} void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );

}

1), that all

// CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

void Spawn( void );
void EXPORT CTFFlagThink( void );
void EXPORT CTFFlagTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

SetThink( &CCTFFlag::CTFFlagThink );
SetTouch( &CCTFFlag::CTFFlagTouch );

} void CCTFFlag::CTFFlagThink( void ) {

ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );
pev->nextthink = gpGlobals->time + 0.1;

} void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );

} // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

void Spawn( void );
void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );

} void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );

}

2 had unique names, so I changed a little bit my code so it look like this:

// CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

void Spawn( void );
void EXPORT CTFFlagThink( void );
void EXPORT CTFFlagTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

SetThink( &CCTFFlag::CTFFlagThink );
SetTouch( &CCTFFlag::CTFFlagTouch );

} void CCTFFlag::CTFFlagThink( void ) {

ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );
pev->nextthink = gpGlobals->time + 0.1;

} void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );

} // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

void Spawn( void );
void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );

} void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );

}

I had no more Can't find address and got my

// CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

void Spawn( void );
void EXPORT CTFFlagThink( void );
void EXPORT CTFFlagTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

SetThink( &CCTFFlag::CTFFlagThink );
SetTouch( &CCTFFlag::CTFFlagTouch );

} void CCTFFlag::CTFFlagThink( void ) {

ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );
pev->nextthink = gpGlobals->time + 0.1;

} void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );

} // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

void Spawn( void );
void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );

}; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );

} void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );

}

4 spam, also touches were detected, in other words: everything worked like a charm. Hope this little "story" will be useful to you or any other modder which has the same problem.

@JoelTroch thank you for the info about the function names having to be unique in the whole class hierarchy.

I think the reason for that is the pointer casting trickery :

# define SetThink( a ) m_pfnThink = static_cast  (a)

However at the moment I am thinking that the Can't find address problems were completely unrelated to that! I am not even sure if the EXPORT is required on those Think and Touch function, but honestly I don't know right now. (I know Valve did it like that almost everywhere, but cannot find a reason for that right now.)

I am stupid, sorry. The EXPORT macro is required, at least for the Debug builds, I am not sure though under which conditions the engine will call in there.

Sorry for my lack of knowledge :-(

@johnstt @tschumann @JoelTroch @ripieces

Despite the fact that the following message is not related to client.dll loading, but since it concerns most users struggling with VS versions or still are using ulterior versions such as VS2010, I believe it would be better to let as many people be aware of the following:

As promised, I managed to fix source code related issues related to warnings/deprecate, except for CRT functions, as using CRT recommended functions would require certain tweaks in various files, such as extra arguments. In addition to this, the fix prevents typical warnings such as precision loss, unreferenced variables, already defined macros, and other warning seen in the current master branch from being triggered.

In short, no more required warning suppression to prevent compiler from generating warnings such as:

The POSIX name for this item is deprecated. Instead, use the ISO conformant name: ...

To solve this, I created two files: warning.h;vstdlib.h in public/vstdlib. warning.h is to help setup preprocessors to enable or disable the fix, while vstdlib.h includes macros to make future POSIX transitions easier.

If you look into the current source engine build, you will notice Valve uses macros such as Q_strncpy, Q_memset, which are all defined in a particular file, which associates macros to C standard functions based on OS, build configuration.

The same procedure was applied here. I had to go through every C standard library functions call in both projects.sln and utils.sln and replace them with Q_* alternatives, which are associated in public/vstdlib/vstdlib.h.

I also promised to give you a working solution for Visual Studio 2010.

Here is a link to my branch.

Note: I deleted my old branches (Do not worry, I made backups) to clean all the monolithic pull requests I'v made.

Before attempting to do other pull requests, I encourage you to take a look at the current one, which contains all fixes specified above.

Please, let me know what you think. I am always forward to improve my work as well as commit skills and I cannot think of better people than you to help point me in the right direction.

Hope it helps.

@malortie

Thank you for your good work.

I checked your changes and these are the things I noticed, that you might want to address in a further commit to the same branch:

• if you include // CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

  void Spawn( void );  
  void EXPORT CTFFlagThink( void );  
  void EXPORT CTFFlagTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

  SetThink( &CCTFFlag::CTFFlagThink );  
  SetTouch( &CCTFFlag::CTFFlagTouch );  
  

  } void CCTFFlag::CTFFlagThink( void ) {

  ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );  
  pev->nextthink = gpGlobals->time + 0.1;  
  

  } void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );  
  

  } // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

  void Spawn( void );  
  void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

  SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );  
  

  } void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );  
  

  } 6 in those files, then the definition of // CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

  void Spawn( void );  
  void EXPORT CTFFlagThink( void );  
  void EXPORT CTFFlagTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

  SetThink( &CCTFFlag::CTFFlagThink );  
  SetTouch( &CCTFFlag::CTFFlagTouch );  
  

  } void CCTFFlag::CTFFlagThink( void ) {

  ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );  
  pev->nextthink = gpGlobals->time + 0.1;  
  

  } void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );  
  

  } // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

  void Spawn( void );  
  void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

  SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );  
  

  } void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );  
  

  } 7 should not be required in the project files, since those headers already defined. Not sure about the // CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

  void Spawn( void );  
  void EXPORT CTFFlagThink( void );  
  void EXPORT CTFFlagTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

  SetThink( &CCTFFlag::CTFFlagThink );  
  SetTouch( &CCTFFlag::CTFFlagTouch );  
  

  } void CCTFFlag::CTFFlagThink( void ) {

  ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );  
  pev->nextthink = gpGlobals->time + 0.1;  
  

  } void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );  
  

  } // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

  void Spawn( void );  
  void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

  SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );  
  

  } void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );  
  

  } 8 define, maybe include that in warnings.h somehow too, if it is required at all?
• // CCTFFlag - Multiplayer Capture The Flag - Flag entity class CCTFFlag : public CPointEntity { public:

  void Spawn( void );  
  void EXPORT CTFFlagThink( void );  
  void EXPORT CTFFlagTouch( CBaseEntity pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( info_ctf_flag, CCTFFlag ); void CCTFFlag::Spawn( void ) {

  SetThink( &CCTFFlag::CTFFlagThink );  
  SetTouch( &CCTFFlag::CTFFlagTouch );  
  

  } void CCTFFlag::CTFFlagThink( void ) {

  ALERT( at_console, "CCTFFlag::CTFFlagThink\n" );  
  pev->nextthink = gpGlobals->time + 0.1;  
  

  } void CCTFFlag::CTFFlagTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFFlag::CTFFlagTouch\n" );  
  

  } // CCTFCaptureZone - Multiplayer Capture The Flag - Capture zone entity class CCTFCaptureZone : public CBaseTrigger { public:

  void Spawn( void );  
  void EXPORT CTFCaptureZoneTouch( CBaseEntity *pEntity );  
  

  }; LINK_ENTITY_TO_CLASS( func_ctf_capture_zone, CCTFCaptureZone ); void CCTFCaptureZone::Spawn( void ) {

  SetTouch( &CCTFCaptureZone::CTFCaptureZoneTouch );  
  

  } void CCTFCaptureZone::CTFCaptureZoneTouch( CBaseEntity *pEntity ) {

  ALERT( at_console, "CCTFCaptureZone::CTFCaptureZoneTouch\n" );  
  

  } 9 and project files: what's up with these VS_2010_FIX, VS_2010_FIX_POSIX, VS_2010_FIX_CRT macros, I think those are not required (just use the Q_\ version)
• you are not using filecopy.bat anymore in the projects, this will have an impact on Valve's automated build process, due to the calling of the p4 command
• in `

define SetThink( a ) m_pfnThink = static_cast (a)

0 you didn't include vstdlib.h and warnings.h. while this file might be a leftover and not used actually anywhere, you might still want to add those for consistency there (since you did it in the other files where the max / min /abs macros were present). (This list item is not that important, you can ignore it)
in  
`  

# define SetThink( a ) m_pfnThink = static_cast  (a)  

1 you introduced project dependencies, those are not necessary afaik, the projects should compile in any order! Maybe remove those dependencies again, please.

I didn't compile that branch yet, but will do later, after you decided whether to address these list items above or not.

Edit: PS: Sorry that I comment here, but you haven't enabled issues feature in your repository.

@ripieces

Thank you for your response.

I fixed all points you mentioned and enabled issues feature in my repository. You should be able to comment on my branch.

Here is the link

The VS_2010_FIX macros were temporary macros used to locate modifications. I did not see the remaining ones, as they were not listed as part of the solution when I was doing Find/Replace in VS2010. I do apologize.

I restored filecopy.bat calls in Postbuild events, but still kept my additional manual copy, as I currently do not have perforce installed, which would result in build failure. Although DLLs build correctly, this would require users to manually copy files to their mod folder.

I finally have an answer to my root problem (cannot find client.dll etc). It was nothing to do with my code, or visual studio, or whatever other stuff.

Apparently the game uses 2 DLLs that are put in Half-Life/ (before the mod path) by the old installer: cg.dll and cg_GL.dll (a graphics API thingy). If it doesn't see those, it gives that totally unrelated error message about client.dll. The fact that the error message was SO misleading cost all of us a lot of time and I'm frankly really disappointed to be writing this.

So I guess we got a lot of insightful discussion out of this, but it's sort of a letdown that the real answer was so dumb. Ah, well!

I've got the same problem when i start modding, i downloaded the source and opened projects.sln file and pressed build,the build done successfully but when i tried to run the game i got "Could not load library client.dll". so i used dependency walker and opened the client.dll file and there was one entry point with a red sign near to it called "GetMousePos@Surface@VGUI",used to get the mouse position in Vgui surface or something ,even though the compiler didn't complain and the linker didn't issued unresolved external error,the weird thing is that my code and the client code dont make any call to this function to get mouse position but to "GetMousePosition" and "GetMousePos" functions exported by the engine in APIProxy.h file, so i thought that the linker got confused and link against "GetMousePos" which located in "VGUI_Surface.h" Surface file ,so i simply and temporally turned the function declaration in Vgui surface class into a comment and rebuild the solution and the red sign in dependency walker gone and the mod worked fine

Regarding the EXPORT macro: it's required for save/restore. The save/restore code looks up the name of think/touch/blocked/use methods through the engine, which in turn looks them up using dllexport tables. It maps addresses to names and vice versa. If you're making a singleplayer mod, you must include EXPORT on all such methods for it to work.

If you have the time you can separate the engine and game save/restore code and use TYPEDESCRIPTION to store this information instead, but that's a lot of work.