Forum posts

You'll have to program that (TriAPI, VGUI, or even ImGui or any other UI system you can integrate). There's no way to achieve that via mapping to my knowledge.

Ah, You caught me, good prank?

Thanks for wasting my time I guess.

I've never seen this before, and something tells me you're joking now.

It is most likely another placeholder image. It is Valve's sense of humour.

It's not an actual tool. It is just a placeholder image.

Have you tried copying the sprites over into your mod folder?

Yeah, C++ is quite the beast. I'd be willing to answer any other questions you'd have, whether here or on TWHL Discord, so feel free to ask.

Okay so generally speaking, avoid writing implementation code like this in headers.

class Class
{
public:
    void Method()
    {
       // Avoid doing this if possible
    }
};

// Class.h
class Class
{
public:
   void Method();
}

// Class.cpp
void Class::Method()
{
   // Do prefer doing this in .cpp files - sometimes it may not be possible
}

This is because of how declarations work in C and C++. When a header is #include -ed into a .cpp file, it is literally copy-pasted there, together with other headers. If a datatype is declared above some code, then that code is quite simply "aware" that it exists.

In other words, when writing code in header files, be aware of other headers that may be included, in the .cpp files that include that header.

In this case, chances are CBasePlayer wasn't declared in one of these situations. So you gotta move that code into a .cpp and include player.h to get the CBasePlayer declaration. Or, if you absolutely have to do it in a header, you can use forward-declaration:

class CBasePlayer; // this class is more fully declared elsewhere

Post your code (preferably a good chunk of the .cpp) please. Something doesn't sound right.

Check the datatype of pOther. It's probably an entvars_t* which you first must convert into a CBaseEntity* via some utility.

Yeah, after a few days working with SDK, I'm starting to think that guys from Valve didn't know about any good coding practices or principles back in 1998.

They knew about good principles, they just didn't really have the time to apply em. Between 1996 and 1998, the game spec changed so rapidly and so much, nobody could really keep up. Game code is very patchy, very volatile, and rapidly evolves. It's simply like that by nature.

but I also want to ask how to get CBasePlayer from CBaseEntity

if ( pEntity->IsPlayer() )
{
   CBasePlayer* player = static_cast<CBasePlayer*>( pEntity );
   ...
}

It is possible you were getting errors because you were casting to CBasePlayer and not CBasePlayer*. This is just C++'s value and reference semantics. In C#, a value type is a struct. In C++, a value type is anything that isn't a pointer. So you were trying to, essentially, convert a reference type into a value type there. Possibly, I'm just guessing.

Rule of thumb: if you know an object is of a certain class (e.g. via IsPlayer or checking pev->classname), you use static_cast. static_cast will throw if the cast fails.
If you don't know what object a class is, and you wish to "ask" it, you use dynamic_cast (a bit like the is keyword in C# but simultaneously it's an as)

You may then write a few utility methods into CBaseEntity too, as an example:

template<class T>
T* As()
{
    return static_cast<T*>( this );
}

template<class T>
T* TryAs()
{
    if ( Is<T>() )
    {
       return As<T>();
    }

   return nullptr;
}

template<class T>
bool Is()
{
    return dynamic_cast<T*>( this ) != nullptr;
}

Usage:

if ( pEntity->Is<CBasePlayer>() )
{
   pEntity->As<CBasePlayer>()->DoPlayerSpecificStuff();
   // or
   CBasePlayer* player = pEntity->As<CBasePlayer>();
}

As for flTime and others, that is the absolute time (in seconds) since the client started... something, I am not 100% sure if it's since joining the server or starting up the game altogether, but it's likely the latter.

And yes, gHUD is the HUD singleton. It represents the clientside as a whole, almost a bit of a god object I'm afraid..

Also, the HUD is redrawn every frame no matter what, it's an immediate-mode GUI as opposed to a retained one. So if you changed some colour variables, and they are being referenced in the HUD code, no worries, it'll auto-apply.

Yeah, HL already does this in plenty of places, e.g. to send damage information to clients. What you're describing is a Remote Procedure Call / RPC, and Half-Life implements it exactly via "user messages".

