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... 

Words of wisdom thank you.

I started looking at code back about front as I wanted to see how to compile before I had written anything to compile. So I decompiled some progs.dat to play with which is why I ended up with code without comments. So now I try to do it right.

I now have the source code and it is yours. What is the extension .$$$ used for? The code in these files includes shalrath_tele. Does the $$$ files get compiled just the same?

How does the game know that the code for monster_shalrath_tele as entered in the map file is in the shalrath qc file, is this defined somewhere else? I am not clear because you say in the readme file that if the shalrath is not to teleport away than use the ordinary shalrath so I think that both will be compiled.

I am really interested in learning about this code so I am sorry if all of this is too simple for you but will be pleased if you will help. 

Arrrgh, I shouldn't have left the $$$ files in there. They are backup files that get automatically generated by the program I use to edit qc files, you can safely ignore them or delete them.

The idea behind the monster_shalrath_tele is this: When a map is loaded, the engine looks at the name of every entity that is included in the map. It then tries to find a function in the QC with the same name as the entity, and runs that function(or produces an error message if it can't find the function). The function is usually designed to set up the entity in question, set it's model, it's behaviour and so on. The engine sets the entity called self to be the entity in the map, so by setting self.health in the function you affect the health of the thing in the map.

When you run this mod along with a map that has a monster_shalrath_tele entity, it runs the function
monster_shalrath_tele();, which basically makes a vore in the right place in the map, with a special death animation that looks like a teleport.

Because there's a new function for this kind of shalrath, the old one is still present, and unchanged. So any monster_shalrath in the map will be just like the ones in the original quake. I could have programmed it differently, so that you just set a flag on a normal monster_shalrath in the map, that makes it teleport out on death, but I did it this way because that's what the original recipient requested.

If you wanted to make, say, a new monster, so that the entity you added to a map was called monster_troll, then you'd call all the animation functions and so on whatever you like(although it's usual to stick to the conventions in the existing code). Then just ensure the spawn function was called monster_troll().

Hope that clears up how the game knows what code to use for which entites. 

Great, I understand now. Thank you. 

Well, I am quite pleased because I managed to find your error tutorial hidden in the shambler.qc file ;-)

monster_shambler_tele_set
and
monster_shambler_set_tele

I stared at it for a long time before I could see it!

I didnot try the progs.dat supplied as I was adding some code so I cannot say if is OK or not. But it compiles good now and works fine. Thanks again.