Engine standards for mod compatibility

[LordHavoc]

[mh]

[metlslime]

[mh]

[scar3crow]

[metlslime]

Some thoughts based on everyone's comments:

1. There have been a lot of suggestions for features that have nothing to do with map or mod support/compatibility. We should definitely exclude these as being completely irrelevant to this project.

2. Some of the suggestions are on-topic, but represent features that are not widely implemented or would be hard to standardize now because they are too new, don't exist, or vary too much, such as native rotating brushes, or weather effects. I think some of these could go into a future standard AFTER enough engines have informally implemented it in a consistent enough way to be useful.

3. Fog is a good example of a feature that is standard enough to be widely used, but still has some issues in that different engines don't interpret the numbers in exactly the same way. Perhaps in this case the standard should include a definition of how the fog should be calculated, for example whether to use GL_EXP or GL_EXP2, and in the case of implementations that calculate their own fog in software (i think Darkplaces does this) define the actual fog calculation. Or, maybe we can accept that fog isn't identical across engines, but is at least close to being correct? If so how close does it have to be? Another fog-related issue is whether the sky is rendered when fog is present, and if so, how the fog interacts with it.

4. Skyboxes are another case where things are almost standard. I think the two issues are orientation (which side of the box is north) and what folder the images should be stored in. I believe almost all engines orient the skyboxes the same way; there was a bug in the older darkplaces that rotated it 90 degrees from the typical standard, but that's long been fixed. The folder issue is fairly simple, it is a good idea for engines to support all known folder paths, so that legacy content doesn't break, but only new content is going to advertise the "standard" and so the standard only needs to declare one folder.

5. QC control of sky and fog is a really good idea, however the "stuffcmd" method is really ugly and has the negative effect that it demands a certain cvar or command be present on a client. I think the correct approach would be to provide builtins for the quakec, and those builtins would generate a message using the server's current network protocol. This way the standard would not have to make any demands of the client UI or the server protocol. At worst, a lazy engine could implement that builtin by generating its own stuffcmd message, but this standard is pretty much going to require some sort of custom protocol anyway (higher precache limits,) so adding additional requirements to the network protocol wouldn't be too much of a burden, i guess.

6. which brings up the question, is it outside the scope of this project to define the network protocol itself? Technically demos are content, and if your engine can't read the protocol it can't display the demo for the user. However, A. that may be a tolerable loss, and B. it is a huge can of worms and would probably stall this project indefinitely.

7. External textures may be a good candidate for this standard, they are widely used in the field, implemented in multiple engines, and are already mostly consistent across engines. It might be worth it to include them, and clean up the small inconsistencies that remain. I think the only issues are with folder paths and file names at this point.

8. We may want to create a roadmap for future versions so that programmers and modders can work towards the future standards as soon as possible. So even if something isn't part of Quake 2.0, we can say that it will be in Quake 2.1 and people can start implementing it.

9. I agree with the observation about "GLQuake mods" and "Darkplaces mods". Part of the problem for me (as an engine developer) is that, when it comes to quakec extensions, there are like a hundred of them and i don't know which are most important, which mods need which extensions, and even which mods are most important to support first.

10. So based on #9, we have already got a pretty good list of map-oriented features, anyone want to put together a bullet list of the most useful quakec additions (ideally already implemented and used in the wild) that we would want in this standard? I would submit that "PR_CheckExtension" is probably feature #1 on such a list.

[Team Xlink]

[Baker]

[r00k]

[Baker]

[Chip]

[mh]

[goldenboy]

[Baker]

[r00k]