Journals

So Valve's 25th anniversary update pretty much broke all custom renderers that would replace Half-Life's world renderer code, and that meant I had to jump into Trinity and apply some fixes. I initially thought I only had to change one engine structure, but oh boy, Valve had some surprises for me. Turns out they now use a variable which I previously used for storing indexes, as it was never used previously. I had to totally rewrite everything that dealt with that particular bit.

You can find it here:
https://github.com/TheOverfloater/trinity-engine

• Abyss Engine

I also wanted to provide some updates on some stuff I spoke of in the Discord. As most of you know, Trinity eventually evolved into the Abyss Engine, used in Abyss-048 and Half-Life Episode Two, and now also a mod called Nohra's Concealment. This engine revision has improved code, such as studio models rendered in retained mode, and support for vertex weights. It's also an all-shader based renderer, which means it's far faster than Trinity was. It uses OpenGL assembly shaders, which means it has very wide support across different GPUs.
So why do I bring this up? I'm planning on revising the Abyss Engine and bringing it into a form that can be open-sourced. I will post that also on my Github page once it's done. My plan is to give it as part of a clean SDK much like Trinity, but that'll also require some work.

• Reckoning Engine

The third and final revision of the engine is known as the "Reckoning Engine", which is what it became before I moved over to my custom engine, Pathos. Now the Reckoning Engine is a very different beast and it also breaks compatibility with some HL features, like switchable/animated lights, but instead it supports those features for dynamic lights. This revision of the engine is completely shader-based also, and uses GLSL. The list of features is way too long to discuss here, but things like a rudimentary facial animation system, variance shadow mapping, support for Paranoia's bump map data in the BSP, specular light reflections, etc are there. I plan on eventually open-sourcing this engine version as well. Opensourcing this version would be a rather difficult piece of work, but it's doable.

• Raven City

I have been thinking of releasing the corpse- er, I mean, the most playable version of Raven City for those who might want to see this mod. Time here is a major factor, of which I don't have much when it comes to fixing some broken things to make it work. It also doesn't help that the mod is in some ways an absolute cringe-fest and I want to just remove some... really embarrassingly cringey crap from it. Another issue is that it requires a very specific version of Cg to work properly, which I need to dig up from somewhere.

• Half-Life : Retail

I think it goes without saying that with the HL25 update, this is effectively cancelled, but I will probably upload the source code at least on Github, but I won't create a final release.

It's been a while!

I wanna write down what I've been up to for the past 6 years, since I was always active, just in different communities, but a separate journal would be necessary as it's a long story. Right now, I want to share what I learned during my development of my first Half Life 2 Deathmatch map, including creating custom VBSPs, color correction, and general discoveries I encountered.

When I first got the idea to make an HL2dm map, I was probably watching old nostalgic 3kliksphillip video and stumbled upon his tutorial on moving water through func_water_analog. I immediately brainstormed ideas and wandered if the functionality even worked in Half life 2 Deathmatch. So far, I played around 100 hours of HL2dm, which isn't a lot compared to my TF2 playtime which is like a 1660% increase, but enough that I realised there's not many maps in HL2dm that utilize func_water_analog, at least one's that aren't killboxes or Undertow from HLDM. So I quickly created a map in hammer just to test this proof of concept, and it works like a charm! The entity isn't the most stable as it is with other source games, but it serves its purpose and the lag compensation helped make it bearable enough for even 100 ping tests. I only hope that the next Mapbase update for Source SDK 2013 MP will fix and give additional parameters for func_water_analog and other entities for HL2dm. Now, it was time for me to conceptualise the gimmick and how to make it fun. After trying to test out and create water textures that would work with func_water_analog, I quickly realised that swimming in HL2dm wasn't fun at all and it was too difficult to create good looking water for the entity due to its limitations. Instead, I went for the toxic slime approach as it gave me a few desirable gameplay approaches:

