Forum posts

Welcome, new guy!

clientscheme.res ain't working, edit TrackerScheme.res instead. You can find the Half-Life TrackerScheme in Steam/steamapps/common/Half-Life/platform/resource/, just copy-paste it to the appropriate folder in your game.

GoldSrc does not support two-sided model rendering. You'll have to clone the mesh manually, and flip the cloned mesh's normals.

You mean, he inspired you.

I shall provide minor programming assistance if needed.

Might wanna post this in the "Post your screenshots" WiP thread. But dang. That looks real pretty. owo

Are there any leaks in the map?

The WAD can store maaaany textures, halflife.wad is an example. I'm not aware of how many exactly.

Also yes, you generally shouldn't make textures too big. Generally, you should stick to 240x240 and less. HLBSP is gonna subdivide polygons every 240x240 texture pixels. This means, if you have a 200x200-unit brush with texture scale set to 1.0, its top will be 1 face. However, if you scale it to 0.5, you'll get 4 faces.

Having large textures is okay if you aren't making the scale really small. 0.5 is the minimum acceptable texture scale IMO, 1.0 is the default, and in larger areas, you can get away with 2.0, sometimes even 4.0.

The error which you get by using low texture scales like 0.5 or 0.25 is typically "AllocBlock full", which means you've hit a limit of how many lightmaps can be allocated for the map. The engine, unfortunately, has a hardcoded value of allocating 1 lightmap pixel per 16x16 texture pixels.

Now, in regards to actual texture dimensions, I'd suggest you to use 240x240 and 480x480 for really HD stuff. HL used to have a "feature" where it would downscale any non power-of-two texture (e.g. 160x160) to the nearest power-of-two one (e.g. 128x128), so you'd lose quality. But, nowadays it's no longer a thing.

Also, the reason those textures might not be appearing in J.A.C.K. is, the texture dimensions maybe aren't divisible by 16. Not exactly sure.
Generally, you should use these values for X and Y:
32, 48, 64, 96, 128, 160, 240, 256, 320, 384, 480, 512, 544.

The maximum texture resolution is about 544x544, but it only works if it's embedded into the BSP.

Do you have any leaks in the map? That could be a cause as well.
The map doesn't look like it needs so many clipnodes.

There are.

HL1:

• Half-Life: Invasion
• Spirit of Half-Life (which was an open-source mod by definition, but anyway)
• Half-Nuked
• Arrangement Rebirth

... and probably a bunch of others.

For HL2, I don't know any, but they're out there for sure.

There is a big problem with the map.
It's surrounded by a sky "box".Instead, you should "cap" the parts where you can see the sky, like this:Clipnodes are collision data for the map. If there were no clipnodes, then we'd fall through the floor as soon as we spawned.
The problem is, when you have a large sky "box" around your map, the compilers will generate clipnodes for literally everything. Even the outer parts that you aren't supposed to reach as a player.
If you seal a map properly and fix all leaks, this problem shouldn't happen.

A small update on the current development status of UAS/ADM:
I've been a bit busy with Heffernan's "Delta City 2155" mod, but I should be back to this thingy next week.
Can't wait to do some more stuff about the FMOD implementation.

Check the player use code in player.cpp. Maybe it's got something to do with that. SoHL added some sorta traceline to check if the player's view of the button is obstructed by any world brushes, and chances are, the SoHL "direct use" flag is messing with vanilla HL use code.

What are the changes between your code and the original?

I think that initially, when/if SL gets its true release, the compatible mods will only be mods that don't use custom code.
So mini mods with maps, models and stuff would be fine out of the box, but if it's got custom code, it'd have to be rewritten in C# following Sharp-Life-specific stuff.

"i wonder what that means.. "custom graphics code" and where that should be "inserted""

We're going extremely off-topic from the original thread, but I believe I must show you an example of "custom graphics code" which will get compiled into client.dll:This can be taken to a whole new level, where you can replace the renderer entirely. So instead of using OpenGL 2.0 or whatever, you use OpenGL 3.3 with GLSL shaders.

Oh nah, I'm not talking about mextrasurf_s but rather this:

