Quake Standards Base discussion

[Downsider]

Modern/casual gameplay design on Inside3D? Blasphemy.

[gnounc]

Modern/casual gameplay design on MY Inside3D?
More likely than you think.

[mh]

Where do skybox textures actually go? I've seen 12 places with (gamedir)\gfx\env being the one I assume is the "standard".

I gave up and just searched the entire gamedir for textures, not giving a damn where they were located. I didn't know about 12 different skybox locations, but even 3 (/env, /gfx, /gfx/env) is too much. Add in the fact that a skybox may or may not have an _ between the name and the suffix and the amount of searching and comparison you need to do is stupid.

YES to the DP standard for texture names. Almost nobody else uses it, but without it you'll break if you ever try to load a replacement for s_light in even shareware Quake!

(Just look in PAK0.PAK and see what I mean...)

Added:

Now that I think a little more about it, I would see external texture support as being optional. They belong in the same country as LIT files really, and they serve the same purpose - to replace content that a creator may have carefully crafted an intended look for with what might or might not be some bastardised version of it. (Even though some of them are very good indeed, they are not an essential feature for running a map.)

So I would vote for "optional but if you want to support them this is the way they should work".

[frag.machine]

I gave up and just searched the entire gamedir for textures, not giving a damn where they were located. I didn't know about 12 different skybox locations, but even 3 (/env, /gfx, /gfx/env) is too much. Add in the fact that a skybox may or may not have an _ between the name and the suffix and the amount of searching and comparison you need to do is stupid.

Have you gave up about the custom config file at the mod root dir telling where to find this kind of stuff ?

Now that I think a little more about it, I would see external texture support as being optional. They belong in the same country as LIT files really, and they serve the same purpose - to replace content that a creator may have carefully crafted an intended look for with what might or might not be some bastardised version of it. (Even though some of them are very good indeed, they are not an essential feature for running a map.)

So I would vote for "optional but if you want to support them this is the way they should work".

This "not essential" reasoning can be applied to a lot of stuff, not only .lit or external textures ("4096 units maps ought be enough to anyone" - Bill Gates ). And since both features are nothing new, are quite common and fit into the "90/10" Baker concept, I'd vote as required - and, if everyone else agree, let's use the Darkplace path/naming convention.

[mh]

Have you gave up about the custom config file at the mod root dir telling where to find this kind of stuff ?

More the case that I actually forgot about it!

This "not essential" reasoning can be applied to a lot of stuff, not only .lit or external textures ("4096 units maps ought be enough to anyone" - Bill Gates ). And since both features are nothing new, are quite common and fit into the "90/10" Baker concept, I'd vote as required - and, if everyone else agree, let's use the Darkplace path/naming convention.

OK. I'm not particularly religious about support being mandatory or not, either way. So long as the standard is reasonably sensible that's the most important thing.

I'd add my vote to the DP naming convention if it is mandatory however.

[Karatorian]

My interest in the QSB is a a modder. Specifically, my current project (still in the early stages) is a total conversion, with the planned end result being a game rather different than Quake. As such, the things that I really want out of an engine (at the moment) might not be quite the same as most peoples, but I figured my perspective could be helpful.

A lot of what matters to me is stuff that makes the engine more modern and generic.

Texture replacement is a feature I think I'll probably require. Even though I'm going to be using all original content, so I won't need the ability to retroactively change other people's stuff, I still think it'd be needed. This is because, AFAIK, the standard Quake data formats only support 8-bit color and I'd like to be able to use 24-bit textures. I suppose if other (more capable) data formats where supported, this wouldn't be an issue, but it looks like texture replacement is quite widely implemented, so that's probably the easiest route.

I haven't gotten far enough along to know if map limits are going to be an issue or not, but from the perspective of a TC developer, I support them in principle. The network protocol issue is a thorny one, but my current focus is on single player, so that is less of a concern to me.

