DevBlog - That old HL mod of mine - Admer456

From now on, I might call the blog "AdmSrc" instead of "That old HL mod of mine".

Some of you might remember a mod that used to be called "Admer: The Game", and was then renamed to "An unknown game". I do for sure. It was a failure but also a success.

In 2015, I started working on my first (and only) HL mod. I had a couple of ideas that I wanted to realise, but I failed. I canceled the mod in 2016 because:

• I was an awful noob at programming.
  It was a time when I had just gotten into C++. My only prior programming experience back then was QBasic. And even then it wasn't much. I didn't know about data types, functions, anything. Just basic input, if statements, goto etc. Barely enough to make a primitive text game.
  All my code for the mod was never really "mine", since I just copy-pasted it from tutorials. And I never learnt anything.
• I was losing motivation to work on the mod. As my mapping skills grew, I realised how terrible my mod's maps were and I was too lazy to fix and redo everything from scratch. The same goes for other skills.
• I was lazy. All my ideas were in my head, I was too lazy to write them down and I had no mod design document, no organisation, no anything. I simply didn't know where I was going and what to do, so I half-baked everything. (ahem, quarter-baked)

Recently, I happened to see the mod's page here. I remembered the old stats, suddenly. It used to have 10s, sometimes 100s viewers a day, and now it varies between 0 and 1. So I thought "How great it'd be to do this again, except with the skills I have now?"

Last year, I was analysing some progress of my skills. Since 2015, I've improved in mapping a lot, in texturing a lot, video editing significantly (I mean, not much to be improved since I've been video-editing since the age of 8), sound editing a lot, music production so-so, but there was just that one skill that stagnated.

It was programming. In late 2017, I started panicking due to the fact that I knew I'd have programming class next year. So I wanted to prepare myself.

I just needed a good start. Something to jumpstart my learning. And in November 2017, a guy came into our classroom, recording a promo video for the high school. We were having IT class, and our professor told us to open Dev-C++ and pretend to be typing something. They all pretended. Except me.
I opened up a source file, saw how it's written, memorised the syntax and commands within a minute, and wrote a program. When I returned home, I got VS 2010 Express, registered it and decided to make GMan killable.

It was an unbelievable experience for me back then. I actually understood something for once. And all he was doing was setting his health to 50% of his max health every time he was attacked:

pev->health = m_iMaxHealth / 2;

Now that was just the beginning. I called my little brother in and showed him that, and he was so amazed. He laughed in disbelief, because all the time he knew about HL (since the age of 2 or 3), he knew that you just can't kill GMan.

However, it's been a long while since 2017. In late 2018, however, I got into C++ again. I got my new PC in July, and that meant I could finally get my hands on Visual Studio 2017, a nice step up from Visual Studio 6.0, 2005 Express, 2009 Express and 2010 Express. My 2007 laptop simply didn't have enough space for 2012, 2015 nor 2017.

And that meant a new beginning, a new age. I was looking for some libraries that can enable me drawing stuff to a window, and boy I found one: SDL. I learnt quite some C++ for those few months, and coming back to the Half-Life SDK once again, I finally understood most of the stuff in it. It felt amazing to finally understand something that troubled you for a few years. That age was an age of learning something I've always wanted to learn.

I had prototyped a function in AngelScript for Sven Co-op (was my first time tinkering with AS scripting), and then I decided to port it to the HL SDK.

Now, what now? Well, I'm working on a small mod base that I'll eventually release. Once the code base is done and the example assets, I can move on to the revival of my old mod. It'll be a big one. :)
What I've done so far is this:

• proper semi-auto for the Glock, and an intentional secondary fire mode that refills your ammo (also planning to do tactical reload for all weapons with ammo and mags)
• env_viewsway - the port of my prototyped AS function, as an entity
• trigger_valueop - an entity that changes keyvalues of another entity; it took quite some time to make, lol.
  This entity is so powerful. You can change ANY keyvalue of an entity with it, health, position, animation, animation frame, class name (why'd anyone change that?), anything. I had to modify the base entity class a bit to make this come true.
• trigger_difficulty - I always wondered why HL didn't have this, a trigger that triggers something only if a certain difficulty is set
• util_rotator - an entity that rotates another entity, can rotate around one or two points (think of it as Moon rotates around Earth, and Earth rotates around the Sun); might change it to a trigger_ instead of utility
• util_consoleprinter - a very useful entity for debugging your entity setups
• shaking can now affect players in the air, but env_shake has options for either mode
• crowbar shakes the player's view when you hit something
• a flashy customisable HUD with so many parameters: frequency of flashing, health level at which the health bar goes red, HUD colour (obviously), curve of TDTR (The Deader The Redder - basically how red the HUD is depending on the health level), wave of flashing (can be a sine wave, saw wave, triangle wave, yet to implement the square wave but that'll be very easy), way of flashing (red to fully transparent, constant red, red to your predefined colour), and so on.
• test effect using the EFX API (imploding bullet tracers for now)
• changes to the base entity that allow for this: GetKeyValue and SetKeyValue
  Essentially, the base entity provides a GetKV and SetKV for all the base keyvalues defined in the pev structure. Other base classes (e.g. CBaseDelay) will implement a GetKV2 and SetKV2, which is for their own respected keyvalues that aren't present in the base entity class. And lastly, entities that inherit from these will have GetKV3 and SetKV3 for their own keyvalues. KV is called first, checking for a keyvalue name. If it fails, it calls KV2 with the same argument. If that fails too, then it calls KV3 and sets it. If even that fails, well, GetKV3 will return "null", and SetKV3 will print an error in the console saying there's no such keyvalue.

In the next DevBlog, I'll post some screenshots and perhaps a video of some things in action. :)