You could place trigger_teleports under every monster.

Go down path 1, teleport monsters from path 2 over into positions on path 1.

Go down path 2, teleport monsters from path 1 over.

You'll run into problems such as having monsters on paths moving off the teleporters, but you can overcome this by trapping monsters temporarily in a func_wall fence. Once the path is chosen and teleports are done, then killtarget the "fences" to let the monsters roam freely again. 

of using Qmaster's idea would be to put all the enemies in teleport boxes, and kill the teleport destinations of the other paths after the player can't go back to take another route.

For the enemies that won't fit in other routes or if some routes you want them to have more enemies, you can killtarget the ones of the other routes just before the exit as no one will notice the numbers growing out of nowhere. You can do the same with the info_intermissions so they show a different scene depending on the exit. 

of using Qmaster's idea would be to put all the enemies in teleport boxes, and kill the teleport destinations of the other paths after the player can't go back to take another route.

Isn't there a problem that in vanilla you don't have multiple targetnames? If you have a single trigger_teleport linked to two info_teleport_destination entities they must have the same targetname. When you killtarget one, the other gets removed as well. I think you need a separate trigger_teleport for each destination, and killtarget that instead (or just only ever trigger one of them).

I mean, there's a way to do it with "use" "SUB_Remove" added to just the first info_teleport_destination on the map, but any hack that is depending on the order of entities in the map is unpleasant to maintain... 

Why didn't I think of using shared trigger_secrets for each path's secrets; that's genius, Preach! :D Thanks also for telling about the -1 value for the sounds key. I had tried numerous other integer values in vain, from 0 to larger ones, but hadn't thought of negative ones. You're a lifesaver, thank you! :)

Thanks for the monster teleport trick, Qmaster! I had actually read about it somewhere else in this forum, if I recall right. I guess that's really the best one can do in an unmodded game. o:

Actually, I had also read something about updating the secret totals in the mapping thread, in a post written by Preach, actually (post number 4316 from the year 2005)! ;D Something about servers, clients and SVC_UPDATESTAT, which made me think something like "wait, don't servers n' stuff mean multiplayer stuff" but I guess the singleplayer runs on a server/client basis as well, so I guess there really is no easy way to modify the totals.

Anyway, too bad I have some monsters present only in one path. Seems the only thing I can do is add the kill count to the right number after choosing a path or right before ending the map (killtargeting the monsters didn't increase the number of kills in my tests, so I'll have to go with boss_death10). Maybe I'll go with right after choosing a path, so the player can keep looking for enemies in a given path before exiting the map to make sure they've exterminated them all. >:D 

shove a trigger_teleport over the untaken paths (one per). trigger it when you feel evil.
all monsters within the triggered teleporter will be teleported to a single spot, telefragging all of them instantly without needing to do anything per monster.
bonus points if you can come up with some logical reason for the gibs to appear in front of the player. spontaneous fountains of gibs! 

Oooh, I like it! It gave me the idea of adding a Doom 3 like teleport sequence at the end, where the player flies through a hellish shower of red. 

sn't there a problem that in vanilla you don't have multiple targetnames? If you have a single trigger_teleport linked to two info_teleport_destination entities they must have the same targetname. When you killtarget one, the other gets removed as well. I think you need a separate trigger_teleport for each destination, and killtarget that instead (or just only ever trigger one of them).

I forgot that. I have done it with using trigger_once or multiple as intermediates but it was for func_walls and triggers. That way for one route the end entites are killed and for the other routes the intermediates. Teleport destinations can't use intermediates so in this case it cannot be used.

What could work is to put one trigger_teleport for each route on each enemy's box (all of the same route with the same targetname) and the destinations on the desired points and kill the triggers after the route is chosen. The downside is that no enemy can be put before that if only this method to deal with the enemies is used, can contribute to reach the limit for brush entities, and that teleporters have to be activated all of the same route at the same time. The upside is that it is quite fast to do.

killtargeting the monsters didn't increase the number of kills in my tests Interesting, i thought it did. Then try telefragging them like it does at the end of e1m7. 

Although not quite as spectacular as teleport gib fountains, there's a trigger capable of killing all the monsters within a trigger here (the second variety):

