Forum posts

If you want to add new weapons & monsters, you absolutely need code access. If HL1 MMod isn't source-available, you are out of luck. Base HL SDK / HL Updated SDK doesn't have any of the additions MMod has.

BTW Half-Life SDK, not exactly Source SDK~

You mean: Also yeah that is quite unusual.

You can do it only with a custom mod that has a veeery proper implementation of movewith / parenting (not Spirit of HL). I wrote a couple entities that specialise in that for HL:WAR. If not a programmer, consider the above solution.

After what felt like thirty years, here it finally is: A bit rushed, and has a little audio bug somewhere around the 10th minute... d'oh well, mistakes are made. I'll have to see if new versions of DaVinci Resolve have this audio problem.

I'm not sure if it can actually move by itself, I'll have to take a look at the code tomorrow.

Well, that depends entirely on the animations themselves. You can inspect them in Blender and roughly see how far they go, I think.

You may begin by editing the VGUI resource files to e.g. remove the save button. You may also unbind the keys for that stuff.
But ultimately players could just type save into the console and work around it, it's an engine-side console command. I'm not sure how to work around that, probably some very ugly hack.

You can do a file search for ACT_ in HL SDK.
Firstly in dlls/activity.h you have all the activity IDs defined: Further, elsewhere you will find given situations or events where animations are looked up by activity: So for example, when the grunt does a "victory dance" i.e. enemy is dead, it looks for an animation with the ACT_CROUCH activity. And then more of them later.

It looks nice, you should upload it to our very own Map Vault!
https://twhl.info/vault

You cannot get that in GoldSRC. The main menu is not customisable in regards to functionality. I think the best you can do is edit one of the resource files and add a button that executes your desired console command.

I'd also discourage using all uppercase in forum posts. People will be less likely to help you if you're perceived as an angry screaming person.
I'd also recommend you to not google when it comes to HL1. It's just useless.

LINK_ENTITY_TO_CLASS( Cus_Char, charizard ); would link it to a "Cus_Char" in the FGD, whilst expecting a "charizard" C++ class.
You want it to be LINK_ENTITY_TO_CLASS( monster_charizard, Charizard ); as Erty said.

I'd argue GoldSRC is cooler than ever now, with modern community-made tools and people doing super cool things with it. So no, definitely not late.

Do you have the Half-Life SDK code? (not the tools from the SDK, but rather the C++ source code, as well as an installation of Visual Studio)

https://github.com/SamVanheer/halflife-updated

hl_cdll, yeah.

Which ones would you like to change? Generally you would go to an appropriate HUD element's .cpp file and change the coordinates, e.g. health.cpp for the health display.

The game code overrides sounds of func_train (and similar moving entities like doors) when they spawn. In case you leave the sound keyvalues empty, it'll just default to sound/common/null.wav. So, ambient_generic is your only option.

Weapons, at last.

That's a pretty cool map, you should also upload it to TWHL's own Map Vault!

If the "platform war" idea was true, they wouldn't have pulled anything off of GoG while EGS simultaneously hosts GoG Galaxy.
From what I've been told, old Unreal games got pulled because of a lawsuit against Epic, about in-game child protection because Fortnite was 1) designed to get kids hooked on spending money on the game 2) no (or not enough) parental controls. Someone big sued them over that and they kinda had to comply.

This affected all of Epic's games. Unreal and others, not having any parental controls whatsoever, had to get delisted cuz' Epic just didn't wanna bother adding those to their ancient games. Unreal is gone from GoG, I cannot find it there any more. Seriously.

This likely won't happen to Half-Life, because of the nature of the lawsuit against Epic (it was ultimately about children being encouraged to gamble), and Epic being cheap. Now I know Valve is cheap too, and they've had their fair share of lawsuits before, but something of this kind just ain't happening any time soon.

If it does happen though, we might see Xash being used a lot more, and that's going to be very damn interesting.

If light_surface has no name (cannot be triggered) and doesn't have an Appearance/Custom Appearance, it should not take up any edicts whatsoever.

I think you can check entities in-game with the entities command. It'll report like this:Here you can see there's 452 entities in c2a1.bsp.

Yes. Each monster is an edict of its own.

Decals, sparks, shells, muzzle flashes etc. are separate from edicts. They're a clientside concept literally called "temporary entities" (tempents), and they have their own limitation, I'm not sure what, but you can safely assume at least 512.

env_spark emits sparks, and is itself an entity. But the sparks it emits are tempents, so those don't count.
env_explosion indeed creates an explosion which consists of multiple things (explosion sprite, explosion smoke, sparks, decals etc.), but only that one env_explosion counts, cuz' the rest are on the client.

