[HLBSP] feature parity with original GoldSrc compilers
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:
- [x] ~~
_lightKV (the way most non-texlights work: color255 + intensity)~~ Should be solved with #465 - [ ]
light_environmentandlight_spotentities. The former is required for proper outdoor lighting on MDLs; it falls back to Q1-style lighting when absent. I would say to roll the latter into regular light entity support, but that would probably break lights that also display models. - [ ]
-notexby default for HLBSP, keeping option to embed if user desires (wasteful to embed halflife.wad when users always have it) - [x] ~~
!prefix usable wherever*or#is.~~ Added in #469. - [x] ~~If a randomly tiling texture (
-0to-9prefixes) is to be embedded, also embed all related textures (like is done for toggled and animated textures)~~ handled - [ ]
@-prefixed textures andTRANSLUCENTtool 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_dwnare flowing water, using CONTENTS_CURRENT_* (-9 to -14). These are never used, so I thought they were ZHLT additions at first. NetQuake and Hexen II automatically convert these to Water at runtime; QuakeWorld considers them invalid.
Some nonessential related rambling:
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
AAAas trigger textures. The base game only hasAAATRIGGER, 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 usesrenderamt(unsigned byte), and only whenrendermodeis set to 1, 2, 3, or 5. It'd be a good idea to internally convert renderamt to a normalized float so that it could be treated likealphaand_light_alphacurrently are. - It might make sense to not 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. That said, the original HL1 compilers lightmapped water by default….
- NULL in VHLT infers its contents type from visible brushes, and only is CONTENTS_SOLID if the brush has no other texture; this means it can be mixed with sky and liquid textures without the need for a special variant.
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
lightidentically. This can cause some undesired behavior if the map contains certain ZHLT+ entities likelight_shadow,light_bounce, orlight_surface. - QCSG uses the command
-nowadtexturesto 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 includeso that any wad which has "include" in the filename or path is embedded. HLCSG also always treats-wadinclude zhlt.wadas 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. #442 partially covers this, but it requires putting the KV on every single bmodel.
- 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 ifrendermodeis greater than 0. If used on a world brush or with rendermode 0, then the transparent texels are just rendered as opaque black.
Some shower thoughts directly related to the OP:
- While the currents and translucent contents should be disabled by default outside of
-hlbspmode, it may make sense to have an arg called-allow_hl1_contentsor something, since FTE will treat them as valid. - I wonder if the currents can reuse the internal EWT contents flags that are used in Quake II mode (they are from Quake II to begin with). Translucent probably shouldn't use the internal flag used by func_illusionary_visblocker.
-
light_spotprobably shouldn't be rolled into the regular light entity, since then theanglesKV would then interfere with lights that use models in Quake I and II. It'd be better to handle things how vmap does, and check classname.
Starting a branch to add CONTENTS_CURRENT_* support: https://github.com/ericwa/ericw-tools/compare/hl-currents?expand=1
It should be pretty easy. I'm using the same internal EWT flags as Q2 currents.
Oh, oops, it's !cur_dwn, not !cur_down; didn't realize I mistyped in OP until reading your commit. My mistake.