It's a manual, tedious process, but fairly simple to follow:
Serverside: declare a global message ID (inline int gmsgMyMessage) and register it, i.e. link it to a name: gmsgMyMessage = REGISTER_USER_MSG( "MyMessage", -1 ), the last number saying how many bytes are sent in this message, -1 if unknown
Clientside: declare a HUD function and glue it to said message name with some macros, like DECLARE_MESSAGE and HOOK_MESSAGE

Here's a guide for that.

In one of the comments, they say they will make a more technical follow-up video. So, we might find out.

My guess is that it's maybe a particular combination of Half-Life SDK and reverse-engineered CS 1.6 code.

Edit:
Author says in one of the comments:

It is a hybrid server that runs both mods so both HL and CS clients can connect.

This is gonna be interesting.

I didn't notice. I will look at your RMF file soon.

By the way, it's over here on TWHL's tools section:
https://twhl.info/wiki/page/Tools_and_Resources#Compile_Tools
Look for "Vluzacn's ZHLT v34".

It is crashing at some point. It's hard to guess what the cause is, with just a compile log and no screenshots of the map or any further information.

I see that you are using some compilers from 2012? Have you tried using Vluzacn's HL Tools a.k.a. VHLT?

That's a beautiful beam, Windawz

It's going to be very tedious, I'd advise to not bother. If you change the resolution of a texture, you'll have to change so many other things in the BSP as well, i.e. scale down the UVs, which leads to more world polygons (they're subdivided every 240x240 texture pixels), and you never know if you're gonna run into lightmap limitations.

There is no such thing as an "accurate decompilation" because the BSP simply doesn't have much data. It has processed faces, but not whole brushes, best decompilers can do is guess. This means no clip brushes, sometimes no triggers either. If a face is optimised away and removed by the compiler, you cannot get it back. There's just not enough data in the .bsp, simple as that.

In my 10 years of modding, I think I've earned up to 400€, most of which was programming, a small percentage of it being mapping. And keep in mind, this was GoldSRC.

On the other hand, I got way more by getting involved in a couple commercial projects, Source and idTech-related.
So it's definitely possible and it definitely happens, but very rarely so, plus you gotta be exceptional and timely. After all, it is professional work you'd be offering.

I remember being 14 and trying to figure out this specific thing, almost a decade ago. I remember I did some stupid nonsense thing to get it to compile, and then it crashed whenever the monster looked at me. I've come a long way since and, even though this would be super easy for me now, it gives me a unique kind of satisfaction, justice almost, to see someone publish a solution. Thank you.

I sure wonder why they returned null in GetScheduleOfType, probably an SDK difference of some sort? In either case you can also edit the tutorial itself.

Personally, i strongly believe they are developing something

I'm sure they're always developing something. I'm guessing that, right now, the gamedev work is mainly distributed across Deadlock (production and testing) and Counter-Strike 2 (maintenance and hopefully content updates), with maybe, maybe just a little bit of wiggle room? For an unannounced game in an early prototyping stage?

But then again, that's just a guess. I might be forgetting to take plenty of things into account.

Hello! In order to mod CS the way you're thinking, you need to have its whole source code. All of the weapons, gamemode rules etc. Unfortunately, there's only an official SDK for Half-Life, and an unofficial OpFor SDK, nothing for CS.

So, the best thing you can do is to replicate CS 1.6 in a HL mod, which is a respectable amount of work, annnd yeah, stuff like adding new weapons requires a good bit of C++ and HL SDK experience.

Valve leaves traces of game prototypes and does other stuff out of practical reasons, which some people misinterpret as them secretly working on something. I honestly really doubt they're working on anything Half-Life-related on a meaningful scale.
(one or two people could be developing some mini prototype at any point, but for it to have any meaning, it needs to be in actual production)

The "White Sands" stuff isn't really telling of anything, the Black Mesa biotech company very much looks like a fan-made thing, and everything else is just a whole bunch of nothingburger, nothing to get excited about, really.