• It becomes a hazard that players will have to go around or use physics props to get across, creating an interesting dynamic that allows players to do quick manoeuvring to gain an advantage against their foes.

• It creates a risk reward style of gameplay with boats located in the canal, where some items and weapons are laid for players to try and snatch.

• It creates a more balanced secret path that requires the toxic slime to be drained in order to access and retrieve the RPG, making players more intrigued and vigilant in their task for the most powerful weapon.

It was through this thought process that I knew I wanted to continue working on this map. I always wanted to make a form of HL2 or HL2dm map but never had any concrete ideas, at least to continue and finish the work. But now, I wanted to make a map based on this idea, and I went and looked for references on canals. The Panama Canal was an obvious choice that I chose its namesake. Now that I got a reference in mind, I went ahead and quickly developed a layout. I went through my HL2 buildings prefabs and picked out some that I believed would be appropriate for the theme. It had to make sense taking place in a jungle like area with developed enough infrastructure to support one of the largest trading networks in the world. That said, the 7 Hour War also destroyed much of the world, so a little dereliction with HL2 assets would be good. Throughout plopping down these buildings, I eventually got the idea to also add Team Deathmatch support to this map and have it work as a Rebel Vs Combine map. And so, the early layout started looking like this: Whether this was my subconscious guiding or a stroke of luck, you'll notice that the Rebel side has more warm orange shades, while the Combine side has much more cold blue shades. I noticed this early on in development and decided to play to its advantage, helping players realize what side of the map they're on. I also wanted to take full advantage of Counter Strike Source and TopHaTTWaffle's texture pack for the source engine, as both had warm colorful textures and useful models that helped sell the theming of a Central American vibe. With these assets, I had a clear path on recreating the buildings from the reference image as well as from my own ideas.

Early on during my texture work, I chose a bright blue skybox texture from TopHaTTWaffle's pack, which looked great on its own, however in-game it looked weirdly dull and flat. I tried saturating and editing the texture manually to get the colors to pop, but I realised that the dullness was likely due to how other textures around affected the look of the skybox. I found a better solution, I experimented with color_correction and found that it not only made the skybox better, but it helped with the Panama vibe by making all the colors vibrant and fitting the tropical environment. For anyone who want to experiment with color correction in their map, keep in mind that there is a bug in the source engine that sometimes doubles the intensity of color correction in the map. The best way to fix this is to get a neutral .raw file and apply that to your existing file at half opacity in photoshop. Full tutorial on the fix and other color correction tips in Source Engine can be found here.

Continued in Part 2...

...Continued from Part 1

Continuing on improving the layout, my previous maps had me first start from the middle and keep adding on the sides until the layout felt big enough. I never knew how big the cliffside should be beyond the derelict house, but it helped knowing how many people will likely be in the area, and base the size on that figure. For me, I always found 1 player every 256 units is a good reference on the scalability of any area, even in other games like Counter Strike and Team Fortress 2. Areas that were 128 units wide were usually designated as "cramped" areas, and 512 unit areas were open large areas. It's important to diversify these areas to make any map interesting and encourage map knowledge as a skill. One gameplay theory I had nostalgia for (despite the rage it always caused) was sniper spots. Basically places where players had beneficial sightlines and an effective long range weapon, giving the one player an easy time to gain frags while the rest noticed and focused on taking them down. It created a common enemy for the server, like a temporary mini-boss, and made taking him down a satisfying reward, even though he was no different from any other player. I knew that these spots were very finicky and that it was easy to abuse these spots if not balanced well, reducing the overall fun factor for every player. I believed that there were three main factors that balanced sniper spots:

• The size of the sightline and line of sight (how far and how much the sniper player can see)

• The ease of getting to the sniper spot (how quick can players enter the spot and utilize it)

• The counterattack (can players counterattack? If so, how easy?)

