One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?

I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme. 

If you're refering to the max_edict issue in unf2, it seemed more like an accidental thing, a glitch in the code or some misfiring script. The map itself feels like the least extreme of the pack. Even unf3 'only' starts at ~800. Or what is the exact reason for the edict explosion? 

Hm, I guess you could write "max_edicts 2048" in the quake.rc to be safe? 

unf2 has light snow, and it makes the map look pretty, but requires a high number of edicts. With the snow, max_edicts peak a hundred or two below 2000. Related to this is the rain in arcanum1. This is why rain falls in clumps in arcanum1. If I had an edict for each rain drop, edict count would be very high and would not run in FitzQuake without increasing max_edicts. For unf2, I cannot make the snow fall in clumps and still make it look good. Turning on corpse removal will disable the snow.

Other engines with higher default max_edicts do not have this problem. 

I didn't think about that. I assume it wouldn't be possible to make the snowfall trigger-based or something and still work/look the same? So that snow flakes are only generated within the current trigger volume. And each outside area is surrounded by a large trigger. 

One of the maps in Tronyn's upcoming Unforgiven can exceed the default of 1024 max_edicts. Can there be a minor update to Fitz that increases the default to 2048 or even 4096 max_edicts?

I know of the max_edict command, but I bet Tronyn and I will read many complaints about one map not working because someone failed to read the readme.

i kind of wish fitzquake defaulted to protocol 666 (it's own protocol) instead of defaulting to old quake protocol.

i remember back when i released ne_tower, some people didn't change to protocol 666 and some items were invisible to them or something.
the thing is that you can't just force protocol 666 in a cfg file because other engines have their own protocols and this causes crashes.

we need a better way to generally tell one engine 'i need extra stuff' that won't cause problems in other engines. 

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?