There's also the possibility that Valve is intentionally trolling us. If I worked at Valve, I'd do the same just to spite the community. Waiting for HL3 has been a meme for such a long time, it makes perfect sense to make fun of it and people's never-ending hope for the game. It's almost a bit like, uhh, Minecraft removing Herobrine every update.

Me personally, I couldn't care less at the very moment. If it turned out that I was way too sceptical and Half-Life 3 actually got a trailer one day, great, I'll probably get very excited for a brief moment. If it never happens, no big deal, I never expected it anyway.

You seem to have custom DLLs. Did you build both hl.dll and client.dll? In fact, tell us how exactly you made the mod i.e. what you've put into the mod folder.

My guess is that the 25th anniversary has custom HUD rendering code right in the client DLL. However, it is possible to do the sprite drawing yourself using the Triangle API (you manually submit triangles to the renderer), and I'm pretty sure some folks have already done stuff like that. I don't recall any GitHub repositories off the bat, I'll let you know though

Make sure you've installed Visual Studio 2022 properly, with a Windows SDK. Then make sure to upgrade the solution to the latest MSVC (in VS2022 it's v143, in VS2019 it's v142 etc.)

Nope. HUD colour is hardcoded, and changing it requires code changes.

Remember: the more stuff you make, the faster you'll get at it, and it will be less of a chore to make it in the future

Or remove the line that gives the MP5 grenades to the player.

Could you provide a screenshot of the error?

TrenchBroom stuff is in my plans. Hammertime will be interesting to see.

That's quite odd. I don't suppose there are any cue points or anything in there, GoldSRC tends to be very picky about those.
This will need some testing in an isolated map t.b.h.

If I recall correctly, voicelines should be up to 11 kHz, mono, unsigned 8-bit PCM, so that the engine can perform crude lip sync.
Other sounds (ambience, gunshots etc.) can be up to 22 kHz, mono, unsigned 16-bit PCM.

Oh by the way, for future reference, technical questions go here:
https://twhl.info/forum/view/goldsource
The "Maps and Mods" category is more for showing off map/mod projects... not that it has been enforced much lately x3

Upload to the TWHL Vault and then everybody can rip it apart!

It's that time of the year again.

Probably means flickering.

New tutorials are always appreciated, so much so we have a special place for them: the TWHL wiki

Hello!
You should definitely look into CGameRules and the code around it.

The class: https://github.com/SamVanheer/halflife-updated/blob/master/dlls/gamerules.h#L61
HL deathmatch gamemode: https://github.com/SamVanheer/halflife-updated/blob/master/dlls/gamerules.h#L260
Gamemode factory: https://github.com/SamVanheer/halflife-updated/blob/master/dlls/gamerules.cpp#L371