As long as these three factors are reasonably attended in the map, this sniper spot would benefit the gameplay space in deathmatch. And with this in mind, I made the tower that would hold the sniper. This Spanish style architectural tower situated outside of the normal gameplay space includes pillars, an L shaped layout, and a one-way teleporter that comes from the rebel base. There are no weapons in the tower and the teleporter is only active 30 seconds after use (during which its deadly to touch). If you want to utilize this tower to your fullest extent, you would've need to find either a crossbow and/or a revolver, and be lucky that you don't have to wait for the teleporter. Not to mention both the pillars and the buildings are an obstacle for snipers, giving players on the ground more leeway and have enough power from the weapons they find to shoot down the sniper in the tower, especially with grenades or an RPG that has a large area of effect to easily take down anyone in the tower. These mechanics, I believe, create a balanced sniper spot that takes effort to be in a powerful position that has enough counterplay that makes fighting the sniper a fun experience.

I also wanted to give the Combine side an interesting mechanic, since it feels like the rebels have a pretty significant advantage with their sniper tower. I didn't get anything concrete in my mind until I remembered about these combine dispensers in Half Life 2, particularly the one in the beginning of City 17 and in the Canals with the checkpoint station that had manhacks fly out. I don't think I was able to have friendly manhacks for the combine team (maybe with vscripting?), but I did figure that it might be possible to have a dispenser of items including health kits and ammo that would be an interesting lottery system. I tried many different methods, many of which kept breaking in spectacular ways. The trigger_teleport method didn't work as it didn't recognise the items to teleport, and when I tried to spawn them individually in each dispenser, it caused a memory leak and I felt like it would require an unnecessarily complex I/O system that would contribute to memory leaks for low-bandwith servers. I almost gave up on this until I was curious how the actual dispensers in the HL2 Trainstation worked, as I initially assumed that it was only animations and would be too limited for me to work with. I was wrong, as it turns out, there's a very useful system in HL2 called Attachments that essentially attach any object to a certain part of a prop. In this instance, it's how the ration package is dispensed for citizens to take, and I am able to attach point_templates to it, essentially spawning anything I want. And so in the above image, I made it so that when you pressed the button, you would get a random chance of an item to spawn and deliver to you. The dispenser itself doesn't have many collisions, so a func_door pushing out and rolling the items was added. I was limited to items that were small enough to fit the dispenser and for balance reasons, so no weapons (except grenades), mainly ammo and energy packs. There's also a delay that runs between half a minute to a minute and a half, mainly to make sure it doesn't get abused by those who want to spawn in intervals and not let other players play the item lottery. And so, both the Rebels and Combine have interesting gimmicks that give players some interesting opportunities.

At this point, I was almost complete with the map, I got a good feel for the gameplay, the layout was complete, I was artpassing everything, including creating custom models for the railings to make them look smoother and shinier! The only other thing left to do was the 3D skybox; I got the mountains and the rest of the lake added seamlessly, but I had an issue in making it feel like a believable distant scenery. In particular, I needed to place trees around, but there weren't many suitable props and I felt like these were going to be way too expensive compared to the prop skycards that TF2 uses for their maps. I was going to make my own custom skycard, until I realized there could be a potentially better solution.

VBSPs are used to create prop_details for blend textures on displacements, to create the illusion of grass using sprites randomly placed along the ground. I immediately thought, why can't I just use the same method for planting trees and foliage in a 3D skybox? And that's exactly what I set out for. I was a little intimidated by the process initially, but with some help, it was just as easy as editing a vmt file. I picked out a bunch of trees that I imagine would be in the Panama jungle, while also being individual so that there's no cut off and repetition. I cropped them, placed them in a vtf, wrote the necessary scripts in the vbsp file, and voila! It works like a charm. The best part is that I had full range of options that I can easily configure in the script, including the density of the sprites, their size, the option to face the player, etc. I also used the opportunity to add grass sprites to blend textures that didn't have any prop_detail associated.

