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. 

holy fuck, does that work? :o can anyone check? i would, but, alas, no quake. :S

regarding the rpg trick, i think you could do it by using the func_wall with the model set, the killtargetting the func_wall and just teleporting in the real monster. 

restrincting a monster to one are are does not work like that. also, having a func_wall with the clip textures let's qbsp stop with an error message.

the rpg trick is achived through func_walls with skip textures, and then killing them when the monsters are supposed to become active. 

oh, of course you can making monsters stay in a certain area by sealing it with trigger_monsterjumps (that should have height and speed set to "1", so it's less obvious), for example. 

the rpg trick is achived through func_walls with skip textures, and then killing them when the monsters are supposed to become active.

Exactly. Monsters behind func_wall made from skip (so it appears invisible), and then killtarget the func_walls when you want the monsters to activate. They suddenly "see" the player and come alive. 

we 

when are we going to see the speedmap session based on tricks from this thread? 

Are you using tyrann's skip tool, or as aguire built it into his compilers. I think I have the skip tool, but I remember Tyrann saying it had some issues so I have steered clear.

This thread is awesome by the way. 

I used Tyrann's skip tool. I've never had any problems with it. 

. 

There've been a few hacks posted in the mapping help thread since this thread last saw light of day, so if anybody saved them it'd be nice to have them here too. Today we're going to see how you can safely remove weapons and ammo from the player.

I discovered this trick looking for something quite different. Doors that require keys compare their items field to the player's items, and subtract off what they find if it matches. So I was experimenting by changing the .items field manually, rather than setting the gold/silver key flags. You can make a door that only opens if you have quad for instance, but the problem is the quad items flag gets subtracted once you open the door. This doesn't affect the powerup, you'll still do quad damage for 30 seconds, but it removes the icon from your screen. And once the 30 seconds is over the flag is subtracted again, which causes an overflow of the items field and all the icons start lighting up - it's bad.


However, the nice thing about the door is that it safely removes weapons, as these are just stored in the items field. So the simple way to remove a weapon from the player would be just to have a door with an item set to that weapon's item number. You can also sum weapon numbers, and if the player has all of those weapons, it removes them all. Two problems exist for this niave approach:

One: Just removing the weapon from the player's item doesn't force the player to change weapons, so if they are currently using a weapon you want to remove they will still be able to use it until they switch away from it.

Two: If you're removing weapons later in a map, you may not know if a player found the grenade launcher or not. The removal is all or nothing, if the player doesn't have all the weapons you want to remove then none of them get removed and the door remains locked (also it sends the message "you need the gold key"...)

We can solve both these problems at once, whilst at the same time removing ammo from the player. The trick here is to use BackpackTouch to give the player all the weapons they need to open the door, then instantly take them away. At the same time, we give the player full ammo, then take it away with another BackpackTouch, this time with negative ammo counts. And when the ammo count is updated, quake checks which weapon the player should be using, so you won't end up using a weapon you don't have.


So, here's the entities you need to add. I'm assuming you want to remove every weapon except the axe(see below), which gives an items field of 128.
First, a brush based info_notnull with the following fields

touch BackpackTouch
think InitTrigger
nextthink 0.2
ammo_shells 100
ammo_nails 200
ammo_rockets 100
ammo_cells 100
items 127

Then another info_notnull with

touch BackpackTouch
think InitTrigger
nextthink 0.2
ammo_shells -100
ammo_nails -200
ammo_rockets -100
ammo_cells -100

Finally, add a regular func_door with

items 127


You want to ensure that the player hits all of these entities in this order, in as quick sucession as possible, and don't let them avoid any of them. So dropping the player onto the func_door through the other triggers is probably best. Putting the two info_notnulls on exactly the same region of the map is wise, as long as the one with positive ammo counts is higher on the entity list. If you still have problems, the following extra entity can help - an info_notnull with

touch teleport_use
think InitTrigger
nextthink 0.2

This trigger sets force_retouch to 2, which means all objects retouch everything next frame. Presumably this means you retouch it, which resets force_retouch again and over again while you stand in it. Oh well.


So, why is the axe exempted from this? Well, it's quite annoying really. There are sections of the code dedicated to what to do if the player doesn't even have an axe, and these all work well and good, but then there's one lazy line in client.qc that always switches you to the axe if you have no ammo, without checking if you have an axe first. Grrr. So you can't completely disarm the player, but you can get fairly close.

A few other things. One is the annoying messages saying "you recieved -100 shells etc.." that you can see in the console. Add an extra info_notnull in the same spot, with the following fields

touch powerup_touch
think InitTrigger
nextthink 0.2
noise misc/null.wav
netname \n\n\n\n\n

This spams some newlines so the messages are only visible in the console. Creative types might include a message here explaining where all your weapons went.