public/tier1/interface.h does not exist

[Thothie]

https://github.com/ValveSoftware/halflife/blame/master/public/interface.h

Requires #include "tier1/interface.h" to compile in VC7.

Said file does not exist anywhere in the SDK (nor does the directory, for that matter.) The only file of the same name, is the one with this include.

Not sure how some folks are even compiling this, given that.

[alfred-valve]

You need to use msdev 6.0 to compile HL1 mods, newer compilers are not supported (and may or may not work). Removing that ifdef may unblock you for now.

[Thothie]

So this is no longer VS2003 compatible? (Or even VS2005 compatible?) Where do I even find a msdev that old? :\

Sadly, removing the ifdef just results in massive nonsensical compile failures.

And given that the include to the non-existent file is there, does this mean it is pending?

[Wasdsensei]

Yeah, that would be silly, given that the two previous SDK releases compiled in Visual Studio 2003 and 2005 just fine. It's hard enough to track down compilers that old, nevermind the prehistoric 6.0.

Trying to fix the same mouse issues for our mod, the same way, with the same issues.

I updated inputw32.cpp Added its dependencies from the GIT (../lib ../public) I removed the ifdef to no where in../public/interface.h ...added the additional library dependencies to the linker: ../lib/public/game_controls.lib ../lib/public/SDL2.lib ../utils/procinfo/lib/win32_vc6.lib And updated ../utils/vgui/lib/win32_vc6/vgui.lib from the new GIT (already a dependent).

But now, with a clean rebuild, I get this: cl_dll error LNK2019: unresolved external symbol _SDL_GetRelativeMouseState referenced in function "void __cdecl IN_MouseMove(float,struct usercmd_s *)" (?IN_MouseMove@@YAXMPAUusercmd_s@@@Z)

Like the function wasn't found in the library, or something. I don't see any other new libraries to include, so...

[alfred-valve]

SDL_GetRelativeMouseState should be exported by SDL2.lib.

[Thothie]

@Wasdsensei

You may have done something similar to what I did, and forget to replace your dependencies for every build. (Although my initial problems were caused by a lack of proper cleaning as well.)

Now, with the procedure put there by you, it seems to compile in VS2003.

BTW, our dependencies are: AdditionalDependencies="../nvidia/lib/cg.lib ../nvidia/lib/cgGL.lib ../nvidia/lib/glut32.lib ../utils/vgui/lib/win32_vc6/vgui.lib ../lib/public/game_controls.lib ../lib/public/SDL2.lib D3d8.lib D3dx8.lib glaux.lib glu32.lib opengl32.lib winmm.lib wsock32.lib ../utils/vgui/lib/win32_vc6/vgui.lib ../utils/procinfo/lib/win32_vc6/procinfo.lib"

You can skip/redirect the nvidia gl libraries if you aren't using them (they are for our bloom function). I'm also not sure if the procinfo.lib is required - I just grabbed and updated every library from the GIT to be thorough.

Now, Alfred fixed the bug that inspired this effort, so we may not need it anymore... But as it seems to be working this way... I guess we should do it this way, in case the SDL2 updates, or something.

Might be worth noting that you can get the latest SDL2 libraries yonder: http://www.libsdl.org/download-2.0.php But hopefully the Goldsrc team will remember to update the library in the GIT, should they choose to migrate.

So, yeah, this thing WILL compile in VS2003, with the edit to this ifdef... Which is good to know. :)

[alfred-valve]

As push request with the edit(s) to make vs2003 (and the vcproj's?) would be appreciated by the community I expect :)

[dtugend]

I'd honestly prefer one of the free VC Express editions (2010 / 2012 / 2013, though with 2012 you need to pay a bit attention so that the code runs on older Windows versions). But I don't plan making a modification of Half-Life, so maybe my opinion doesn't count (the HL SDK code we use compiles in Visual Studio C++ Express 2010 flawlessly).

[Thothie]

Well, the previous two SDK's compiled in VS2003 and VS2005 respectively - indeed, they recommended VS2005 in the last release (SDK 2.3?). VC 6.0 isn't available for purchase anywhere - you'd have to sail the seven seas for that... So if you make this SDK VC 6.0 only, you're basically telling all the modders to become pirates. ;)

If it'd compile in the latest free editions of VS, that'd be even better, of course - but a suite of vcproj's for broad spectrum compatibility would be best, given how many legacy mods there are that can be difficult to update.