And from here it was time to polish up my map with optimizations and clipping. I initially wanted to forego the clipping as many hl2dm maps didn't have clipping, but I don't think authenticity here triumphs over jankiness. I added areaportals, hints, clipping to stairs and out of bound areas. I also added some easter eggs and hidden tricks that you can find if you check paths that nobody would take (including one that you would assume is out of bounds ;). I added cubemaps, packed the map, repacked it for smaller size, and uploaded it. This felt like a huge accomplishment to me, as I was in a moment of my life that was truly lost and had no idea what to do, so finishing this project and giving it out to the public made me feel better. dm_panama

The last thing I discovered after uploading my map and playing it with the community is how close knit it was, despite the lack of official content after almost 20 years. This is really a tight-knit community and many appreciated that I made an HL2dm map in 2023. I played in some full servers, got some good feedback that I should implement the next time I update the map, and many really liked it. I hope this encourages people here to also make hl2dm maps because it was worth it for me, even if I'm not the biggest fan of the game itself.

And that's my dm_panama experience! I'll want to write another journal later about my experiences in the sourcemod community, but for now I hope you all enjoyed this reading and learned something from it.

🦭

"It's important to comfort the children, but it's also important to challenge them too."

So when I get into a standard and get my projects on television, I will challenge the children with my cartoons! That's a part of my big dream here.

Well, it turned out that my aviation dream was a big detour in my career.

My reflexes and hand-eye coordination aren't what they used to be, and I hit an obstacle when I tried landing the plane (Cirrus SR20). I never damaged the plane in any way, but my landings were inconsistent--sometimes ballooning, sometimes landing too hard, and sometimes veering off the midline. My instructor could not clear me to fly solo. In addition, my vision was deteriorating after my retinal surgery in 2019. I had to make the tough decision to stop flying and return to medicine.

Now I am about to start working full-time at a new medical practice, and embark on a new but familiar adventure.

I wanted to upload a screenshot but now I'm confused as to how to do so...

What do you guys think? Is it cool looking or horrible looking? I say the latter one.

A month has passed since I migrated. It only took two weeks for Malta to feel like home. It is even more beautiful than I remember. And so warm. I cannot believe I wasted one third of thirty years being cold and depressed in Sweden.

I started a new job. Colleagues are nice. They like to go out for drinks... maybe a bit too often. I should be careful.

I found a friend to go hiking with and I reunited with some nice people I met when I visited last winter. And I found someone to celebrate Christmas with.

I brought only one game with me, a chessboard, and I have already enjoyed some great games. Still... I think I will build a PC soon I miss the people I love that I left behind. I promised I will always come back to see them during summers, but I might go and see a couple of them before that. Still. Life feels good right now.

Just wanna share some goodies I put into uBlock Origin (uBO). This is partly an exercise to explore uBO's CSS capabilities which I recently learned is a thing, so you can just use uBO for simple CSS injections without requiring a user style extension.

! exclamation mark at start of line marks a line comment
! similarly you can comment out entries below by prefixing with !

! 26/12/2023 https://twhl.info

! these 2 lines remove the background for a better Dark Reader result
||twhl.info/images/body-background.png$image
twhl.info##body:style(background-image:none !important)

! this makes textareas use monospaced font
! trust me, you're going to need this!
twhl.info##textarea:style(font-family:monospace !important)

! this compresses entity guide's attribute value lists into 3 columns
twhl.info##:xpath(//h3[contains(text(),"Attributes")]/following-sibling::h3[1]/preceding-sibling::ul[preceding-sibling::h3[contains(text(),"Attributes")]])>li>ul:style(columns:3)
twhl.info##[id^="Attributes"] + ul > li > ul:style(columns:3)
twhl.info##[id^="Attributes"] + .card + ul > li > ul:style(columns:3)

