Engine standards for mod compatibility

[Urre]

[goldenboy]

[Urre]

[goldenboy]

About external textures, and other external resources, the one thing that should probably be standardized in 1.0 is the location for these, ie standard paths.

So modders don't have to do any guesswork about where to put their sound files, textures, models, skins, conbacks and so forth.

Should resources like texture packs be loaded in a hierarchical order to avoid resource conflicts (alphabetical order or similar)?

What about file formats?

[Downsider]

[Chip]

[mh]

[frag.machine]

[avirox]

And now that I've uploaded a for it, how about rotating brush support as well? At least in its basic form, so mod-makers don't need to rely on the hackish hipnotic ents.

[ceriux]

[avirox]

[Baker]

[c0burn]

This is an excellent thread Urre - and the exact issue I ranted on IRC about a while back - I was going to post something similar myself but I'm a lazy bastard, so here we go now.

Personally, I think the community needs to come together and work together, on a new engine and a new set of tools to go along with it.

Mapping and the BSP format

As far as I'm concerned, Q1BSP mapping tools were perfected a long time ago and don't need any focus whatsoever. There are excellent mapping tools, compilers, vis and lighting tools already.

Modelling and Textures

I always feel iffy using stuff like TGA textures and MD3 models in mods - it's not "pure" and unless you're doing a total conversion stuff always looks out of place anyway, so it's a bit pointless. Just my 2 cents. If you want to use MD3, use Quake3.

Making Q1MDL files reliably is an absolute nightmare and something that needs to be addressed, in my opinion. Personally I generally make mods that fit into the Q1 universe so the limits of the MDL format do not generally bother me - just look at the excellent work in mods like Painkeep and Perquake. But of course, this isn't how everyone is using the Quake1 engine.

Along these lines, I would suggest if we're going to do a new engine standard we should also focus on adding, improving, extending and basically perfecting something like FrikaC's unreleased quake data formats editor/FIMG.

That is, an all in one "misc" formats editor

- MDL
- PAK
- LMP
- SPR
- whatever else i'm forgetting

I'm sure we've all wanted to stab ourselves after using Qme/exporting stuff to Q1MDL format/etc/etc. This is a must to me.

Network protocols

Why oh why oh why do people keep basing engines on NQ? Yes, testing mods in a single executable in lovely and convenient but in the long run, some nice multiplayer mods would be great. There's no reason we can't have QW server and client in a single executable (FTE and loads of others do it).

Some sort of modern network protocol with interpolation and prediction is a must, or I simply wouldn't want to mod for it.

QuakeC

An IDE would be nice. I'm sure we all have our own homebrew solutions. There have been IDE's in the past I vaguely recall, but they were all shite. Hell, even picking a free multiplatform editor that supports external syntax definitions would be great.

CSQC

It's nice, but it's a big job, and imo in its current form is an undocumented mess that doesn't even have nice compatibility for csprogs.dat between Darkplaces and FTE. This kinda rubbish needs knocking on the head if we want to get anywhere.

Personally, although CSQC is nice, I always thought adding a few builtins to draw a hud in SSQC would have suited 99% of my needs. I couldn't care less about making smoke client side and stuff like that - but that's just me.

Misc stuff

Pruning of all unused/gameplay changing/cheaty client side cvars - or forcing their values via QuakeC - I don't want to see any stupid QW crap with white walls and solid colour players.

Darkplaces menu.dat is nice but I always thought an XML file with things like "slider" "button" definitions that was parsed by the engine would have led to less headaches. On this topic, if you're going to add features, add a fucking menu option with appropriate options. And can we make mouse support standard in the menu? It's 2009.

This post is probably a mess but I got most of it out, I guess.

[r00k]

Joystick support for remote controlled robots.

[Spike]

Each time I read this topic, I think 'well what has this got to do with engine standards regarding mod compatibility'.

If you want to argue about QuakeC IDEs for instance, create a new thread instead.

Any engine standard shouldn't state that there must be dedicated servers, dedicated clients, or that there cannot be either.
It should not dictate the network protocol other than that a given extended protocol must be supported for demo compatibility only. A non-networked (flash?) engine needn't have a network protocol at all.
It would be nice if all engines could network together. In fact, any standard should specify builtins and fields, not SVCs and TEs.

csqc standardisation? would be nice, but it needs to mature still. don't specify that it need be supported yet. There's a doc that specifies the behaviour of each field and builtin on fte's svn. As far as I'm aware, FTE matches it exactly.
But more interestingly, would you prefer q2-esque hud-script support?

a mouse controlled menu has nothing to do with mod compatibility unless the mod has direct control over the menu - in which case you're asking for something else or far more.

Stating that an engine must have ARB multitexture instead of legacy multitexture is ironic - ARB multitexture is legacy since it is core. If you really want to get rid of legacy features, you should be using OpenGL multitexture... But that's me being pedantic.
Any standard should not say the method used to achieve a goal, only how the method is used to achieve a desired effect. That is, it should state that you need a .lit file for coloured lighting. Not that the lighting must be done with multitexture. I don't see the standard mentioning requiring Combiners to do fullbrights and detail textures.

changing resolution on the fly is a personal preference thing, and has nothing to do with mods. If a QC mod ever changes my video resolution/vsync/etc, I will not be happy (unless its a menu and the new values are completely under the user's control).

'stupid QW crap' can be done in NQ engines too. Just change your player model's texture to a single colour in the last 32 pixel values in the palette, probably a yellow. Easy, at least if you have an editor. 'cheaty client cvars' just make the process easy for all, not just the people who will use any and all cheats. White walls? really depends upon your choice of retexturing set. Those cvars provide nothing new, they only simplify their use for people who are not accustomed to hacking their entire quake install just to win a couple more games.
Frankly, if you removed those easy settings from the engines that support them, you would find the users switch to a different client that does support them (or just stay with an older version).
Any standard with any chance of adoption should not specify features which may not be supported. Sorry, but if the engine was your engine, why would you need an actual standard for your mod in the first place.

Any standard for mod compatibility should not fully mandate what is supported, nor how it is supported. Only how it is activated or used if it is supported.
Knowing that the engine will use your fog if it is supported is far more useful than knowing it supports fog without knowing how its switched on. Different engines activate fog in different ways. But they must all support activating fog using the same mechanism. Either a worldspawn key or qc+stuffcmd. If so, what's it called, does it scale from 0-1 or 0-255, the ordering, count, and the defaults of the fog's settings.

If the standard says 'must support tga replacement textures' then the standard is useless. If the standard says 'must support version X and mode XYZ tgas with correct interpretation of the bottom-up flag as replacement textures stored with name blah/blah.tga' then the standard becomes a hell of a lot more useful.
It is actually quite hard to put in all the words to fully specify a standard. In all honesty, without an example mod/map that tests each requirement, such a standard will not be widely supported and thus not widely usable. With regards to mapping, Don't forget QW clients in the example mod/map. They've a slightly greater following, in europe, anyway, and you don't really want two standards.

Mneh, you get the idea, and I apologize if anyone takes personal offence, none is intended. But please stay on topic.