This thread's almost fallen off the page, so I thought I'd put a couple more things on here. The first is how to make a non static entity with a model. This is like the func_illusionary trick, but because the entity remains dynamic you can remove the entity later. You can also set angles on it, something neg!ke said wasn't possible with a func_illusionary.

The downside is that you have to mess about with modelindex to make the model display correctly. Make an info_notnull with these properties:

mdl progs/player.mdl
modelindex n
think SUB_regen
nextthink .3

Where n is the modelindex of the model you want to load. How does modelindex work? As the quake engine precaches models for the game, it places them into a numbered list. The modelindex of a particular model is it's number on this list. Index 0 is the null model, index 1 is the world itself. The next models will always be the brush models from the bsp, then the models precaches by the QC in the order that the models are first precached by the spawn functions.

This all makes it a big pain to work out which model has which modelindex. I'd recommend running the map through darkplaces or aguires engine, as these have commands that will display the list of models along with their modelindex. Be warned, the order in which models are precached may change if you alter the entities in your map. Also, different skill settings may have a different modelindex, so be careful.

On the plus side you can set all the things like frame number and angles without a problem, and even give the same entity a use function if you desire.


Ok, now for overwriting paths. What this does is allows a one time alteration of the path of a func_train. You can't toggle it back, and you can't switch it again to another path. But someone might be able to find a use for it.

Ok, here goes. To make the explanation simpler, we are going to alter just one point on the path, you can expand this to replacing multiple points and doing more complex things quite easily, it just takes more fiddling with triggers. Make a path of path_corners with targetnames p1 -> p2 -> p3 -> p4 -> p1. Then make the replacement p1 path_corner, making sure it is further down the entity list than the original p1. Give the replacement p1 the same targetname and target.

At this stage what should happen if you run the map is that the train goes between the first four points, the second p1 path_corner will be ignored. Now for the trick, add a key to the original p1 of

use s_explode6

Now, when you want to change the tracks, just fire a trigger that targets p1. This will run s_explode6 on the original point, which removes it in 0.1 seconds. The new p1 has no use function, so it remains. Why use s_explode6 instead of SUB_Remove? Well, just for neatness really, it's possible that you'll be triggering p1 from a touch function, and removing entities during a touch function can be dangerous.

That's the basic idea, anyhow, but you can do quite a bit with it, it's mostly how you set up the new p1. For example, there's no reason the new p1 has to target the same entity as the original p1, it could go p1->p1a->p1b->p2 and then back through the original path. You could choose never to return to the original path, do something like p1 -> q1 -> q2 -> q3 -> q4 -> q1. And then you could pull the same trick again with q2, switching onto yet another path...

You might be tempted to try this with monsters following paths as well. In theory this should work, but there is one problem. If you remove the point the monster is currently heading for, it'll start heading for the world origin and won't ever resume it's path. This doesn't happen for func_trains as they calculate exactly how far they have to move as soon as they start moving. Monsters have to hit the trigger of the path_corner, and constantly correct their course using the navigation AI. Bit of a shame, but there's not as much use for changing monster paths as func_trains offer anyway. 

How many of these tricks will become invalid when loading the map in a custom progs.dat, such as Nehahra or Zer? That's perhaps the only thing that might stop me from using some of these. 