! this compresses Render FX list into 6 columns
twhl.info##[id^="Attributes"] + ul > li:has-text(/^Render FX/) > ul:style(columns:6 !important)
twhl.info##[id^="Attributes"] + .card + ul > li:has-text(/^Render FX/) > ul:style(columns:6 !important)

! this hides the bloated TFC entity guide panels below most entity guide pages
twhl.info##[id^="Team_Fortress_Classic_only"]:upward(1):style(display:none !important)

! 2024-05-23 resize game icons in articles down from 32px
twhl.info##.inline img[src^="https://twhl.info/images/games/"]:style(width:20px)

! 2024-06-22 make overflowing card scrollable
twhl.info##.card:style(overflow:auto)

! 2024-02-14 https://twhl.info
! === wiki edit pages ===
! makes edit page fullwidth
twhl.info##form[action="https://twhl.info/wiki/edit"]:upward(1):style(max-width:100vw !important)
twhl.info##form[action="https://twhl.info/wiki/create"]:upward(1):style(max-width:100vw !important)
! reset original width for preview
twhl.info##.wikicode-input>:last-child:style(max-width:1140px; margin:auto)
! 2024-05-08 added fira code for code blocks
twhl.info##code, kbd, pre, samp:style(font-family:Fira Code,SFMono-Regular,Menlo,Monaco,Consolas,Liberation Mono,Courier New,monospace !important)
! 2024-06-10 side-by-side editor-preview adjust size of preview card
twhl.info##.full-screen-wikicode-editor .form-group:last-child .card:style(max-height: calc(100vh - 60px))

Here's a preview (Dark mode achieved with Dark Reader extension):

---

EDIT 2024-12-02

• Uses a more robust selection using xpath so that the attribute value list compression works across grouped attributes

Lookin for something to do with free time.

It has been a while since my last journal. I've mostly just been busy with work and being exhausted and had all my project on hold except for my part in this year's Ragemap (a mapping collab for Sven Co-op).

I brought up the fact that func_illusionary will produce cliphulls came up earlier today when helping Sassy Boy with advice on reducing clipnodes, which came as a surprise to some. Understandable, it's always non-solid so why would func_illusionary need cliphulls for in the first place? I thought a journal might be a tidier format for talking about this.

---

So the thing is, the CSG compiler that comes with the HL SDK makes no classname checks, it's pretty much entity-agnostic in this regard. So the compiler generates clipnodes on all HULLs for func_illusionary just as it does for any other brush entity. It doesn't become non-solid until it's spawned in-game and the game code gives it pev->solid = SOLID_NOT.

Big waste of clipnodes if you ask me.
Surely those who've worked on ZHLT and VHLT would have thought about this too and made sure to skip cliphull generation for func_illusionary. I opened up the source code for VHLT v34 and searched for "func_illusionary" and just as I expected I found a conditional checking for that classname and flagging those entities as "noclip" (which will make them skip cliphull generation). Though then I remembered I had this habit of adding zhlt_noclip 1 to func_illusionary in my FGDs, and I was pretty sure that even in VHLT the entity will still have cliphulls generated by default.

What better way to check than testing it?
So I set up a basic room. That's 6 faces with a clipnode each, times the 3 clipping HULLs, for a total of 18 clipnodes for the room itself.
A box is created and tied to func_illusionary. 6 faces on that one as well, so we can expect an additional 18 clipnodes if the generation isn't skipped. Run compile, and... We have 36 clipnodes total, what we expected if func_illusionary's cliphull were generated after all.
Doing another test with zhlt_noclip 1 on the func_illusionary, and without the entity at all, as controls we get the total of 18 clipnodes we expected to see if it was skipped.

So this confirms that func_illusionary does produce clipnodes in both the HL SDK CSG and VHLT v34's CSG.
But why?

Unfortunately I do not have that answer yet, but I'm curious about finding that out and so I started looking into it today.
I tested the conditional in VHLT's CSG where it checks the classname in isolation and it worked, so that can be ruled out.

