Comments

• R - 0 if positive, 1 if negative
• G - abs(speed) // 16 (floor division)
• B - floor( abs(speed) * 16 ) % 256 (modulo or remainder)

fgd
@BaseClass = ZHLT
[
    zhlt_lightflags(choices) : "ZHLT Lightflags" : 0 =
    [
        0 : "Default"
        1 : "Embedded Fix"
        2 : "Opaque (blocks light)"
        3 : "Opaque + Embedded fix"
        6 : "Opaque + Concave Fix"
    ]
    light_origin(string) : "Light Origin Target"
    zhlt_hull1(target_destination) : "info_hullshape (standing)"
    zhlt_hull2(target_destination) : "info_hullshape (big monsters)"
    zhlt_hull3(target_destination) : "info_hullshape (crouching)"
    zhlt_usemodel(target_destination) : "ZHLT Template Model Target"
    zhlt_copylight(target_destination) : "ZHLT Copy Lighting From Target"
    zhlt_noclip(choices) : "ZHLT No-clipping" : "" =
    [
        "" : "Default clipping"
        1 : "No clip"
    ]
    zhlt_invisible(choices) : "ZHLT Invisibility" : "" =
    [
        "" : "Default (visible)"
        1 : "Invisible"
    ]
    zhlt_customshadow(string) : "ZHLT custom shadow (Alpha/RGB)" : : "Float value that specifies opacity of this brush entity. 0.0 (opaque) -> 1.0 (no shadow). Enter three values for RGB."
    zhlt_embedlightmap(choices) : "ZHLT embed lightmap" : "" =
    [
        "" : "No"
        1 : "Yes"
    ]
    zhlt_embedlightmapresolution(choices) : "ZHLT embed lightmap resolution" : "" =
    [
        "" : "[UNSET]"
        1  : "1 "
        2  : "2 "
        4  : "4 "
        8  : "8 "
        16 : "16"
        32 : "32"
        64 : "64"
    ]
    skin(choices) : "Contents" : "" =
    [
        ""  : "[UNSET]"
        -1  : "Empty"
        -2  : "Solid"
        -3  : "Water"
        -4  : "Slime"
        -5  : "Lava"
//        -6  : "Sky"
        -15 : "Translucent"
        -16 : "Ladder"
        -17 : "Fly field"
        -18 : "Gravity fly field"
        -19 : "Fog"
    ]
]

• Door hack flag makes the entity un-use-able but solid (default is useable but not solid)
• Not useable flag has no effect [not implemented?]
• [bug] the entity only works well with positive distance (clockwise opening). Negative distance makes the internal value "start open". The linked momentary_door will always be opening when the momentary_rot_button moves clockwise and vice versa.
  • solution: have all linked momentary_rot_buttons have positive distance, and rotate the entity's yaw 180 degrees to make it spin counterclockwise (and now lighting needs to be taken to consideration)
• [bug] [Related with negative distance also,] if there are 2 or more linked momentary_rot_buttons and the other has different signed distance then the other button will keep spinning past the end (and the internal ratio value would go past the 0 ≥ x ≥ 1 range)
  • solution: same as above
• If 2 or more linked momentary_rot_buttons have different distance/speed the one being USEd will dictate the speed and distance of the others. Then when it reaches the full distance all the others will snap to their fully opened/closed positions.
• As per RUST: Creating Proximity Doors triggering the momentary_rot_button every 0.1s does move it at the prescribed speed, but if "auto return" is not set it'd just continually ping-pong between opening and closing.

Addendum

1. path_corner (p1)
   • target = m1
   • wait = 0
   • spawnflags = Teleport (2)
2. momentary_door (m1)
   • target = p2
   • wait = 0
3. path_corner (p2)
   • target = m2
   • wait = 0
   • spawnflags = Teleport (2)
4. momentary_door (m2)
   • target = p1
   • wait = 0

1. A way to place/reuse the model multiple places in the map. Maybe a point entity that targets the main func_ entity, inheriting the func_'s convert_to.
   • Technically you can do this with MESS that runs after map2prop, but why use 2 tools when 1 tool do job.
   • Using brush entities that inherit others is actually mighty useful actually, to get the right sizing and positioning in the map. Maybe something like zhlt_usemodel approach is more ideal. Maybe do both.
2. More bones 🦴, a way to assign different parts of meshes to different bones, and a way to set bone hierarchy (easy enough using target keyvalue)
3. A way to create separate meshes (i.e. separate bodygroup parts) that is later combined into a single model. Probably separate entities that has a shared keyvalue (like MESS). Probably needs a way to set the main entity from the group too (also like MESS).

Edit 2024-03-17

1. A wall of tiling 16x16 brushes textured with a texlight.
   • _frange should make only a disk of those brushes around the light_surface emit light.
   • _fdist, if my interpretation of plane is correct, should light up all of them since the normal distance of all the faces to the plane is identical even if they're infinitely far away. That's the nature of planes.
2. Similar setup to the above but the next row above recedes 16u behind the previous row, producing a staircase. Place light_surface in the middle of this flight of stairs.
   • _frange should produce a sphere of lit up faces.
   • _fdist, if my interpretation of plane is correct, should have all faces on the same row light up until a certain distance away from the entity because again, all of them should have same normal distance to the plane.

1. Take advantage of it by naming entities you want to get triggered as part of the choreography, just like introchair, or
2. Avoid naming any entity in the map with the options value of the event[s]

The resource A has a limit of X because it is referenced by JKL with data type T, using [Remark]
The resource clipnodes has a limit of 32768 because it is referenced by other clipnodes with data type short, using positive values > 0

• This version of the map format is colloquially known as Valve20 to differentiate from the original Quake version
• Valve20 is now the de-facto map format all Quake-based and Quake-derived editors and compilers support due to the precision in texture alignment
• TrenchBroom uses the OS's clipboard for copy and paste (not the case with JACK/VHE3.x) and uses the map format to represent brush & entity data to be pasted. It also means clipboard-based IPC can be done using the map format.

• func_detail does not reduce world leaves
• func_detail instead reduce VIS portals generated by HLBSP. if without it HLBSP makes VIS portals around detail geometry, with it it just treat the surrounding area as a single VIS leaf
• func_detail is gone at the end of HLBSP, and is world geometry after that point
• hence HLRAD cannot treat it in any way other than opaque world brush because it's gone by the time it's run

• wheels distance is only measured forward from origin. To make the train travel as much on the path as possible, the origin needs to be located at the center of the back axle.
• wheel distance defaults to 100.
• target of a path_track is fired when the origin passes the path_track.
• the position and angle is set wrt the origin point as follows:
  1. trace a line forward.
  2. if there's enough distance to the end of the current path, keep heading
  3. if wheel distance > distance to next path, subtract current distance to next path, then iterate the path forwards until the distance fits the path. the point where distance is 0 is the new heading.
  4. origin moves forward
  5. angle is adjusted to point to the heading. this will in all cases be shorter than wheel distance; the sharper the curve the more noticeable. this also means the front wheel part will always overshoot the path. but the origin is guaranteed to always be on the path.

textures can be scaled as need because now lightmap can be recalculated after any changes.

1. trim the wasted space the table headers are using, and give more space for the description column
2. Immediately infer the properties with emojis without constantly having to look up the yes/no columns back to the header way up the page
3. hopefully get this to display better on mobile