Forum posts

Neither bump mapping nor normal mapping will achieve the effect you want in those screenshots. You seem to want actual 3D extrusions, instead of the effect of bumpmapping.
You might wanna do some research about parallax mapping and relief mapping.

https://www.youtube.com/watch?v=5gorm90TXJM

There are ways to do it for brushes. Detail textures aren't gonna cut it at all unless for a very specific lighting setup.
This article is a good start. However, instead of using Cg for the shading, you can use GLSL shaders.

Discord
The social platform that suits folks like me the most. My parents ain't there, my classmates ain't there, none of my IRL friends (which I don't have) are there, just my Internet buddies. Turning on its light theme will give your eyes the equivalent of Chernobyl 2.0, but at least there's a way for custom themes, if you're willing to take the risk of getting your account into trouble.

I like how I can share my screen, voice chat and do stuff like that. Tis a pretty flexible lil thing. TWHL has a Discord server too, but everyone knows this by now, lol.

Sometimes it can be unreliable with messages not sending themselves, and at other times there are server outages, and my God, any new feature they add nowadays just seems like a blatant attempt at ripping off Guilded. At least, that's what my friends say. Discord's latest 'reply' feature is cool but it seems like it adds a lot of noise, making chats harder to moderate.

But overall, I'd always, and I mean ALWAYS, use Discord instead of Skype, Viber, Facebook Messenger and whatever other stuff I've used in the past. God bless them.

Hamburgers

Oh yes, that is the video indeed. Very cool stuff.

I remember those two first screenshots from a ModDB video or something. owo
Nice work!

Team Fortress 2
Funny game with funny characters, silly hats and one of the most wholesome (and dumb) characters in all GMod and SFM films (Heavy).
I played it when I was 7 or so, and that's the game where I used a microphone for the first time. My very FIRST efforts at socialising were there. Everyone thought I was German for some reason, probably due to my accent back then. But everyone here knows I'm Bosnian.

I think TF2 is partially responsible for the start of my mapping journey as well, as it's the first Source game I tried mapping for. Soon after, though, I moved to CS 1.6 mapping and stayed there for a good while. :^)

Err... looking back at it today, I got no interest in it and it's definitely not like it used to be. Mann vs. Machine was cool tho'.

QuArK (the map editor, not physical quarks)

Ay, you're welcome. Speaking of tutorials, I think some basic TriAPI lens flares would be good tutorial material, for example on the TWHL Wiki.

One simple method, perhaps, is to use TriAPI's "world to screen" projection of coordinates, if your "sun" is somewhere in 3D space and you're performing a traceline every few frames to determine its visibility.

That way, you'll get the 2D coords of the farthest lens flare, which can be the sun sprite itself. Then draw a series of sprites that are offset from each other, going towards a "pivot" (which is the centre of your screen). In other words, world-to-screen projection followed by multiple reflection around the screen centre.It's quite simple if we treat the pivot as position (0, 0). Let's say if WtS is (-8, 20), its reflected counterpart (let's call it R) would be (8, -20). And then you subdivide the "line" between them and put some more flares.
For example:
FlarePos1 = 0.75*WtS + 0.25*R
FlarePos2 = 0.50*WtS + 0.50*R
FlarePos3 = 0.25*WtS + 0.75*R

The other method is some trigonometry where we do this projection manually, that is, implementing a perspective projection matrix to convert some 3D coordinates into 2D. Then you do the same thing as above.
https://www.scratchapixel.com/lessons/3d-basic-rendering/perspective-and-orthographic-projection-matrix/building-basic-perspective-projection-matrix

You can open the .vmf file with J.A.C.K., if I recall correctly.

Oh yeah, let's rock'n'roll, folks.
I'm pretty happy to be part of this project lol

In Source, I don't seem to have this effect, probably because I've been playing Source games since I was quite young (7 or so). It was creepy back then, but I guess not now lol.

However, with that said, I had had this phenomenon in one of my GoldSRC maps, de_kobbl. I can't tell what version was creepier to me when playing it alone, the day or night version. Dark, once-lively mining town with traces of its victims. Then you hear gunshots in the distance, and the wind. Oh, does the occasional wind make it creepy.

