Journals

while playing half life i quicksaved while a barney was saying "Got another one!"
there was a brief freeze while i was saving, after the "Go" and it resumed at "ne!"
this resulted in barney cheerfully stating "Gu n! :D"
funny
the end

My single player Op4 campaign (tentatively titled "Op4: Wrench/Barnacle/Snipe") emphasizes use of just the wrench for most of it, then the grapple, and finally the sniper rifle.

Do people generally hate that? The problem I face is that, for people who love the wrench (like me), it's extremely easy to clear rooms of monsters. For people who hate melee, it will be super difficult.

Hi, hope you all are well!

For me I've just been very busy at work and stuff, and most days been too tired to work on any personal projects. Most of these days have just been working, cooking, and trying to sleep. 😅

But had a few days where I managed to force myself to argue with geometric planes and fix up silly mistakes and eventually got the MAP parser and converter finished up and released a new beta version of Map2Prop (and with that also opening the repo to the public).
With that I feel like it's getting near to a state where I can confidently elevate it out of the beta and up to a proper full release. With that comes of course the question of what remains for that.

---

In the development branch I've already added a config option and CLI argument for auto exiting on finish (instead of waiting for input). I decided to keep the wait-for-input on finish as the default behaviour to give non-CLI-savvy users the opportunity to see the success message or alternatively any possible error/warning messages before the window closes. This option should make it easier to use the application in batch scripts and such, which will later on open up for including it in map compile processes.

Next up is making use of tool textures to accomplish certain tasks. So far I've got this list:

• ORIGIN: Set a custom origin point for the model instead of using world origin (removed from mesh)
• BOUNDINGBOX: Set the parameters for the $bbox QC command (removed from mesh)
• CLIP: Set the parameters for the $cbox QC command (removed from mesh)
• CONTENTWATER: Mirror all faces of the model
• BEVEL: Smooth all vertices within this volume (removed from mesh)
• CLIPBEVEL: Do not smooth the vertices within this volume (removed from mesh)

Lastly I want to create a FGD with a custom brush entity class that will be read by Map2Prop. The idea is to include Map2Prop in the compile process and when fed a MAP file it will read these custom entities, convert their brushes to models, and change these entities to item_generic/cycler_sprite/etc (classname will be specified using a keyvalue) already filled out to use the newly converted model.
The entity class will include keyvalues to configure many of the options already exposed in config/CLI but on a per-entity basis (this will of course also be available outside of the compile process context).

I haven't decided yet whether any of these features will have their own release, or if I'll save all of them for v1.

---

I want to thank you all for the love you've shown my silly little project already. I'm looking forward to seeing all the maps you guys are making using it and I hope it continues to be helpful 😁

2️⃣3️⃣

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 hope it will be the first of many together.

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##[id^="Attributes"] + ul 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)

! 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)

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

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.