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

Help... Quake music without CDs Goto page Previous 1, 2, 3 Next

| Inside3d Forums Forum Index -> General Discussion

View previous topic :: View next topic
Author | Message
--- | ---
neg!ke Guest |

Posted: Wed Nov 14, 2007 9:06 am Post subject: |

leileilol wrote:
pix or it didn't happen

http://speeds.quaddicted.com/q1light.jpg

Sajt wrote:
higher mapper limits

Some of them apparently, but the most important ones (in my view) are still standard.

Back to top |

Baker Joined: 14 Mar 2006 Posts: 1538 |

Posted: Tue Dec 04, 2007 1:29 pm Post subject: |

scar3crow wrote:
Nash - It uses a terrible form of "security" that servers seem to think does a damn thing, and others have adopted it, leading to clients perpetuating horrible and ineffective code that simultaneously divides.

Several months ago, I managed to persuade almost every server operator to remove ProQuake "cheat-free" because of that.
I didn't tell anyone except LordHavoc because I didn't want some reactionary player contacting the operator to have it back on or some forum argument erupting
Only 1 cheat-free server remains of any significance. But players don't have any control of what a server operator does.
Aside from that, there really isn't a good reason to hate any engine.
The ideas in several different engines have really contributed to a diverse pool of ideas in the collective Quake DNA.
Although you may not realize it, aside from the above and arguably about how it encouraged mods to use QCCX'd QuakeC (which was necessary in the day because things had to run with unmodified winquake.exe), ProQuake has some very nice bug-fixes in it and subtle improvements that have found their ways into a lot of different engines.
It's not DarkPlaces or FTE, but most of the divisive stuff in Quake is inherited due to Quake's rather fast decline back in the day that left many projects as virtually abandoned (Team Fortress, ProQuake, etc.) with players forced to play with whatever that unplanned state of things was.

Back to top |

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

Posted: Tue Dec 04, 2007 3:57 pm Post subject: |

ProQuake was definitely not 'back in the day'

Back to top |

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

Posted: Tue Dec 04, 2007 4:00 pm Post subject: |

It really is sad that QSG more or less died. It's also sad that QSG didn't handle anything else than new builtins. If you ask me, those are secondary to bugfixes and other modernisation features (not including prettyness things). This because those things apply more to the players than extensions do. Extensions are for modders, as they mostly include builtins, or just to describe certain supported features like new map/model formats.
Admittedly, bugfixes and other features (like higher precision angles and origins) should have been part of the extensions system, not just builtins. A few were, but the point of a standards-group is that as much as possible should be standardized.
But that brings us to the problem that is if all things were standardized, why even bother making new engines? If you follow the standards, there would be very little difference between the engines. Or, the more likely situation, which is that the most popular engine rules, and others have to fall in line. That's what's going on in the world of web-browsers. The browser that's most popular rules, no matter the standards, which the popular browser in question doesn't follow as well as it should.
_________________
Look out for Twigboy

Back to top |

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

Posted: Tue Dec 04, 2007 4:31 pm Post subject: |

The point of the QSG as it was originally conceived was to prevent one mod or map to one engine. This was a two part concern: 1. Engine authors would go nuts making a bunch of new features that wouldn't cooperate with other engines - even though they are more or less functionally identical, therefore map and mod authors would be forced to choose an engine for their map or mod and it would only run on that. It's bad for map/mod authors because portability of some engines was compromised (especially in the era of fmod and such).
2. Engine authors would make custom mods only for their engines (See Tenebrae, Fiend Hunter) and those would be the only mods that could run in the engine. Not much of a concern - and that's perfectly acceptable for TCs and such, but it would be nice if there's a way to remain compatible with the huge amount of existing Quake content and still write new features and make mods/maps that make use of them.
Thus the original QSG plan was to develop a series of highly compatible baseline features that extend the engine or fix various bugs. This would've been QSG level 1, as a baseline it could be asked for by mod authors and supported by engine coders to make everything all nice and compatible. It was entirely an option for engine authors to adopt, but hopefully the clamor would be such that it would get implemented broadly. There was also a QSG Level 0, indicating base Quake compatibility. Future revisions of the standard would up the number.
The Tomaz/LordHavoc extension system ultimately was a much better plan that came much later and it actually better accomplishes the two goals above.
Under both systems, the engine authors were free to implement whatever they wanted. In the case of the old Level idea, it demanded a core set of fixes and features and the ability to ignore extended information given to it (in the case of network protocol and bsp and such), with a standard format for the extended information. On top of this framework, engine authors could build what they liked.
Again, the extension system is better, but perhaps less comprehensive than the original QSG Level 1 scheme. It's not meant to be like web browsers, as the featuresets of each engine were meant to be variable wildly on top of a set of core fixes and compatibility enhancements. The extensions system allows more variability in what features the engines support while maintaining the idea of common interfaces, but really they could've been used together - level 1 could've had the extension system in it if we had any brains and had that idea when we were planning all of this.
We were fully aware of the "One engine rules" concept, but the QSG was never meant to standardize EVERYTHING to the point of where an engine was merely a bag of our standards. It was all about interfaces and compatibility.

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Tue Dec 04, 2007 8:41 pm Post subject: |

Getting a bit off topic... but I never cared for topics anyway. :P I personally only appeared online when I went to uni, so missed all the QSG stuff. Very rarly went online. :) checkextension is nice and all, and allows engines to implement new features that they choose... But compared to a baseline set of extensions/bugfixes it is ultimatly more complicated. With the qsg system Frikac described, you encourage engines to support the same set of features, which is good for modders certainly, as it means that modders are more able to focus upon that specific subset.
With the checkextension system, modders have to pick and choose which subset to use, and its harder to explain to an end user which engines can be used.
Although with the reduced number of active engines nowadays, most of this is moot. A mod can check which extensions are available if it so chooses, but chances are, the mod will be only run on at most 3 engines (that the mod author hears about).
There's a quote that I'm rather fond of:
The great thing about standards is that there are so many to choose from.
As far as my experience with the actual 'QSG', the only engine I know of which actually advertises anything to do with qsg is quakeforge, which has some quakeworld protocol extensions. No other quakeworld engine has those same protocol extensions (not even fte). I'm biased with when I appeared on the scene, but my entire perception of the actual QSG group is 'those people from quakeforge'.
Ultimatly its the modders that choose what becomes standard, as a result of the players needing those extensions to run their mods. Or of the players, who choose mods (and thus engines) based on cool features.
Unfortunatly, quakeworld is more player-based where the players choose an engine with high framerates and low latency and only play on the servers within 28 milliseconds of themselves, and where all mods all mimic the exact same feature set anyway.
QSG was a single group of engine modders. Engine modders specifying what is to be standard in all engines is... well, wrong. It should be the gamer that ultimatly chooses which engine to use. Some mods may restrict the choice, but if the mod correctly queries extensions, then other engines are perfectly free to implement those extensions.
The QSG system sounds nice, but Tomaz/LordHavoc's system is ultimatly better, imho.
Urre, if you want to come up with a cross-engine standard, there is absolutly nothing stopping you from specifying one (presumably on the quake wiki). If it isn't too hard to implement missing features, and they do not conflict with anything else, I'm sure they'll end up in FTE. Eventually.

Quote:
Or, the more likely situation, which is that the most popular engine rules, and others have to fall in line.

Consider FTE, compared to DP (note which one supports the other's extensions). Consider FTE compared to mvdsv (note which one supports the other's extensions). Consider FTE compared to ezquake (this is the only situation with significant (feature) cross-copying that I can actually think of). I'm clearly doing something wrong. :P
Standards are good, but don't standardise for the sake of standardisation, for this can get far far far far too complex.
_________________
What's a signature?

Back to top |

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

Posted: Tue Dec 04, 2007 9:29 pm Post subject: |