Yes, it is an Arctic fox.

"I did not know that the latest SDK was on Github, neither I know how to use another program to code"

You're in luck, because this month, I'm planning to make a video about the installation of VS and doing some stuff.

BTW, writing code in any IDE and text editor is basically the same. You just click somewhere and start typing on your keyboard (unless you're using one of those things like Vim).Some tools have different features compared to others, but at the end of the day, C++ is still C++.

"what is that ugly creature? is that a dog, a cat, an albino fox?"

Pretty sure it's you.

"That keyboard typing sound in the background was a bit distracting"

Oh yeah, the background noise comes from my younger brother. He was writing some Roblox Lua scripts. I'll definitely try to find a quieter place to record stuff in, either the attic or the basement.

fox*

Though it does look like a dog. After all, foxes are dog hardware on cat software lol.

"I'm not sure why you brought Visual Studio 6.0"

There are some folks, I'm guessing, who believe that modding old games is best with old tools. With some specific games it's true, but not with HL.
Other than that, you might also find some people who still think HL SDK 2.3 is the latest, in context of code. Also not true, since the latest one is on GitHub.
So in short, I just wanted to pay some attention to all that, with the message being "always use modern tools if you can."

Speaking of the SDKs and that type of stuff, one might ask why I didn't mention and explain them in this part. I actually planned that for the next part, where I'll cover choosing an SDK, setting up a mod and making the first change. And then, in the part after that one, I'll start doing some simple entity stuff.

Either way, I'm very happy with how it turned out, and people seem to like it, so this series is definitely going to go forward.

Inspired by Dimbeak's "Gaming for Your Sins", I've decided to start a video tutorial series as well, however, it's programming instead of mapping. Programming for Your Sins, anyone? xD

Here, I'll post each part as it gets released. Hopefully, the frequency of uploading will be once per one or two months.This first video is long by design, but videos after it are gonna be a bit faster-paced. The first few videos are gonna be meant more for beginners, with rough explanations of what classes are, what pointers are and whatnot, but once the series progresses and I start showing some really fancy stuff (complicated entities, weapons, NPCs, money system etc.), then it'll be even faster-paced. I'm hoping that the videos will be no longer than 6 minutes, while some short ones will be up to 2 minutes.

Note: the audio quality is not what I wanted it to be, but given the conditions I'm in, I think it turned out good enough. I'll record in the basement next time, for complete silence and free reverb. xD
Or maybe the attic, wherever's more quiet.

You are legit inspiring me to also do a tutorial series. xD

Time to show some dumb screenshots from my even dumber ioquake3 fork.Since school started, I decided to start working on a little engine project for next year's Bosnian gamedev competition. It's gonna be a heavily modified Quake 3 engine that shares some of its ideas and philosophy with GoldSRC and CryEngine. What that actually means will be explained some other day.

So... what is this? A blue dynamic light entity? No. It only looks like it. I'll explain what's going on. Simply put, the engine is managing two entity systems at once.

The engine was originally written in C, and as such, the concept of entity classes isn't achieved via classes themselves. It still does it the way Quake and Quake 2 did it, by using structs and function pointers. Nothing wrong with the approach, depending on the scale of the game.
For example:

void func_breakable_pain( gentity_t* self, gentity_t* attacker, int damage )
{
    if ( self->health - damage <= 0 )
    {
        // Gib me
        GibEntity( self, 0 );
        // Remove entity from world
        G_FreeEntity( self );
    }
}

void func_breakable_use( gentity_t* self, gentity_t* other, gentity_t* activator )
{
    // Damage itself when triggered
    func_breakable_pain( self, activator, self->health );
}

void SP_func_breakable( gentity_t* self )
{
    G_SpawnInt( "health", "50", &self->health );
    G_SpawnString( "model", 0, &self->model );

    trap_SetBrushModel( self, self->model );

    // Link entity into world
    trap_LinkEntity( self );
    self->takedamage = 1;
    self->pain = func_breakable_pain;
    self->use = func_breakable_use;
}

I'm not satisfied with that though. To get what satisfies me, it'd take much more work to modify the existing system, than to make a new one from scratch. So the latter is exactly what I'm doing.

This is how it'd approximately be in the new system:

class FuncBreakable : public BaseQuakeEntity
{
public:
    void Spawn() override
    {
        health = spawnArgs->GetInt( "health", 50 );
        takeDamage = DamageTypes::All;
    }

    void Use( IEntity* activator, IEntity* caller, UseType useType, float value ) override
    {
        Pain( activator, health );
    }

    void Pain( IEntity* attacker, int damage ) override
    {
        if ( health - damage <= 0 )
        {
            SpawnGibs( GetOrigin(), 20, "models/somegibs.md3" );
            MarkForRemoval(); // next tick, this entity is gone
        }
    }

    const int GetEntityFlags() override
    {
        return EntityFlags::SolidBrushEntity | EntityFlags::Static; // will automatically set up a brush model, movement type and solidity
    }

private:
    int health{ 0 };
}

This is just there to get you the basic idea. There's a ton of other stuff I've had in mind for this project.

The blue light is there instead of a visible brush entity, because I didn't finish the networking code. The netcode treats the entity from the new system as if it were one from the legacy system, so it ends up writing the data entirely wrongly, and the client, of course, interprets it wrongly. It's a miracle that it didn't crash the game LOL

Other than that, I'm messing with it just so I can get an excuse to use TrenchBroom instead of J.A.C.K. (even though J.A.C.K. also supports Q3)
I'm loving it so far!

I mean, I used to do it with smoke sprites too. It's just that smoke sprites are, well, entities. They use edicts, and you can't have too many of them.

In reality, I just worked on it sporadically throughout the last 3 years, which is basically how I work on any large map. Lol

WILL I GET YOU INTO A PLAYABLE STATE THIS YEAR?!
I THINK SO!My classmates have been waiting for basically 3 years at this point LOL
I will probably make a few new big textures to cover larger areas, and release some sorta preview.

Are you sure you provided the correct link to the tutorial? It leads to a forum thread where none of the 3 links in it are active, and in the Web Archive, nothing can be found regarding the water shader files.

Amazing concept! I'll have to try this out soon.

Seedee's tools basically introduce a new tooltexture and fix the portal files.
Hammer, J.A.C.K., Sledge, basically any editor out there, refuse to open .prt files due to the way VHLT generates them. Seedee's tools basically fix that AFAIK. (so do my tools, but I won't mention those any time soon )Nem's batch compiler should expose everything you need to do with VHLT for now. There are maybe some features that it doesn't expose, but they're rarely used anyway.

