Also, static lights do not count as edicts, so the entity count usually doesn't have much in common with the in-game edict count. 

So, how is it possible to determine "approximatively" edicts count, in order to anticipate and avoid crash ingame??
When I see Kinn latest release with an incredible amount of monsters (final battle for example), I'm guessing there for sure a method to determine edicts count. I tested Kinn's "Bastion of The UnderWorld" and "Marcher Fortress" with FitzQuake, and I had no problem, while in the same time I had the problem with my CMC map...(I reach the limit in hard skill..), but I don't find a good method to determine edicts count max value...
I know Kinn is talented (much much more than me...), but even if there are some "tips" in his 2 maps (due to QC I suppose), for common mortal I am, there is certainly a good method to evaluate edicts count in map.. Any idea ?? 

You can see how many edicts are being used in game by bringing down the console and typing 'edictcount'.

Also:
edicts - lists info about all the edicts
edict N - lists info about the Nth edict 

the famous 600 edict limit in normal engines, there's also another related issue; the server signon buffer size.

This typically becomes a problem when saving the game and then reloading it. If there are too many active edicts, the signon buffer will overflow and the engine aborts with the also famous SZ_GetSpace: ... error.

In my upcoming engine versions I've tried to improve this check so you'll get a warning when you exceed the normal limit. 

How much is too much? How could it be made more interesting? I just realized I've got quite a bit good 'ol backtracking action going on here. 

around the same general area would be excessive, unless you open areas up from new vistas or do neat Doom style room deformations then you could go maybe as many as twelve encircling routes. 

at http://user.tninet.se/~xir870k . All engines are updated with many features/fixes, e.g. more help to debug maps and reduced CPU load. RVis includes more ambient sound control and TreeQBSP has a minor fix. Please also see readmes for details.

Any comments are welcome. 

I get an error about fmod.dll. I have this file in the right place but nehahra will not start. 

thanks for info about the laser :) I should have known that by myself. 

Make sure you're using the fmod.dll from the Nehahra pack. Newer versions of this DLL (distributed by e.g. JoeQuake) is apparently not backwards compatible, i.e. there's a missing call entry. I wonder what reason they had for doing this ... 

That pretty much depends on the map and how it's implemented. As a vague rule, I'd say that backtracking for more than 1/3 of the entire map is probably a bad idea.

As mentioned Headthump, there are lots of things you can do to spice it up. Typical stuff is just spawning in a few monsters to surprise and toy with the player. For more varied and unique situations, you'd need to analyze what the player did before having to backtrack. Did he activate/deactivate a power grid? Maybe have that open some windows, turn off some lights, or activate some idle machinery. Are there balconeys the player can't get to? Maybe add a few scripted scenes for the player to watch; or perhaps have some lights flicker briefly as if there was a momentary lapse in power.

And if you're well and truly out of ideas, just make random things blow up and have pipes spew massive quantities of steam; that's always a thrill. 

If you truly did "just realize" how much backtracking the player needs to do, then you might consider opening up a few new alternate routes for the player to get back to the previous area. Maybe let him crawl up into a pipe or onto a catwalk and go view some of the map from a previous angle. 

Okay, that post was rather incoherent.

If you truly did "just realize" how much backtracking the player needs to do, then it's probably not too late to change the layout or route a little bit. Maybe let him crawl up into a pipe or onto a catwalk and go view some of the map from an angle that was previous inaccessible. This would also be fun for sniping on unsuspecting soldiers that have somehow re-filled the area. 

backtracking is ok as long as the gameplay changes significantly on each backtrack.

If a maps layout and architecture is OMG THE BEST EVER [like Insomnia for example], then backtracking can become "a wonderful thing" (TM), not just annoying. 

A working installer of Darkedit, an updated version of BSP has been found recently.

http://www.fileplanet.com/dl.aspx?/planetquake/elf/darkedit.zip 

Thanks! 

Well, um. I have three alternate routes through upper maintenance sector. But player still has to go through it twice. Maybe I'm just being overtly sensitive about backtracking. However, the idea about machines changing state is interesting. 

I read PRG's ideas about backtracking and it forced me to ask a similar question.

When backtracking is too long to be replaced by teleporter?

In my map for arcane project player needs to backtrack thru a rather long part of map twice: the first time when he presses the button, the second time when he gets the silver key. So I was thinking about placing teleporter somewhere, but I like to make backtracking much more.

Any ideas? 

Backtracking is a good way to extend the length and monster count of your map, but it's not to be taken lightly.

First, there must be new monsters. Period.

