surfaceflags are defined in engine code, not in game code

[illwieckz]

See: src/engine/qcommon/surfaceflags.h

They contains Unvanquished-specific code like CONTENTS_NOALIENBUILD. Those flags are game-specific, for example the value for Unvanquished's nobuild surfaceflag is known to be the value for the Urban Terror metalstep surface.

[illwieckz]

Can we imagine a kind of proxy array?

Engine would have:

#define ENGINE_SURF_METALSTEP 0x1;
#define ENGINE_SURF_NOBUILD   0x2;
#define ENGINE_SURF_SNOWSTEP  0x4;
#define ENGINE_SURF_LANDMINE  0x8;

One game would have:

#define GAME_METALSTEP 0x1;
#define GAME_SNOWSTEP  0x2;

surfaceflags[GAME_METALSTEP] = ENGINE_METALSTEP;
surfaceflags[GAME_SNOWSTEP]  = ENGINE_SNOWSTEP;

Other game would have:

#define GAME_SURF_NOBUILD   0x1;
#define GAME_SURF_METALSTEP 0x2;

surfaceflags[GAME_SURF_NOBUILD]   = ENGINE_NOBUILD;
surfaceflags[GAME_SURF_METALSTEP] = ENGINE_METALSTEP;

So, instead of testing for SURFACEFLAG we would test for surfaceflags[SURFACEFLAGS], I don't know if it's silly or not… [Well, this is absolutely silly, it's not how bitwise operations works, but you got the idea of something acting like a proxy].

[DolceTriade]

I think we need to ensure that all the surfaceflags used by the engine are common between all the games. The game should be able to define additional surface flags in their own header files that the engine doesn't need to know about.

IIUC, these surface flags are just used as parameters to trace functions. It would be sufficient to simply have two header files.

[illwieckz]

One of great thing in QVM / NaCl is that any game developer can provide a game without having to go to the engine build process that requires having a toolchain (and perhaps the related hardware) for all supported OS and architectures. Doing this kind of customization at run time to enable game developers to not have to rebuild engine themselves on a release purpose would lower the entry gap a lot. I'm not sure people rebuild themselves and have to rebuild themselves the whole Godot, UE4, Unity or the Source Engine to be able to release.

Having to rebuild and ship its own engine was the biggest issue of id tech 3 in the long time, that was a project killer. See comments in this Smokin' Guns thread:

TheDoctor: Also, I think, it was a bad idea for every Q3 mod to become standalone. If there would be a chance for a number of games to share a single engine again, this would help to share a player base and assemble forces.

This and my answer starting with Yeah, that was both a bad idea and a big mistake.

Going through the engine release process is very hard (and we know something about it), making that process a requirement is deadly for projects. There is some technical issue related to this but the biggest issues are related to how human beings behave.

[illwieckz]

Another related issue (but simple issue) is terminology. It would be possible to use a generic team_red / team_blue wording, and well, we already do this, look at plat23 map! 😉

And this would make things less weird if some game needs to add a third team or more and require surfaceflags for that.

[t4im]

Might be useful to get a general overview about where the maps used by games differ by collecting surface and content flags somewhere. Including for games that have not yet decided to attempt a daemon port.

[illwieckz]

@t4im such surface flags are documented in q3map2 source tree, in game_*.h files:
https://gitlab.com/xonotic/netradiant/tree/master/tools/quake3/q3map2

example:
https://gitlab.com/xonotic/netradiant/blob/master/tools/quake3/q3map2/game_unvanquished.h

By comparing quake3 and unvanquished we see that unvanquished's nobuild content flag uses the same value quake3 uses for metalstep surfaceflag. Content flags and surface flags are not same things but I guess there is something wrong somewhere like setting the content flag from the surface flag or something like that because urbanterror (quake3)'s metalsetp surfaces prevents to build in unvanquished.

NetRadiant trees has all the defines [GtkRadiant has] (with more games and more options).

Sometime those files are living within their own fork tree, like the game_smokinguns.h file (I will import it one day btw).

Games can also ship those defines in a custinfoparms.txt file.