New Age "Quake" Engines Specs

[Baker]

Many replies, not much time now, but a few things ...

tl;dr version: quake2. fteqw. We've had all these features for years but who's going to use them really? NOBODY.

It isn't always having a feature available, sometimes it is having a framework available. A kabillion PSP modders were attracted to the KurokQuake engine with an attempt to use the Half-Life format. Quoth attracted hordes of mappers; there are still Quoth mappers (JPL, for instance).

People map and model for Xonotic/Nexuiz/Open Arena ... all of which have documentation and a support community. Quoth had documentation.

Metlslime has always said most successful things have 1 degree of change. Quake id1 progs >> Quoth. Quake map format >> Half-Life map format.

The concept is take what people know and like to work with, extend it a little bit. Document it (DarkPlaces never had documentation, let alone a forum support community until the last few years.) Produce workable

As a super experienced person who actually does produce custom shit in quake I will have my opinion shared among this:

1. wrong. csqc requires beyond-engine coder expertise but for making custom huds in csqc, it isn't difficult at all. having partial csqc support JUST FOR THE VIEWPORT ALONE is enough for this.

A lite HUD scripting "language" or set of cvars would do something important: it would let the zillons of retexturer type of people that know little more than Photoshop independently play around.

There must have been 200 new skins for DarkPlaces posted at QuakeOne.com this summer, as an example. Make the barrier to entry for experimentation LOW.

10: complaint: ezquake's console is like a christmas tree in march. Tacky, without even being festive. A regular user shouldn't be expected to look at the console for anything other than chat/death messages.

I agree that ezQuake's console is tacky. Sometime I need to put more explanation into what I mean there.

Qwalk2 is going to have some features for easily and visually creating tags in existing MDLs (based on relative positions of existing vertices).

I didn't know you could do that.

If the NetQuake network code were to be rewritten, what would be included that wasn't before, what would be removed?

I'm not sure that NetQuake's code would be "rewritten", but more likely substituted with something existing (DPP7? QW? Something else?)

[Spike]

when I said network code, I meant the 8 or so net_ files which can be replaced with just one or two.

as an example, to find out which players are on the server, you must:
send a packet to find what the max is.
for each player slot:
send a packet asking for that slot's details.

This is absurd.
The same issue applies with querying the server rules.
Its stupid and slow.
Not only that, but the server using a different port for each client is braindead and breaks all NAT assumptions.
Sending a separate packet for reliables is also ugly, especially for mods that like to spam stuff like setangles.
Spawning a client from a single potentially-spoofed packet can also be problematic.
Resending the entire gamestate each frame is merely the icing on the cake, and while it would be nice if it supported proper deltas, it doesn't cause unmitigatable issues, really the only issue is with lots of pickups/corpses.
NQ players have played without prediction for years, its kinda one of the selling points of it. Adding prediction in a reliable way will result in physics changing, so I can't advise that for all, the other issues though... well, can there be any excuse for those? At all?

Q2 has a hud scripting thing. its kinda ugly, and fairly limited (scoreboards use it too). You can always write a hud scripting language in csqc. Its not hard, just a case of 'draw this here with this size'. But in qc programming language instead of parsing a string each frame, and because of that, it has the potential to be _much_ richer, and have proper animations and stuff.

Spirit: Open up FTE's bothdefs.h, find the line '//#define SQL'. Remove the two slashes. Recompile. There you have mysql support in a quake server. Requires mysqlclient.dll. You'd need to ask Timeserv for docs for it though.

[Baker]

Maybe there's something cool you can do with an in-game document viewer, I don't know.

My thought on the document viewer ... and it could be just a really simple one ... is easy encapsulation --- the concept that a total conversion + the engine contains the entirety of the experience. An example, some of the single player releases include text files or HTML and while this wouldn't be a substitute for HTML, the idea that a minimal set of documentation is included and available in-game. The help screen lmp files are too inflexible in most circumstances to really provide "help". I've made help screen .lmp files for some mini-mods I've made, while fun they are really far too limiting.

I know some people might think I am slightly insane [you'll get no argument from me --- sane just has never worked for me, seriously], but with a couple of hard pushes a moderately modified Quake engine plus maybe that Quake-oriented QER editor could be converted into a package for making a variety of different games including such things as RPGs.

And the ability to run those on Windows/Linux/OS X plus a variety of non-traditional platforms ... PSPs, Wiis, iPhones, Android OS ... I guess I'm saying ... why isn't there really super-platform independent open source development of scale? Well, there isn't today. I think just a couple of successful working mods that demonstrate the concept is possible is enough to start a snowball.

Look at the mini-snowball that Kurok created.

The vibe I got from Kurok: "How abouts trying to make a bit bigger snowball?"

[dreadlorde]

Which part of the "embbeded" you missed ?

I didn't miss it. Using a database would complicate things in so many ways. Flat files works fine.

[mankrip]

I'm making a MDL format extension that adds higher quality vertex coords to the end of the file, where they'll be ignored by engines that don't support them (they will just use the old crappier vertex coords).

qME 3.0 does this. If you figure out how the extra vertex data is stored in models edited with it, this may help a lot.

[mh]

Which part of the "embbeded" you missed ?

I didn't miss it. Using a database would complicate things in so many ways. Flat files works fine.

I think your own technical preferences and prejudices are causing you to completely miss the point here. I'm smelling a similar reaction to what you widely see among many (not all, thankfully) people who share those preferences and prejudices - anything that doesn't fit into a certain world view is automatically viewed with intense negativity, irrespective of it's merits elsewhere. No analysis is being performed.

A database engine has about a billion practical uses outside of just data storage, and there's absolutely no reason why the data storage mechanism can't remain as flat files that are read into the database during startup.

What kind of uses? Indexing, fast searches, sorts, joins, etc. Keep your edicts on the server in a database and do cool stuff with them - they never even go into any on-disk storage - it's in-memory all the way! Cvar and command storage. Visible edicts. Currently active players. Things that aren't read from disk, aren't written to disk, but do need a fast and flexible means of access to them. Try that with a flat file.

[frag.machine]

Which part of the "embbeded" you missed ?

I didn't miss it. Using a database would complicate things in so many ways. Flat files works fine.

Try to create a RPG with missions, experience trees, achievements and others using flat files. Good luck, you'll need it.

[Baker]

Rather than comment on the SQLite thing. Why is it that every funky idea out there ends up being something Spike says is an #ifdef in FTEQW

[Yeah, it's MySQL but still ..]

[Team Xlink]

Rather than comment on the SQLite thing. Why is it that every funky idea out there ends up being something Spike says is an #ifdef in FTEQW

[Yeah, it's MySQL but still ..]

I think its because FTEQW is a gold mine of hidden features.

[frag.machine]

Rather than comment on the SQLite thing. Why is it that every funky idea out there ends up being something Spike says is an #ifdef in FTEQW

[Yeah, it's MySQL but still ..]

Yup, I too have this feeling that Spike is always at least a couple steps ahead of us and every cool thing we could imagine is already implemented in FTE.

[Spike]

mysql is impractical for anything but dedicated servers.
sqlite requires much less configuration and is thus superior as a general integrated solution.
Its a define in FTE and not enabled by default, so there's no risk to databases on server computers that may be configured to not require passwords for connections from localhost, or whatever. sqlite would not have that problem.
FTE's implementation was written by Timeserv.
You can do a lot of things with a database.
But ultimately enough talk about databases/FTE - its going off topic.

[Sajt]

I'm making a MDL format extension that adds higher quality vertex coords to the end of the file, where they'll be ignored by engines that don't support them (they will just use the old crappier vertex coords).

qME 3.0 does this. If you figure out how the extra vertex data is stored in models edited with it, this may help a lot.

I do have the specs for the qme 3.0 extension. It has a lot more crap in it such as objects, but it doesn't seem to have higher-quality vertices. Anyway, it does have a unique identifier before the extra data, so loading a model with my extensions in qme 3.0 won't crap out.

My extension will simply have vertex coords stored as shorts with per-frame scale/bias, and normals stored in single 32-bit ints. And it will be extensible to more stuff in the future.

[dreadlorde]

Try to create a RPG with missions, experience trees, achievements and others using flat files. Good luck, you'll need it.

RPG != Quake. A large RPG (like WoW) would probably benefit from a database. Quake, isn't WoW though, and there are simpler ways of doing things for what Quake supposedly 'needs.'

[dreadlorde]

I think your own technical preferences and prejudices are causing you to completely miss the point here. I'm smelling a similar reaction to what you widely see among many (not all, thankfully) people who share those preferences and prejudices - anything that doesn't fit into a certain world view is automatically viewed with intense negativity, irrespective of it's merits elsewhere. No analysis is being performed.

No, I just didn't explain what I really meant enough.

A database engine has about a billion practical uses outside of just data storage, and there's absolutely no reason why the data storage mechanism can't remain as flat files that are read into the database during startup.

What kind of uses? Indexing, fast searches, sorts, joins, etc. Keep your edicts on the server in a database and do cool stuff with them - they never even go into any on-disk storage - it's in-memory all the way! Cvar and command storage. Visible edicts. Currently active players. Things that aren't read from disk, aren't written to disk, but do need a fast and flexible means of access to them. Try that with a flat file.

Isn't that all data, though? Not all data is stored on a disk (you even mention that).

The /proc filesystem on unix-like and plan 9 are example of flexible use of flat files; actually, they're not real files, they are just represented as files. When you do something like `cat /proc/$pid/fd`, the kernel gives you that information, that information isn't actually stored in a file for every process. The information is just represented as files as text because text streams are a universal interface.

Then again, I'm apart of the 'worse is better' camp.

[mh]

It depends on what you're trying to achieve. Sometimes the appropriate tool is a database engine, sometimes it's a text file, sometimes is a binary file, sometimes it's something like the Windows Registry, and sometimes it's something else.

My specific example of visible edicts could be well served by a database engine, primarily because they can be freely added to or removed from on a frame-by-frame basis and they need to be sorted on multiple different keys (model type, textures, translucency, distance) for efficient and correct rendering.

Just saying "worse is better" and closing one's mind to the possibilities means that you'll be forever stuck in 1972 here (and with severely limited skills, knowledge and experience to go with it). There are other tools available, and using the most appropriate tool for the job you want to do is what I believe in.