That's poor mapping style. Giving the map a quick run-through in the most common engines is not too much to ask. 

I installed DP once, a while ago, and for some dark reasons it crashes after some minutes... so I decided to stick to more than most common engine... FitzQuake is the reference here, so it is largely enough for me if my maps run properly on it...

And I don't think it is a poor mapping style: it is rather a poor testing style :P 

 

DarkPlaces doesn't mix well with ATI. It's ATI's fault for a long history of shitty Opengl support, but that doesn't change the fact that when Dark Places crashes it REALLY crashes. I lost my firewall registration information the last time my computer crashed after installing the latest ATI drivers and running Dark Places and it was a big hassle to get everything back in order on that front, so I will never take that risk again. 

Testing in common engines is one thing, but darkplaces compatibility shouldn't be expected. DP is from my experience just too far removed from a regular quake engine for people to negotiate around it. It's like where you have horses and donkeys: they can interbreed, but the offspring is sterile. Usually things fall into two categories, made only for DP, and made for other engines. If the latter work in DP, then great, but often it's too much work or sacrifice to achieve. 

@JPL:

Does the old DPs still crash for you, like DP1.02?

And your new map, is it going to be limit breaking (the Fitzquake 0.80 limit)? 

Ironically, one of your Travail secret maps also had the same Framerate problems as Five Rivers Land ;) 

I don't remember which version it was.... so I can't tell you. Also, I deleted DP from my HD, just playing with aguirRe's GLQuake, and FitzQuake..

Fortunately, it was not as dramatic as HeadThump mentionned: I didn't had to re-install everything on my computer... 

The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it. 

Lemme give you my canonical bugbear. When regular engines report the size of a sprite "model" in the QC fields mins and max, they set them to the dimensions of the sprite in pixels, relative to the origin of the sprite. Since quake renders at 1 unit to 1 pixel, this is a very useful feature, and Quoth uses this information to create a solid bounding box around wire-mesh/grill entities.

Darkplaces sets these fields differently. It reports roughly sqrt(2) times the largest dimension in each coordinate, effectively giving a bounding box for the sprite at any rotation. I didn't actually know it did this until someone reported that the quoth basetest wasn't completable. As a result of the difference, the solid bounding box generated by each mesh is much larger, blocking off the hole next to the mesh through which you must climb.

The thing is, there isn't much that can be done about this particular difference in engines, besides throw out the "solid" feature or make it much more effort to use (by requiring mappers to manually enter the dimension of the sprite on the entities). So even if I had known ahead of time, I probably would have said it was something for DP to fix. Perhaps it's a bit different when it comes to making maps compatible, but that's my take on the matter. 

probably best to let mappers place clip brushes. That's how I did it back when I had sprite-based grates in rubicon2. I decided to stop using them because:

1. they don't take the ambient or dynamic lighting at all (I actually had 6 frames which were the same grate but different light levels.)

2. on almost all non-fitzquake engines, they have ugly pink edges. 

The solid box is optional, you can also use clipping brushes. It's whether you want to allow projectiles to pass through or not. It seemed a shame to require an extra entity to be the invisible hull if you want to block shots as well as players. As for the orange edges, people can usually see past them, if you go for rusty textures at least. 

true, the pink edges are fairly subtle when the artwork itself is warm orange/red in color, such as the light globe sprite in original quake.

As for blocking bullets/projectiles, this can also be accomplished with a skip brush instead of a clip brush. Except the skip brush will cast a shadow, unless you make it a func_wall, which as you say, is an extra entity.

Unless! maybe you can assign a brush model to the sprite entity, which the quakec code uses to call setsize() and then changes the model to a sprite after that. Of course this uses a model precache :P 

The burning can I made with the zdoom model had the same strange line along the sprite.
It seemed as if the used pictures needed an extra line surrounding them. And to stay within the 4 divided measure for gl they became bigger.
Without line. 

The think with Darkplaces is that many people use it (because it looks SO AWSUM!). If you want your stuff to be played by newbies then you should test it.

Careful here.

It has a couple useful extensions (like nonsolid, but shootable corpses), it runs TWIG, and it supports CSQC, which allows you to do lots of otherwise impossible stuff like moving sound sources, inventory, keyboard input - ever tried to getchar() in qc? and more things like that.

Yes, the newbie/awsum effect is there, but careful plz, modders don't prefer it for nothing.

DP/FTE/QSG extensions and csqc have been the answer to a surprising amount of questions I came up with during RMQ development, and by now I think Darkplaces is rather awesome.

I used to think like you, though. ;-)

I would like to see CSQC supported by Fitzquake type engines, please. Because quite frankly, it is awesome. 

DarkPlaces is structured in a radically forward thinking way.

The memory management, the QuakeC handling, movie playing capability, the protocol, true interpolation (try setting max fps to 500 and watch what other engines do when you use a lift) and on and on.

Most engines don't even have simple basic fixes like not aborting when a model isn't found, a chase cam that doesn't poke through walls, colormapping of dead player bodies, view weapon capability and on and on.

Most new features engines have added in recent times are things that DarkPlaces has had for several years.

LordHavoc's work has been far, far ahead of the times even in the early days (DP has had color mapping of dead bodies since 2000). 

I don't think that because DP has a different behaviour and different features compared to "standard" engines (e.g FitzQuake... ) that it can be said that DP is "bad": it is just different.
Well, I don't want to drop down DP just because it crashes my PC once, and I'm pretty sure I can find many people that think DP is better than FitzQuake, just because there are used with it 

I think you think to know my thoughts while you don't. :p

Darkplaces is an amazing engine in my opinion. Sadly it breaks Quake "compatibility" a bit too much. So I don't think it is that good to play Quake singleplayer maps/mods.

What I said up there should be read as: Many newbies go for Darkplaces just because it has realtime lighting, parallax(?) mapping, shiny water and maybe the soundtrack support. They don't give a fuck about the "developer features". But then they mostly don't play custom maps either I guess, so ... 

I have been waiting for SO long for someone to create a quake client that properly interpolates the monsters, yet doesn't stick in a ton of eyecandy....

Darkplaces was nice and had correct interpolation, but changed too much stuff and had too much eyecandy and the exe size got too big.

Every other client used the same copy&paste interpolation from some tutorial that would not correctly smooth the monsters' movement when connecting to a remote server.... They would still be all jerky.

But this new fitzquake does it right! The monsters on FvF look great now that they aren't hopping around like they are spastic!

Finally a GOOD ProQuake replacement....

Great Work!


http://www.fvfonline.com

connect FvF.ServeQuake.com 

How about adding in ProQuake remote console functionality for remote administration of servers (RCON)?

I could really, really use that.... It makes things so easy. 

do you mean, adding support so a fitzquake client can RCON to a proquake server? 

Yes, or some other way to remotely control a server. ProQuake's RCON works well and is easy to use. And since ProQuake already contains this functionality, it seems like it would be easiest to just copy the ProQuake stuff. Then FitzQuake would be able to RCON to a ProQuake server or to a FitzQuake server.

Another nice ProQuake feature that would be easy to add is the longer text chat lines....

I'm going to compose an e-mail with more feedback/bug reports/suggestions. 

Christ, if someone's naming Forwards Compatible as "secretly one of the best releases of 2008" then the rest of y'all should be ashamed of yourselves. 

I was wondering if you looked into LordHavoc's dynaimc lights speed up option and the possibility of putting it in Fitzquake? Thx 

I haven't really looked into it yet, but based on baker's post, it sounds like that was merely a speedup to the code for determining the floor light value under a monster (since that is how monsters and players are lit, based on what they're standing on.)

Second, i already probably use that optimization, since i got my .lit support code from darkplaces, and that includes the changes to R_LightPoint and related functions.

The major issue with glquake lighting in general is that it requires uploading new lightmap textures anytime the lightmaps change, which is one of the slowest things you can do with a video card. At some point I will look at ways that can be improved; I can think of a bunch off the top of my head (using 8bpp textures when level has no colored light, uploading more, smaller rectangles of texture data instead of fewer, larger ones, etc.)