Glad to have you here, Philip!
Anyway, as I was originally typing...
X and Y scaling should be proportional to the aspect of the base texture. If the base texture is a skinny 16x196 texture then having both X and Y scales be 10 means each tile of the detail texture would be 1.6 by 19.6 pixels relative to the base. If you can't tell, this is horribly, horribly stretched.
Sadly there exists no tool today afaik that can easily plug in the aspect ratio values to you.
I got linked here after going on a nostalgia-binge of Half-Life modding sites and was very surprised to see this article preserved from VERC! I'm the original author and never expected it to be preserved twenty years later
Some of the commenters on the original VERC article were a little... suspicious... of how I managed to decipher the format of the detail texture list file given that the only software using it was the (then un-released) Counter-Strike: Condition Zero. Despite my protestations to the contrary, after twenty years I feel I can come clean: yes, I downloaded a pirate copy of CS:CZ. In my defence I was an idiot 19 year-old who was really excited to figure out a new feature for one of my best-loved games and wanted to document that for everyone to use (and get a bit of recognition myself).
It also wasn't strictly necessary -- the cvars were publicly known, and I had access to a legit copy of IDA Pro; I just didn't want to go to the effort of reversing the client DLL given Valve's import table stripping. I later did that anyway to try and figure out the function pointer table entries that were added post-Steam but not mentioned by Valve. Never documented any of that publicly though; most of them weren't useful for single-player modding which was where my interest lay. All long since lost several hard drive failures ago. The cheater community, I'm sure, figured them all out long before me and I didn't play multiplayer anyway.
I'm glad someone is still keeping the HL modding scene alive though -- it's one of the most thoroughly-documented games/engines I know of, right from the era where a tiny mod team could produce content rivalling commercial releases. My playing around with the HL SDK eventually helped me get a job as a software developer barely a year later! Not the games industry itself (too stressful!), but having the ability to play around with a 'real' piece of software's code was a massive boost for me. It helped me grow from knowing I could make a computer do whatever I wanted to knowing how to tell it to do that, and it did it in a context I knew and enjoyed.
Commented 1 week ago2024-06-07 08:18:56 UTC
in vault item: fy_lockedoutComment #106196
Eww... Halo. XP
I'm pretty sure there's Half-Life haters as well. Humans are in nature quite hateful after all.
For the map. I don't have Source anymore but it looks might fine from the screenshot. Old isn't too bad cause of the majority of crap people does in today's age.
Commented 2 weeks ago2024-06-01 15:00:45 UTC
in vault item: cross_stalk_tributeComment #106193
`Please provide feedback here if something needs to be fixed.
Also, if you're running a server, please add it to a map rotation. This actually 'saves' Stalkyard, as no one is playing it now - and running to a Bunker is always fun`
Ah yes, stalkyard needs more appreciation, good to see there's people who still love to play this map, same goes for boot_camp
Commented 2 weeks ago2024-05-31 21:47:25 UTC
in wiki page: env_shakeComment #106190
env_shake doesn't work for players who are not on ground at the moment env_shake is fired, at least in counter strike
even trigger_relay with trigger state on doesnt seem to bypass this, and neither does globalshake flag for env_shake
note that delay before trigger attribute can alter timing of firing
Commented 3 weeks ago2024-05-23 20:44:32 UTC
in journal: Level BoundariesComment #106185
I was always impressed with the L4D games and their approach to this. Not always flawless, but the player was guided really intuitively through level design
Thanks for the feedback! I also think that empty fields would look better, but at this stage the code become so messy that I afraid to touch even such a small thing. The whole code even depends on this entity list table.
Whoa this is super cool. Ill test it out at some point. Suggestion just from looking at the screenshot: instead of saying "NO" on fields that have nothing, can it just be left blank? or maybe "n/a"? because i could see it being kind of confusing for boolean fields where they're actually a yes/no or true/false
Commented 1 month ago2024-05-16 17:25:22 UTC
in vault item: sewagex3Comment #106179
Really stinkin beautiful with the brushwork detail! It might hinder playability but ya can't deny it's a very cool place to gawk at things. Especially that gantry crane, gyatt damn!
Commented 1 month ago2024-05-03 16:45:33 UTC
in journal: Code of interestComment #106172
All that's gonna do is crash once you have a big enough array. All those function calls are gonna add up and eat the stack.
Best to use a for loop in this scenario.
Commented 1 month ago2024-05-01 05:21:10 UTC
in wiki page: func_conveyorComment #106169
The scroll speed of scroll* textures for the entities are encoded in a hacky way by hijacking FX Color (rendercolor) and you can control the speed of scroll* textures in any brush entity, and even change them with env_render (I tested, it works! 😁)
An algorithm you can use is:
R - 0 if positive, 1 if negative
G - abs(speed) // 16 (floor division)
B - floor( abs(speed) * 16 ) % 256 (modulo or remainder)
DO NOT USE trigger_auto on the second map. trigger_auto fires only once. DO USE instead "change target" in trigger_changelevel of the first map to fire eleend_mm on the second level. This makes it repeatable and reliable.
If the elevator is to be used both ways, the reverse setup is also needed.
If you want to study how Valve does it, use newbspguy and open any Half-Life map with elevator changelevels.
Commented 1 month ago2024-04-27 03:04:34 UTC
in vault item: Riverpool 2Comment #106162
It seems really nice, although I'll hold off on rating since I also haven't played it.
I did notice a minor issue in that the render mode for the forcefield around the rpg seems to be set to texture rather than additive
Yes, the trees and everything is all for goldsource. I tried to keep the trees at a polycount that isn't terribly high so you can use a lot of them in a map or scene. They were all built with optimization in mind and the philosophy of "what if these were made in 1998." I hope you enjoy them.
It's almost like starting over, meeting new patients and working with new nurses and colleagues.
I need to upgrade my computer before it can play the latest Microsoft Flight Simulator.
Anyway, as I was originally typing...
X and Y scaling should be proportional to the aspect of the base texture. If the base texture is a skinny 16x196 texture then having both X and Y scales be 10 means each tile of the detail texture would be 1.6 by 19.6 pixels relative to the base. If you can't tell, this is horribly, horribly stretched.
Sadly there exists no tool today afaik that can easily plug in the aspect ratio values to you.
Some of the commenters on the original VERC article were a little... suspicious... of how I managed to decipher the format of the detail texture list file given that the only software using it was the (then un-released) Counter-Strike: Condition Zero. Despite my protestations to the contrary, after twenty years I feel I can come clean: yes, I downloaded a pirate copy of CS:CZ. In my defence I was an idiot 19 year-old who was really excited to figure out a new feature for one of my best-loved games and wanted to document that for everyone to use (and get a bit of recognition myself).
It also wasn't strictly necessary -- the cvars were publicly known, and I had access to a legit copy of IDA Pro; I just didn't want to go to the effort of reversing the client DLL given Valve's import table stripping. I later did that anyway to try and figure out the function pointer table entries that were added post-Steam but not mentioned by Valve. Never documented any of that publicly though; most of them weren't useful for single-player modding which was where my interest lay. All long since lost several hard drive failures ago. The cheater community, I'm sure, figured them all out long before me and I didn't play multiplayer anyway.
I'm glad someone is still keeping the HL modding scene alive though -- it's one of the most thoroughly-documented games/engines I know of, right from the era where a tiny mod team could produce content rivalling commercial releases. My playing around with the HL SDK eventually helped me get a job as a software developer barely a year later! Not the games industry itself (too stressful!), but having the ability to play around with a 'real' piece of software's code was a massive boost for me. It helped me grow from knowing I could make a computer do whatever I wanted to knowing how to tell it to do that, and it did it in a context I knew and enjoyed.
All the best from the UK -- Philip
For the map. I don't have Source anymore but it looks might fine from the screenshot. Old isn't too bad cause of the majority of crap people does in today's age.
Take care of yourself, and hope you get well soon!
Also, if you're running a server, please add it to a map rotation. This actually 'saves' Stalkyard, as no one is playing it now - and running to a Bunker is always fun`
Ah yes, stalkyard needs more appreciation, good to see there's people who still love to play this map, same goes for boot_camp
even trigger_relay with trigger state on doesnt seem to bypass this, and neither does globalshake flag for env_shake
note that delay before trigger attribute can alter timing of firing
As for the map, delicious clean architecture and texturing in the Rimrookian style we're used to
very good job
the flowchart just demonstrates how confusing it really apparently is
Best to use a for loop in this scenario.
scroll*
textures for the entities are encoded in a hacky way by hijacking FX Color (rendercolor) and you can control the speed ofscroll*
textures in any brush entity, and even change them with env_render (I tested, it works! 😁)An algorithm you can use is:
0
if positive,1
if negativeabs(speed) // 16
(floor division)floor( abs(speed) * 16 ) % 256
(modulo or remainder)Also, has anyone found any secrets yet?
DO USE instead "change target" in trigger_changelevel of the first map to fire eleend_mm on the second level. This makes it repeatable and reliable.
If the elevator is to be used both ways, the reverse setup is also needed.
If you want to study how Valve does it, use newbspguy and open any Half-Life map with elevator changelevels.
I did notice a minor issue in that the render mode for the forcefield around the rpg seems to be set to texture rather than additive
thanks