Apex Legends coll* entity only triggers

[snake-biscuits]

Apex Legends maps use a "*coll0" "<base64>" form for triggers
Seems line an evolution of Titanfall 2's plaintext brushes & planes.

For decompiling & compiling maps we need to understand & re-create these structures.

[snake-biscuits]

Example Entity

>>> import bsp_tool
>>> b = bsp_tool.load_bsp("E:/Mod/ApexLegends/season15/1nov22/maps/mp_lobby.bsp")
>>> {print(f"{k:<16} {v}") for k, v in b.external.ENTITIES[5].items()}
model            *12
cubeMapIndex     0
mins             -3968.000000 -1024.000000 -1536.000000
maxs             3968.000000 1024.000000 1536.000000
cubemapID        0
origin           8254 -2386 512
target_noRename  0
target           env_gladcard_pfb18827b123a9d8a3
priority         10
classname        envmap_volume
*coll0           QAAAADgAAABEAAAAAQAAAAAAAAAAAQAAXAAAAFwAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYQBgAAAAAAAEAS4xBUT09MU1xUT09MU0VOVk1BUFZPTFVNRQAIBgABAAAAAAAAAAAAAAAAAAAANgCEAOAA0ACE
*coll1           AOAAMACEACAAMACEACAA0AB8AOAA0AB8ACAA0AB8ACAAMAB8AOAAMAABAwQFBwAEAQIGAwADBAEHAgAAAFAAAAAAEHAADAAwAAgYMAEUABABDAAQAgAQcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*coll2           AAAAAAAAAAAAAAAAAAAAAACEAHwAfAB8AHwAhACEAIQA4AAgACAAIAAgAOAA4ADgANAAMAAwADAAMADQANAA0AAAAAAAAAAAGAAAABEAAAA=
{None}

Structure sizes

>>> {len(e["*coll0"]) for e in b.external.ENTITIES.search(classname="envmap_volume")}
{160}
>>> {len(e["*coll1"]) for e in b.external.ENTITIES.search(classname="envmap_volume")}
{160}
>>> {len(e["*coll2"]) for e in b.external.ENTITIES.search(classname="envmap_volume")}
{108}

As bytes

>>> len(base64.b64decode(b.external.ENTITIES[5]["*coll0"]))
120
>>> len(base64.b64decode(b.external.ENTITIES[5]["*coll1"]))
120
>>> len(base64.b64decode(b.external.ENTITIES[5]["*coll2"]))
80

[snake-biscuits]

envmap_volume appears to be a cuboid brush marking a space for parallax mapping cubemaps.
The Season 15 Lobby's only coll* ents are these, but other unrendered trigger volume types use coll*

[snake-biscuits]

None of the envmap_volume origins seem to align with their target cubemaps, or the center of their bounds:

>>> {print(c) for c in b.external.CUBEMAPS}
Cubemap(origin=vec3(8393.0, -2385.0, 1539.0), unknown=0)
Cubemap(origin=vec3(12.0, 5721.0, 32.0), unknown=0)
Cubemap(origin=vec3(11811.0, 286.0, 66.0), unknown=0)
Cubemap(origin=vec3(5120.0, -168.0, 53.0), unknown=0)
Cubemap(origin=vec3(3105.0, 25.0, 535.0), unknown=0)
Cubemap(origin=vec3(-29.0, 581.0, 95.0), unknown=0)
{None}
>>> {print(e["cubemapID"], e["origin"]) for e in b.external.ENTITIES.search(classname="envmap_volume")}
0 8254 -2386 512
3 8175 -8177.5 -6439
3 -96 1204 112
3 -8230 -7644 360
5 2 816 144
2 11805 517 29
3 4096 11360 256
3 5088 506 26
3 7224 506 26
3 9312 506 26
3 2976 506 26
3 11328 3978 512
3 0 5760 256
3 4096 6338 256
3 11200 8320 256
{None}
>>>

[snake-biscuits]

Viewing coll* as bytes, there's a lot of dead space.
We can see texture names in coll0, single byte indices? in coll1 & multiple shorts in coll2

>>> import base64
>>> from bsp_tool.extensions.diff import xxd
>>> {print(L) for L in xxd(base64.b64decode(b.external.ENTITIES[5]["*coll0"]))}
0x00000000:  40 00 00 00 38 00 00 00 44 00 00 00 01 00 00 00 00 00 00 00 00 01 00 00 5C 00 00 00 5C 00 00 00   ....8...D...............\...\...
0x00000020:  5C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36 10 06 00 00 00 00 00 00   \......................6........
0x00000040:  40 12 E3 10 54 4F 4F 4C 53 5C 54 4F 4F 4C 53 45 4E 56 4D 41 50 56 4F 4C 55 4D 45 00 08 06 00 01   ....TOOLS\TOOLSENVMAPVOLUME.....
0x00000060:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36 00 84 00 E0 00 D0 00 84                           ...............6........
{None}
>>> {print(L) for L in xxd(base64.b64decode(b.external.ENTITIES[5]["*coll1"]))}
0x00000000:  00 E0 00 30 00 84 00 20 00 30 00 84 00 20 00 D0 00 7C 00 E0 00 D0 00 7C 00 20 00 D0 00 7C 00 20   ...0.....0......................
0x00000020:  00 30 00 7C 00 E0 00 30 00 01 03 04 05 07 00 04 01 02 06 03 00 03 04 01 07 02 00 00 00 50 00 00   .0.....0.....................P..
0x00000040:  00 00 10 70 00 0C 00 30 00 08 18 30 01 14 00 10 01 0C 00 10 02 00 10 70 00 00 00 00 00 00 00 00   ...p...0...0...........p........
0x00000060:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                           ........................
{None}
>>> {print(L) for L in xxd(base64.b64decode(b.external.ENTITIES[5]["*coll2"]))}
0x00000000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 00 7C 00 7C 00 7C 00 7C 00 84 00 84 00 84   ................................
0x00000020:  00 E0 00 20 00 20 00 20 00 20 00 E0 00 E0 00 E0 00 D0 00 30 00 30 00 30 00 30 00 D0 00 D0 00 D0   ...................0.0.0.0......
0x00000040:  00 00 00 00 00 00 00 00 18 00 00 00 11 00 00 00                                                   ................
{None}

[snake-biscuits]

According to @r-ex this is similar to rmdl collision
Though their 010 .bt crashed, might be some issues with indexing

[snake-biscuits]

Could we create a trigger w/ vscript and dump the *coll keyvalues?
Would make for a useful reference

[snake-biscuits]

Some entities have more than 3 *coll entries, the terminating entry can be variable length
e.g. "model" "*179" in season14/9aug22/maps/mp_rr_aqueduct goes up to *coll32

[snake-biscuits]

all *coll probably get combined into one bytestream to make a big variable-length struct

*coll0 is always 160 chars long, the max for any *coll value
probably something to do with string parsing speed / interruptibilty

[snake-biscuits]

all *coll probably get combined into one bytestream to make a big variable-length struct
rexx found the code for parsing *coll & this is indeed the case

*coll is apparently the same as physics structures in .rmdl

This means there's BVHNode & BVHLeafData