Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Engine standards for mod compatibility Goto page 1, 2, 3 ... 14, 15, 16 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Dec 30, 2009 10:24 pm Post subject: Engine standards for mod compatibility |

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
_________________
Look out for Twigboy
Last edited by Urre on Wed Dec 30, 2009 11:03 pm; edited 1 time in total

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Wed Dec 30, 2009 10:29 pm Post subject: Re: Engine standards for mod compatibility |

Urre wrote:

- 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.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Dec 30, 2009 10:32 pm Post subject: |

I nominate LordHavoc, FrikaC and Spike. 'Glad to be an advocate of hilarity, Downsider. _________________ Look out for Twigboy Last edited by Urre on Wed Dec 30, 2009 10:49 pm; edited 1 time in total

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Wed Dec 30, 2009 10:41 pm Post subject: |

Urre wrote:
I nominate LordHavoc and Spike. 'Glad to be an advocate of hilarity, Downsider.

You don't understand why it's funny?

Back to top |

FrikaC Site Admin Joined: 08 Oct 2004 Posts: 947 |

Posted: Wed Dec 30, 2009 10:44 pm Post subject: |

Italics make things funny.

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Wed Dec 30, 2009 10:47 pm Post subject: |

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

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Dec 30, 2009 10:48 pm Post subject: |

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.
_________________
Look out for Twigboy
Last edited by Urre on Wed Dec 30, 2009 10:52 pm; edited 1 time in total

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 478 |

Posted: Wed Dec 30, 2009 10:51 pm Post subject: |

There's no minimum limit for entities, though. Don't you see the irony in your mistake?

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Dec 30, 2009 10:56 pm Post subject: |

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

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Wed Dec 30, 2009 10:58 pm Post subject: |

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).
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

LordHavoc Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA |

Posted: Wed Dec 30, 2009 11:04 pm Post subject: |

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."

Back to top |

scar3crow Inside3D Staff Joined: 18 Jan 2005 Posts: 837 Location: Las Vegas, NV

Posted: Wed Dec 30, 2009 11:07 pm Post subject: |

alpha, colormod, frik_file come to mind immediately in terms of just being 'useful.' But I think LordHavoc is on to something there. _________________ ...and all around me was the chaos of battle and the reek of running blood.... and for the first time in my life I knew true happiness.

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Wed Dec 30, 2009 11:08 pm Post subject: |

LordHavoc wrote:
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.
_________________
ReMakeQuake
The Realm of Blog Magic

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Wed Dec 30, 2009 11:13 pm Post subject: |

That is exactly what I meant _________________ Look out for Twigboy

Back to top |

Spirit Joined: 20 Nov 2004 Posts: 476 |

Posted: Wed Dec 30, 2009 11:18 pm Post subject: |

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.
_________________
Quake Maps

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> General Discussion | All times are GMT Goto page 1, 2, 3 ... 14, 15, 16 Next
Page 1 of 16

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group