Forum posts

Posted 5 hours ago2022-10-02 07:28:45 UTC
in Wiki enhancment thread Post #346922
For pages in category:Entity Flags, we should either:
  • add to the title, in parentheses, the base class or entity it applies to, OR
  • put them into subcategories with the same info
so you can know that from a glance at the category page instead of having to click on every single page – a problem that would get worse as more pages are added.
Posted 17 hours ago2022-10-01 19:35:13 UTC
in Func_Button Never Works (HL1) Post #346921
I don't think 1 is the default value for the health property, should be 0, however, as Bruce pointed out, changing from one entity to another causes the properties from the first entity to carry over to the second entity, including values. This is a bug with Jack. If you have func_detail set as the default entity, the first time you create an entity out of brushes, it'll be func_detail and from there you can change to the entity you want. Func_detail properties don't carry over.
The Mad Carrot The Mad CarrotMad Carrot
Posted 17 hours ago2022-10-01 18:49:15 UTC
in Func_Button Never Works (HL1) Post #346920
Ok, I found the problem. You somehow gave the button a Health (shootable if > 0) value, which was at 1. So with a health value of 1 or higher, the button can't be used by 'use-keying' it but instead will activate if shot at. Cheat in some weapons and see for yourself. Set the health value to 0 should make the button usable again.
Yep that fixed it. Some how it was set to 1 by default and I never knew that would prevent a button from working. Thanks for the help you've saved me from using Button_Target until the end of time.
Posted 18 hours ago2022-10-01 18:29:48 UTC
in Func_Button Never Works (HL1) Post #346919
Sometimes when an existing entity is changed to another type, the parameters will remain. That can be annoying.
Posted 21 hours ago2022-10-01 15:41:54 UTC
in Func_Button Never Works (HL1) Post #346918
Ok, I found the problem. You somehow gave the button a Health (shootable if > 0) value, which was at 1. So with a health value of 1 or higher, the button can't be used by 'use-keying' it but instead will activate if shot at. Cheat in some weapons and see for yourself. Set the health value to 0 should make the button usable again.
The Mad Carrot The Mad CarrotMad Carrot
Posted 21 hours ago2022-10-01 15:18:06 UTC
in Func_Button Never Works (HL1) Post #346917
Posted 21 hours ago2022-10-01 15:02:10 UTC
in Func_Button Never Works (HL1) Post #346916
Would you mind posting the jmf?
The Mad Carrot The Mad CarrotMad Carrot
Posted 22 hours ago2022-10-01 14:44:53 UTC
in Ambient_generic doesn't work in-game Post #346915
apc_engine_idle is supposed to be a looped sound. You need to uncheck "is not looped". Whats happening is you're going into the game and the sound is playing once or not at all because idle sounds are used for looping.
Posted 22 hours ago2022-10-01 14:24:45 UTC
in Func_Button Never Works (HL1) Post #346914
Door has the default speed value of 100 and I know what lip is, changing it makes no difference. Door still doesn't work and button can't be interacted with. Changing flags on both the door and the button makes no difference either.

I've switched out Jed's HLMV for Half-Life Asset Manager, thanks for the recommendation.

I had HLVIS running twice for some reason, corrected that now so that HLRAD runs like its supposed too.
Posted 22 hours ago2022-10-01 14:09:23 UTC
in Func_Button Never Works (HL1) Post #346913
Make sure the door has a speed value high than 0. If it's 0, the door won't move.
If it does have a speed value, make sure the lip value isn't the same as the speed value. Values above 0 but bellow, let's say, 5 or 6 are good values for lip. The wiki says: The lip value is the number of units left after move (the lip value is subtracted from the move distance).

If you set the Don't Move flag on the button, the button won't move.

Some unrelated thingies:
Avoid using Jed's HLMV, it's old and buggy. Use Half-Life Asset Manager by Solokiller instead.

Judging from the compile log you posted, you seem to be running HLVIS twice, and HLRAD is skipped.
The Mad Carrot The Mad CarrotMad Carrot
Posted 23 hours ago2022-10-01 13:13:40 UTC
in Func_Button Never Works (HL1) Post #346912
So I am new to Half-Life 1 mapping but reasonably experienced with Half-Life 2 mapping. Func_Button will not work no matter what I seem to do. Button_Target works fine but its obviously not what you're supposed to use and it lacks features. I have tried Func_Button in the map I'm making and separate test environments and neither will work. Func_Button will not work with doors, trains, different textures or anything. I have followed multiple tutorials and googled the hell out of the problem and nobody seems to have this issue.

What I'm doing:
1. Create door and give it a name. No flags.
2. Create button and set target to name of door. No flags.
Apparently this should work but it doesn't. Just for the record there no leaks in the map or anything. Maybe its me being incredibly stupid but I don't know.

Compile Log:

I am using:
JACK editor 1.1.1064 (64-bit)
Zoner's Half-Life Tools Compiler
Jed's HLMV
Half-Life (Steam)

