Engine standards for mod compatibility

[Urre]

The reason I believe few modders opted to using QSG extension checks and such is because it's pretty tedious business. Most simply wrote which engine was required/recommended in the readme when releasing the mod, and if people didn't like the requirements, screw them, basicly. This is fine in the sense that you know the end users get a consistent experience playing your mod, but if you stop being a control-freak for a second, and realise the upsides of more people being able to play your mod cause they can pick their own engine, we just might end up with a richer scene.

The even worse case is the fact that a lot of modders shy away from using extensions/dependencies at all because they do want their mod to run on as many engines as possible, and since a lot of popular engines dev's haven't even thought about supporting modder features (increased limits for mappers seem to be popular though), it's often not an option.



Now, what if there was a unified standard set of features for your engine to be considered cool? It'd break all sorts of barriers for modders and mappers. You wouldn't have to worry as much about which engines your mod works on, as long as you keep yourself inside the limits of the standard.

Some important notes:

• Very clear descriptions of features
  Example:
  Good: increase MAX_STATIC_ENTITIES to a minimum of 512
  Bad: increased limits
• Tutorials for required features if they don't exist would be very useful. I'm willing to chip in for bounties on this one (Spirit you inspirational you), I'd love to see others who are capable do so as well
• Standards should come in succession to eachother based on usefulness, and are dependent on eachother
  Example:
  Standard v1: could include lots of basic things like increased limits
  Standard v2: musn't be implemented without implementing v1 first, listing support for Standard v2 would assume v1 is also supported
• Some features will already exist in engines, but be somehow incompatible. To properly support a standard, the engine would need to be compatible with the way the feature is specified in the standard
• As you might have noticed, this is far from limited to extensions

I'd like all of you to start listing features you'd want to see in standards, keep them all coming, no matter how simple or advanced they might be, and please put some form of importance level next to the features, in order to more easily categorize which level of standard the feature would belong to. Try to be specific, but you don't have to. You can say "increased limits" just fine, the final standard would be specific, even if your suggestion isn't. If possible, motivate. If you're feeling really ambitious, try to think of problems which might occur from implementing the feature, and a solution to it.

Example of feature with a problem:
Feature: Stop entities sliding on top of eachother (able to stand on exploboxes and more).
Problem: Might break old mods which rely on this behavior in Quake.
Solution: Make the feature toggleably by cvar, default to off.

I would like to see a kind of board be formed for discussing which features to include in standards. So not only do I want you to list features, nominate people to the board!

Feel free to suggest a name for the standard

[Downsider]

• Very clear descriptions of features
  Example:
  Good: increase MAX_STATIC_ENTITIES to a minimum of 512

Oh God.. Fail..

Good article otherwise, but that just made me laugh.

[Urre]

I nominate LordHavoc, FrikaC and Spike.

'Glad to be an advocate of hilarity, Downsider.

[Downsider]

I nominate LordHavoc and Spike.

'Glad to be an advocate of hilarity, Downsider.

You don't understand why it's funny?

[FrikaC]

Italics make things funny.

[Downsider]

It's cause you said 512 is the minimum of the maximum allowed amount. It's not very specific, you just know it's >= 512. The other one just says limits increased. Which means you know it's >= 512.

They mean the same thing, neither is more specific than the other ;O

[Urre]

Not really. My guess would be that it's the maximum possible limit, which I'm not realizing because I don't code Quake engines. Possibly some form of language/grammar error I'm not seeing. If it's something along the lines of it not being specific because it's a minimum limit, then yeah it might be a little funny, as the modder might misinterpret it and use more than 512 static entities. Otherwise feel free to enlighten me!

EDIT: Huh? Wasn't the limit much lower? I recall 128.

[Downsider]

There's no minimum limit for entities, though.

Don't you see the irony in your mistake?

[Urre]

Wait, that's just weird logic. Don't you understand I meant increasing the limit of maximum allowed static entities?

[goldenboy]

Yup, this would be good to have.

For the mapping side, I think most modern engines support the "raised limits" bit sufficiently, Fitzquake finally did this with 0.85 and protocol 666. Unsure about mh's engine, Proquake, Joequake and Qrack. Tyrquake needs a kick in the nads here or be dropped from the list.

Basic csqc support is the next thing (Spike's win-csqc-quake as a blueprint).

After that, like you explained to me, monsterwalk and tracebox.

avelocity based rotation for eventual use of origin brushes a la Half-Life and Quake 2. AFAIK this already is in the engine, and a tutorial exists.

alpha.

Support for colored lighting (.lit files) of course.

Unified way to specify fog.

Sorry for being mostly unspecific, I stopped considering engines without support for higher map limits a while ago (ie, target engine is usually Fitzquake .85 in that regard, so that's kinda the expected level of raised limits) and I don't know enough about the details of the other features.

Standard name could be Quake Standard Base, inspired by Linux Standard Base (a standard for Linux distros to provide a basic set of features).

[LordHavoc]

What is needed is that one or more knowledgable modders/level designers work independently or together to write draft documents for capability extensions, different from normal extensions in QuakeC because they define entire sets of capability, ensuring compatibility as a whole with things that demand this capability subset.

After a draft proposal is written, it can be refined with feedback from the community, then written up as a technical document in final form and listed on a website like quaddicted, and then as each engine adds support for the capability, they can be added to that page's list of supporting engines.

Then level designers and modders can simply state "this requires URRE_MAPLIMITS_V1 - see www... for a list of engines that can run this."

[scar3crow]

alpha, colormod, frik_file come to mind immediately in terms of just being 'useful.'

But I think LordHavoc is on to something there.

[goldenboy]

Then level designers and modders can simply state "this requires URRE_MAPLIMITS_V1 - see www... for a list of engines that can run this."

This.

Please.

[Urre]

That is exactly what I meant

[Spirit]

What Downsider is trying to make fun of like a know-it-all 8th grader is probably that you said a "minimum of a maximum" while there could only be one value and that would be the maximum. You probably said minimum because you meant a common maximum of 512 would be a good minimum standard to see among engines. But hey, it is way moar lulz to post backseat remarks instead of simply correcting.

I love you for posting this topic, very good initiative.