The only exception I think is the gib shooter entity, because gibs it throws are indeed serverside entities, weirdly enough. If you launch 100 gibs, you're wasting 100 edicts. Gibs thrown by func_breakable and others though, don't count, they're tempents.

The game has to be launched with -num_edicts 2048 regardless of Steam or WON, so yeah, the server has to do it. Otherwise you're limited to a total of 900 entities, regardless of if they're brush or point entities.

However, I'd rather say it's a little lower than that. Worldspawn is 1 entity, there's up to 16 players (so 16 entities), there may potentially be weapon drops by the players (count another 20 entities potentially), so you're left with about 850 in a practical scenario.

Oh snap, it's been a while. This month I'm planning to write a couple articles regarding TrenchBroom:

• Setting up TrenchBroom
• TrenchBroom Half-Life support report

One is to address the problem newcomers face when trying to set up Half-Life with TrenchBroom. J.A.C.K. provides an automatic game configuration for Half-Life when you give it the HL executable path, with various built-in compile configs too.

In the other, I'll be defining what it exactly means to "support Half-Life", i.e. what features or mechanisms an editor needs to have. I've also been thinking of alternatives for this one: "Transitioning from J.A.C.K. to TrenchBroom", "Differences between J.A.C.K. and TrenchBroom", "Hammer vs. J.A.C.K. vs. TrenchBroom". Some may want a unified list of all relevant map editors to be compared, I'd like to focus on just two-three main players in the community.

Next month, I'd be looking to take care of some "review required" pages (or maybe even this month) and renew some guides. I'd like to rewrite "In the beginning" in a modern context, using J.A.C.K. and VHLT,

The maximum number of all entities together depends on the number of edicts, which is 900 by default in Half-Life. However with the -num_edicts parameter you can bump it up to 2048.

The latest Visual Studio works just fine, no need for 2015.

That being said, it is very rare to catch programmers in the wild for HL1 these days, most either have a project of their own, or they're in some team, working on some project. You may have to look around a lot, or learn to do some things yourself.

Ooh, now we're talking!

Just for the record, you can't "edit" DLL files, they are compiled binary blobs just like MDL and BSP. You gotta obtain the source code that these DLLs result in compiling.

You can use Solokiller's HL OpFor SDK: https://github.com/SamVanheer/halflife-op4-updated

Hostile Barneys can be a copy-pasted Barney with a single line of code changed, or you can add a map property to monster_barney (or to all NPCs) to make them change their classification (friend vs. foe).

DMC/Quake-style ammo is really just looking at the Tau cannon or gluon gun code, they have no reloading just like in Quake. Identify which parts of the code are responsible for that, and apply them to your weapon(s).

Red HUD colour is easy, simply change the hex colour value here: https://github.com/SamVanheer/halflife-op4-updated/blob/236e77682f1a2c147eab794b47880329e50b5011/dlls/cdll_dll.h#L204
Here are some example values: https://github.com/SamVanheer/halflife-op4-updated/blob/236e77682f1a2c147eab794b47880329e50b5011/cl_dll/hud.h#L25-L27
0x00FF0000 is pure red (255,0,0) and so on.

As for scientists that cower away from you, I think it is possible to alter their classification table so that they're always afraid of the player, i.e. treat the player as an alien. There's a whole classification mechanism in Half-Life's AI system where some NPCs see other NPCs as predators, or prey, or they mean nothing to them, and so on.

I'm not sure about boss fights, because that can mean literally anything. For all I know, I could be fighting a worm in a goldfish container (reference to sc_toonrun). You can set those up as a combination of a sequence of triggers and stuff, plus a special entity that sends fireballs at you (doesn't even have to be an NPC depending on what kinda boss it is), but of course, that will require knowing entity programming.

If you have questions (which you probably certainly do), feel free to ask. Are you looking for a programmer to do this for you, or do you wanna try and learn how to?

Can you provide (a lot) more info? Nobody's gonna help if they don't know what the problem is.

From my limited experience with Source, this appears to be normal. I don't know of any fixes or workarounds.

New video is out~

Iiiii vote D.

Depending on what you really need, you don't even need an NPC (CBaseMonster), really. You can inherit from CBaseAnimating and handle animation switching manually.

In any case, you can also look into monster_generic's code, you'll find a brutally simple monster example there. (genericmonster.cpp)
Also look into the monsters programming chapter in TWHL's programming book: Monsters Programming - The Concepts of Half-Life's AI

There is a way simpler way to get a reflection vector.