Help me TWHL you are my only hope
Posted 1 day ago2022-10-01 07:58:49 UTC
in Ambient_generic doesn't work in-game Post #346911
you don't need to add nodes, uncheck "is not looped", and increase the max audible distance to something like 1024.
Posted 1 day ago2022-09-30 14:01:40 UTC
in Ambient_generic doesn't work in-game Post #346910
I think you may need to add nodes to delineate the area where the sound is audible.

I don't remember exactly how to do this, since I haven't mapped for ten years.
satchmo satchmoWhat you can do today should have been done yesterday.
Posted 5 days ago2022-09-26 17:54:11 UTC
in Extracting clip node data from BSP Post #346907
Thank you for the help so far! Looking forward to what you can dig up. Using a trace is one idea, but the preference of course is to just be able to extract all the world clip vertices so that invisible walls are also taken into account.

For example, tracing func_illusionary won't help with the barricade at CT spawn in cs_militia: the AI will still think it can crouch under the barriers if the invisible wall can't be detected.
Posted 5 days ago2022-09-26 16:26:23 UTC
in Extracting clip node data from BSP Post #346906
Hmm, I'll need to download BspGuy's code tomorrow and experiment. This was so far just me interpreting the code from its GitHub.
I wonder if it would be enough to perhaps query the BSP with a trace through the func_illusionary brush location to see if it hits something?
Ah! You can actually borrow HLRAD's BSP raycast code... I think... it's meant for hull 0, but could be adapted for cliphull123 perhaps.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 6 days ago2022-09-26 11:12:02 UTC
in Extracting clip node data from BSP Post #346905
An additional thought to the above: the BSP renderer seems to have some issues with heavy artifacting of clipnodes as well. Looking at this section of map from ns_eclipse:
Visible SurfacesVisible Surfaces
Given that all I really want to do here is determine if a func_illusionary is solid or not, I wonder if it would be enough to perhaps query the BSP with a trace through the func_illusionary brush location to see if it hits something? Might save a lot of headaches. Problem is doing that from outside of GoldSrc...
Posted 6 days ago2022-09-26 10:41:52 UTC
in Extracting clip node data from BSP Post #346904
Yeah I've already filtered those out. I also noticed that the BSP viewer code doesn't do anything with indices, so presumably it already just pushes the vertices in the order in which they're meant to be rendered, so the triangle indices would just be 1,2,3,4,5,6,7 etc. I've added that to my code.

This is what the code looks like now, it's mostly just a copy of the BSP viewer code, except I arbitrarily scale down everything by 1000 so at least the resulting map isn't insanely big:
if (map->isValid())

		int numTris = 0;
		int vertCounter = 0;
		int triCounter = 0;

		Clipper clipper;

		int clipnodeLeafCount = 0;

		vector<NodeVolumeCuts> solidNodes = map->get_model_leaf_volume_cuts(0, 1);

		vector<CMesh> meshes;
		vector<vec3> allVerts;
		vector<int> modelIndices;
		int IndiceCounter = 0;

		int indicesOffset = 0;

		// This bit is the same as the BSP viewer
		for (int k = 0; k < solidNodes.size(); k++)

		for (int m = 0; m < meshes.size(); m++)
			CMesh& mesh = meshes[m];

			for (int face = 0; face < mesh.faces.size(); face++)

				if (!mesh.faces[face].visible)
				set<int> uniqueFaceVerts;

				for (int edge = 0; edge < mesh.faces[face].edges.size(); edge++)
					for (int v = 0; v < 2; v++)
						int vertIdx = mesh.edges[mesh.faces[face].edges[edge]].verts[v];
						if (!mesh.verts[vertIdx].visible)

				vector<vec3> faceVerts;
				for (auto vertIdx : uniqueFaceVerts)

				faceVerts = getSortedPlanarVerts(faceVerts);

				if (faceVerts.size() < 3)
					//logf("Degenerate clipnode face discarded\n");

				vec3 normal = getNormalFromVerts(faceVerts);

				if (dotProduct(mesh.faces[face].normal, normal) > 0)
					reverse(faceVerts.begin(), faceVerts.end());
					normal = normal.invert();

				// convert from TRIANGLE_FAN style verts to TRIANGLES
				for (int k = 2; k < faceVerts.size(); k++)
					allVerts.push_back(faceVerts[k - 1]);


		// Add the verts into the float array
		TriData->ntris = numTris;

		for (int i = 0; i < allVerts.size(); i++)
			TriData->verts[vertCounter++] = allVerts[i].x * 0.001f;
			TriData->verts[vertCounter++] = allVerts[i].y * 0.001f;
			TriData->verts[vertCounter++] = allVerts[i].z * 0.001f;

		for (int i = 0; i < modelIndices.size(); i++)
			TriData->tris[triCounter++] = modelIndices[i];

		TriData->nverts = vertCounter / 3;

		return true;

