[BUG] func_bob implementation breaks the deathmatch maps from Dimension of the Machine

[zalon]

Describe the bug In some of the maps from the Dimension of the Machine expansion, they use the func_bob to create a mist above lava and other liquids.

With the implementation of func_bob in ktx (commit 9418cd9), these now appear as solid entities instead of non-solid and transparent.

This breaks at least MGDM1 and MGDM3.

To Reproduce Steps to reproduce the behavior: Use a ktx build from before commit 9418cd9, eg. latest release

Expected behavior Non-solid block with alpha value

Screenshots

Additional context This PR for mvdsv from dsvensson might help with supporting the alpha value https://github.com/QW-Group/mvdsv/pull/110

And since this seems related and would be a nice feature as well https://github.com/QW-Group/mvdsv/pull/117

[dsvensson]

Try with ktx on top of ftesv + fte. But if it's actually solid, in that you can stand on top of it it's a bug.

[dsvensson]

This bug is actually that func_bob implementation lacks support for BOB_NONSOLID spawnflag. When running the map which expects alpha support by design, under a server that has alpha support, and client with alpha brush ent support it renders correctly.

Here ktx is running under ftesv, and client is ironwail. The fog is fairly subtle, but if you look at the platform you'll see the effect:

But as ktx implementation currently doesn't implement support for non-solid bobs, you can walk on it which kind of breaks the illusion of having mist/fog there :D

I would suggest you simply remove that entity with a .ent override.

See here how that's done: https://github.com/QW-Group/ktx/tree/master/resources/example-configs/id1/maps

[dsvensson]

Worth noting is that the map uses spawnflag 3 (0b11) to signal non-solid, while progsdump and arcane dimensions uses 4 (0b100). Perhaps it's a mixup of bit vs value. I'm inclined to opt for spawnflag 4 for nonsolid to match progsdump as that's likely more common, and you may override that with an ent-file for maps that use 3.

[Shpoike]

https://github.com/id-Software/quake-rerelease-qc/blob/main/quakec_mg1/func_bob.qc#L20

[dsvensson]

Ah, nice. Ok, perhaps better to just support both variants there, as the spawnflags are free. Supporting both flavors will be a bit of a best effort as they differ in implementation even if they share the same name.

At any rate I think this is a bit broken issue. Really three things going on here.

• An issue in mvdsv to unbreak the half-implemented transparency support (only works with model ents since many years ago)
• Support for alpha brushes in ezQuake, https://github.com/QW-Group/ezquake-source/issues/630
• Support for progsdump/arcane dimensions style non-solid func_bob
• Best effort compatibility support for mg1 style func_bob that share the same entity name as the implemented progsdump/AD entity. Can be detected by the entity having a wait or spawnflag & 1, which ad/pd does not, and lack of waitmin/waitmin2. If all missing, default to pd/ad style bob.

But as mentioned, just extract the ents from the bsp, delete the offending func_bob's and have ktx load that to get rid of the issue.

There's also a third option, hardcode mg1 behavior for the mg1 maps, if that style of func_bob is not widespread.

[mortenbh]

But as mentioned, just extract the ents from the bsp, delete the offending func_bob's and have ktx load that to get rid of the issue.

This is not ideal since the latest MVDSV/KTX doesn't have this bug and clearly not everyone is going to install custom .ent files so when the next releases roll around this problem is going to show up more widely. The MGDMX maps in particular have recently gotten popular in the KTX wipeout game mode so a new bug showing up there would be unfortunate.

[dsvensson]

Isn't that just a matter of adding that ent file to nquake server setup and it'll be distributed? This is how CTF works everywhere.

Anyways, that's the quick fix, the slightly slower is to add support for nonsolids that will make it behave correctly in mature servers/clients, and at some point in mvdsv/ezq.

You have the alpha problem with all other entities fyi. Be it func_illusionary, func_wall, or func_laser, so the alpha part is not a bug in ktx, just a limitation in the server/client setup. And as for bug, it actually is an existing bug in mvdsv years old, the transparency it implemented was broken from start and only works with mdl entities. But now that ezq has recently synced with mvdsv it'll be easier to fix.

Or ofc hardcoding mg1 quirk to skip creation of func_bob. Ktx has a number of hardcoded map quirks, and while it would be defeat, it wouldn't be the first time.

So in summary. Even if this bug is fixed - or rather - nonsolid feature implemented, users of mvdsv/ezquake will still perceive mg1 maps with func_bob fog as being buggy, due to a many years old protocol bug between mvdsv and ezquake, and lack of alpha brushes in ezquake renderers, thus excluding the func_bob entities in any of the ways outlined above for maps with other design goals is probably the best workaround until all pieces have been fixed.