typedef struct texture_s
{
    char                name[16];
    unsigned int        width, height;
    int                    gl_texturenum;
    struct msurface_s    *texturechain;        // for gl_texsort drawing
    int                    anim_total;            // total tenths in sequence ( 0 = no)
    int                    anim_min, anim_max;    // time for this frame min <=time< max
    struct texture_s    *anim_next;    // in the animation sequence
    struct texture_s    *alternate_anims;    // bmodels in frame 1 use these
    unsigned short        fb_texturenum;        // auto-luma texturenum
    unsigned short        dt_texturenum;        // detail-texture binding
    struct mextrasurf_s    *lightchain;        // used for drawing spotlights
    unsigned int        unused[2];            // reserved
} texture_t;

Allegedly, this works just fine with vanilla GoldSrc. I found this texture_s version with gl_texturenum in it on accident, in a Russian tutorial about mirrors.
I wouldn't be surprised if I can get a reference to detail textures this way, too, because then I can just do gl_texturenum = dt_texturenum; or if that doesn't work, I grab the actual texture handled by gl_texturenum and replace it with the one from dt_texturenum using OpenGL commands. It'd be pretty interesting to experiment with these.

The only reason Paranoia has a custom opengl32.dll is because they didn't know how to achieve things without it. Everything they did with a modified opengl32.dll was entirely possible with the original one, by using proper graphics programming techniques.

They did 3 things: added a stencil buffer, added an alpha buffer and modified the depth range. The alpha buffer was, interestingly, used to support really old GeForce graphics cards, in terms of storing render data for dynamic lights. There are other ways to do that without using a hacked DLL.

But the funniest thing of all is, the stencil buffer was "needed" to prevent the flashlight texture from tiling itself, which was actually easily fixable without a custom DLL.
Here's an illustration:Instead of modifying opengl32.dll, they could've just used a simple flag for the texture: GL_CLAMP_TO_EDGE with, of course, a completely black border around the texture itself.
Here are 4 different options for texture wrapping:Taken from here.

The depth range modification was unnecessary, because they could've used some maths to adjust the depth values on the receiving end.
In case you're wondering, this is depth:These values go between 0.0 and 1.0, and it is generally used to blend fog, soft particles and such. I don't know how Paranoia's renderer utilised it, but editing the DLL was needless.

If you want to improve performance in Xash3D, or any HL mod, really, you have to learn about graphics programming with OpenGL. If you have access to Xash3D's source code, you can probably do some smaller optimisations without rewriting the renderer.
Otherwise, if you want a 2x, 3x, 5x improvement in framerates, you need to have quite some experience in modern OpenGL or Vulkan. The most ideal one IMO would be OpenGL 3.x.

One misconception is that rendering APIs like DirectX, OpenGL, Vulkan etc. automatically just render your frames and whatever you throw at them. People think they're like "plug'n'play", but no, they're not. Instead, you are the one who defines how OpenGL will work. You tell it how to render the triangles etc. There are many, many functions that the API provides to you, and you can use it. You are wrestling with your graphics card, yelling at it how to render your stuff.

The problem is, GoldSrc's renderer uses OpenGL in so-called immediate mode. And I've probably talked about this 120 times on TWHL Discord, but here's how immediate mode rendering works: (in a very very simplified way)

• you tell OpenGL to "begin" rendering
• you send texture data, vertex data (vertex positions, UV coordinates etc.)
• you tell OpenGL to "end" rendering and wait for the next frame

The thing is, the CPU is always sending rendering data to the GPU, every frame. The GPU receives the polygons, the textures etc., but it immediately "forgets" it the next frame. This is reason #1 why GoldSrc and Xash3D can perform poorly with many wpolys and even more epolys. Of course, in the late 90s, video cards were built for immediate mode, so logically, it was the only option.
But, it's an issue today and it'll be an issue for God knows how long, because modern GPUs have to emulate this mode. Modern GPUs are built for something else, called retained mode.

Retained mode works this way:

• upload data to the GPU's video memory (preferably when the map starts), and it stays there
• render them and wait for the next frame