Let's construct it piece by piece. Say you have an incoming vector V:And you would like to obtain the reflected vector R:You also happen to know the normal vector of your surface, N:So, we're aiming at something that is roughly the opposite direction of V. We can obtain the dot product of V and N, and it'll give us, well, something for a start:(I'm visualising this rather unconventionally, just note that the dot product will be negative in this instance, something like -0.8)

Now check this out. What if you take that dot product, and multiply V with it in some way? And then add (V*d) on top of N?Hell yeah, we're GETTING somewhere now! (actually you should subtract to get this result, because remember, the dot product is negative in this case)

Now, this is not actually it. Instead of N - V*d let's actually try -2N*d + V and see what happens:This expression can be simplified a bit: V - 2*N*d

So yeah, there's your formula right there.

const float doubleDot = 2.0f * direction.Dot( normal );
return direction - (doubleDot * normal);

If you don't believe me, here's how some engines & maths libraries do it:
https://github.com/godotengine/godot/blob/master/core/math/vector3.h#L516 -> Godot game engine
https://github.com/g-truc/glm/blob/master/glm/detail/func_geometric.inl#L104 -> GLM maths library
I'm surprised this isn't present in some engines & physics engines I know.

What you can do next is also add a bias that multiplies the influence of the normal:

Vector Reflect( const Vector& normal, float normalBias = 1.0f )
{
   const float doubleDot = 2.0f * normalBias * Dot( normal );
   return *this - (doubleDot * normal);
}

And then have a random number on each bounce to simulate surface imperfections. I guess you don't want that, but it's just a fun thought.

Also I honestly don't know how people came up with the exact formula, and I don't know myself, but through experimentation it eventually makes somewhat of a sense. No wonder I'm failing Maths in college lmao. But yeah, hope this helps!

The source code from my videos is now finally available:
https://github.com/Admer456/hl-sdk-videos-src

Some of it could be useful material for TWHL Wiki, temporary entities in particular.

YESSSSSSSS this is EXACTLY what I like to see!!!! Ottoman Empire (mainly the Balkan part of it) in the 1800s is such an underexplored game setting, I've always wanted to see it in this slick little low-poly form.

I'm loving this.

The RUST & VERC articles are archives, so I think those should be kept as-is.
TWHL's own guides, however, should definitely have redundancies taken care of. I believe what we have now is, simply, a consequence of transitioning from TWHL's legacy article-writing format to a wiki format, and so long as we have this, the transition isn't 100% complete.

Properly explain how to set up JACK for mapping, ensure things like getting up-to-date compile tools [...]

For years I wanted to rewrite "In the beginning" and basically update a buncha mapping guides into a modern context. I think I could attempt something soon enough.

Ideally tutorials would be split into 2 lists: ones that are known to be up-to-date and relevant and archived ones that are outdated, possibly referencing obsolete tools or older methods.

I agree, it would be nice to categorise those.

You seem to have posted an image link to a Discord image. It may work if the image is in a server, but certainly not in DMs, that stuff is inaccessible. You can copy-paste images directly into posts here, or alternatively use Imgur or some other image host.

Tutorials can be fun in 3rd person too. For TWHL's books (e.g. the programming series), a 3rd-person style without too much "fun" is a must, because it certainly is authored by several people (Penguinboy, Solokiller, Shepard, me, etc.) and must be consistent.