What is missing though is the conversion from clip local units to world units. When I render the resulting mesh it looks like this regardless of which map I use as an input (the below is meant to be de_dust):
That&#039;s... not how I remember itThat's... not how I remember it
For reference, to rule out the possibility of the issue being with the rendering of the mesh itself, this is what it looks like when I render it by extracting the faces and edges from the BSP tree (but of course that's missing CLIP brushes):
Much better!Much better!
Posted 6 days ago2022-09-26 08:28:52 UTC
in Extracting clip node data from BSP Post #346903
Might wanna check this too:
int vertIdx = mesh.edges[mesh.faces[i].edges[k]].verts[v];
if (!mesh.verts[vertIdx].visible) {
Vertices can be visible/invisible too, it appears.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 6 days ago2022-09-25 14:11:35 UTC
in Extracting clip node data from BSP Post #346902
Thanks Admer456! Here is my code, which is mostly lifted from the BSP viewer, hopefully the comments make sense:
Bsp* map = new Bsp(filename);

	if (map->isValid())

		int numTris = 0;
		int vertCounter = 0;
		int triCounter = 0;

		Clipper clipper;

		int clipnodeLeafCount = 0;

		vector<NodeVolumeCuts> solidNodes = map->get_model_leaf_volume_cuts(0, 1);

		vector<CMesh> meshes;
		vector<vec3> allVerts;
		vector<int> modelIndices;

		int indicesOffset = 0;

		// This bit is the same as the BSP viewer
		for (int k = 0; k < solidNodes.size(); k++)

		for (int m = 0; m < meshes.size(); m++)
			CMesh& mesh = meshes[m];

			for (int face = 0; face < mesh.faces.size(); face++)

				if (!mesh.faces[face].visible)

				// First add all the vertices to the vertex pool, then in a moment we'll define the indices that form each triangle
				for (int v = 0; v < mesh.verts.size(); v++)

				// My understanding is that the indices held in the edges index into the verts array for that mesh, so if we want to combine
				// all meshes into a single soup, we need to offset the index number by the total number of indices already present
				for (int edge = 0; edge < mesh.faces[face].edges.size(); edge++)
					modelIndices.push_back(mesh.edges[mesh.faces[face].edges[edge]].verts[0] + indicesOffset);
					modelIndices.push_back(mesh.edges[mesh.faces[face].edges[edge]].verts[1] + indicesOffset);

				int indexCounter = 1;
				int totalIndices = (mesh.faces[face].edges.size() - 2);

				numTris += totalIndices;

				// Now we need to break the convex shape into triangles, fanning out from the first index and adding them into the
				// total indices array
				for (int x = 0; x < totalIndices; x++)

					TriData->tris[triCounter++] = modelIndices[0];
					TriData->tris[triCounter++] = modelIndices[++indexCounter];
					TriData->tris[triCounter++] = modelIndices[indexCounter - 1];



			indicesOffset += mesh.verts.size();

		// Add the verts into the float array
		TriData->ntris = numTris;

		for (int i = 0; i < allVerts.size(); i++)
			TriData->verts[vertCounter++] = allVerts[i].x;
			TriData->verts[vertCounter++] = allVerts[i].y;
			TriData->verts[vertCounter++] = allVerts[i].z;

		TriData->nverts = vertCounter / 3;

		return true;

Basically, TriData is a structure which contains an array of raw floats representing each vertex and an array of integers representing the indices that form the triangles. Effectively, it's the same format as an OBJ model.

The above approach works fine if I'm just extracting the vertices and edges direct from the map itself, but falls apart when trying to do it with the clip nodes. I'm not sure if this is because my approach isn't compatible with the way clip nodes are represented, or if it's incompatible with wootguy's mesh setup (or both...)
Posted 1 week ago2022-09-25 11:38:05 UTC
in Extracting clip node data from BSP Post #346901
Here's my thoughts:

vector<NodeVolumeCuts> solidNodes = map->get_model_leaf_volume_cuts(modelIdx, i);
What's interesting is the return type of get_model_leaf_volume_cuts. NodeVolumeCuts is the BSP planes that "define the leaf boundaries when applied to a bounding box". So these aren't just some random planes, these are effectively the planes that form the convex volume of a BSP node or well, leaf in this case.

vector<CMesh> meshes;
for (int k = 0; k < solidNodes.size(); k++) {
A CMesh is just a bunch of vertices, edges and faces, nothing special there.
What clipper.clip does is create a box CMesh that is the max size of a map (-131k to +131k units), which actually explains the thing you were seeing there, with -1317821 for the X coordinate. It then proceeds to chop up the box with cuts - the BSP planes that define that node's volume. It removes verts/edges/faces that are below the plane, and retains the ones above the plane, I believe. Or vice-versa. Doesn't really matter, you get the idea.

Basically works the exact same as the clipping tool in Hammer.

for (int m = 0; m < meshes.size(); m++) {
    CMesh& mesh = meshes[m];

    for (int i = 0; i < mesh.faces.size(); i++) {

        if (!mesh.faces[i].visible) {
For the next few dozen lines, it is basically optimising the mesh, removing redundant vertices etc.
And that's... it I think? Get BSP planes that define the convex volume of a leaf, and create the mesh of that convex volume by chopping up the planes against a huge bounding box. Alternatively you can create a polygon object for each plane and cut those polygons up, instead of using a big cube as your starting clipping object.

NGL I did not think it was that simple, just getting the bounding volume of each solid BSP node per hull. Obtaining the list of solid BSP nodes isn't hard either.
Can I see your code? Maybe there's a tiny oversight somewhere.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2022-09-24 22:28:06 UTC
in Extracting clip node data from BSP Post #346900
Ok so I've been having a play with it, but I've noticed something strange. The BSP viewer tool takes models and their collision planes and uses a "Clipper" object to carve each model into a mesh object by its various planes. The mesh holds a set of vertices, edges and faces. What I'm finding though is that the vertices produced in the meshes have insanely high or low values (e.g. -1317821 for an X coordinate).

The BSP viewer produces the exact same results as me, so it's not a mistake on my part. It must be doing something in the clipnode buffer to reduce the coordinates back down to something sane, but I can't see where it's doing it. As far as I can see, it's loading those huge values into the buffer for rendering. Any ideas on what I'm missing here?
Posted 1 week ago2022-09-22 18:15:31 UTC
in Extracting clip node data from BSP Post #346899
It indeed expands the hulls because the player hull is like, 36x36x72 units I think. Similarly, cliphull2 would be larger, and cliphull3 would be the smallest.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2022-09-22 15:59:47 UTC
in Extracting clip node data from BSP Post #346898
I think the answer can be found in BspGuy's source code, since that one renders clipnodes. Or at least seems to.
Yes, you're right! It does. The actual collision hulls don't match the original brushwork however, as you can see, the collision hull is considerably larger than the original brush:
Clip nodeClip node
I wonder if this is because it actually does a point test for player collision at the centre of the player hull, and simply expands the collision hulls to account for player height and width. It may be possible to retrieve the original collision hull by scaling it down by player radius and half height.

Looks like I need to do some digging now. I'll update if I find anything!
Posted 1 week ago2022-09-22 13:48:22 UTC
in Extracting clip node data from BSP Post #346897
I am also curious about generating a triangle mesh from clipnodes.
I think the answer can be found in BspGuy's source code, since that one renders clipnodes. Or at least seems to.

You could look into the original Quake compiler sources to see maybe how they're generated, but TL;DR you definitely gotta do some form of plane intersection to get polygons in the end.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 week ago2022-09-22 12:12:30 UTC
in Extracting clip node data from BSP Post #346896
Hi everyone,

I have a bit of a challenge. I want to generate a navmesh for HL maps as I'm creating a bot for some HL1 mods (especially Natural Selection) which have limited or no bot support.

To do this, I'm currently extracting all of the vertices from the BSP file and rendering them into a triangle mesh. Vertices exist for all visible entities in the BSP file, but I am excluding func_illusionary entities since these do not collide and therefore should be excluded from navmesh generation.

The challenge I have is clip brushes. These are used for things like chain-link fences and railings where the visual brush is a func_illusionary and then a brush with the CLIP texture is added to prevent players walking through them. The problem is that brushes with the CLIP texture are special cases and do NOT appear in the list of vertices (presumably because they're never rendered): they exist only as collision hulls.

The result is that right now, I only have two choices: include func_illusionary entities in navmesh generation, and have the AI unable to walk through things like the cs_747 curtains and other decorative features, or exclude them and have the AI try to walk through the chain-link fence in cs_militia.

The preferred option of course is to have the clip brushes retrieved and added to the list of vertices, but currently I have no idea how to do this. I've had a look at the hlbsp project's breakdown of the v30 map format here and the map optimisation tutorial here, but I'm still unsure how to convert the planes into a set of triangles. As far as I can see, they're defined as a set of infinitely wide and tall planes with a normal and distance from origin.

Has anyone managed to do this before?
Posted 1 week ago2022-09-21 05:52:12 UTC
in Mod_NumForName: *155 Post #346894
Found the issue! I was using a game_zone_player that the transitions elevator button activates to avoid an exploit where the elevator button can be pushed from the outside, breaking the sequence. For some reason this entity was causing the crash after it was activated during a level transition. To prevent the crash I just had to add a trigger_relay that kills the game_zone_player after it's done its job.

Luckily this transition is only one-way or this would be a real hassle.
Posted 1 week ago2022-09-20 21:09:09 UTC
in Ambient_generic doesn't work in-game Post #346893
I started working in Source engine and I'm making a CS:S map. I added a sound of APC idle and all is right but when I play it in game the sound doen't exist, is silence. The start silent checkbox is desactivated and checkbox is NOT looped is activated. What could be happening and why it doesn't work?
Here you can see all is correct.Here you can see all is correct.
Same I said before.Same I said before.
Posted 1 week ago2022-09-20 17:18:05 UTC
in Mod_NumForName: *155 Post #346892
Hi! Are you using custom DLLs? If so, try without them. If that doesn't help, start removing every object from your maps until you have only the spawn points, level transitions, and simple rooms. That should narrow down the cause of the problem
Posted 1 week ago2022-09-20 11:00:32 UTC
in Mod_NumForName: *155 Post #346891
Hello, I'm having a strange issue with my Goldsrc mod. Whenever I transition between two certain levels, it crashes with this error.
User posted image
I looked up the error on the wiki, but it stated that this error should refer to a model or sprite that has had its path written incorrectly, but it does not. All the other level transitions in my mod are working and both maps function fine when launched with the "map" console command, this only happens when transitioning from one to the other. I have no idea what's causing this, the transition was working fine earlier today and now the crash is unavoidable. I even verified HL's game files.

Anyone have any experience solving this?
Posted 1 week ago2022-09-19 21:37:18 UTC
in Problems with compiling viewmodels in Blender Post #346889
Glad that it worked out for you. :)
Posted 2 weeks ago2022-09-18 08:30:57 UTC
in eXperiment HL horror mod Post #346888
Did use a TDI Kriss at first but decided to do a new model with new animations and sounds for the 9mmAR
Yes it makes sense, I thought about it too, I just wanted to know if it is possible to somehow remove the colon without resorting to a workaround. For recording, I use HLAE (you can record the HUD and the game separately).
Posted 2 weeks ago2022-09-17 16:35:37 UTC
in Half-Life Updated (custom SDK) Post #346886
<== Continued from previous post

New UI: preliminary research

I've been looking into RmlUi a bit more. There has been work done recently to refactor its render backend which would make it easier to integrate in a Half-Life mod.

I see two possible implementations: The second option is probably more efficient but means dropping Software mode support. To prevent users from reporting this as a bug i'd have to add a forced quit command when the engine is started in Software mode (IsHardware() returns 0).

The best of both worlds is to use OpenGL when the engine is loaded in OpenGL mode and the VGUI1 workaround in all other modes (D3D mode returns 2, though it obviously won't ever do that now since it was removed).

This work is planned for RmlUi 5.0 (currently at 4.4) with no ETA so i don't expect to be doing this any time soon.

In the meantime i can make a standalone test program to see how feasible it is to make a HUD with it. That's a quick way to determine if the library is an option here at all.

I'm not planning to add a new UI in V1.0.0 so it's not a big deal if it takes time. I've given them some feedback on CMake modernization they want to do to help them along.

I've also looked into how VGUI1 and VGUI2 handle TGA loading. Both use the same backend that boils down to glGenTextures and glTexImage2D calls, it doesn't pass through the engine's texture loading routines which handle loading, filtering, resampling and rescaling.

VGUI1 supports very large textures (134,217,727 RGBA32 pixels max) but doesn't free the main RAM buffer. VGUI2 limits textures to 256 x 256 pixels but doesn't keep a buffer allocated.

All backends support 24 and 32 bit uncompressed TGA with no custom origin coordinates (only game.tga and game_big.tga use a non-default origin, and game_big.tga can probably be changed since it's used by Steam and not the game), so sticking to that format will work regardless of which option we use.

This means we'll need a tool to take the sprites and convert them to TGA. For animated sprites we'll need a framework-specific solution: RmUi has sprite sheets (single large texture divided into rectangles for each frame) but VGUI1 and 2 don't have a built-in feature so that'll require splitting frames into separate textures either at the file level (filename0.tga, filename1.tga, etc) or at file load time.

Either way a separate file is needed to specify animation frames. It is possible to just use sprites here if we handle loading ourselves but i'd like to get away from the limitations of the sprite format (256 colors for all frames combined, variable framerate sprite frames which aren't supported by the engine anyway, etc).

Some other container format could work, even Source vtf might work here but i'd prefer to keep things simple and RmlUi has its way of specifying sprites already.

Only once a decision has been made on where to take the UI can i figure out how to deal with the Opposing Force image replacement problem. This depends on the UI framework since the manner in which images are referenced differs between them.

Regardless, the actual directory structure will likely be:
  • mod directory
    • gfx
      • ui
        • op4
The default UI will go in the ui directory, with Opposing Force-specific UI images going in a subdirectory, matching the structure used for other file replacements already in use.

The choice of framework will also influence how other UI-related issues will be handled, so there isn't much to gain from discussing that now.

Remaining work to be done

  • Merge pull requests into repository (done)
  • Implement new sentence playback system, add all sentences (done)
  • Review malortie's work and provide feedback (done)
  • Global sound replacement (done)
  • Global sentence replacement (done)
  • Rework the client command registry to eliminate use of shared pointers
  • Rework game configuration system to no longer rely on std::any to harden the API against incorrect use
  • Update Packager tool to provide list of files not included in the package to spot missing files more easily
  • Update changelog to include all changes
  • Write documentation for all new features (partially complete)
  • Investigate making the wiki accessible for pull requests to allow direct modification or make the wiki part of the repository Vcpkg does this, albeit for their website)
  • Review all changes
  • First alpha build
  • Stress test the three campaigns and fix issues that show up
  • First beta build
Work expected to be needed in the future (in no particular order):
  • Networking system (transfer contents of replacement files, precache lists, possibly other immutable data): work in progress
  • New UI (including HUD image replacement for Opposing Force): being researched
  • Versions of Opposing Force-only HUD images that have the scanline effect removed: some preliminary research done, needs more investigation
  • A way to start all three campaigns from the main menu. Probably the same solution as used in Condition Zero Deleted Scenes (menu button that starts a map that opens an SDK-level menu that enables campaign and training selection). Depends on the new UI
  • Unknown unknowns
There has also been more work done on the Updated projects with bug fixes and improvements which i'll list when i release the next set of beta builds. I need to investigate a couple more things before i can do that.

Many thanks to a1batross, hammermaps, Shepard, BryanHaley, Ronin4862 and malortie for helping to get this project much closer to its first release. I couldn't have done this without you.
Posted 2 weeks ago2022-09-17 16:35:01 UTC
in Half-Life Updated (custom SDK) Post #346885

Progress on Half-Life Unified SDK

Make sure to read the wiki for more information.

There's been quite a bit of work done in the last month and a half.

SDK code changes

  • All open pull requests have been merged in
  • The new OpenAL-based sentences system has been implemented
  • Music now stops playing when disconnecting from servers, when starting a new map using the map command or when loading save games
  • Reworked the model replacement code to be more generic to allow its use for the other replacement systems. The work done also makes implementing per-entity versions of all replacement systems very easy
  • Added global sound replacement with client-side player movement sound replacement support (to replace footstep sounds)
  • Added global sentence replacement. This can replace individual sentences as well as sentence groups (to replace entire sets of responses, sets of randomly selected sentences, etc. Depends on how entities use them)
  • Updated all new code to use a consistent naming style
  • Updated new files to use better names to reflect their content more closely
  • Updated JSON library to 3.11.2
  • Updated JSON schema validator to latest commit
  • Added fmtlib as a direct dependency. fmt::format is now the way to format strings safely, std::format will not be used since it isn't available everywhere yet and will likely suffer from the same problems as other standardized APIs (can't be updated due to backward compatibility)
  • Updated EASTL to use a local port that uses the latest commit to allow it to compile when using GCC
  • Added helper commands for debugging maps, like infinite air, armor, finding entities based on classname or targetname, triggering them
  • Reworked UTIL_dtos1-4 to a single function UTIL_ToString that converts an integer value to a string without allocating memory
  • Reworked Visual Studio natvis configuration to use intrinsic functions to allow string_t values to be displayed immediately, instead of requiring manual evaluation. This allows for faster debugging
  • Added entity info hud to display the classname of the entity you're looking at as well as its health. The color of the values is determined by the entity's relationship with the player:
    • white: no relationship
    • blue: friendly
    • red: hostile
  • Talk monsters now only treat other talk monsters as potential friends to avoid monsters trying to talk to random nearby entities and crashing as a result
  • Removed obsolete Quake code used to handle the cloak powerup (doesn't exist here)
  • Renamed VModEnable client command to vmodenable adhere to new client command naming rules
  • Defined dummy vmodenable client command to silence console errors in singleplayer
  • Removed superfluous Random value from monster_otis bodystate keyvalue (was equivalent to Holstered)
  • Use proper constants for all uses of GetBodygroup and SetBodygroup
  • Reworked animation body groups for NPCs that use new submodel structure. This is to make weapon submodels more consistent across the board
  • Added new game icon to the game installation to display in the program title bar, in the task bar and in the Steam library

C# tool code changes

  • Reworked the Utilities library to reduce the number of C# objects created by merging the entity and map APIs with the provider-specific types. For any given map this reduces the number of objects created by 1/3rd
  • Added events to allow listening to entity creation, removal, keyvalue changes and keyvalue removal
  • Added diagnostics system to enable verbose logging of all changes made to a map
  • Added command line option --diagnostics-level to the Installer and MapUpgrader tools to enable diagnostics output to show what is changed in a map

Asset changes

  • Merged sentences.txt for all three games into a single one containing all unique sentences
  • Added global sound and sentence replacement files for Opposing Force and Blue Shift
  • Added source files for new game icons
  • Added more assets to PackageManifest.json to ensure game installations contain everything needed to run the game

New sentences system

The new sentences system has been fully implemented:
Although there are still a few kinks to work out it's pretty much all there.

You can also hear footstep sound replacement in Opposing Force and sentence replacement when interacting with scientists and Barneys in Blue Shift.

The new system changes some limits:
  • Maximum number of sentences: was 1536, now 65535, can be further raised by changing the network message used to send them to the client but this will increase bandwidth usage
  • Maximum number of sentence groups: was 200, now unlimited
  • Maximum number of words in a sentences: was 32, now unlimited
  • Maximum sentence name length: was 15 ASCII characters, now unlimited but warns if it exceeds 31
  • Maximum number of unique sounds: was 1024, now unlimited
  • Maximum sentence line length: was 511 characters, now unlimited
  • Maximum number of concurrent sounds of all kinds (static, dynamic, ambient): was 128, now unlimited
Sentences are now paused when the game is paused and will not be cut off.

There are console commands to play sounds to test them out. You can optionally specify volume, attenuation and pitch although attenuation isn't very useful since the sounds always play on your local player entity.

There is a cvar to toggle between the old and new sound systems, although this only works for the first 1536 sentences listed in the file.

I've also implemented sound effects using OpenAL's EFX API which is the successor to EAX. It uses almost identical parameters but since the original implementation used software mixing and fixed position 3D sound sources the results aren't identical.

Half-Life, like Quake, uses software mixing regardless of which audio API is used to actually play it. This means distance calculations are done before the audio is sent to the EAX 3D sound sources.

To avoid duplicating distance effects Half-Life has 4 3D sources placed around the player. If you imagine a box 2x2 units wide and long centered on the player, the sources are placed at the corners of the box:
Image not to scaleImage not to scale
The new sentences system lets OpenAL handle distance calculations so sound sources are handled properly by the EFX extension, so the sound effects are working properly, but sound different from the original effects.

The effects do sound correct in-game but it's always going to be different.

Regular sound playback is also fully supported, the only thing preventing its full use is that the sound precache list can't yet be sent to the client to map sound indices back to filenames.

Improved natvis debug configuration

When viewing an entity in the Visual Studio debugger you can now see certain string values directly:
User posted image
In the future i'd like to turn string_t into a strong type (as opposed to a typedef which is treated as its underlying type) to allow this to work for all of them, but i need to make sure this doesn't cause problems before i can do that.

Entity info

This feature was added for debugging purposes, as well as to show how to implement this kind of feature.
User posted image
More information can be found here:

New game icon

The new icon is the default Half-Life icon, modified to include the base colors from all three games (shown enlarged here):
User posted image
In the Steam library:
User posted image

Diagnostics output in Installer

Here's an example of the diagnostics output from the Installer:
User posted image
Because there is an upgrade that alters the angles of every entity there is an additional diagnostics level that filters those changes out. Otherwise the amount of log output would dramatically increase.

Continued in next post ==>
Posted 2 weeks ago2022-09-17 06:11:56 UTC
in Black Mesa : Classic Post #346884
Black : Mesa Classic -
This is a GoldSrc project aimed to remake Black Mesa: Source with Half-Life assets on PC. With a classic visual style and features that push the limits of what's possible within the GoldSrc engine, including detailed textures and a more realistic environment.

Our main vision for this is to give a new look to the original Half-Life in the original Engine, Adding more realism and Inmersion, making Half-Life more enjoyable and giving long live to Goldsrc.

Our second vision is to make a new base for modding, giving some new dynamics and gameplay features keeping the
classic feeling of Goldsrc.

This project aims to be capable for be played on any PC without matter requeriments or High End Hardware. With high optimization tricks for make sure to have high FPS while playing.

We are in dire need of level designers (mappers) right now, so if you are interested, feel free to contact us. We are looking for level designers that are capable to replicate Black Mesa in GoldSrc engine with a mix of Half-Life elements in it.
Hi! The photo is was not available because "Для того, чтобы это сделать, нужно сначала войти на форум" which I think means attachments are only available when you are logged in to that website. I suggest using instead

Unlike the digits, the colon is not drawn from a 640hud sprite file, I suspect it's instead drawn entirely programmatically or from a font. Do you have recorded demo files? If you do, you can play back the demo twice, once with hud_draw 0 to hide the colon, and once with hud_draw 1 to capture the kill feed. Then using a video editor, you can combine the bottom half of the first capture and the top half of the second capture. Does that make sense?
Hello everyone, can you please tell me how to remove the colon next to the timer? Before that, I installed "full hud remover", but the colon remained.
I'm just trying my hand at moviemaking and I need the crosshair and the killfeed to be visible.
User posted image
P.S. Why is the photo not visible, but writes "User posted image"?
Posted 2 weeks ago2022-09-16 21:29:24 UTC
in HL1 Mod HUD suddenly disappeared? Post #346881
It's caused by the larger resolution. The armor hud is positioned at a fraction of the resolution so the greater the resolution the further right it moves.
Oh my god I forgot to switch the compile mode to GoldSrc in blender. Hopefully I won't make that mistake again, lol!
Posted 2 weeks ago2022-09-16 19:29:26 UTC
in HL1 Mod HUD suddenly disappeared? Post #346879
Ah, makes sense. Thank you for responding again! It wouldn't be hard to set it back to a more reasonable amount of digits worth of space, would it?
Thank you for responding. In most cases I haven't touched the bones at all. I've simply decompiled the model from crowbar, edited a (really poor) scope on, and have tried compiling it again. "Bone09" was already there when I decompiled the model. It's just the SMG attachment bone, if I'm correct.

If I delete Bone09, it just tells me that it can't find the bbox for any of the other bones. I'll check out some of those blender tutorials though, thank you!
Posted 2 weeks ago2022-09-16 16:30:33 UTC
in HL1 Mod HUD suddenly disappeared? Post #346877
Always compile both DLLs when editing weapons.

The classic WON-era view bobbing is part of the HL Updated SDK.

The HUD shifting may be a consequence of this:
User posted image
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 weeks ago2022-09-16 12:19:24 UTC
in Problems with compiling viewmodels in Blender Post #346876
You may have accidentally created a new bone called bone09. But that is unlikely seeing how it is called bone09.
What exactly did you do while looking at the model in blender? Did you copy meshes and body parts of it into an own model of your making?
Make sure that if you did that. That you copy all attached bone names as well as the body meshes (or their groups) onto the new model mesh.

Keep in mind that you can not copy paste models (for example new torsos.) onto another models head without making adjustments to the bones which are all parents of specific mesh groups. Some models got like exp. 128 bones while others perhaps only got a 100 bones. You would need to de-parent all the meshes of it's old bone structure and parent the meshes onto their new bone groups from scratch or by selecting several parts of the meshes to the desired bone section.

Bones are actually that what makes the models move later on in any game. Like our bones inside our own bodies keep us from falling and collapsing in itself to the ground as 1 large bag of water. The very fabric of what we namely are - bags of water. :) I suggest you checkout some tutorials.

Check out the great tutorials made by Tetzu0: How to install Blender for Hl1 Gold Source Engine Part2 Bone tutorial on simple can. Animating things Fixing broken Animations IK Bone rigging (Important regarding your current situation) Animation Tutorial2

Have fun.
Recently i've decompiled HL1's SMG viewmodel to edit in blender. However, whenever I export the smd from blender and attempt to compile it with Crowbar (which I know is just a GUI for Valve's official tools, making studiomdl the problem here) It just says " unknown attachment link 'Bone09' ".

Is there a reason for this? I'm unfamiliar with HL1 viewmodel editing.
Posted 2 weeks ago2022-09-15 18:38:14 UTC
in HL1 Mod HUD suddenly disappeared? Post #346874
Thank you! That was the solution after all. It works perfectly now! :crowbar:
EDIT: I appear to have the classic Half-Life view bobbing (The one where the camera tilts from side to side).

I don't remember doing the tutorial for that, but I'm not really complaining to be honest! I like this view bobbing! :)
A few HUD elements are a bit odd, though. The suit meter is quite a bit away from the health meter, and the MP5 viewmodel's a bit more centered. Is this a problem with some sort of code talking about aspect ratios?

EDIT 2: The viewmodels are fine, actually. Still confused about the HUD shifting slightly though.
Posted 2 weeks ago2022-09-15 15:51:14 UTC
in HL1 Mod HUD suddenly disappeared? Post #346873
If I'm correct, hud_draw was set to 1 when I checked it in the console. However, I think I only compiled hl.dll. Should I compile client.dll now? Thank you for responding to me.
Posted 2 weeks ago2022-09-12 21:31:44 UTC
in HL1 Mod HUD suddenly disappeared? Post #346870
Hello there, I'm the author of that tutorial.
Did you compile both DLL files? Did you accidentally change hud_draw to 0?
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 weeks ago2022-09-11 13:41:41 UTC
in HL1 Mod HUD suddenly disappeared? Post #346869
Hello. I've been working on a mod for Half-Life 1 simply so I could test some things out. So far, all I've done programming-wise is change the func_wall entity to print a message to the console (for which I just followed this tutorial, and I've changed the MP5's secondary function to the crossbow's secondary function (Instead of the Grenade launcher, the MP5 has a zoom-in feature.).

However, for some reason my HUD appears to be completely missing. In my starter map I have an HEV Suit placed down at the player's spawn point, so it is equipped. Even the flashlight and H.E.V voicelines work! However, I can't switch my weapon, and I can't see any HUD elements.

I've only modified hl.dll. I haven't touched client.dll.

If it helps, I could try and include the DLL files.
Posted 3 weeks ago2022-09-09 03:38:21 UTC
in Strange issues with J.A.C.K editor Post #346867
make sure you don't save your map with UV lock turned on, apparently that can corrupt the faces
At least on the linux jack, if I remember correctly, textures get screwed up if you open the map with UV lock turned on. If you get these messed up textures, don't save the map, instead turn off UV lock and then restart jack and open the map again, then it should be fine
Ahh, that might be the issue, I had UV lock on fairly often. I fixed up the warped textures and the seem to be behaving on reload now, so I'll keep that in mind. Thank you!
Posted 3 weeks ago2022-09-09 02:45:23 UTC
in Issues with seedee's compilation tools Post #346866
Hi, a patch has been released which should resolve this issue.
HLVIS cleans up the .prt file after compilation, letting you import it to J.A.C.K. seamlessly. However, sometimes it can skip this process where necessary, and skipping it was set to cause a fatal error when it wasn't supposed to.