Thanks! It works without a hitch. Working link for the .zip:
http://quakeone.com/proquake/interims/fitzquake085_mp3.zip 

that is a quakec bug. 

But it works in some clients. Old winquake for instance. That's how I noticed the difference. 

you mean that unlocking sound? afaik, it never worked correctly.

in the qc, the unlock sound is played on the same channel that the door move sounds are played on and it is played before the move sounds and it's all done on the same frame, so the engine never even 'sees' the request to play the unlock sound.

are you sure it works in winquake? i can't think of why it would. 

My bad. I must have toggled the console at the right moment or something. 

i've been experimenting with a rain effect and i'm pretty happy with what i've ended up with.

essentially, it's an edict intensive method: spawn one entity with a sprite model and treat it like a particle for every rain drop.

looks pretty sweet, and with increased max_edicts, it's not a problem since even large areas will only take up maybe 800~ edicts (since max is 32k i'm not worried at all.

problem is that it seems like the engine can't cope with drawing all those models because lightning bolts flicker or just don't get drawn at all.

it's weird because other temp entities like rocket explosions are drawn just fine. it's only the beam effects.

this happens in both fitzquake085 and quakespasm.
using sv_protocol 666 and max_edicts 8192. 

so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn? 

MAX_VISEDICTS is defined to 1024 in Fitz. 

well, so this might be the problem:

The lightning bolts are made up of individual segments. Each segment requires a new "temp entity" to be spawned which also occupies a "visedict" slot. So if you reach MAX_VISEDICTS, or MAX_TEMP_ENTITIES, you the rest of the beam segments and any other beams after it will not be visible.

The raindrops wouldn't affect your temp entity budget, but they do use up visedicts if they are visible. So the addition of all these raindrops has probably used up the visedicts (max 1024 in fitzquake) before the beams can get fully drawn. (I believe the beams are added to the list after everything else, so they are the first to go.) 

so you're saying -- you have X number of lightning bolts being drawn correctly, then you add your many raindrops, and the raindrops are fine but it causes the lightning bolts to not be drawn?

yes, this is it exactly. :) 

aside from using another engine or modding fitzquake, i would recommend trying to optimize raindrop count by only spawning rain when the spawner entity is within a sphere around the player (e.g. 512 or 1024 units), since far-away drops will be less visible anyway. Unfortunately, that's probably the best approach :(

Or switch the behavior so up close the drops are independent, but past the middle distance you spawn fewer instances of a second model which is a clump of drops? 

some experimentation is in order i guess.
thanks anyway. :) 

FitzQuake 0.85 protocol 666 supports 32000 entities/edicts, 32000 being a rather huge number. Server edicts eat up a ton of memory, client entities not so much.

Throwing one idea out there ... well, less of an idea since I've already done it, is to count the entities in the entity string [while ...strstr(entities, "classname")] and then on the client side use the server's estimate if sv.active. Requires moving allocation of sv.edicts to after loading the map and another block of code. Beats allocating 8192 edicts or 32000 and also beats running out of edicts. You might call this the "max_edicts 0" option (if not specified, "guess").

----------
r_nolerplist or whatever it is called. This code doesn't properly check for null termination and can drift off into memory beyond the cvar string. Just by chance it actually doesn't do this with the default string. Not really important, but throwing it in the thread.

I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.

I know there isn't a standardized plug-and-play compressed and predictive protocol for coop at the moment, but I kinda of think this is not far off (considering the list of hated engine challenges/problems has shrunk considerably in the last 2 years or so).

Someone needs to solve the rain/snow thing. It looks so nice in Nehahra ... and then turn it into 3 or 4 worldspawn params or optionally as a "rain" or "snow" command in the console. 

I hope someone comes up with a "standardized" rain/snow effect that can be used that ... well .. isn't QuakeC. Snow/rain fall into the fog/particles department and if not, fall into the "view presentation" and not the 3d world. Can you imagine how large a demo would be with 2000 rain particles being written every frame.

i hope NOT. i tried using Darkplace's rain effect and it's just terrible, mainly because there's just no control over the thing.
if you want to have your own simple drops next to a wide open torrential downpour, your drops end up looking different. the current implementation i have for DP doesn't use the DP effect at all.
Built-ins suck! :P
or if you're going to do it, you must give total control over it so it can be properly integrated into the rest of a mod. ie: the ability to specify what model to use (not just a built in effect), initial speed, how much gravity affects it (if at all), collision and fine control over when and where a drop falls. 

Would FTEQW's particle system help? 

have you tried actually talking to Lord Havoc about the rain effect?

I can second FTE, it is an awesome engine and Spike is an awesome guy. IIRC FTE recently had its renderer rewritten and should also run more stable now than in old times. Give the nightly builds a try.

otherwise you can always use func_emitter from extras with a rain sprite you make yourself (e3m1rq did this, but the raindrop model sucked).

Maybe DP's effectinfo.txt allows you to alter rain drops? 

have you tried actually talking to Lord Havoc about the rain effect?

no, and, i don't want to. not really interested in having to chase after someone else for personal changes (and likely bug them too).

as for fte, i was told it wasn't really a modding engine, so i didn't invest too much time into trying to figure it out.
also, it turns off mouse accel in windows and doesn't re-enable it when the engine closes, which... i don't know, why does it even disable it in the first place? just needlessly annoying.

anyway, yeah, my foray into fancy custom engines was not a fun one, so i hope FQ stays close to what it is currently. even after all this time, i still consider it perfect (except for that multicore timing problem, which is easily fixed). 

I quickly searched through the thread and didn't find threw answer. :x 

no idea, personally. but from what i recall when the problem first surfaced, it has something to do with the timing function (or whatever) used, and replacing it with a newer function fixes it.
quakespasm has this fix, which is what i use.
i believe baker may have made a version as well? but i have no idea where to get that. 

No texture transparency support of any kind? TGAs alpha chan dosent work, couldnt find anything about it in the radme either. (((
Any hope of getting texture transparency for fitzquake at all? 

Yeah, there's hope. How do other engines do it? Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?

The main work in implementing it is creating a sorting algorithm for transparent objects (and maybe for individual triangles) a nd then rendering them in the right order. I assume most engines either don't bother or they do it per-object only. 

This is not solved in, for example, darkplaces*: polygons with alpha transparency do not render properly against triangles from the same model behind those polys. You end up seeing the background behind the model rather than the rest of the model geometry as expected.


*At least last time I bothered checking... 

I solved this in DirectQ but it does involve sorting everything on a per-poly basis (rather than per-model, which would be standard for most). It's not hard but it is messy. You should probably also sort particles, water surfaces, sprites, MDLs (which I left sorted per-object rather than per-tri for performance reasons), and possibly other stuff into the same list.

(Aside: There is still a case where 3 or more triangles could partially overlap each other, and which no sorting algorithm could solve. That needs proper order-independent translucency, at which stage you've raised the hardware requirements for the engine so high that few enough people would be able to run it.)

What I did not do was allow for any TGA (or other type) with an alpha channel to have transparency. There are a lot of other BSP format-related problems with this, and ultimately Q1 BSP is just not set up for it. If nothing else, these polys would need to be treated the same as water for visibility determination/portalization, but still be able to generate clipping hulls, which I believe Q1BSP just does not allow at all.

You would need to make them "*" models which is one potential workaround. It would probably also make sense to have a texture naming convention for them, so that you're not slowing down load times by scanning every TGA for alpha (although some engines already do that anyway). 

"Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?"

Yes, apparently thats what they all do.
DP has no problem sorting huge number of bmodels with alpha. But slapping the translucent tex on the entire ground caused some minor sorting issues.
http://imgur.com/a/Zto3F#5 

Very nice screenshots, pretty dark though. Good to see you're working on a town map - I don't have to feel bad for not finishing mine then.