Nice and welcome back. :3
Are you using ZHLT map compilers? Lots of stuff has changed in the last 12 years.

Fog... or fumes?:'D

"The renderer is certainly a massive discovery! you should be super proud! I cant wait until the next update!"

I'm super duper proud already, as with all my work so far.

It's not much of a discovery TBH. People have done it multiple times in the past, they just didn't share too much stuff around. I primarily wanted to do the experiment when I saw this old video again:In fact, I once saw a Vulkan renderer from the same guy in 2017. There were screenshots on the old Valve Developer Union Discord, but that place is gone now. IIRC engine updates broke some things so he stopped working on it.

The thing is, however, a lot of these renderers from scratch tend to never get released, and most of them that do are mostly renderer additions, not rewrites. The most significant releases I can think of are Trinity Renderer, Paranoia's renderer (in the Paranoia Toolkit) and MetaRenderer. But they all have flaws. Paranoia's renderer is slow and sometimes buggy IIRC, MetaRenderer can get you a VACation due to its usage of a hacked opengl32.dll etc.

So, I thought it'd be a good time to plant the seed of a fast, safe & public renderer rewrite. The best part about this IMO is that it doesn't use any extra DLLs, and it doesn't do anything yet that would trip VAC. We'll see about it in 5 years lol.

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.