On the other hand, for guides (esp. series of guides) written solely by a single person, I think 1st-person is acceptable (but you don't want it to be strong). Realistically, it's not like someone's gonna edit a huge chunk of the guide, usually it's just minor improvements like correcting typos, grammar, or some numbers. I will admit I am a little biased, I like seeing personality in tutorials, and I'm particularly guilty of it myself, having written quite a few with lots of... personal touches.

But honestly, if you think about it, people visiting TWHL absolutely don't care who wrote the tutorial - they're interested in the tutorials, not the authors. If they're reading it for recreational purposes or for fun, then yeah, personality is cool. But most people are just looking for explanations and step-by-step guides, so having consistency in writing would be good to have. Having a pretty different writing style in each tutorial would break this consistency a lot.

In conclusion, I honestly dunno, I'd like to have 1st-person but at the same time, it has some side effects I briefly mentioned up there.
If someone really cares a lot about personality/fun and wants to read stuff from a specific author because they're fun to read, there are websites like Medium, where you can write about anything and in any way, within reason that is. That's my take on it.
(obviously, nobody here writes on Medium, but it could be anything really, e.g. I make video tutorials on YT)

If you don't have anything to show for the mod, there may be very little interest. It's simply in people's nature to not be interested in ideas, but in final products instead. Having a bit of a vision of that final product helps attract attention.

My personal advice is: it would be easier to learn most those skills yourself (mapping in particular) than to form a team. Definitely try doing that first, and at that point you'll have actual stuff to show too.

At least bother wrapping it in an image tag, @Animator2003

[img:https://i.imgur.com/aAJoIXF.png]

Otherwise I'm doing fine, thanks! What about you?

Sounds like you were using older compilers, these tend to slip things through and compile the map anyway.

A more technical explanation of what happens:
What you actually lose with leaking is something called "outside filling". Normally, the process of BSP filling would strip out all unseen surfaces:That's kinda the beauty of BSP. These X'ed faces get removed. Nowadays we got tool textures like NULL to forcibly do this, but they don't really make a difference if your map is compiled without leaks, unless in some more special situations like with func_detail.

Everything that is considered to be the "outside" of the map is erased. Point entities (player spawns, lights etc.) dictate what's considered "inside", and the world geometry is used to then figure out what's outside from there.

However, with a leak, the compiler can no longer figure out what's inside & what's outside, so ALL faces stay. You get 6x more polygons in the map and it decimates performance basically.

This majorly increases the usage of the following resources, that can be seen if you compile with the -chart option:

• AllocBlock
• clipnodes
• worldleaves
• map surfaces

So basically, a map that would normally fill up 20% of these limits would, with a leak, fill like 60% or even more.
I hope you now have a bit of a better insight as to how leaks "work".

Show us a concrete example of that "leak". A leak only counts if the compilers complain about it and prevent you from compiling the map further. I've had "pseudo leaks" where it was actually an enclosed space between my hallways, but it was all NULL faces and nobody ever really noticed. Still doesn't count as a leak, because the compiler didn't yell "LEAK IN HULL 0" or anything.

The disadvantages of leaks are, as Zegfalt said, having your map fullbright, cuz' compilers generally stop at the BSP stage when you have a leak, and so VIS & RAD won't execute. But that's the least of your concerns.

VIS won't execute, meaning most, if not all of your map, will be rendered at once, and this also means all entities are sent at once. This breaks all engine limits (256 max visible entities for example) if your map is large enough.

So, the introduction video has been remade:Happy belated 2nd anniversary, my HL SDK Programming series.

And now we got a video about temporary entities:

Most of Half-Life was developed in software mode AFAIK, so I'm pretty sure they changed quite a couple of things here'n'there. I mean, just look at the water in software mode.

In Quake, gameplay logic is in QuakeC, but the client code is inside the engine. The client DLL in HL SDK is practically just engine code moved into a separate DLL. I don't think Valve renamed all the .c files into .cpp? No way to check that really, so I dunno.

GoldSRC also separates the hardware renderer and software renderer. hw.dll and sw.dll are actually entire builds of the engine but with different renderers.

"please add realtime rendering"

Hammer, J.A.C.K., even Worldcraft, all have real-time rendering. You can control the camera in real time with your mouse and WASD, and it renders at 60fps. That is real-time rendering, yes.

I imagine you're asking for real-time lights or maybe a lightmap preview. That's probably unlikely. This thread isn't about ideal editor features, but rather, what tools might be good for a programmer to develop one map editor.

I'm pretty sure xash is made off of the 2003 leak engine?

Xash started off as a fork of one of those Quake engine forks, and it used 2003 leak code at some point for a couple of smaller things. I don't remember what, but either way, that got removed from Xash-FWGS and replaced with clean code.

GoldSRC has code from all kinds of places. IIRC it's mostly WinQuake/GLQuake with some QuakeWorld for networking and view bobbing and a teeny tiny bit of Quake 2 for some other things.

Seems like a good enough approximation.

Amazing.

The darkness could be due to gamma settings in-game etc., but also TWHL having pretty bright colours in general.

I don't think that can be done. Here's the code responsible for ordering the engine to spawn the sprites:

switch( event->event )
{
case 5001:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[0], atoi( event->options) );
    break;
case 5011:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[1], atoi( event->options) );
    break;
case 5021:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[2], atoi( event->options) );
    break;
case 5031:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[3], atoi( event->options) );
    break;
case 5002:
    gEngfuncs.pEfxAPI->R_SparkEffect( (float *)&entity->attachment[0], atoi( event->options), -100, 100 );
    break;
// Client side sound
case 5004:
    gEngfuncs.pfnPlaySoundByNameAtLocation( (char *)event->options, 1.0, (float *)&entity->attachment[0] );
    break;
default:
    break;
}

The R_MuzzleFlash part only accepts a position (here the attachment point on the gun), and a type, presumably the type of the muzzle flash, some sprite ID.
void ( *R_MuzzleFlash ) ( float *pos1, int type );
As you can see, there is exactly nothing there that can possibly change the angles of these muzzleflashes. It is the engine's Efx API that controls this, which is out of a modder's reach.