When you're not sending all the data every frame, you can theoretically render the entire map at 200fps, lol.

So, if you want better fps, learn graphics programming and rewrite a part of, if not the whole renderer to work more efficiently. Otherwise, don't make high-poly models.

In other words, if you take Paranoia's opengl32.dll, you are NOT gonna get its neat graphical effects. None of them. Chances are, something might even break.

If you want to add fancy graphics, you must implement all that yourself and none of it requires a custom opengl32.dll!
Bloom (outdated, relies on Cg)
Normal mapping (also outdated since it relies on Cg)

If you want those fancy effects, your best option is to just rewrite the whole renderer, use OpenGL 3.3 with GLSL shaders, and do your stuff from there.

That is called graphics programming. opengl32.dll is usually inside the System32 directory, so there's no need at all to put your own into your game folder.

In order to use OpenGL, you might wanna install some stuff like GLEW, to be able to check for OpenGL extensions easily, and also (in case it's not been done), make sure you link against opengl32.lib:Then you can use OpenGL functions:It doesn't require a custom OpenGL DLL at all.

There's a process called rip-enting, where you can only change the entity data in the BSP.
However, you cannot exactly open that up in Hammer, it's all text editing.

Hold up. Sixcentgeorge, is that you?

Hello there.

First of all, I'd recommend you Visual Studio 2019 with Solokiller's updated HL SDK for it.
Here's an example trigger_random class which basically acts like a trigger_relay but it has a trigger percentage keyvalue.

class CTriggerRandom : public CBaseDelay
{
public:
    void Spawn();
    void KeyValue( KeyValueData* pkvd ); // this will load your map editor keyvalues/properties
    void Use( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value ); // this is called when the entity gets triggered by another one

    int ObjectCaps( void ) { return CBaseDelay::ObjectCaps() & ~FCAP_ACROSS_TRANSITION; }

private:
    float triggerChance = 0.5f; // 50% trigger chance by default
}

LINK_ENTITY_TO_CLASS( trigger_random, CTriggerRandom );

void CTriggerRandom::Spawn()
{
    // nothing here
}

void CTriggerRandom::KeyValue( KeyValueData* pkvd )
{
    if ( FStrEq( pkvd->szKeyName, "chance" ) )
    {
        triggerChance = atof( pkvd->szValue ); // read the map property and assign it to a variable, it's in range between 0.0 and 1.0
        pkvd->fHandled = TRUE;
    }

    else
    {
        CBaseDelay::KeyValue( pkvd );
    }
}

void CTriggerRandom::Use( CBaseEntity *pActivator, CBaseEntity *pCaller, USE_TYPE useType, float value )
{
    if ( RANDOM_FLOAT( 0.0, 1.0 ) <= triggerChance )
        return;

    SUB_UseTargets( this, USE_TOGGLE, 0 );
}

Now, I gotta say one thing. This entity has to be triggered first. If you want it to try to automatically trigger something every 0.1s, for example, you will have to modify the code a little bit, but for now, I think this will show you the basic idea of how to do it.

Funny thing is, Source 1 has nothing to do with Source 2, as they're completely different beasts. One makes you angry, the other is just, I dunno, friendly.

The editor doesn't actually have to work that way, since you can build rooms wall by wall.
All the "brush" editing is still there, except you are no longer limited to just them.

In fact, I think that what I'm doing is a little bit wrong (inverting a cube), because I might fall through the floor that way in-game. But, I'll see about that in summer, or someone else can test it for me, lol. (edit: actually, no, you don't fall through the floor, so that's good)

The way the editor works is literally like a modeling program like Blender, except it's more specialised for level geometry. You can make a hollowed out room, but you don't have to.

"Search on EBay and for less than 50$ your problems will go away"

Or, you know, you can just get Solokiller's updated HL SDK, and Visual Studio Community 2019, and pay 0$.

Visual Studio 6.0 is practically abandonware (abbadon-ware ), and you can get it for free if you got a Microsoft account with the Dev Essentials thingy. At least I think so. Many older versions are available there after all, so.

Yeah, those are "hotspot" materials, they're really cool. I wish we had something like that in TrenchBroom or J.A.C.K....
Also, I think they might make a Source 2 version of it but not as soon as the next few months IMO. But I surely hope it'll come out, because I'd love to get back into mapping. uwu

I've had experience with it in SteamVR, but I haven't tried out the workshop tools yet. I'll probably try them out once I buy HL:A this summer. I don't have any VR equipment, but I don't care at all.

I absolutely love Hammer 5 / Source 2 Hammer / Hammer 2.0 / whatever you call it. (canonically should be Hammer 5, but let's just call it Source 2 Hammer to avoid all confusion)
I love it, I love it, I just love it. I'd have sex with it if I could. It's just such a good piece of software.

I don't need to pull off 6 brushes to make a room any more. I can just invert a cube!And then do stuff to that inverted cube.Also, arches are so God damn easy to make now, as well as curved tunnels. Carving is GONE, too. I LOVE THIS SO MUCH!
Let's say you got this thingy here:And you want to convert this, like, diagonal piece into an arch.
You'd just delete the 4 faces between them (this is all 1 "brush"), select the two edge loops, hit Bridge, and BANG!I can tell you, we've just entered a new age.

I set fps_max to 999 and tried out the same map. I only got stuck at the 45° part, which is where these two brushes meet:But then I tried out a normal arch, which is not twisted or bent like the one in there.(note: everything there is on-grid)

And I'd get stuck a lot. Anywhere where two brushes met. This happens due to how GoldSrc map collision works. It has something called clipnodes, which basically define a mesh for collision, it's a bunch of planes.
These clipnodes expand on common brush edges:If they didn't expand, then the player would go into the edges, as if it were something like this:Ironically, it seems to fare better with off-grid coordinates than on-grid ones, hah!
I don't think there's a way to solve this without modifying the player movement code, though. And since you're mapping for TFC, that is not an option.

It could be anything.
I conducted a small experiment where I placed an arch consisting of 16 sides.The map was compiled with -cliptype precise in HLCSG.
In-game, it was perfectly fine without getting stuck anywhere.

But, you mentioned not following the grid. So that probably means you got floating point coordinates in places. To get an off-grid result, I added a ramp here:However, the result was basically the same. It was smooth with no clipping into walls.
So, I tried to manipulate the arch a bit to be under a different angle:Yet the result is still the same. The resulting vertices in the BSP are basically off the grid, but the player movement code handles it just fine.
Here's a video of how it looks.

So my question is, what compilers are you using and what compile parameters are you using?

Well, here's what you can do.

Use something like WinMerge or any code comparison website, compare what you've changed between HL SDK 2.4 and your own .cpp files.
And then carry over the differences to the updated SDK for VS2019.

Did you compile both DLL files? Weapons are both in hl.dll and client.dll.

What code did you exactly change or add?
Chances are, if you switched to HL SDK 2.4, you maybe overwrote all the changes you did to your 2.3 SDK.

BTW about newer versions of Visual Studio, you should use Solokiller's updated HL SDK, works with Visual Studio 2019 even.
https://github.com/Solokiller/halflife-updated

Thank you. You're gonna see more environmental stuff in my mod Utopia at Stake. ^^

Looking at the screenshots, the map geometry is all over the place.I hope you are not putting a huge sky BOX around the map, because doing that can cause a lot of problems.
From the compile log, it seems that HLBSP just crashes at 15%:
1000...1500...

Lol, Abbadon, he was asking koe1, not you.

You can look here for Opposing Force:
https://github.com/Solokiller/halflife-op4

The Specialists definitely didn't change the player hull size.
I dunno about ESF though. I still don't quite think that's the case.

Creating massive maps needs 3 things: changing values in delta.lst, changing a couple of things in the HL SDK code, and using custom compilers that support this new boundary. Or, well, 4: a map editor that can place brushes at these large coordinates.

My latest test involved making a map that is about 57k x 57k units and it worked just fine in my mod.It wouldn't work work in vanilla HL, that's for sure.

Also, if you're thinking of decreasing the hull size, I think you're gonna have to do 2 things: use a custom hull file while compiling your map (which defines how large the hulls are, while generating cliphulls) and make modifications to the HL SDK.
I've never done it personally, because if you decrease the player's size, then you have less room for detail. 1 unit will look like 2 units to the player, or even worse, 1 unit will look like 4, depending on how much you decreased the size. So if you want it to look like 1 unit to the player, you'd have to somehow make 0.25...

My assumption is that even if you modify that texture data, you won't see any changes.
texture_t isn't exactly the same as in GoldSrc IIRC. There is a gl_texturenum for detail textures AFAIK but you need an updated com_model.h for that. uwu

This was true back in the day, but it's definitely not true nowadays, that's my point. If someone doesn't use VHLT, they're basically shooting themselves in the foot.

@tschumann I haven't even touched it, sadly. I must've forgotten again.
Anyway I am gonna take a look at it today. uwu

@Solo
Thank you very much for the info! I'm planning to poke around just in OpenGL mode, as the experimental branch is already crashing in Software mode, LOL.

Feel free to visit the TWHL Discord if nobody here at the forums is really responding.

"If your map lags - it is usually due to micro leaks your current compilers won't even detect. One more reason to use the compilers I recommended they got a very good detection system to find such micro leaks."

I'm sorry, but this is stupid. If any sort of leak happened, HLVIS and HLRAD would likely crash. In fact, HLBSP could probably crash first because some of the coordinates in the .prt file would go to infinity.
If your map lags, then your map is either not optimised at all or it's just so complicated and full of details in one big area that you can't optimise it (which is bad design).

In other words, if you're using a big hollow box around your map (as a sky "box"), then the engine is gonna render almost the entire damn map, and that is just too much for weak PCs. Maybe you are also compiling with fast VIS, which also leads to the engine rendering everything at once.

Also yes, flickering lights do cause lag because the lightmap data has to get modified by the CPU, then reuploaded to the GPU every 0.1s, which is horrible for performance.

"Ever wondered why you haven't seen a CS_superbowl map? I am not saying it can not be done, I am saying that the engine isn't up to it."

The engine can be up to it if you do it right.

Oh, we got tutorials for that here at TWHL Wiki:

https://twhl.info/wiki/page/Half-Life_Programming_-_Getting_Started

Glad it worked, though!

It'd require a little bit of programming. Each monster has got a 'classification', which can be one of the following:

• CLASS_NONE
• CLASS_MACHINE
• CLASS_PLAYER
• CLASS_HUMAN_PASSIVE
• CLASS_HUMAN_MILITARY
• CLASS_ALIEN_MILITARY
• CLASS_ALIEN_PASSIVE
• CLASS_ALIEN_MONSTER
• CLASS_ALIEN_PREY
• CLASS_ALIEN_PREDATOR
• CLASS_INSECT
• CLASS_PLAYER_ALLY
• CLASS_PLAYER_BIOWEAPON
• CLASS_ALIEN_BIOWEAPON
• CLASS_BARNACLE

So, you could download Solokiller's updated HL SDK for Visual Studio 2019 and change every CLASS_PLAYER_ALLY for example, into CLASS_HUMAN_MILITARY, then compile the .dll files.

Or you can just edit the monster relationship table:Alternatively, you could probably use Spirit of Half-Life 1.2, which allows you to set the classification for each monster individually, in the map editor. (though, it has a tendency to break other things and crash more often than vanilla HL)

I forgot I was gonna do that. Oops. Well, now is the weekend, so... time to see.

This part here:Basically, you have a 4-sided brush there, while the other 3 brushes are 3-sided.

It needs to be merged into the same corner, like this:

Are those boxes func_wall?
You might wanna switch them to world brushes, or func_detail.

Doom 3 is the best Doom IMO.

Chances are, you probably just placed the brush outside the map boundaries. Do you have any brushes that go over 4096 units, or under -4096 units?In this screenshot, for example, every single brush is within the -4096 to +4096 unit range. Regular entities will stop moving if they reach those boundaries.

Also, what compilers are you using? ZHLT or VHLT?

Also, one thing to keep in mind is, you're gonna need an updated header file for BSP models.
As for the offsets, I'll try to check these out this weekend.