The problem with your current approach is that the appearance of your entity isn't caused by the info_notnull spawn function, it's caused by your hacks. So there's no benefit to delaying the spawn function. You would need to delay your hack, but there isn't a function which can turn the hacked values on or off, our only opportunity to set them correctly is the initial load.

Instead, we need to think laterally. Go back to the original rotating entity hack, and then add an "origin" key to the entity of '0 0 -4000' - this probably positions it a long way below your map (if your map goes that far down choose another coordinate which is outside the map). This way the entity is present, but the player can't see it.

Then we add a "use" function to the entity of "SUB_CalcMoveDone". The idea is that rather than spawning the entity mid map, it will always exist and we will just teleport it into sight when needed. You can use the "finaldest" to specify the coordinates you would like it to appear at.

Bonus hack: if you are using the rotator hack, but would instead like to stop the rotation at some point, you can use the "use" function "SUB_CalcAngleMoveDone" to do just that. You can't start it again though... 

Man, I dunno how you folks figure out this stuff. Way above my head. It works great, though; can't tell what position rotation-wise the entity will be in when the player triggers it and causes it to teleport, but that isn't a big deal at all and I'm sure a number of neat things could be done by loading up a bunch of entities and teleporting them in while killtargeting the previous in order- might be heavy on the entity count but I'm not worried about that right now. 

Neat. As a matter of fact, I tried to get the same effect (sun gem), but didn't succeed. Seems SUB_CalcMove* has some unused potential. 

I'm actually planning to write a whole blog post just on this function, it's the best! 

Not sure if I'm just bad at looking for information or figuring out Quake C, but I couldn't find the answer to my problem:

Is there a way to change the number of kill/secret totals midgame? I'm working on a map with branching exclusive paths, meaning that you can't have all the secrets and kills in one run. I was hoping it would be possible to adjust the total counters for the kills and secrets upon choosing a path, so once you finish the path, you can still get a satisfying end screen with all the kills and secrets you can get for that path.

If that is not possible, the next best thing, I thought, would be to just trigger every secret and use the boss_death10 function for every monster one can't kill on a chosen path.

I'm just having a surprising amount of difficulty triggering the secrets in the desired fashion. I'd like the secrets to silently trigger (no sounds, no messages) once I choose a path.

There is a problem, however: There HAS to be a sound for the trigger_secret, it can't be set silent. It's not necessarily a problem however, if the secret is triggered so far away from the player that it's completely attenuated.

Another problem is the message "You have found a secret area!" Well, I figured I'd just find a workaround solution by just having the trigger_secret display a single space as its message. So the silent triggering problem solved, kinda.

Problems arise, however, when I DO want the secret to be normally triggered in a path where the secret is attainable. Since I have set the trigger_secret to display a blank message, I thought I'd just create a trigger_once with the message "You have found a secret area!" inside the trigger_secret but that creates a new problem: whenever a trigger_once displays a message, it can never be silent, either, even with the "sounds" key set to 0! So, when I touch the secret, I hear both the normal "secret" sound and the message sound from the trigger_once.

So that is where I ran out of juice and turned over to you guys: Any ideas? Is there a way to make a custom silent trigger_secret out of scratch with an info_notnull or something? I'm too confused right now to figure it out myself. @~@ 

There's no way you'll get a hack that changes the secret count or monster count mid-map. It's really hard to do even if you're making a mod for the game, because of client-server separation. The QuakeC always changes things on the server side, and relies on the engine sending updates to clients. The server by default only sends the secret/monster count when a player first connects. The code you need to manually send an update to a client isn't contained in the vanilla progs.

A hack to make a silent trigger_secret is pretty standard though. Add the following key

"sounds" "-1"

How it works: By setting an invalid sounds value, we skip the code which default the key to -1, and skip all the code which sets a path to a sound file in "noise". As long as "noise" is unset, the actual trigger code remain silent.

However, I have a better plan than that. It turns out you can create point entities with the classname "trigger_secret" (like a trigger_relay). Imagine that you have exactly one secret on each of your branching paths. Alter your map to contain a single point trigger_secret, and in each path's secret area, place a trigger_once which targets it.

This pattern easily generalises to two or more secrets on each path, so long as every branch has the same number of secrets, they can share the trigger_secret. And if one of your branches has fewer secrets, you could use the silent trick, but why not just add some more secrets to balance it out! 

we skip the code which default the key to -1
should read:
we skip the code which default the key to 1 

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.