It's hard to say exactly how many would still work with a new progs. Potentially all of these could be broken by a new mod, if it was written correctly. But I'd say in the vast majority of mods, the vast majority of tricks will work. Like the use trick would stop working in only two circumstances; the mod completely rewrites the entity triggering system(which would mean you'd have to map differently for it anyway), or the mod adds a use function to the entity you're trying to use. The former would really only occur if it was some total conversion thing, and the latter is unlikely to affect info_notnulls.

I'd say that probably all of these tricks would still work in zer, and quite a lot of them in nehahra. As a rule of thumb, a mod that just adds content without changing the base stuff should accept these tricks. The more it alters what went before, the greater the chance something will fail, which is why zer should run them but nehahra may not. 

I know QdQStats will break the coop detection stuff, because it allows some of the 'cheats' in coop (for route planning purposes). 

having mapped for this game for a few years and all that, i thought it was really cool that there were so many tricks i never knew about. thanks for these-- i already found a use for the respawning items trick. ^_^ 

What do you mean by 'create an func_illusionary entity (=no brush!)'?

In BspEditor, there is no choice but to have a func_illusionary attached to a brush. This is where you can walk through what appears to be a solid wall.

If I use "model" and "frame" anyway, the model does not appear, just the brush. 

The idea is to make a regular point entity, and give it the classname func_illusionary, as though func_illusionary were a custom mod entity. In worldcraft, this causes problems as the fgd file says func_illusionary is a brush class. One way to get round that is to remove the definition of func_illusionary completely, as it has no parameters, and name both brush and point func_illusionary entities manually. I don't know how much of that extends to BSPEditor, but you may want to look at doing something similar. 

OK, so I remove the func_illusionary from the ents.qc and now I can't see it in the editor.

I then create a light entity and rename it to func_illusionary and add 'model' and 'frame'.

I have Qbsp on -verbose and see that a texture is not being found, and when I look at the map file, a texture has been added to the func_illusionary:-

{
"frame" "1"
"model" "progs\player.mdl"
"classname" "func_illusionary"
"origin" "0 0 0"
{
//"0000" "0"
( -8 8 8 ) ( -8 -8 8 ) ( -8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
( 8 8 8 ) ( -8 8 8 ) ( -8 8 -8 ) NONE 0 0 0 1.000000 1.000000
( 8 -8 8 ) ( 8 8 8 ) ( 8 8 -8 ) NONE 0 0 0 1.000000 1.000000
( -8 -8 8 ) ( 8 -8 8 ) ( 8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
( -8 -8 8 ) ( -8 8 8 ) ( 8 8 8 ) NONE 0 0 0 1.000000 1.000000
( 8 8 -8 ) ( -8 8 -8 ) ( -8 -8 -8 ) NONE 0 0 0 1.000000 1.000000
}
}

The actual origin of the entity is not '0 0 0' but I can now see the player model in-game where I set it in the map (not 0 0 0).

If I now try it again with "model" "progs/ogre.mdl", the engine gives an error of 'no precache' of the model for the func_illusionary even though I have ogres in the map.

Does this mean that the engine is seeing the func_illusionary before the ogre is precached, and if so, can I do anything about it without resorting to messing with the progs.dat? 

in the map file a monster_ogre entity must be placed before (are rather above) the func_illusionary.

i don't know about texture thing you said, but there must not be a brush assigned to the illusionary. try to delete the brush and set the { and } accordingly. 

I cut'n'pasted the func_illusionary to the end of the file and then ran Qbsp from outside of the editor (because the editor seems to change the order of things arbitrarily), but still no show :-( 

First off, I don't think that the brush info at the bottom should be there, but I can't say why it appears. Perhaps try deleting all those brush info lines from the map file to make it look like the other point entities then try a recompile. Then again, if it's working with a player model maybe that's what BSPEditor expects.

The precache thing I suspect is fixable. Precaches occur in the spawn functions of entities, and the spawn functions are called in the order that the entities are listed in the map files. So if your func_illusionary entity is higher up the list of entities than the ogres in your map are, then the ogre.mdl won't have been precached yet, even though one would be before the map loads.

So just make sure there's at least one ogre higher up the entity list, and that error should go away. 

I took twice as long as neg!ke to say the same thing, never mind that post 

I'm not sure that this is interesting enough, but I'll post it anyway.

If you have a monster_ogre_marksman next to a monster_ogre, the end result will be 2 ogres that can get mad at each other. I don't know if any map uses this yet (or wants to use it) but someone might find a use for it...

This bug only works, because in the code, the classname isn't changed when it tells it to just put in a normal ogre. 

Didn't you play PuLSaRs Hellbridge recently? :)I think that on this map you can see some ogres fighting on skill 3. 

is it possible to make shootable doors? basically, you shoot the door, and it opens. then after a bit, it closes. ideally, whenever you shot the door, it would open up again -- even if it was in the process of closing.

i want to do something like the doors in q3's tourney4 map (pro-t4). 

You just have to set a health value (5 is in general ideal, i.e you can open the door with axe), and set wait at a positive value (-1 never return)... I think I did this for a secret area door hidden in a wall in my last map... I think other people here could confirm... 

I guess you understood I was talking about func_door fields there... ;P 

thanks! and yes obviously they are teh doors ;) 

What JPL described will work; however, shooting the door while it closes will not have an effect--you can only shoot it while it's closed. You could minimize this problem by giving it a very fast "speed" field, though. 

i just might do that, thanks 

about the trigger that can me touched by anything in #11:

i did it exactly like you said (btw it's multi_trigger), but i couldn't get it to work. in the test map i made it was supposed to just fire a trigger_relay with a message.
there were also some unknown bboxes with that shouldn't have been there and they disappeared when shooting them. they seemed to be related to the touch-trigger. 

If anything that prints a message has an activator other than the player, the message won't be printed to the player.

You can see this at the end of terra5 where a trigger_counter counts the deaths of the fiends and wakes up chtohohothothton and prints some messages when they're all gone. However if you trick the fiends into jumping in the lava, there's a trigger_hurt there that kills them, and then the messages aren't displayed because the activator was the trigger_hurt.
Same thing with the logic gates you can build with trap_spikeshooter and doors in front of a button. You can't have the button print a message because it's activator is the trap_spikeshooter, not the player.

So I dunno if I'm quite following you up there, but if you are trying to prove a trigger was fired by something else than the player by printing a message, you should try something else. (Perhaps a light switching on of a door opening or something.) 

i thought it would be fine if not the trigger itself had the message but some other entity that is fired by it.
i tried it with a light then and it worked.

to have a message displayed, i guess i would have to let it activate another trigger which spans over the entire room the player is in at that moment, or something like that... 

gibs don't trigger it, either.
there goes my idea... :/ 

I am not 100% sure this really does work or not, but I THINK that if you create a func_wall entity that surrounds a monster, and kill the func_wall when the level has loaded, the monster will stay in the same place as if the func_wall was still there, yet be able to see and shoot the player. If the monster has a jumping attack, then if it jumps toward the player, it will come out of the box and act as normal.

I am about 50% sure this works, as I remember doing this when I made apsp1, trapping some enforcers on a ledge. The func_wall may have been made from clips.

I've seen some other strange func_wall tricks used in other levels. RPG used some funny trick in one of his mini Ep1 maps, where there were some nights trapped apparently within func_wall brushes. that acted like statues, but came alive later in the level. I would be interested in how that works, RPG.