Speaking of protocols, in general, I think the idea of changing coords and angles to floating point makes a lot of sense. Both the client and the server use floats internally, so the loss of range and precision for the sake of a few bytes in the network stack seems kinda outdated today. However, the argument for greater fixed point precision has merits as well. (In general, fixed point is cleaner and if I was writing my own engine from scratch, it'd probably be all fixed.)

The ability to use a more modern model format is appealing. While the difficulties of finding tools to work with mdl files (especially for Linux) is a factor, that's not the big issue. In my research, I've read that the compression used by mdl (8 bits per coord or something like that) makes it difficult to make quality models in the format.

I've noticed that md2 format is in the standard, but not md3 and this concerns me a bit. It seems to me that md3 is more commonly supported by tools. Furthermore, in the DP docs it says that md2 isn't supported for player models due to a lack of multiple skin support. If this cannot be worked around, it's a bit of a hassle.

It's convenient for a developer if they can standardize on individual formats. It makes the content pipeline much easier to implement. However, if md2 isn't suitable for player models (or anything else with multiple skins), then the only option (within QSB) is to use a mix of mdl and md2, or just use mdl. This negates much of the advantage of improved model support.

It's not that I have a specific attachment to md3. It's just that it seems that md2 has a lack of parity with mdl in the skins department, so it seems to be a poor choice of replacement.

Map improvements like lit files, skyboxes, fog, alpha, fullbright, transparent liquids, and rotation improvements would be nice to have. They allow for a game with a more modern feature set to be made. I don't know that I'd personally have much use for scale, but I can see how people would find it very useful to have.

New movetypes and improved physics (such as bug fixes) will make implementing gameplay easier. Control of physics from QC (ala DP) is really nice, but the issue of breaking prediction could make that impossible to incorporate into the standard.

One thing that's really needed for a total conversion is the ability to create one's own effects. The standard quake effects are rather specific to the game and aren't particularly useful for TCs. The only system I'm aware of for this is the one in DP, but I'm sure there are others and I have no idea as to what would be the best to standardize on.

The other thing a TC need is control over the hud and menus. Client Side QuakeC seems to be the best thing since sliced bread in this regard, but I'm not sure it's ready to be placed in the QSB. It's kinda immature at this point. AFAIK, there are only two implementations (FTE and DP) and they're not even mutually compatible.

The other development in this department is Menu QuakeC. This shouldn't be part of the standard. The reason is pretty simple, it seems to be completely undocumented. I haven't been able to find any docs on or mention of engines that support it (other than apparently DPs). Furthermore, with CSQC, is it even needed?

That said, if there are any features that make implementing this sort of thing possible server-side (as an alternative), I'd say they're very important.

Now that I've dropped my wish list, I'll say a bit about the standardization process. HTML is a good example to learn from.

In the early days, HTML basically standardized what was already common in the wild. This worked pretty well. Then the W3C changed their approach and things went downhill. They started to design things in a vacuum without listening to the browser developers (and to some extent, the web developers as well). As a result, the browser developers started to ignore the standards. This went on for years. The standard was irrelevant.

Then the HTML5 project was started. The (major) browser makers had the most pull. If they refused to implement something, then it didn't get into the standard. (A standard is only of any use if it gets implemented). In the case of the QSB, the engine developers are the ones with that pull.

I've been out of the scene for a while, so I don't really know what the dominate engines are these days, but a list of them and what they support (and are willing to support) would be very useful.

In the QuakeWorld scene, it seems like ezQuake has become the dominate engine. Reaching out to them would probably be a good idea. After all, if the dominate QW client doesn't eventually support the QSB, it will be another factor in the segmentation of the community, which seems antithetical to the goals of the QSB.

P.S. It's hard to say which thread this really belongs in. It's mostly a discussion of stuff that's in the standard or was already suggested, so it might go here. But I think a few feature requests slipped in, so it could go over there instead. Sorry if I got off-topic.

[Spike]

I'll agree that md3 is more useful than md2 (and mdl). From what I hear, md2 exporters are insanely buggy.

Regarding ezquake, if it still doesn't run NQ mods, then its a lost cause, at least as far as modding goes (mapping+texturing is still important).

menuqc is still needed even with csqc, as csqc only runs when on a server (though that could potentially be changed).
FTE also has a scriptable particle system, one that can have effects created via stuffcmds, otherwise DP's method to spawn specific named effects is the same as FTE's.

If you want to decide an html5-like standard with Quake, you have to decide which engines are the big players. Sadly this probably includes proquake. Which means you're up an inappropriately named creek when it comes to extensions (no (personal) offense Baker, but surely you see my point).

[Baker]

If you want to decide an html5-like standard with Quake, you have to decide which engines are the big players. Sadly this probably includes proquake. Which means you're up an inappropriately named creek when it comes to extensions (no (personal) offense Baker, but surely you see my point).

I think engines get shaped by important mod releases. As long as information on a certain feature is wide-spread and a tutorial or easy to extract prototype of a feature exists, I think new standards are fine even if every single engine doesn't support them.

ProQuake will eventually have extensions. RocketGuy has recently made a ProQuake 4.00 with EBFS and FrikFile to support some features he has in RQuake AND it has support for old "qccx hacks". After testing and when I get time to get that, it will be a standard part of ProQuake and the support for qccx hacks will probably be relegated to a command line parameter. There are only 5-6 mods that need qccx hacks, but well ... they are popular (RuneQuake, CRMOD, Clan Arena X, ...).

[dreadlorde]

Mediocrity finds safety in standards, though this 'standard' seems sane.

[Karatorian]

Regarding ezquake, if it still doesn't run NQ mods, then its a lost cause, at least as far as modding goes (mapping+texturing is still important).

It does run NQ mods, but support is still somewhat experimental and not really recommended. However, I still fail to see the point of your argument in this regard. Why is it that being mod-worthy requires NQ rather than QW? Is it just because most of the popular mods are NQ only? Or is it something deeper I'm not aware of?

I know that a lot of the NQ engines have added more modder friendly features, but from what I've seen the ez devs seem to be willing to push things forward. (This is just an estimate based on their current feature set, not personal interaction). So perhaps there's some hope in that department.

[Spike]

The NQ/QW split is one of near complete incompatibility regarding mods. You need to recompile the mod in order to get it to run in a QW engine, traditionally. Thus there is no reason to require that a standard among a group of engines require another group of engines which are incompatible to support it.
The door should be left open, yes. But not forced open.
Traditionally, mods have been made for NQ because QW engines are perceived as harder to mod for. It does not help that QW has no particle() builtin, cannot spawn ents based upon skill level, etc.

Like baker said, I think the solution is to go for things that have some tutorial somewhere stating what to change to support it, and to not worry too much if not every engine supports it (as that will never happen anyway, if people start using it, it becomes more likely).

[r00k]

Md3 should be an advertised avenue. Even if its available in a majority of engines, yet not all, there are tools available for conversion to .mdl(IDPO).

QW seems to be only geared to multiplayer and KTX has that wrapped up and not even on a .qc level. The thing about ezQuake's push is it's got a collective of college students adding this or that with no real direction to why. Whereas most other engines are coded by one person for personal reason or for a single general purpose.

My netQuake mods are featured for ProQuake clients, mainly because PQ is the common client/server for netQuake multiplayer players; due to CRMOD's poularity. Players are stuck with what they know works. Creating a new version of the same mod under FTE or DarkPlaces would be 10x with features, but getting the current userbase to jump ship is like asking everyone to start playing a would-be Source mod with the same gameplay.

I would also like to add a common network code with prediction could also be included as a standard for maybe QSB2.0. FTE and DP share DP7/QW support, so something along those line would benefit Qrack, ProQuake, or DirectQ. But thats more engine side than mod specific features.

ClanArenaX and CRCTF both could be ported to FTE/DP simultaneously if I just stopped working on my engine and convinced the current playerbase to use those clients instead of Proquake, which is like growing a tail.