the reason env_sprite doesn't support body and skin is that apparently those values were hijacked by the sprite renderer as part of the system that makes sprites attached to models in one of their attachment points.
Sorry for the slander. This was years ago when I tried to import exported BSPs and back then the UI for importing BSP files was broken. I know it works now. Still glad that the program exists.
Commented 1 month ago2024-10-03 13:08:16 UTC
in wiki page: trigger_counterComment #106436
Between 1.0.0.0 and 1.0.0.9 when the game_* entities were added, this entity is the only entity available for counting. Therefore, it's NOT just a "debug" entity, and I've removed that red notice.
Commented 1 month ago2024-09-26 04:21:10 UTC
in wiki page: func_monsterclipComment #106419
blocking hull0 (point hull) entities like snarks might require a completely separate method: An invisible func_wall with "passable" set to yes (zhlt_noclip = 1) which makes it have no clip for monsters using other hulls but solid to entities using hull0.
Be careful with this. You only have 31 named lights to work with per map.
A more optimized way, that comes free with most entities, is to use entity effects (effects) property.
There's a way to use just a single set of path_corner's by using both a boundingbox brush (center of path) and an origin brush (center of beam targets) for the func_train's. while traveling on the path both trains would align their `boundingbox`-es to the path, but have different origins, so the beams and lasers continue to work.
'But why bother?', you ask? Well, less entities mean less surface area for mistakes.
Commented 2 months ago2024-09-18 01:45:55 UTC
in wiki page: func_tankcontrolsComment #106403
You can maybe have an ambient_generic play a cocking up sound (just like when using the emplaced pulse gun in hl2) by having it have the same name as the tank, so the func_tankcontrols triggers both of them.
I'm shocked to find today that for whatever reason default builds of VHLT removes all falloff code from the executable. No _falloff KV, no -falloff # argument. Codebases that have #ifdefs removed outright removed the code for the feature altogether! Idk how falloff even functions now.
Commented 2 months ago2024-09-11 16:43:56 UTC
in journal: fragMOTIONComment #106387
Yes pls! 😁
I'm scratching my head over how to do IK. I want to freeze a bone in place while moving the root bone in an animation. it doesn't work, the "frozen" bone just moves along with the rest of the skeleton. a tutorial on how to it how i meant it to work would be much much appreciated.
Commented 2 months ago2024-09-10 15:46:26 UTC
in wiki page: SpriteComment #106382
Probably the sprite type/orientation/format explanation from env_sprite can be moved here.
Also it appears that the sprite renderer has an in-built way to render the sprite attached to a studio model's attachment point. This is why making env_sprite render models can only use body and skin 0, because those properties are taken over to store part of the information used to get this to work.
I feel strongly about loading the exported .map file to find leaks, since it's what the compilers actually see when they compile the level. In fact this image from the page might have been just that, so why not just explicitly tell people to do it?
dead bodies of stock models that have death animations, but no dead poses (coincidentally the NPCs using these models don't have monster_*_dead versions)
I think different paradigm is possible: a single func_train elevator cab with built-in doors, and func_wall_toggle cabs that are stationary at each level. doors would be local to each level.
2'8" is too wide? I eyeballed my shoulders and they're exactly 2ft. Add to that a bulky HEV suit and a little bit of personal space and 2'8" isn't too bad. The doors around my house are 3ft wide and would fit him just fine.
And don't forget that info_hullshape exists now. You can squeeze Gordon into as narrow a space as you like. It's just that his buddies (and enemies) can't follow.
The biggest flaw with sticking to 16u = 1ft in Sourceland is that you have rooms that are visibly too large... exactly 33% too large. NPCs interact with door handles and buttons at chest height that in real world (and visually in Sourceland) are at the halfway point i.e. waist height. And props are built with 12HU=1ft as well so they're also 75% of the size relative to the geometry of the room they're in.
Commented 2 months ago2024-09-03 14:46:18 UTC
in wiki page: item_airtankComment #106360
considering its cut content status, it has surprisingly more use as it can target other entities on touch as compared to health/hev chargers where such function is most desired.
Commented 2 months ago2024-09-02 18:20:23 UTC
in wiki page: FGDComment #106356
The FGD grammar is technically whitespace-agnostic. You can for example spread the @ThingClass declaration across multiple lines in cases where there's a lot of attrs() with long values, for readability sake. The problem is that third party programs that doesn't use a proper DSL parser and parses directly, makes assumption that it's always on one line. Worse still there's one snapshot of TB that assumes property lines must be indented, and breaks with a custom FGD written with poor indent discipline.
Commented 2 months ago2024-08-30 14:27:21 UTC
in wiki page: lightmapComment #106349
If you're curious about how lightmap sizes are calculated, and the techniques used to light those lightmaps, I highly recommend this excellent video:
In Half-Life/GoldSource/VHLT it's more like Q2's QRAD3. Also discussed is Ericw-tools, which you can use on GoldSrc maps (though support is only in alpha as of writing)
Commented 2 months ago2024-08-22 12:03:29 UTC
in wiki page: func_waterComment #106322
Note for GL mode: the wave grid size is constant at 64x64. If the textures are not 64x64 it'd be stretched to fit.
It's also possible with BSP binary hacking to rename a normal texture used on normal brushwork into water, bypassing the culling done by the compiler, so that any surface it's applied to – walls, ceilings, etc – has the wavy effect, but with waveheight of 0.
Actually, it's not the lightstyle 255 that marks "no light data" but the "special" flag on the face's texinfo. If your map is pitch black all the light styles on all faces will be 255 but they're all still valid faces because BSP already chopped them up so that the lightmap size is reasonable. Faces with "special" flag don't get chopped.
Commented 3 months ago2024-08-15 10:30:54 UTC
in wiki page: func_breakableComment #106298
^ based on my env_render testing render modes other than normal and solid creates glass bullet decals when shot, so in that sense the engine assumes a brush entity in those modes as being made of glass. the grenade code must be using the same logic as well, so that checks out.
I feel like migrating the stuff I added to env_render page here, and redirect from that page, but I'm undecided on how much I should rewrite the original content of this page, and even who the original author to be credited is, because the entire page content will need to be reworked to properly label and address bmodel/studiomodel/sprite differences.
Commented 3 months ago2024-08-07 07:30:02 UTC
in vault item: Vanilla sprite trainComment #106282
To clarify angular velocity for sprites, the XYZ values of avelocity is treated as the angle's PYR to rotate for. Assuming parallel sprite (always facing the camera), the third value of angles (Roll) is used to initially offset the sprite's rotation. So to animate the rotation you use the third value of avelocity (Z).
18 is the effect used by monster_gargantua as it explodes.
19 is the classic doom/quake glowing effect wrapping a model. It takes FX color as the colour of the glow, and FX amount as the offset between the model and the glow aura. Note that in some render modes FX amount is also used to adjust opacity and sadly you can't separate the two when using FX 19 + off-normal mode.
Commented 3 months ago2024-07-26 11:34:21 UTC
in vault item: storagex3Comment #106270
Pros
The hornet trap is novel to me; an uncommon puzzle in Half-Life and mods in general, let alone in multiplayer HLDM. The upstairs area is also very comfy.
And the gantry crane makes another appearance
Cons
The elevator however is clunky in that you need to bump onto the button twice, once to call the elevator and once more to move up. There should've been buttons inside. It does feel like overall you couldn't figure out how to make func_train elevators with doors etc.
There are a lot of ledges with trigger_push on top. this could've been simplified with clip brushes shaped like wedges, tied to func_detail and made to use info_hullshapes that are pointed at the bottom. see the following vault for example:
Commented 4 months ago2024-06-29 07:36:26 UTC
in wiki page: titles.txtComment #106222
Has anyone ever get their non-english titles.txt to work properly?
I tested the Korean version. Its titles.txt comes in UTF16LE encoding, but it looks like the engine fails to parse this encoding, so all env_messages just displays their message names instead of the message's contents. And of course it all uses default values for the $ settings.
set light's custom pattern if needed, and whether it will be initially dark
set an entity to trigger the pair. they will be triggered together because of the shared name.
the effect being that the light emitted by the texlight has the same light style as the paired light entity instead of being static, and thus can be toggled with it.
But now that VHLT has light_surface, just use that instead.
Commented 4 months ago2024-06-22 01:03:25 UTC
in wiki page: VERC: Custom DecalsComment #106208
Curious about how the engine differentiates between monochrome and alphatest decals. I've seen (and used) decals that has full colour with the last index being the transparent colour, just like regular { textures. My working theory is that it checks that palette indices 0-254 are monochromatic (black→white or the reverse). If it's neither then it assumes alphatest mode. I think I've also seen decals.wad in the wild that have the palette indices 0-254 all zeroed out (i.e. black all the way), but I haven't loaded them in game and see how the engine interprets that decal.
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.
Commented 6 months 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!
env_spritedoesn't supportbodyandskinis that apparently those values were hijacked by the sprite renderer as part of the system that makes sprites attached to models in one of their attachment points.p.s. good to have you back.
game_*entities were added, this entity is the only entity available for counting. Therefore, it's NOT just a "debug" entity, and I've removed that red notice.zhlt_noclip=1) which makes it have no clip for monsters using other hulls but solid to entities using hull0.A more optimized way, that comes free with most entities, is to use entity effects (
effects) property.path_corner's by using both aboundingboxbrush (center of path) and anoriginbrush (center of beam targets) for thefunc_train's. while traveling on the path both trains would align their `boundingbox`-es to the path, but have different origins, so the beams and lasers continue to work.'But why bother?', you ask? Well, less entities mean less surface area for mistakes.
- all
- all other
- all
Pickup target results:CBaseDelay::SUB_UseTargetshasdelayandkilltarget. descendants:item_airtankweapon_entitiesCBaseEntity::SUB_UseTargetsdoesn't havedelaynorkilltarget. descendants:item_entitiesammo_entitiesCBasePlayerAmmodon't callSUB_UseTargetsso bothtargetandkilltargetare useless.ammo_*= noneitem_*=targetonly, nodelay/killtargetweapon_*anditem_airtank= all oftarget/delay/killtargetpitchinto the pitch component ofangles. World and model lighting should just work._falloffKV, no-falloff #argument. Codebases that have#ifdefsremoved outright removed the code for the feature altogether! Idk how falloff even functions now.Anyway, let's just take small steps forward. As long as we move forward it'd be ok.
I'm scratching my head over how to do IK. I want to freeze a bone in place while moving the root bone in an animation. it doesn't work, the "frozen" bone just moves along with the rest of the skeleton. a tutorial on how to it how i meant it to work would be much much appreciated.
Also it appears that the sprite renderer has an in-built way to render the sprite attached to a studio model's attachment point. This is why making env_sprite render models can only use body and skin 0, because those properties are taken over to store part of the information used to get this to work.
And don't forget that
info_hullshapeexists now. You can squeeze Gordon into as narrow a space as you like. It's just that his buddies (and enemies) can't follow.The biggest flaw with sticking to 16u = 1ft in Sourceland is that you have rooms that are visibly too large... exactly 33% too large. NPCs interact with door handles and buttons at chest height that in real world (and visually in Sourceland) are at the halfway point i.e. waist height. And props are built with 12HU=1ft as well so they're also 75% of the size relative to the geometry of the room they're in.
@ThingClassdeclaration across multiple lines in cases where there's a lot ofattrs()with long values, for readability sake. The problem is that third party programs that doesn't use a proper DSL parser and parses directly, makes assumption that it's always on one line. Worse still there's one snapshot of TB that assumes property lines must be indented, and breaks with a custom FGD written with poor indent discipline.monster_grunt_repel,monster_human_grunt,info_node,func_breakable,multi_manager,trigger_once,env_explosion,monstermaker.monstermakerto spawn hornets, as part of a trap. really cool.It's also possible with BSP binary hacking to rename a normal texture used on normal brushwork into water, bypassing the culling done by the compiler, so that any surface it's applied to – walls, ceilings, etc – has the wavy effect, but with waveheight of 0.
angles(Roll) is used to initially offset the sprite's rotation. So to animate the rotation you use the third value ofavelocity(Z).19 is the classic doom/quake glowing effect wrapping a model. It takes FX color as the colour of the glow, and FX amount as the offset between the model and the glow aura. Note that in some render modes FX amount is also used to adjust opacity and sadly you can't separate the two when using FX 19 + off-normal mode.
Pros
The hornet trap is novel to me; an uncommon puzzle in Half-Life and mods in general, let alone in multiplayer HLDM. The upstairs area is also very comfy.And the gantry crane makes another appearance
Cons
The elevator however is clunky in that you need to bump onto the button twice, once to call the elevator and once more to move up. There should've been buttons inside. It does feel like overall you couldn't figure out how to make func_train elevators with doors etc.There are a lot of ledges with trigger_push on top. this could've been simplified with clip brushes shaped like wedges, tied to func_detail and made to use info_hullshapes that are pointed at the bottom. see the following vault for example:
Finally we have the goldsrc equivalent to source's Propper!
I tested the Korean version. Its titles.txt comes in UTF16LE encoding, but it looks like the engine fails to parse this encoding, so all env_messages just displays their message names instead of the message's contents. And of course it all uses default values for the
$settings.- have a light and func_wall entity pair of the same name
- set
- set
- set an entity to trigger the pair. they will be triggered together because of the shared name.
the effect being that the light emitted by the texlight has the same light style as the paired light entity instead of being static, and thus can be toggled with it.func_wall's style to-3light's custom pattern if needed, and whether it will be initially darkBut now that VHLT has light_surface, just use that instead.
{textures. My working theory is that it checks that palette indices 0-254 are monochromatic (black→white or the reverse). If it's neither then it assumes alphatest mode. I think I've also seen decals.wad in the wild that have the palette indices 0-254 all zeroed out (i.e. black all the way), but I haven't loaded them in game and see how the engine interprets that decal.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.