Thought the extension system was work of the QSG, kudos to Tomaz and LordHavoc then. Ultimately, it does feel like the extension system did work out very well. Lots of engines incorporate lots of various extensions and share extensions between eachother, and even implementation differs sometimes, which is cool as long as the result is as expected. My point was though, that a lot of features that are essential for certain mods aren't defined by any standards. Some engines incorporate changes to existing things which are perfectly compatible with Quake and (most) old mods, but you can use them in ways that were not possible before. To pick something from the top of my head, DarkPlaces lets intersecting solids move out of eachother. Quake did not, it made them stuck inside eachother, unable to move. I love the new behaviour, if you remove the telefrag code from your mod, you can make use of this great new feature. It did however break an old mod of mine, which contained a sort of grenade whose explosion was a mucus blob, which made you immobilized if you were in its radius, because it did a setsize on the mucus model ontop of yourself. Let's not go into the obviousness of how it could be better designed to work with the new DP feature and whatnot. Imagine instead if it was an old mod, which people liked to play every now and then. It would now be broken in DP, because it (to my knowledge) is not toggleable, nor does it say anywhere that this feature exists. Should a change such as this be part of the extensions system, or something else? Should one care? I know LH would, he tends to put compatibility first. (NOTE: I'm not saying that this should be "fixed", I love the way it works now).
Personally, I've come to believe that it really *is* better with the mod-per-engine deal. I do however not mean that everyone who makes a mod should make their own engine, but rather that people who make engines meant for modding (DarkPlaces, Telejano, Vengeance, FTE and more) shouldn't care about making their engines compatible with anything. They should just construct their engines with the goal of being good for modders, be it in the easy and fun way, or the feature-complete way. This because many mods are made this way nowadays anyway. Ever heard someone say "DP mod"? A mod like this could certainly be made to check extensions and work differently if not found or whatever. But most people don't seem to have the patience or time to do this, since they could just as well tell people that a certain engine is required, since it's accepted. Sometimes people refuse to play if they don't like the engine in question, but mostly they can overlook those kinds of things because of the simple fact that the mod was designed with this engine in mind, so it will have a consistent feel, which makes it okay even if you might not use the engine otherwise.
This would obviously not stop compatible engines from existing, as there is a place for them as well. People will want these as well, to get the most out of their Quake. Fitz is a very good example of an engine with a good balance between improvements and features and compatibility. But it doesn't provide very much features for modding, only a few basic ones, so to me it's a true "improved" Quake engine. Beasts like DarkPlaces or FTE are more like indecisive masters of everything, which generally speaking fail a little at everything. Most people don't like using them as their regular Quake engine since they feel so different. But they're also tough on modders because of the feature creep and the limitations of compatibility. I've heard DarkPlaces is close to impossible to maintain mainly due to the compatibility. Implementing new features constantly has to take good ol' Quake in mind. Now I'm gonna say something I'm not allowed to say, but if Tenebrae didn't suck so much, and if the author was more clear about his intentions with the engine, it would have been a good engine. Why? Because it wasn't compatible, it had its own feature set which it followed blindly. Thus it was popular, both for modders and players. It didn't suffer even close to as much from all the problems the "cool" engines of today do.
Just my thoughts
EDIT: *notices Spike posted as he was writing his post, reads...*
Yeah I figured my previous post would come across as such, that I support standardisation, which I don't, cause it will never work in the end, unless it's a closed group making the standards whos decisions can't be affected. That on the other hand works against the idea of a community. Not even OpenGL is free from this problem, both ATI and Nvidia make up their own extensions to show off new features and whatnot, and sometimes developers even end up using those. And if the game is popular, the opposing brands cards will be voted "crappy" cause they don't support the new features.
_________________
Look out for Twigboy

Back to top |

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

Posted: Tue Dec 04, 2007 11:27 pm Post subject: |

Spike wrote:
As far as my experience with the actual 'QSG', the only engine I know of which actually advertises anything to do with qsg is quakeforge, which has some quakeworld protocol extensions.

There was a big misunderstanding with the QuakeForge people, the original idea is they'd supply the reference implementations of whatever the standards were, but they also wanted to dictate what the standards were. I don't think that argument ended amicably.

Quote:
QSG was a single group of engine modders. Engine modders specifying what is to be standard in all engines is... well, wrong.

Standards are not for the heck of it, or something a 'single group of engine modders' dreamt up, but rather it was an attempt to put a leash on the chaos - to prevent 9000 different ways of doing the same thing.
Basically the original idea was for to people to go off and fix things and make improvements on their own, and those fixes and improvements from various projects would be submitted to the QSG if the authors thought it was a good idea for everyone to have. Then we'd have an open discussion about the changes. If the change is highly compatible, aids interoperability and is simple and light, then it would be standardized. If significant objections raised, it would be held off. The closest to a QSG like thing was Maddes's QIP engine.
Also the QSG wasn't a group of engine modders. It was a web guy, me and Ender. I tried to get LordHavoc in on it, but he ended up joining QuakeForge.

Back to top |

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

Posted: Tue Dec 04, 2007 11:37 pm Post subject: |

Urre wrote:
Personally, I've come to believe that it really *is* better with the mod-per-engine deal. I do however not mean that everyone who makes a mod should make their own engine

There was an assumption, perhaps naive, that no one would write a good "modder engine", and for a while there it was looking like it wouldn't happen ever.
Generally people are selfish and they work for their own benefit. It was assumed that greedier coders would be making "super realtime lighting Quake" and it would only run their own "super realtime lighting mod", okay it's a bad example because it already happened.
QSG compatability was meant to be a bullet point that people could add to their engine feature list. People love feature lists, thus a selfish way to get interoperability.

Back to top |

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

Posted: Wed Dec 05, 2007 4:55 am Post subject: |

FrikaC wrote:
1. Engine authors would go nuts making a bunch of new features that wouldn't cooperate with other engines - even though they are more or less functionally identical, therefore map and mod authors would be forced to choose an engine for their map or mod and it would only run on that. It's bad for map/mod authors because portability of some engines was compromised (especially in the era of fmod and such).

A far better example is mvdsv (most popular quakeworld server), its primary feature is being able to record multiplayer demos (which is actually *very* easy, just dump every outgoing game packet to a file, something that should just be an extension to define a common file format).
mvdvsv's other features are several completely non-standard QuakeC builtin numbers (which conflict with such lovely things as FRIK_FILE), primarily dealing with string buffer functions (yes, it is completely vulnerable to overflow buffers in QC in mvdsv with these functions).
mvdsv is also full of exploitable bugs - you can even crash an mvdsv server at will with a DP client by issuing a moderately long setinfo command (mvdsv only has the stock qwsv limit of 96 bytes of setinfo space, and no buffer overflow checks/prevention) - admins ALWAYS run it in a chroot jail with nobody or similar for this reason.
To deal with the fact that almost every qw mod is written exclusively for mvdsv, the FTE QW server actually detects whether a mod was written for mvdsv or the extension system, and uses different builtin renumbering accordingly - a perfect example of what standards are supposed to prevent.

FrikaC wrote:
2. Engine authors would make custom mods only for their engines (See Tenebrae, Fiend Hunter) and those would be the only mods that could run in the engine. Not much of a concern - and that's perfectly acceptable for TCs and such, but it would be nice if there's a way to remain compatible with the huge amount of existing Quake content and still write new features and make mods/maps that make use of them.

I think Nehahra is the most famous example of this, and its engine did not follow QSG standards, despite being written by the self-proclaimed leader of the QSG (Ender), and containing a horrible network protocol that was calling itself QSG level 1 (example: it wrote three additional floats per entity, just to add a fullbright flag and alpha value - that's 12 bytes extra on entities that are usually only 12 bytes to begin with - a fast path to "packet overflow" warnings).
Although due to my involvement the network protocol changed to QUAKEDP (which had already existed by this point) in the Nehahra engine for multiplayer purposes (the Nehahra cinematics are still in the weird QSG format).

FrikaC wrote:
Thus the original QSG plan was to develop a series of highly compatible baseline features that extend the engine or fix various bugs. This would've been QSG level 1, as a baseline it could be asked for by mod authors and supported by engine coders to make everything all nice and compatible. It was entirely an option for engine authors to adopt, but hopefully the clamor would be such that it would get implemented broadly. There was also a QSG Level 0, indicating base Quake compatibility. Future revisions of the standard would up the number.

Ender tasked me with writing the QSG extension system, and asked to use one of my numbers for checkextension (#99 - at this point I owned the range #90-99, before getting #400 and #500 ranges).

FrikaC wrote:
The Tomaz/LordHavoc extension system ultimately was a much better plan that came much later and it actually better accomplishes the two goals above.

There's an interesting story behind this, full of deception and intrigue - ok, just a little.
I was using the QSG extension system by the time Nehahra was done, but QSG had such a rotten reputation by this point that I felt there would be no chance of widespread adoption of the extension system if it had the QSG name attached, so I renamed the cvar from qsg_version 1 (or whatever it was called) to pr_checkextension...
At the time TomazQuake (which was just a graphical effects engine at the time, with no modding features) was the most popular engine, and I knew that for this to have any success it would have to be supported by TomazQuake.
So I convinced Tomaz to implement this system, and call it co-authored by both of us - he wanted to just credit it to me, but for it to be a standard I knew it had to look like a community effort.
A year or two later the QSG started referring to the pr_checkextension system as the QSG extension system, a fact that still offends me to this day, as the entire point of the pr_checkextension system was to remove all QSG involvement in this component, due to gross incompetence on the part of the QSG organization.

FrikaC wrote:
Under both systems, the engine authors were free to implement whatever they wanted. In the case of the old Level idea, it demanded a core set of fixes and features and the ability to ignore extended information given to it (in the case of network protocol and bsp and such), with a standard format for the extended information. On top of this framework, engine authors could build what they liked.

Such a system is comparable to Direct3D, where all possible features for a given version of the Direct3D API are decided before its release, and then the vendors (hardware in Direct3D's case, quake engine coders in QSG's case) implement support for this API, with each feature being optional (capability flags, or "caps" as D3D calls them).
Such a system works only as well as the organization designing the versions, since QSG was grossly incompetent at the time (arguably still is), I saw no future in this approach.
Additionally, extensions are more friendly to engine coders - if an engine coder can't convince the QSG review board to add a feature to the next QSG level, that feature can not be implemented, or is implemented as a non-standard feature which is countrary to the entire idea of standards.

FrikaC wrote:
Again, the extension system is better, but perhaps less comprehensive than the original QSG Level 1 scheme. It's not meant to be like web browsers, as the featuresets of each engine were meant to be variable wildly on top of a set of core fixes and compatibility enhancements. The extensions system allows more variability in what features the engines support while maintaining the idea of common interfaces, but really they could've been used together - level 1 could've had the extension system in it if we had any brains and had that idea when we were planning all of this.

QSG levels are nothing but meta-extensions, anyone can write up meta-extension specs and start advertising them and get them adopted by the other engine developers.

FrikaC wrote:
We were fully aware of the "One engine rules" concept, but the QSG was never meant to standardize EVERYTHING to the point of where an engine was merely a bag of our standards. It was all about interfaces and compatibility.

I never saw the point of the QSG organization itself, it was meant to be composed of engine developers, collaborating on standards specifications - this is ironic considering how frequently engine developers chat with eachother without the need of an organization already.
And the only big engine project at the time was QuakeForge, who wanted to have nothing to do with the QSG, figuring that they were the leaders and all other engines were pointless. (A concept I rejected from the outset)
Meanwhile I simply worked on my DarkPlaces engine for modders, and had no interest in the politics of the QSG or QuakeForge, I saw more value in getting to know the other independent engine programmers than in conforming to any organization.
I argued with Ender that there wasn't a need for lots of engines, simply one really good one and a few experimental research engines (such as NPRQuake, Tenebrae, FisheyeQuake/PanQuake, etc), I chose to lead the way on this with DarkPlaces.

Back to top |

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

Posted: Wed Dec 05, 2007 5:18 am Post subject: |

FrikaC wrote:
Also the QSG wasn't a group of engine modders. It was a web guy, me and Ender. I tried to get LordHavoc in on it, but he ended up joining QuakeForge.

If I recall correctly I kind of scoffed at the entire idea of the QSG, and then didn't see any significant leadership abilities on Ender's part, so I didn't join.
My joining QuakeForge had nothing to do with the QSG - I only joined QuakeForge because I met knghtbrd on IRC and he explained that he was trying to turn QuakeForge into an efficient and minimalist engine with graphical features that users would like, without destroying framerate (which most other engines were doing at the time) - to this end I proceeded to port DarkPlaces features over to QuakeForge to improve its (abysmal) framerates and make it look better.
When knghtbrd was kicked out of QuakeForge (by the other developers who didn't agree with his vision) I went to his new Twilight Project which was dedicated to his vision of a fast, efficient, pretty, and user-friendly engine with just the right features.
Meanwhile I never ceased working on DarkPlaces, I only contributed to these other projects.
I think knghtbrd had the right idea, a user-friendly and pretty engine with pretty good framerates, as demonstrated by the success of TomazQuake for singleplayer and ezQuake for QW.

Back to top |

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

Posted: Wed Dec 05, 2007 5:19 am Post subject: |

FrikaC wrote:
Generally people are selfish and they work for their own benefit.

It is both comforting and somewhat amusing that the QSG were wrong about the goals of Quake engine coders

Back to top |

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

Posted: Wed Dec 05, 2007 10:25 am Post subject: |

Very interesting readings, certainly, this off-topickery. Forgot to mention, but I think there's only two mods who really care about the checkextension system, Conquest and Prydon Gate. Even though very cool mods, doesn't that count as a failure? There are lots of mods that use all kinds of new features, without checking for the extension. In practice that becomes just using an engine of the modders choice.
On the opposite side, mappers often say that their new map only works in a certain engine, whereas in truth the map may also work in others. To be more specific, the hacky upped limits in arguires engine are incorporated in DP as well, unsure about FTE. Mappers say this either because they don't know, or because they don't like the way their map looks in a different engine. Often both. I'm not sure what to think about things such as this. I'm more leaning towards standardized approaches for these things, since it's not very special things they're up to, just increased limits, so why not let all engines take part of this map? Dunno...
_________________
Look out for Twigboy

Back to top |

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

Posted: Wed Dec 05, 2007 10:10 pm Post subject: |

LordHavoc wrote:

FrikaC wrote:
Generally people are selfish and they work for their own benefit.

It is both comforting and somewhat amusing that the QSG were wrong about the goals of Quake engine coders

Maybe. Remember that army of engine coders that arrived with the release of the Q1 source and departed with the release of the Q2 source? I don't think they had any community oriented motivations.
Also, I'm insulted that you think I'm incompetent.

Back to top |

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

Posted: Wed Dec 05, 2007 10:20 pm Post subject: |

LordHavoc wrote:
QSG levels are nothing but meta-extensions, anyone can write up meta-extension specs and start advertising them and get them adopted by the other engine developers.

My goal in the early days, when we were discussing QSG level 1, was to make it completely about compatibility - and I was hoping they'd hold true to that. I didn't want to add features that a software engine couldn't easily implement.
From original concept which I had laid out in the QSML "A call for standards" mail and private chats, QSG would've been awesome. I blame others for its failure.

Back to top |

Display posts from previous:

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

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