REQ: Support for alpha-channel map entities in EZQuake

[inf1niti]

Is your feature request related to a problem? Please describe.
Other modern Quake engines support alpha transparency on func_wall and func_illusionary entities in a bsp file. this is supported via the alpha property on brush entities.

This effectively lets a map implement semi-transparent brushes that can be see-through, like vis'd water, to represent windows, lasers, glass doors, etc.

Describe the solution you'd like
I'd like ezquake to be able to support this so it can align better with where other quake engines are at today. Although ezquake is more gamplay focused, this is a change that effects gameplay as much as aesthetics because transparent brushes effect gameplay.

Additional context
IIRC support for this was added in protocol changes to the original quake protocol. As such, support might need to be added through updating the QW protocol as well.

Impact on server or mods
If there are necessary protocol updates, this would have an impact on (or would require updates to) KTX/mvdsv as well.

[meag]

Can you supply an example .bsp file and qwd/mvd file with the alpha property being sent?

[inf1niti]

So I'm not actually sure the alpha property gets sent - because its func_wall or func_illusionary it is non-vis blocking, so you can see things through it. As long as it's being rendered appropriately in the client it should be fine?

In standard quake however, support for this feature was added in Fitzquake and rolled under a protocol change (protocol 666), and it doesn't work in protocol 15 network play (that's why I mentioned it). Spike could likely provide more details if necessary (this works in multiplayer using FTE as a server).

Example

Here's an example BSP using the alpha property on a window element.

Details	Screenshot
setting property in trenchbroom
Rendered in EZQuake
Rendered in QSS

[dsvensson]

Talked with @qqshka and @ciscon, I'll extract the protocol parts of my alpha branch and introduce a server side client version check similar to what FTE uses for ezquake. The motivation for a version check is because it not working is a bug in the original implementation of FTE_TRANS wrt PF_EXTRA_PFS support that forgot to read an extra byte. Should that byte arrive the protocol state is off-by-one.

@ciscon: and we're going to stop stealing from spike now? i think not

This will make it trivial to support alpha entities as a first step as that's already supported by the renderers, just needs some wiring up across networking/progs over to renderer corner. Brush support is working since 2 years in my branch, but it's a larger diff, so better to break up.