Engine standards for mod compatibility

[Spirit]

[Baker]

[Urre]

[Baker]

(Urre/Spike ignore this and continue ... not wanting to distract from main theme of thread)

For Goldenboy and anyone else who does have an interest in software renderers (I do) ...

r_wateralpha and Makaqu ... software rendering and alpha ...

[Urre]

Baker: talking about alpha in software engines is staying on topic

[Urre]

Having IRC'd with Supa a bit, I want to try and squash some possible misinterpretations.

There will always be mods wanting to do things outside the standard, being unable to live without feature X and so forth. That really is up to them, and is their problem. The goal isn't to make all engines be as feature-filled as say FTEQW. The goal is to up the bar of basic modding and mapping. I want to kill GLQuake dead! Modding and mapping needs to get out of the dark ages!

Instead of lots of modders thinking "oh no, can't do that cause then my mod won't work on Dreamcast-Quake", they should now be able to, because Dreamcast-Quake will want to support this awesome new standard which all the awesome mods use.

Imagine Solitude using a generic PSP Quake engine instead of their own special one, because a generic one doesn't support all the features they need.

Checkextension alone doesn't cut it. We've seen how engine devs just pick the extensions they like and implement them, but ignore the ones they don't like. The idea is that everyone would need to agree on a minimum set of features.

Something which I think many realise, but it hasn't been said yet, is that there needs to be a big ol' rallying of convincing people to realise the importance of this. Especially the ones who don't care a lot, like say QW engine devs, 'cause their userbase "only plays MegaTF anyway". You'll need to convince the people who are capable of convincing the other people. Imagine if the MegaTF players became aware of this huge world of cool mods that their favorite engine is compatible with, just because they see something about QSB compatibility in the next engine release changelog.

[Dr. Shadowborg]

If what I'm about to say doesn't apply, then just ignore it, but...

It would be cool if we could have an engine feature that allowed at the very least limited generation of genuine new keys / buttons that could be configured within the config menu. i.e. for things like altfires, Rune controls, etc. (This isn't really too high priority though as this can be done from QuakeC and the console, but would definitely be a nice feature to have from a "easy for end user to use" standpoint.)

[Urre]

Supporting extra buttons is fine as a request, but listing them in the menu can be tricky, and not really part of this. That'd be a menuqc job if done right.

[Supa]

Just to throw my two cents in - PLEASE don't ignore the extension system that we already have.

I know most people ignore it in favor of dropping everything for NQ compatibility, but that's just because a mod~game can depend on multiple extensions just for base level functionality. What can you do when you *need* DP_SV_FOO, DP_QC_BAR *and* DP_EF_BAZ, but the engine only supports DP_EF_BAZ? I really think that if we do this, each standard needs to be a pure advertistment extension itself. So we'd know that every engine with STANDARD_QSB_2010 will support a guaranteed set of extensions, we wouldn't have to put up with the current patchwork support problem that we have now. That patchwork support problem (see above) is currently a *huge* incentive to target either just DP or base NQ, and it *needs* to go away. I understand that if a game hinges on a certain extension outside of the standard it's their problem, but right now I'd just be estatic if we could climb out of the pit of despair that is NQ.

Basically, I just want to see more support for the QSG extensions system[1] in general. It irritates me that only DP and FTE make an effort to support it and other engines focus on generic things that have already been ran into the ground, like alpha support or another skybox standard. We should build on what we already have and play to the strengths of the QSG system - we should build some kind of reference library, like a DP codebase that isn't insane at times. :P

One more thing - right now, I have a project that I cannot help but target at DP because it relies on a DP quirk/behavior, specifically the capability to allow stuck/merged entities to move outside of the others' bbox. Words fail me when I try to describe how wrongheaded this is. I need this behavior for my game, I want people who don't/can't use DP to be able to play it, I want other engines to be able to support this behavior, but without an reference for how it's supposed to be implemented and checked for it'll become worse than useless - it's too likely it would be advertised but not correctly supported, or supported and not advertised. Just *how* is the SSVM supposed to tell the difference between engine quirks?

To get to my point, I want to see more pure advertisment extensions - an extension that advertises every DP sv_gameplayfix* cvar, one for DP's collision behavior, extensions for anything that one would remark about when examining a specific engine. If an engine supports x skybox format, it needs an extension. I don't care if it means we'll end up with triplicate extensions that amount to the same thing, all I care is that the gamecode can find out on its' own what the engine supports. We all know users won't check the docs first, the gamecode *needs* to be able to know as much about the engine as it can.

*1 Yes, I'm aware of the QSG vs DP extension system history, I just think 'QSG extension system' is a more neutral name to present to potential implentators. :)

[LordHavoc]

[LordHavoc]

[MDave]

[LordHavoc]

[MDave]

[Downsider]