https://tomeofpreach.wordpress.com/2017/01/29/rapid-fire-trigger_hurt/ 

Can we do them?

For example, the regular torches and fires in quake create a sound that decreases as you walk away, and originates from a point in the map.
Can we do this with custom sounds? Is it possible in id1 or do we need to code something? 

I'm not entirely certain, but to my knowledge, any sound you intend to use in Quake must be precached, and this is done in your progs file. Thus if you intend to use a custom you must modify the progs.dat and therefore must create a mod in essence.

Arcane Dimensions apparently works some black magic to precache any sound you place in the ad/sounds folder and thus you can use your custom sounds without further altering the AD progs. It also supports attenuation (sound at a distance) with the speed key.

In summary, this has already been done but to my knowledge cannot be done in ID1. 

HexenMapper: something like in #8

You can, for example, use a 'notouch' trigger (ideally point entity) with a "use" "train_wait" or "use" "plat_hit_bottom" field or the like, and a corresponding "noise" "ambience/fire1.wav" key, provided the sound is precached as Redfield says. If it's a looped sound, it'll play forever from the origin of this entity, although it'll have a different attenuation than regular ambient sounds. As a bonus, it also possible to killtarget it if you want the sound to stop. 

For doors... The "effects" field... I would do this. I don't want a flame war... I have a sever impediment... It is not laziness...
It would be awesome to be incorperated in the Entity def's and qrk. files etc


Ric... Mapper since 99 

Got a challenge from a reader of the old blog and I can't resist a challenge. The basic premise is to have five statues in the map, where the most recently touched one is selected, causing it to be lit up.

It's a real multimedia extravaganza as well today, with a full write-up, an example map and even a video, so come on down!

https://tomeofpreach.wordpress.com/2018/02/22/five-statues-challenge/ 

While I know of talisa's/seven's nail-position fix which offsets the NG's & SNG's nails to come out of the barrel instead of your face when aiming upwards, I miss such a fix for every other weapon, especially the GL, which makes shooting upwards a PITA. I'm no coder and wouldn't even try to mess with the source code/progs.dat. So by request, is anyone else up to the task to do it? Thx in advance. 

I'm doing exactly the same thing in my current map, except with the AD entity state system, wouldn't have bothered ever trying in vanilla hah. 

Hot on the heels, the promised hack that lets us ignore the order the entities are placed in the map, but still dictate the order that triggers fire.

https://tomeofpreach.wordpress.com/2018/03/06/the-alternator/

The article also includes how to make an "alternator" - a setup where a single input trigger switches between activating two different targets. 

Imagine you have several shootable triggers or buttons and want to fire an event once a certain total amount of health has been depleted. The damage done to the triggers transfered to an independent source, so to speak. So you can shoot each a random number of trigger a random number of times and once the overall health depletion reaches n, the event fires. Basically like a counter based on "health" instead of "count". 

func_button.target > W_FireAxe notnull hack
W_FireAxe hits a func_door.
Func_door.health = 1000 or 2000 etc.

And voila, just add func_buttons. 

but, don't you want the player's actual weapon damage to matter? E.g. shooting it with 10 nails should cause less total damage than 10 rockets. 

Make as many "shootable buttons" that you need. Select all of them, turn them all into one func_door with a health value, give it a target, set lip equal to bounding box so it doesn't move. 

The sum of all damage done combined. No idea if it's possible, and the applications would certainly be limited. For the lack of a better example: a machine needs to be damaged by a certain amount in order to be charged or explode and there are several exposed shootable parts. You can focus on a single one, or shoot each of them equally - the event fires once its global health is depleted. 

Exactly was @ metlslime.

But yeah, turning them all into a single door or button should work. Though what happens if they are supposed to be spread all over the map 

yeah, will you exceed max efrags and it disappears? I think in modern engines the efrag issue is solved and it is always drawn maybe... 

Nothing as far as I know, so long as the lip is set right for whichever movedir is set. I can't recall if func_button has an option to be silent in vanilla, so a func_door probably would work better. 

And yet, I have another possibly simple or already-answered-but-I'm-too-dumb-to-find question: how to spawn fully functional movers like trains, doors and plats half-way through the map? Basically invisible until triggered and then working like normal entities. Think "use" "func_wall" but without being thwarted by precache functions.