Second, these areas must be designed well enough that the player discovers new gameplay, with new advantages/disadvantages, when he's coming into these areas from the other direction.

Third, don't backtrack too much. The map will wear thin if you make the player haul across the same stuff three or four times.

Fourth, make it clear where he's going. Unless the map has a really unique and varied design that the player can easily remember his way around in, make sure he's ushered in the right direction. The big obvious quake-arrows help. It's a pain wandering around a map where everything looks the same, finding a key, and going, "okay, where the hell was the door?" The player doesn't have a top down view like you do. 

is that the player has already learnt from his previous experiences, what are the best ways to fight in a certain spot (or should at least have an idea anyway).
to this end, you can increase difficulty to what would normally be a little excessive. the player's knowledge of the areas he'll be fighting in, should give him a bit of an edge, and make that excessive situation just about normal. 

- fighting your way down a pit and then fighting back up

- shift platforms or walls, reveal traps

- open up the ceiling to reveal the skybox or other inconsequential coolness

- block directions the player shouldn't take

- and of course spawn more monsters 

I have two progs.dat files. One is much bigger than the other and I am looking at the differences. I am looking at ogre.qc and see these two differences-

void () ogre_die3 = [ 114, ogre_die4 ]
{
self.solid = SOLID_NOT;
self.ammo_rockets = SPAWNFLAG_LASER;
DropBackpack ();
};

and the other-

void () ogre_die3 = [ 114, ogre_die4 ]
{
self.solid = SOLID_NOT;
self.ammo_rockets = MOVETYPE_FLY;
DropBackpack ();
};

Why should there be differences and what does it do in the game? 

MOVETYPE_FLY and SPAWNFLAG_LASER are both just constant floats within the QC, defined in defs.qc and in misc.qc. SPAWNFLAG_LASER takes the value 2, so that the ogre drops 2 rockets in that mod. MOVETYPE_FLY normally has the value 5 assigned to it, so in that mod the ogres will drop 5 rockets instead. However, the fact that either of those constants appear in the code you're quoting suggests that you got the code by decompiling. Are you sure that's the only difference between the two sets of code?

If it is the only difference, then the size of the compiled progs files could just be due to the compiler originally used on each one. More recent compilers perform lots of optimisations that reduce the size of the progs(the size reduction is a side effect of the intended aim, which is to make the file hit fewer limits in the quake engine and so on). If there are more changes in the code, then they are much more likely to account for the difference in size.

In short, the only gameplay difference will be the number of rockets dropped by the ogre, and I'd guess that shouldn't affect the progs size at all. 

Thank you for explaining. What is the benefits by using constants instead of entering the value you want?

Yes, I did get the codes from de-compiling and one of the versions was (I think) yours - spawning monsters by the use of the 'style' flag in the map?

I have since found some more differences which is to do with setting monsters health from the map file. And also to do with ogres shooting missiles instead of grenades but I can not yet work it out. 

The advantage of of using constants is to make the code clearer, and the ogre code above is a really bad example of this, as it's made things more confusing not less. The quake engine and the QC code both remember a lot of properties, such as the way an object moves (it's movetype) as numbers. But if you want to code something with the flight movetype, it's annoying to have to look up a number, and when you read the code back:
self.movetype = 5;
isn't very clear; you'd have to look up what movetype corresponds with 5 to figure out what the code means.
self.movetype = MOVETYPE_FLY;
is much easier to understand, although once it's compiled, both lines are equivalent.

The equivalence causes a problem when you come to decompile the code. The decompiler can't see which constants to use where(to the best of my knowledge) and so it takes a guess as to which ones belong where. In the case of the ogre, it's guessed incorrectly that the number of rockets should be a constant. In the case of the ogre, there is no advantage in using a constant instead of just entering the value, and in the original code it is just a number:

void() ogre_die3 =[ $death3, ogre_die4 ]
{self.solid = SOLID_NOT;
self.ammo_rockets = 2;DropBackpack();};


As a recommendation, I'd try to not work with decompiled code where you can, I hope that the source to the mod I wrote is included with the mod, otherwise let me know and I'll send you it. If you're trying to merge multiple mods together, and there's no way to get the source code for the other mods, start with the clean source/source to my mod, then add just the bits of decompiled code that you need to that base.

Decompiled code also lacks comments, which are sometimes quite helpful. For the teleport mod, all the changes I made were commented, so if you wanted to add teleporting to another mod, you could simply find all the comments in the code, and follow the instructions to copy them into another mod.

Phew, that ended up long...