Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zalon opened this issue Jan 14, 2024 · 7 comments
Labels

Comments

@zalon
Copy link

zalon commented Jan 14, 2024

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
ezquake058
ezquake057

Additional context
This PR for mvdsv from dsvensson might help with supporting the alpha value
QW-Group/mvdsv#110

And since this seems related and would be a nice feature as well
QW-Group/mvdsv#117

@zalon zalon added the bug label Jan 14, 2024
@dsvensson
Copy link
Collaborator

dsvensson commented Jan 14, 2024

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
Copy link
Collaborator

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:

image

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
Copy link
Collaborator

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
Copy link
Contributor

Shpoike commented Jan 14, 2024

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

@dsvensson
Copy link
Collaborator

dsvensson commented Jan 14, 2024

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, REQ: Support for alpha-channel map entities in EZQuake ezquake-source#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
Copy link

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
Copy link
Collaborator

dsvensson commented Jan 15, 2024

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.

dsvensson added a commit to qw-ctf/ktx that referenced this issue Jan 16, 2024
Support for non-solid func_bob has not yet been implemented. Best to
remove them for now to avoid blocking players on maps that do use them.

Partial fix for QW-Group#330
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants