Fitz does default to 666 on map load. For demos it will use whichever of the two protocols the demo was recorded with.

One potential problem with a higher default max_edicts is memory usage. The size of an edict is variable, and the way they are accessed by the engine (in particular the VM) makes true dynamic allocation incur a cost in code complexity. Set the default too high and memory costs will soar, even for maps that don't need to use so many. 

John, do you plan on adding .mp3 support to FitzQuake? In its current state, the engine fits to my needs perfectly apart from this single issue. It's getting tiresome to insert the cd everytime I want to load up a map. 

But here goes: http://forums.inside3d.com/viewtopic.php?p=19144 

Could it be that Fitzquake doesn't play the proper sound when opening a key door? I think so. 

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.