Broken map logic in FTEQW

[Nolcoz]

Description of Issues

---

More than one map has issues where in FTEQW map logic breaks, most of the times when moving platforms and entities interact with each other. Here are some issues I found on maps I have made. I havent checked maps done by others as I am more familiar with my own.

E1M7 At the end of the map, you end up in an area filled with dead Grunts, leading to the exit of the map. The way this works is that the grunts spawn on top of a CLIP platform that rises them down to a trigger_hurt that will kill them in contact. The platform then leaves the bodies on the floor. In FTEQW, the Grunts are in place but are alive.

E2M3 At the start, the silver key that is supposed to be carried away from the player by a func_train. In FTEQW the key simply does not collide with the platform, allowing the player to pick the key up where it is. This key is used for the exit gate, allowing you to skip pretty much all of the map.

E2M4 In the acid pit with the big eyeball, there is a platform that rises from the acid carrying a Death Knight, that is meant to shoot at you while the platform moves around, and eventually jumps unto your platform. In FTEQW it seems the Death Knight gets stuck in the platform, constantly hurting him and not allowing the platform to move, breaking the whole sequence

E2M5 The tech gates that appear in the map have blue signs that are func doors, that retreat once a level progression switch has been found. For some reason. in FTEQW. these signs seem to only appear at a specific range and outside that range they dissapear, which does not happen in Quakespasm or Ironwail

Visual Sample

---

E1M7 Issue Intended behaviour FTEQW

E2M3 Issue https://github.com/user-attachments/assets/548d6b6f-210a-469e-a824-4d3c8b33a19a

E2M4 Issue Intended behaviour https://github.com/user-attachments/assets/d3058ecb-773c-435c-8916-f01e4587314d FTEQW https://github.com/user-attachments/assets/4f9f137f-aa47-4230-b3df-7125e831d3de

E2M5 Issue FTEQW https://github.com/user-attachments/assets/5689f7be-0106-4468-92a6-7a6d101cc9cc

[MotoLegacy]

I'm going to self-assign this to you so we can track progress here, feel free to remove yourself if you do not want to be the one to tackle it.

[Nolcoz]

At the moment I dont really plan to tackle it, as I am gonna be fairly busy these weeks, so I am gonna remove myself

[lavenderdotpet]

maybe this would be fixed by forcing a netquake protocol instead of using quake world

[MotoLegacy]

I think the idea was specifically to allow these maps to work in QuakeWorld as well. I'm not sure how you could elegantly swap between the two protocols without some weird QC hack. It is my opinion that we should focus on actual map fixes

EDIT: That wouldn't even work, ignore me

[MotoLegacy]

I spoke to Spike about these, posting the responses.

E1M7

there's a bug where time isn't set quite the same as in nq engines at the start of the map, this breaks a few mods apparently, but it meant to be fixed in the latest git revision... but probably isn't fixed in eukara's builds and certainly not the tth builds.

Suggested Actions: Test on latest FTEQW from GitHub. Notify Spike if bug is not fixed. Do not change the map.

E2M3

if you're depending on specific trigger touch orders, then that's also broken in dp. so don't do that. note that this can be a serious issue for wind tunnels where they regularly overlap and fight over which one gets to set the velocity..

Suggested Actions: Verify Spike is correct that this is a result of an assumption over trigger execution order. Change the map to stagger the triggers slightly if correct.

E2M4

vanilla's trigger_hurt can misbehave when eg teleporters trigger. the force_retouch can forcd the hurt to relink, causing it to de-link, an when next reset it changes its solid back to solid_trigger WITHOUT relinking it. this bug tends not to happen in both fte and dp (xonotic depends on it not breaking for one thing), but can result in a behaviour difference on eg vanilla's end.bsp

Suggested Actions: Confirm Spike's assumption. Investigate fixing in QuakeC if correct.

E2M5

no idea wtf that's about. looks like zfighting. 'r_polygonoffset_submodel_map ""' should be librequake's default consistent with glquake... which did not have any 'zfix'/zbreak...

Suggested Actions: Test if this cvar fixes. Add to config if it does.

[Zungrysoft]

@MotoLegacy @Nolcoz

e1m7

I know monsters can be super finnicky when it comes to collisions with triggers. I was able to get 3 out of 4 of the grunts to die by just making the trigger extend all the way to the ground. Then the fourth one would die after noticing the player and walking around in the trigger volume for a bit. It's bizarre.

I'll see if I can figure out how to compile FTEQW from source some time this week so I can try out the latest build. I've been meaning to see if I can add some features to the engine.

EDIT: The latest build of FTEQW doesn't solve it. One possible workaround is to use trap_spikeshooters to kill the grunts instead of the trigger_hurt, as those are much more reliable.

e2m3

I tested Nolcoz's suggestion to put a killtargetted func_wall under the key to hold it up so it's high enough to be picked up by the platform. It worked.

EDIT: This issue is fixed in the latest FTEQW build.

e2m4

I don't know what Spike is talking about here. This sequence doesn't use a trigger_hurt at all. I know the bug he's referring to and it's fixed in LibreQuake's custom progs.dat.

e2m5

That cvar seems to fix it after a vid_reload. I think what's going on is that this cvar is a zfighting fix. But Spike has mentioned that it doesn't so much fix z-fighting as shift the bugs elsewhere, which might be what we're seeing here. The default setting for FTEQW is a wildcard thing that matches all levels in the original game and mission packs. So any level named "e4m3" or similar will have z-fighting "fixed", while other levels will not. Presumably, this setting works great for all original Quake maps. But it causes problems in ours. So we should add the cvar to the config.

[lavenderdotpet]

@Zungrysoft

I don't know what Spike is talking about here. This sequence doesn't use a trigger_hurt at all. I know the bug he's referring to and it's fixed in LibreQuake's custom progs.dat.

does that mean it would break with stock progs or progs that dont fix it

[Zungrysoft]

@lavenderdotpet Well like I said, I don't think that bug is even caused by trigger_hurt. The bug in e1m7 uses trigger_hurt, but it doesn't get fixed even with the fixed progs.dat.

[Nolcoz]

Ended up fixing the issue in E1M7 with a method like Zungryware proposed, using spikeshooters, in this pull https://github.com/lavenderdotpet/LibreQuake/pull/241