Given that we have an include here that points to a nonexistent file, however, I'd call that a bug. :) Even if the line isn't reachable under the intended compile tools, there's no reason for it to be there, and it should be undone.

[alfred-valve]

If someone wants to supply a code patch I would be happy to consider it, but we only compile this codebase with VC 6.0 so I don't have the ability to effectively test the requested change.

[Thothie]

Well, it seems all you would need to do is remove the include to no where error... The rest, in our case at least, seems to have been simple user error and not the fault of the SDK. (At least holds true for compiling in VS2003.)*

Where do you guys get VC 6.0, btw? (Or should I not ask?) ;)

• That is, assuming you have no more "if _MSC_VER >= 1300" lines in the SDK with other non-existant includes. I've only tried adding the inputw32.cpp changes, and this came up with one of its includes - so there maybe other similar ones in there, but I don't think so.

[alfred-valve]

We have copies of VC 6.0 in the building from the Half-Life 1 days still.

[Thothie]

Well archive those well, my friend, as I can tell you, even on the seven seas, you'll be very hard pressed to find enough seeds to grow new ones, if you know what I mean, and thar be no other place to go. ;)

Also wonder how much longer it'll continue to operate under newer Windows revisions. Though, I suppose, you can always use an XP vbox to compile, if it comes to it.

But again, just remove the include - and any similar occurrences - and that maybe enough. Kinda makes me wonder if the file ever existed though, and what was in it (I mean, why would one put up an include to a file that doesn't exist?)

[joropito]

Just for reference, newer VC needs some changes

• 'ARRAYSIZE' macro in 'engine\eiface.h' needs to be undefined, a macro with the same name which defined in 'winnt.h'
• 'HSPRITE' type on the client should be renamed to 'SpriteHandle_t' due to 'windef.h' which defined same-named type for itself. I hope you will like this new typename. :)

http://www.moddb.com/games/half-life/downloads/half-life-sdk-v23-for-visual-studio-2008

I have this sdk workin with VC2008 and VC2010

[joropito]

@alfred-valve how can I push or submit my changes?

[dtugend]

If someone wants to supply a code patch I would be happy to consider it, but we only compile this codebase with VC 6.0 so I don't have the ability to effectively test the requested change.

Last time I checked the license there weren't restrictions on commercial use with Microsoft Visual C++ 2010 Express. You are only required to register your product after 30 days or so. (Exception from that being Silverlight video codecs (H.264/AVC Visual Standard, and the VC-1 Video Standard) that are being shipped for private and non-comercial use only.)

[alfred-valve]

@joropito , check out the github help pages on how to use git and their branches.

[dtugend]

@joropito @alfred-valve :

I am currently in the process of addressing this and atm manually (VC++ 2010 Express doesn't support auto-conversion) converting the HL, DMC and ricochet dsp to vcxproject.

There are two other options

(a is what you said, renamin HSPRITE and ifdef undef the macro and there are a few more changes to do actually, i.e. sqrt(someint) is ambiguous now)

b) using push and pop macro and namespaces around the window.h includes (not 100% sure if namespaces will solve HSPRITE ambiguity, have to try).

c) Making a new .h file that supplies the windows functions used in the SDK and encapusulates them into a .cpp file where windows.h is included, meaning windows.h would only be included in that cpp from now on. This way we could switch the functions for Linux there too and would replace all windows.h includes with the new .h file. Thus platform specific function mappings could be managed inside a single .cpp file, and we could avoid having to rename HSPRITE.

I prefer c) but don't have a good name for the file yet.

However I don't know if a) or c) is better? Maybe someone has an even better idea?

[joropito]

@ripieces have you tried to undef HSPRITE? before defining it? Also you can do something like this:

define HSPRITE deleted_HSPRITE

include

undef HSPRITE

Another way:

Rename HSPRITE to HL_HSPRITE on each file from sdk.

I had not time yet to check my modifications to push here.

[dtugend]

Have yet to try that.

I think c) is problematic, I haven't thought it through properly enough: I would want the MAX_PATH macro to be the value from windows.h, however if I am including it in a separate .cpp I won't get the value out from there (at least not for use in array definitions).

:...(

Edit: maybe could work around it with extern const MAX_PATH; Edit2: but then I would get in trouble when trying to assign the const MAX_PATH [constant meant] = MAX_PATH [macro meant]; But maybe I can get around that too :) Edit3: working around it won't work, since extern const is not a constant expression.