Forum posts

I like what I'm seeing there. ^^

Recently, I've been experimenting with OpenGL and I'm pretty happy to have found out that modern OpenGL is, indeed, possible in HL.If I were to rewrite the entire renderer, provided I know what I'm doing, it could dramatically increase the performance, and allow maps to use custom shaders and stuff like that. Think about a shader for real-time moss growth.

However, before I can even think about working on such a renderer (which would replace the entire GoldSRC game renderer, except for the main menu, HUD and stuff), I'll have to focus on bugfixes in my mod base, and then on my ioquake3 fork. But, who knows, maybe it'll be there sooner.

That is caused by linear texture filtering, where the edges between each individual pixel are blurred. OpenGL does not care about the texture boundaries, nor any neighbouring faces, so it blurs every single pixel in the texture.
If you use gl_texturemode gl_nearest_mipmap_linear, this should be gone.

Otherwise, you probably have no option but to shift the texture 1 or 2 texels toward that other texture, so you can prevent the artifact from appearing.

Also, something that I find good in J.A.C.K. are the entity connections. It draws lines between triggers and targets, so you can know what entity should be triggering what entity at all times. It definitely helps with the direction arrows too, so I can know exactly how my light_spot or light_environment is rotated.

Other than that, you can toggle NULL, CLIP, HINT and SKIP, and AAATRIGGER. All those except NULL are transparent too, so it doesn't clutter the 3D view.

There's no prefab support in J.A.C.K. Your only option is to open two maps at once, and copy-paste from one to the other. There are several prefab maps out there with all HL1 prefabs.

That's a side effect, you'd have to do quite some effort to carry items and other data across transitions in multiplayer.

changelevel2 will never work in multiplayer, as far as I know.
Your best bet is using just changelevel and pass the next map's name.

You could try opening the .map file in J.A.C.K. I wonder if it'll complain about too many visible objects lmao.

"Oh! and the tools, lockpicks and the such!"

Oh wait, don't get it confused with Utopia at Stake. xD
They're not the same thing, albeit UAS will be based on ADM.

ADM is the base which will have FMOD, vehicles and a bunch of other entities, while UAS is gonna be a total conversion mod that will actually introduce the new tools, weapons and such stuff.

The upcoming release will basically be ADM 0.1 alpha. This means it should have the following ents: (some of which aren't yet implemented, but will be there soon)

• audio_2d
• audio_music
• func_novis
• func_loadbar
• func_lag
• phys_box
• phys_explosion
• util_consoleprinter
• util_kv_operator
• util_servercommand
• util_movewith
• util_rotator
• env_sky
• filter_date_smh
• filter_date_dmy
• trigger_difficulty
• trigger_timer

And some vehicle entities: chair, couch, bathtub car and a simple helicopter with a few seats (which is not yet implemented).
Other than entities alone, it should support up to 65k x 65k x 65k-unit maps out of the box (although some effects like explosions don't yet work outside of 8192 units).
I'm planning to host a testing session live with some buddies on TWHL Discord, too, right about before this gets released. It's either gonna be crazy, or it's gonna be a disaster. Maybe both.

I'm glad someone is excited. ^^
Can I know some of the features you're looking forward to?

That is excellent.

I haven't posted anything of my own in here for some time, hmmmmmm. :3c
Time to change that.

A smol debugging overlay:Point ents -> boxes
Sprites -> spheres
Brush ents -> corner boxes

Some more progress on my old Quake map (it's been in sporadic development since 2017):While testing Advanced Development Mod with my brother one night, we decided to play on the 57k x 57k units map. Dang. He looks so small from a distance.Outside of Half-Life, I'm planning to start a 2-in-1 project with CryEngine 5. It'll be a game, but also a "game system", if I could call it that way...
The main thing about it is that it'll be a full-on FPS template that is good for beginners and people who are coming from GoldSrc and Source. The main thing about it will be the way entities work. I want to achieve something like GoldSrc or Source's trigger system in a modern engine.

And as a mini pet project, I am converting idTech 3 to C++, bit by bit. I've had success since the game, client and UI DLLs are in C++. The engine EXE and dedicated server EXE are also in C++. Now I just gotta actually C++-ify some parts. Efforts have been made in the entity system, since there's an engine entity interface, for example. There's a lot of work to be done, but yeah, I'm pretty happy with it so far.

It's not showing cuz' you linked the album. You need a direct link ending with the extension, like fj39ud3.png or something like that.

[img:https://i.imgur.com/VHdUlnq.webp]

There we go.

Make every angle 0.1. env_sprite has weird rotation logic when it spawns.
So if you want to set pitch to 90°, you should set yaw and roll to 0.1° each, e.g. 90 0.1 0.1 in the properties.

I think the 7G on security doors in HL1 means "Sector G, lab/area/room/whatever 7" or something like that.

You'll need to use a special Xash SDK for that. You'll need to do some digging to find a VS2019-compatible one tho'. Last time I checked, they built it with VS 6.0, lol.

That'd be pretty nice. I think it could go somewhere here:
https://twhl.info/wiki/page/Tools_and_Resources

Though, we'll have to see what Penguinboy thinks of that first. I'm just a regular community member, so I just think it'd be nice.

That will require some OpenGL programming, and that's not really meant for beginners.
Specifically, you would have to implement a projected texture, although if you really want to do it, you can probably take a look at Trinity Renderer's source code.

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. ^^