I'll be sure to update this journal if I find out more, and if anyone reading this happens to know anything about it, please let me know!

---

Update:

Oxofemple brought to my attention that the -clipeconomy must be on to skip generating cliphulls for func_illusionary (and similar entities).
This was strange to me as I was sure it should be on by default, which used to be the case for ZHLT. Solokiller helped me confirm that the flag was changed to be off by default for whatever reason somewhere early in the VHLT branch.

So to sum it up it's not a bug but rather a change in default behaviour from earlier versions.

I Open "Half Life SDK on steam
I create a basic map after following a tutorial.
I have a problem and ask around
I get told to download J.A.C.K
I Get some weird thing called a "Leak"
Here I am

I made this to get my head around the structure of a BSP file and its lumps. Updates:

• 2023-12-20: now has data from all 15 lumps
• 2023-12-22: cleaned up. lump references explicitly marked, and implied to be index into lump struct

So basically, the highest level data is the models lump. Its items have indices into the BSP tree and to the faces that comprise the model. You can safely and completely bypass the BSP traversal by directly retrieving the faces, but that means you're drawing absolutely everything. The world is the first BSP model, and every brush entity is its own BSP model referenced by its index into this lump.

The BSP tree has a lot of academic literature so I'll just skip it.

One unique property BSP leaf is the contents, describing whether the volume is air, water, ladder, etc. The marksurfaces info translates to face entries. There doesn't seem to be an offset of leafs from the Model struct so tracking the sum of all previous models might be required.

A face defines a plane, its edges, texture information, and lighting style. There is only a pointer into the lightmap data; the exact shape and size of the data is inferred from the plane, its closest axial orientation, texinfo vectors, and the styles (non-255 value means there's 1 lightstyle of the calculated size, up to 4 lightmaps)

An entity can have the model reference the internal BSP model of a BSP file with the *N notation. Interestingly it can also reference external BSPs, in which case it'd load only model 0 of that BSP afaik.

---

This is just tentative information as of writing. My end goal is to understand enough to be able to completely translate a BSP file into a 3D scene for rendering. I would update this page as I learn things as I go.

References

• https://hlbsp.sourceforge.net/index.php?content=bspdef
• https://www.gamers.org/dEngine/quake/spec/quake-spec34/qkspec_4.htm#CBSP0

First off, I'd like to say that this is my first journal that I am posting to both TWHL and SoFurry. I'd also like to add the disclaimer that I am not encouraging anybody reading this on TWHL to seek out the SoFurry platform, as that would violate the site's rules. In fact, I'm going to say that if you're not there already, you're not the kind of person who should go there. Anyway, onto the journal.
So I recently started drinking coffee, which is of course much higher caffeine than my previous go-to, Dr. Pepper. Well, last night I drank two coffees and failed to fall asleep at all. It's now five in the afternoon and I'm still not "tired." Which means I see a high likelihood of this becoming a recurring problem...
Why do I keep doing this shit to myself? I'm easily the most self-destructive person I know. I'm going to end up working myself to death, or lazing myself into morbid obesity. I can't find a middle ground in anything. I like to say that I don't think in black and white, but I can't seem to find the gray...

Hey there,

Finally another journal, and it is of the lighter kind this time around. I have finally got the courage to start moving the information about Deleted Scenes towards the TWHL wiki!

This is pretty big for me as generally I don't feel very comfortable writing things up in the proper, professional way. I feel as if I am not good at structuring things. But, I do understand that this needs to happen eventually, even if it is just one wiki entry a week or a tutorial a month on the weird stuff that Deleted Scenes can do.

I started with the special items in Deleted Scenes, like the "Tools" and the brush entity that is required to use them, that being "trigger_usetool". I hope that I can stick with this for a bit and migrate all the knowledge that I have in my head to a more stable and helpful place, which is in the TWHL entity guides section.

Anyway, that was all I wanted to write about.

See ya later!