Quake Standards Base discussion

[Urre]

Standards by committees suck because they have to adress so many different needs and views, so they become big and cluttered, often slow, whereas non-committee driven standards simply grow out of competition, which is the very thing I'm trying to fight against for once. I'm forced to make it act like a committee-like standard, even though I've just made it up myself, based on peoples wishlists. I'm forced because the goal is the same as committee standards, I'm trying to please as many as possible. Not only the modders and mappers, some of them don't even know they need pleasing, but also the engine devs, that's the biggest headache, really, as all of this is pointless if all engine-devs find it stupid or useless or whatever. So far it seems QSB is getting a lot of support, atleast the idea of it, which is really all I wanted for starters. The next step is cementing a first version of the standard. The step after that is to actively lobby for the idea, make sure engines get it implemented, along with me (and hopefully others) working on making test cases for it.

That's how I see it...

The question remains, should QSB ignore checkextension?

[dreadlorde]

That's really the only part I don't see a point for.

[Spirit]

What easier way would there be for a mod to check if the engine supports it (or vice-versa)?

[Spike]

checkextension is only there for if the mod wants to check it. its existance does not mandate its use.
if you don't mind your mod crashing/etc on a legacy engine, then there's no need to check to see if it supports stuff.
that said, smaller mods like frikbots enjoy optional support from the engine, without breaking too much on such legacy engines, without breaking the mods they get ported to.
but yes, in an ideal world, every engine would support everything you wanted to do, meaning checkextension is useless. in an ideal world, anyway.
The engine should support it, imho, but there's no reason for the mod to need to bother.

[Baker]

A QSB 0.5 would be nice.

Right now I am thinking that the ideas behind a 1.0 standard violate the 90%/10% rule (90% of the gain for 10% of the effort).

My personal philosophy is that development and standards are fueled by completed works that people enjoy playing and are popular, increasing the demand and use of the feature.

Certain features have LOW implementation costs and HIGH gains for implementation:

* Scale
* MOVETYPE_FOLLOW
* EF_NODRAW
* EF_ADDITIVE
* DRAWONLY_TO_CLIENT
* FRIK_FILE

etc.

And certain other changes have very HIGH implementation costs and LOW gains for implementation:

* Memory management systems
* Major protocol changes
* Major changes to break limits

I'd like to see a stepping stone standard as a reasonable first step towards a greater standard.

There is nothing inherently wrong with QSB 1.0, but a fast and easy to achieve QSB 0.5 with most of the easy win features that would allow better modding would be nice as a checkpoint to a 1.0.

Obviously with a protocol 15+/666+ to support it maybe even with delta compression if that isn't too difficult to achieve.[/list][/code]

[mh]

One other advantage I can see of a QSB 0.5 is that it would let us road-test the standard rather quickly. We all know that talking about great ideas is one thing, but actually doing them and seeing how they work in practice is completely different. By getting something up and running sooner rather than later we can easily identify and find solutions for potential trouble spots.

It would also greatly ease the implementation overhead for engines that have already been evolved well boyond the ID Quake baseline.

The danger of course is that the standard will become stuck at 0.5 and not go much beyond that.

[frag.machine]

We can create a QSB 1.0 standard with a really minimal list of features, I don't see the need for "< 1.0" version numbers. Actually I already told that: let's start small, a list of 10 or less features that we, the community, could consider the "minimal" to expect from a non-vanilla engine. QSB 1.0 doesn't need to be "complete" - actually, it's unlikely it will be in the first incarnation. I see QSB only reaching a "mature" state after the fourth or fifth iteration. So, I'd vote to start small, but following the "90/10" rule Baker mentioned.

Another advantage in start small is to dissipate a bit this "formal committee" image we are creating to people outside the discussions. Both dreadlorde and Urre have valid, although different, points regarding this committee image. But IMO the simpler we start the easier people will embrace the idea.

Regarding checkextensions, I share Urre's point of view: why not implement it ? It's really simple to do, a number of projects already have it (filling the "let's standardize what's common" requisite) and quite useful for modders. Having the ability to detect in a safe way if the engine can/cannot do something is useful. Unless somebody is considering another QSB-exclusive mechanism - and, TBH, I think it's not a good idea to reinvent the wheel, since checkextensions works just fine.

[mh]

Let's do it then.

No reason not to at the very least implement checkextensions and just return false for everything, is there?

[Baker]

One other advantage I can see of a QSB 0.5 is that it would let us road-test the standard rather quickly. We all know that talking about great ideas is one thing, but actually doing them and seeing how they work in practice is completely different.

Avelocity is going to get used. Scale will get used. Alpha will get used. Colormap (I hope this works in software renderers?) will get used. Movetype follow will get used. Drawonly to client will get used.

The sooner and easier they become available, the better.

Protocol is not immediately so important because most of the usage would be in single player or in "game-locked" engines (dedicated total conversion engines). For multiplayer, at least at this point, DarkPlaces and FTEQW would be what people use ... until a new standardized protocol emerges.

The danger of course is that the standard will become stuck at 0.5 and not go much beyond that.

I have a hard time believing that would happen.

It's just I think massive changes for part of a standard for a first stepping stone puts the entire idea in jeopardy.

[metlslime]

I agree. To restate my earlier posts:

- smaller, incremental standards. Multiple small versions are easier to implement, but more importantly, easier for a committee to agree upon than one "ultimate standard"

- standardize common practice, rather than inventing new features. new features are too hard to spec, existing practice is proven to be usable in the field.

- keep it modding relevant and eliminate anything that is outside of that scope. Console size, tab completeion are NOT modding relevant.

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

[mh]

I agree. To restate my earlier posts:

- smaller, incremental standards. Multiple small versions are easier to implement, but more importantly, easier for a committee to agree upon than one "ultimate standard"

- standardize common practice, rather than inventing new features. new features are too hard to spec, existing practice is proven to be usable in the field.

- keep it modding relevant and eliminate anything that is outside of that scope. Console size, tab completeion are NOT modding relevant.

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

The only thing I'd add to that is when BSP/etc limtiations are artificial - i.e. a function of the implementation as it exists in ID Quake, rather than as it is derived from the format - they should be included (but perhaps deferred to a second rev of the standard to allow it to get off the ground quicker).

[Sajt]

I'm looking at the QSB wiki page, and it almost looks like you're increasing every single limit you can find. Are these values based on an existing good engine, or are they kind of arbitrary? It would be an annoying task to update all these in one's engine (not to mention probably causing memory use to balloon). Maybe most of it should be kept for a later version... (same with the humongous amount of extensions)

Anyway, this looks pretty good. The wiki page could be expanded into something like that old site which had a huge list of Quake bugs and how to fix them. I would add a few more which I came across and fixed already in GoldQuake (and I would be happy to write tutorials on the wiki for them, maybe I'll do that later today).

Features:
- "freelook" cvar.
- "showfps" cvar.
- mouse4 and mouse5.
- "in_pitch_min" and "in_pitch_max", like DarkPlaces but defaulted to the Quake values.

Actually, according to metlslime's post those first three shouldn't be included. But the pitch min/max should be.

Bugfixes:
- "sv_gameplayfix_setmodelrealbox" (setmodel sets bbox to model bounds, not '-16 -16 -16', '16 16 16').

Also a cvar to disable the effect in Quake where the weaponmodel is nudged upward when the hud is activated (causing the weaponmodel to shift when you look up/down). This is particularly noticeable when you have an effect which is supposed to be sourced at the gun's barrel... when you look up or down it doesn't quite match up anymore.

And a cvar to enable vertical-based FOV, which makes widescreen work properly (or is this again not modding-specific?).

I think the default for all "fix" cvars should be off, to match Quake's behaviour. Mods should set them in autoexec.cfg.

[metlslime]

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

The only thing I'd add to that is when BSP/etc limtiations are artificial - i.e. a function of the implementation as it exists in ID Quake, rather than as it is derived from the format - they should be included (but perhaps deferred to a second rev of the standard to allow it to get off the ground quicker).

Oh, yeah I don't want to drop such limits entirely, just try to redefine them in an implementation-independant way. For example, define it in terms of a combined total for bsp textures + skins + sprites needed by a single level.

[mh]

I'm looking at the QSB wiki page, and it almost looks like you're increasing every single limit you can find. Are these values based on an existing good engine, or are they kind of arbitrary? It would be an annoying task to update all these in one's engine (not to mention probably causing memory use to balloon). Maybe most of it should be kept for a later version... (same with the humongous amount of extensions)

Anyway, this looks pretty good. The wiki page could be expanded into something like that old site which had a huge list of Quake bugs and how to fix them. I would add a few more which I came across and fixed already in GoldQuake (and I would be happy to write tutorials on the wiki for them, maybe I'll do that later today).

Features:
- "freelook" cvar.
- "showfps" cvar.
- mouse4 and mouse5.
- "in_pitch_min" and "in_pitch_max", like DarkPlaces but defaulted to the Quake values.

Actually, according to metlslime's post those first three shouldn't be included. But the pitch min/max should be.

Bugfixes:
- "sv_gameplayfix_setmodelrealbox" (setmodel sets bbox to model bounds, not '-16 -16 -16', '16 16 16').

Also a cvar to disable the effect in Quake where the weaponmodel is nudged upward when the hud is activated (causing the weaponmodel to shift when you look up/down). This is particularly noticeable when you have an effect which is supposed to be sourced at the gun's barrel... when you look up or down it doesn't quite match up anymore.

And a cvar to enable vertical-based FOV, which makes widescreen work properly (or is this again not modding-specific?).

I think the default for all "fix" cvars should be off, to match Quake's behaviour. Mods should set them in autoexec.cfg.

Despite the fact that they're not in metl's list, these are interesting features and probably more suitable for a "baseline essential engine features" thread.

One thing that I think is relevant is cvar name standardisation. DirectQ is shortly going to have the ability to refer to a cvar by multiple names (and potentially to declare new cvars on the fly from QC, but that's a whole 'nother story), but that's not something that most engines would have, and it's important to get right for any included feature that is cvar-controlled.

[r00k]

1.> QSB 1.0 engine limits
2.> ENHANCED STRING FUNCTIONS / FRIKFILE support
3.> SKYBOX, FOG, ENTRYSPAWN world spawn fields
4.> enchanced SVCs for hud features.(teamscore, match time, flag status)
5.> 24bit texture support. atleast menu and world textures
6.> animation interpolation
7.> cvar standards