[Bug] Problem with func_train

[NightFright2k19]

Gotshun's "Lost Levels" for SoA have an issue in the last map, e2ue "Connect". At the beginning of the map, there is a silver key which is sitting on an (invisible) train entity, supposed to be pulled into a compartment once triggered, with a second key being pushed out of another compartment nearby. However, this does not happen, at least not in vanilla SoA. The key will just sit there, in a lower position than it should, indicating the train on which is was supposed to rest is missing.

Tests revealed this:

• Quakespasm 0.94.1/Mark V: Effect works as intended
• QSS: Effect does NOT work with vanilla SoA (from 1997), but works with Quake Enhanced (from 2021)

Used QSS build: Win64 (x86-64) from 2021-09-13

This indicates it's a code-related issue.

[NightFright2k19]

No improvements in updated build from Oct 6.

[NightFright2k19]

Update: The Authentic Models Pack also has an impact, but only its progs.dat file. The problem remains as described:

• Works with SoA from Quake Enhanced
• Does not work with: SoA vanilla and/or Authentic Models Pack (custom progs.dat)

[QUINTIX]

reiterating my comment here on the upstream fork vkQuake, running pr_checkextensions 0 in the console (or setting in the config) before loading the level in question is a workaround that I suspect will work here as well.

To elaborate, part of the trouble comes from world.c's SV_LinkEdict expanding the "absolute" bounding box of the pusher entity to fit any 45 + 90*[any integer] degree rotation about the reported origin along any axis if an entity has any non-zero rotation. But the origin is outside the baseline bounding box, being at {0,0,0}, so the area being tested by func_train via SV_PushMove in sv_phys.c explodes in size, encompassing other entities that can block a pusher if they're within the "absolute" bounds of the tested bounding box. pr_checkextensions 0 disables that particular bounding box adjustment.

You can run edict 8 in the console with and without pr_checkextensions enabled to see what I mean.

with pr_checkextensions 1, you should get

EDICT 8:
modelindex       2.0
absmin         '-1236.4 -1236.4 -1236.4'
absmax         '1236.4 1236.4 1236.4'
ltime            0.1
movetype         7.0
solid            4.0
angles         '  0.0 270.0   0.0'
classname      train
...

with pr_checkextensions 0, you should get

EDICT 8:
modelindex       2.0
absmin         '991.0 -641.0  31.0'
absmax         '1057.0 -527.0  41.0'
ltime            0.1
movetype         7.0
solid            4.0
angles         '  0.0 270.0   0.0'
classname      train
...

[Shpoike]

angles set on a bmodel will rotate both its visuals and collisions, instead of just its rotations. its lack of an origin value simply means its pivot is a long way away from its midpoint. the massive absmin/max is required for rotated entities that might not relink following changes to their angles field, it still uses the bmodel to check for any actual collisions (and thus needs at least a partially expanded aabb so it doesn't trivially reject things its actually intersecting).

simply put, the map is defective and is unintentionally making use of extensions, leaving it broken in a few different engines. pr_checkextensions 0 should bring it back to QS's glitchy rotated-visuals-but-unrotated-collision behaviour. there's been a few maps+mods that do similar evil things now, and the only way to 'fix' them is to break other stuff...