-classic/-fancy sounds fine to me, assuming other engines also adopt this

However I think a profile selector in the menu would be more useful to people who don't read the readme (a lot of people seem to ignore the readme already). 

Yeap, on this system it is an ATI Rage Pro. You make a very convinving argument.

I really should switch up the GeForce 4 MX that I have on my crapped out machine someday, except it is at my brother's and we have been playing a game of 'who'll blink first' and expend a half a tank of gas to visit the other. 

With gas prices how they are, sometimes it costs less to buy a new card than to visit a relative, scary isn't it :) 

I think I finally understand the reasons for the friction there has been for so long between the coders and mappers of the quake community. It's all down to different ways of loving quake.

The mappers, here and elsewhere, love quake for it's art design, it's gameplay and immersion. They love quake as it is and always has been, as id intended. They build new levels in fitting with it's style, to try to extend the quake experience, all fitting within the quake world. If they didn't love quake for these reasons, then many of the mappers here would leave and take their considerable skills elsewhere in the modding community, moving on to pastures new as it were.

The coders over on quakesrc.org and elsewhere mostly love quake for a different reason. They see quake as a blank slate, an open source engine on which to experiment and build their dreams. For them, and many of the QC coders on inside3d and #qc, quake is a modder's dream, a plaform to build from. Most are happiest using quake to develop new games that are wildly different from the original. It is the moddability and open source nature of quake that they love, the endless opertunities it presents. The original art design matters far less to them, it's modability that matters.

There is a clear difference of opinion. Both sides love quake, but for different reasons. Neither is wrong, it's just a case of looking at it differently.

Stuck somewhere between these camps is LordHavoc and a few others. They have the same love of quake's style and design that drives the mappers, but also the desire for modernisation of the coding camp. This leads to DarkPlaces, which as LordHavoc has said before now is an attempt to capture the feel of Quake in a modern engine. He also builds it as a platform for modders to work on, adding many new QC features for people to be able to use it to develop new games based off it.

Darkplaces is faithful to quake, not to the pixel, but to the spirit.

Perhaps I've over-simplified, perhaps I've over-generalised. This is only my view of the situation.

I know this is perhaps slightly off topic, but I think it's important that everyone understand each other's viewpoint. We all love quake, just in different ways. 

I have posted a new darkplaces beta which includes mac binaries. (agl+coreaudio and dedicated server, could not get sdl version to build on my friend's mac, libstdc++ linking problems - SDL for Mac OSX is C++)

I do not have a machine to test the agl binary on, good luck. 

Good clarification, I knew this but hadn't thought to explain it.

There is however a third group not represented in your post, there are artists who treat Quake as a blank slate like the modders do, unfortunately almost all of them have moved on to other games now, they were involved in many of the mods of old. 

can I quote your awesome post in the quakesrc thread? 

Feel free 

Thank you :) 

Mappers (and map fans) want to embrace it and snuggle it.

Coders (and coding fans) want to rape it and deface it's battered body.



....different kinds of love.... 

I was waiting for the shambler input.

and I agree 100% with Mauvebib, though you get the 4th group of people too I think, The "Mindcrimes" of the Qmunity (lol) who love both sides, art and code, just as much and end up with something like Nehahra, which imo is the single greatest achievement Quake has ever seen. 

It is worth mentioning that addons like Nehahra etc would not have been possible without mappers and coders working together on a common goal.

I wonder what was different about Nehahra that made the 2 "camps" think and work collectively on the project? Its a shame it doesn't happen more as Nehahra is testament to what we can acheive. 

I think it worked ok for Nehahra cause mindcrime was a story teller before actually being a coder, and had a good idea of what he wanted to achieve, without imposing much on us the mappers. He came at us saying something like "look, I added lots of funky stuff to quake that you don't really need to use if you don't want to, and I'll add a cool story to whatever maps you build, and pretty much add whatever else you want me to, interested?".
That being said, I still think there are many things we could have done better in nehahra, hopefully the revamp will fix those though. =)

About this whole coder/mapper issue, I think most mappers don't even really want much new visuals, I know I don't, I like quake as it is already, when I want fancier stuff I just go play new games. My only interest is in possibly enhancing the, uh, "mapping experience", such as with details and hints, fewer limits, etc, but even those things aren't really necessary I guess. 

You really don't get it, do you? 

lol, take no notice of smabler - it's his job here to provide "controversial" viewpoints - it spices things up a little 

what i think would totally roxor would be for there to be a way to use 'real' rotation stuff from custom engines, but still have it work in normal quake/glquake... maybe have the custom engine automatically remove func_movewalls and just use the new collision system or something like that.

that way, the stock id engines will still have the fake collision, but the custom engines that support it will automatically 'convert' it to the new real rotation, thus making it completly transparent to the player. 

as i use func_togglewalls sometimes for larger rotation brushes (ie: a large drawbridge or somesuch) and have only two togglewalls, one for the first position, and the other for the second position, and simply switch between the two whenever the rotating bit gets triggered.

you could have some kind of key, like "_rotationobject" and, when set to '1', custom engines that support the real rotation collision would just remove those as well.

perhaps it would be better to ONLY use that method instead of automatically removing func_movewalls, even, since there's always the possibility that the func_movewalls could be used for something else.

i guess this isn't really on topic, so apologies for that, but these things just come to me out of nowhere. :P 

no one wanted to follow any standards to make engines somewhat compatible
its one of the big reasons mappers dont take advantage of engines new features 

...but having said that, mauvebib - thank you for putting things into perspective. Bal probably put my position best. If I was to pick one new visual that I would like included, I'd have to admit that I like using the lightning gun in JoeQuake. I think this is a good example of an enhanced effect, that adds rather than detracts from the original ethos. 

what is the main thing keeping engines (qw and netquake) from jumping into 2005? the map format and the aesthetic quality of the engines?

or just a lack of collaboration? 

Even despite the QSG... 

The QSG died a long time ago. 

If I want details casting shadows but the game still to be fast (you need that in dm) using func walls, I had better to make the whole map in q3 bsp? There aren't necessarily that many unique models in dm maps so the shadow-casting func_wall would work and would need just a light.exe mod, but I can see the models running out in sp maps a lot, so the compiler coders don't think it's worth the trouble.

Would it be that hard to try an example q1 .map -> q3 .bsp with q1 ents?

There are tons of q1 .map files that can be edited in gtkradiant and converted to q3 maps and bsp:s. (metl's ant or czg's terra for example)

Then people (mappers) can load them up in fte or darkplaces and start listing the things that look right / don't look right and we see where we can move from there. And what the fps really is there... You really need solid 77 for dm. And physics must be similar to current q1 bsp.

If the whole thing works, someone like the ezquake people can port it to their engine and you can play qw in bigger better maps too. Now it's mostly just boxroom-L-corridor-boxroom.

I've never mapped for q3 so I don't know how to do all that but someone most certainly can. Hell, I don't even have internet at home. 

That is a bloody good idea. I've actually loaded up a lot of existing Q3DM maps in DarkPlaces and run them with Aard's DMSP mod - the monsters run around no problem, although at the time, patches didn't block tracelines (so monsters "see" straight through patches), so there still needs to be some tweaking done(unless that's been fixed already) 

for SP only. Forget dm-online. DP is not QW (thats 1 of the many reasons)