You can basically select your different scenarios in InstallGameRules (assuming they'd be implemented as gamerules) instead of mangling with different DLLs. The latter could be pretty messy.

I'm down for writing a number of beginner tutorials. I could allocate some time to write them all by New Year, just need a bit of a plan first.

You get to the next map via an elevator I think? This is just before Office Complex yeah.

What ends up happening is you're going between 2 maps that depict basically the same area, you just kinda do a "U-turn" in terms of levelchanges to get to the other side of the (destroyed) bridge in map 1.

You mention a new ammo counter for a specific weapon. That'd require keeping track of a tertiary ammo source, which would require changes to some of the prediction code too.

Can you show your code? I just realised this thread is 2 months old, I've no idea how I managed to miss it...

Yeah, I would advise against using ChatGPT for GoldSRC-related stuff, because there isn't much information about it. It has worked okay for doing my brother's Bosnian homework (writing little poems etc.), but I'd definitely not use it for this.

You can just use CVAR_SET_FLOAT:

// Gravity will vary +/- 400
#define GRAVITY_VARIATION 400

int myRandomGravity = 800 + rand() % GRAVITY_VARIATION;

CVAR_SET_FLOAT( "sv_gravity", myRandomGravity );

But of course, there are ways to convert numbers into strings (the values in quotation marks are called "strings").

Files like health.cpp, battery.cpp etc. implement their own HUD elements with exact coordinates in them.

I'll give you a bit of a detailed explanation so you mechanically know what's going on, if that makes sense.
For example, battery.cpp starts with:

//
// battery.cpp
//
// implementation of CHudBattery class
//

Implementation of CHudBattery huh... what's that?
It is defined in hud.h:

class CHudBattery : public CHudBase
{
public:
    bool Init() override;
    bool VidInit() override;
    bool Draw(float flTime) override;
    bool MsgFunc_Battery(const char* pszName, int iSize, void* pbuf);

private:
    HSPRITE m_hSprite1;
    HSPRITE m_hSprite2;
    Rect* m_prc1;
    Rect* m_prc2;
    int m_iBat;
    int m_iBatMax;
    float m_fFade;
    int m_iHeight; // width of the battery innards
};

Each of these HUD elements are C++ classes, which inherit from CHudBase. The HUD system contains a collection of these CHudBase based objects.

Now, here's the thing. When the HUD wants to actually draw itself onto the screen, it visits each of these elements and asks them to render themselves. This is what the Draw functions are for. If you want to find what coordinates are used, you would simply find, for instance, CHudBattery::Draw, like so:

bool CHudBattery::Draw(float flTime)
{
    if ((gHUD.m_iHideHUDDisplay & HIDEHUD_HEALTH) != 0)
        return true;

    int r, g, b, x, y, a;
    Rect rc;

    rc = *m_prc2;
    rc.top += m_iHeight * ((float)(100 - (V_min(100, m_iBat))) * 0.01); // battery can go from 0 to 100 so * 0.01 goes from 0 to 1
    UnpackRGB(r, g, b, RGB_YELLOWISH);

    if (!gHUD.HasSuit())
        return true;
... // rest of the code

Scrolling down in the same function, we see this code:

y = ScreenHeight - gHUD.m_iFontHeight - gHUD.m_iFontHeight / 2;
x = ScreenWidth / 4;

// make sure we have the right sprite handles
if (0 == m_hSprite1)
    m_hSprite1 = gHUD.GetSprite(gHUD.GetSpriteIndex("suit_empty"));
if (0 == m_hSprite2)
    m_hSprite2 = gHUD.GetSprite(gHUD.GetSpriteIndex("suit_full"));


SPR_Set(m_hSprite1, r, g, b);
SPR_DrawAdditive(0, x, y - iOffset, m_prc1);

if (rc.bottom > rc.top)
{
    SPR_Set(m_hSprite2, r, g, b);
    SPR_DrawAdditive(0, x, y - iOffset + (rc.top - m_prc2->top), &rc);
}

This says "Hey GoldSRC, please render a sprite at these coordinates here". SPR_Set tells the engine to use a certain sprite, and SPR_DrawAdditive tells the engine to draw it. So, now you might be wondering what's up with these x and y variable things. You can declare your own temporary variables to essentially "chain" HUD elements one after another, so you don't have to manually specify every single coordinate yourself. You can use it to say "the next one will be 5 pixels more" etc.

Now if you actually know C++ and stuff, woops! I tend to assume people don't know, and this may be useful to people in the future anyway, so yeah.

So, generally, it boils down to maths. You just gotta read the code really well to see where the coordinates are defined, and you'll be fine. You can change it to whatever you want, whether it's moving something from the bottom-left corner into a top-right corner, or make them bounce up'n'down through time and anything you can imagine.

It teaches you about programming map entities, weapons and such. It will help you if you know C++ programming fairly well from the start.
You can also check out programming tutorials here on TWHL.

Also hi, I made that

In the latest HL Updated SDK, some places in the game code use the gravity CVar for certain things: Other than that:

• HUD_TempEntUpdate has a cl_gravity parameter,
• pmove_t has a gravity member,
• CWorld::Spawn sets the value of sv_gravity

Definitely do a keyword search for "gravity" across the entire codebase, you'll find all possible references to it there. For a randomiser, I believe it may be the best to do it in CWorld::Spawn if each level is essentially randomised.

Even then, the player hull is kinda hardcoded in the engine's physics code.

Oh I remember ya from the ModDB article about making realistic, atmospheric scenes. This is lookin' pretty good!

Oh, thank MrFloyd for that, I was just doing some programming there x)