ZHLT/VHLT support would be too messy, but compatibility with maps that are designed for the original 1998 compilers would be feasible, just like how EWT fully supports compiling maps that are designed for stock Q1, Q2, and HX2 compilers.
Things that the original (non-ZHLT) HLBSP compilers do/have which EWT currently does not:
[ ] _light KV (the way most non-texlights work: color255 + intensity)
[ ] light_environment and light_spot entities. The former is required for proper outdoor lighting; it falls back to Q1-style lighting when absent. The latter's KVs can probably be rolled into regular light entity support.
[ ] -notex by default for HLBSP, keeping option to embed if user desires (wasteful to embed halflife.wad when users always have it)
[ ] ! prefix usable wherever * or # is (I'm pretty sure this is implemented for regular liquids, but testing needs to be done for the special tool textures like *skip and *waterskip)
[ ] If a randomly tiling texture (-0 to -9 prefixes) is to be embedded, also embed all related textures (like is done for toggled and animated textures)
[ ] @-prefixed textures and TRANSLUCENT tool texture (similar to but not the same as func_illusionary_visblocker; this one is kinda niche). This uses CONTENTS_TRANSLUCENT, which is -15, and is basically another liquid.
[ ] Textures with a prefix of!cur_0, !cur_90, !cur_180, !cur_270, !cur_up, or !cur_down are flowing water, using CONTENTSCURRENT* (-9 to -14). These are never used, so I thought they were ZHLT additions at first. Quake 1 automatically converts these to Water at runtime.
[ ] Automatically load a RAD file with the same name and path as the MAP.
Quirks about GoldSrc mapping that aren't handled in any special way the original HLBSP compilers, but are directly related to things that are handled in special ways in EWT (neither are complicated):
* Treat any textures starting with `AAA` as trigger textures. The base game only has `AAATRIGGER`, but gearbox.wad and hlbasics.wad have additional variants to help distinguish different types of triggers, using this prefix.
* Compared to Quake source ports' usage of `alpha` (normalized float) for translucency, GoldSrc uses `renderamt` (unsigned byte), and only when `rendermode` is set to 1, 2, 3, or 5. It'd be a good idea to convert renderamt to a normalized float so that it could be treated like `alpha` and `_light_alpha` currently are.
* Don't splitturb by default, as lightmapped water isn't supported by non-Xash versions of GoldSrc. Wpoly makes a bigger impact in GoldSrc compared to Q1/Q2 source ports due to its ancient renderer, so unnecessary cuts and subdivision should be avoided.
Slightly rambling anecdotes not essential for vanilla compatibility:
* VHLT automatically retextures AAATRIGGER with NULL; this is very useful, but not essential. Ideally any trigger texture would be retextured.
* Half-Life's compilers and forks only treat specific entities as lighting entities, unlike how Quake's treat any entity that starts with `light` identically. This can cause some undesired behavior if the map contains certain ZHLT+ entities like `light_shadow`, `light_bounce`, or `light_surface`.
* QCSG uses the command `-nowadtextures` to revert to the Q1 method of embedding all textures in the BSP. HLCSG adds the option `-wadinclude`, which takes a wildcard as a parameter; I personally use `-wadinclude include` so that any wad which has "include" in the filename or path is embedded. HLCSG also always treats `-wadinclude zhlt.wad` as being present, since that's where the tool textures are.
* ZHLT+ treats SKIP as nonsolid nodraw when used on non-hint brushes.
* ZHLT adds an unusual shortcut wherein using CLIP as a nodraw texture results in giving the brush collision for all clipping hulls except 0. This probably confuses EWT.
* ZHLT+ (or at least VHLT; it's not mentioned in changelog) has a nohull2 parameter, which is useful for conserving clipnodes on maps that don't use hull 2, such as those for Counter-Strike or Day of Defeat. It also has some tool textures for creating clip brushes that only affect one hull.
* Xash-fwgs and probably FTE can take advantage of BSP2 with HLBSP hull sizes. BSP2 with 24-bit BSP30-style lightmaps are also valid, although I don't know what supports it besides newbspguy.
* Alphatest (`{`) textures are only rendered as transparent if `rendermode` is greater than 0. If used on a world brush or with rendermode 0, then the transparent texels are just rendered as opaque black.
ZHLT/VHLT support would be too messy, but compatibility with maps that are designed for the original 1998 compilers would be feasible, just like how EWT fully supports compiling maps that are designed for stock Q1, Q2, and HX2 compilers.
Things that the original (non-ZHLT) HLBSP compilers do/have which EWT currently does not:
_light
KV (the way most non-texlights work: color255 + intensity)light_environment
andlight_spot
entities. The former is required for proper outdoor lighting; it falls back to Q1-style lighting when absent. The latter's KVs can probably be rolled into regular light entity support.-notex
by default for HLBSP, keeping option to embed if user desires (wasteful to embed halflife.wad when users always have it)!
prefix usable wherever*
or#
is (I'm pretty sure this is implemented for regular liquids, but testing needs to be done for the special tool textures like*skip
and*waterskip
)-0
to-9
prefixes) is to be embedded, also embed all related textures (like is done for toggled and animated textures)@
-prefixed textures andTRANSLUCENT
tool texture (similar to but not the same as func_illusionary_visblocker; this one is kinda niche). This uses CONTENTS_TRANSLUCENT, which is-15
, and is basically another liquid.!cur_0
,!cur_90
,!cur_180
,!cur_270
,!cur_up
, or!cur_down
are flowing water, using CONTENTSCURRENT* (-9 to -14). These are never used, so I thought they were ZHLT additions at first. Quake 1 automatically converts these to Water at runtime.