amazing thanks, that should give me everything I need to make some nice corpses...

I tried setting angle as -1 and rotating the entity but it doesn't seem to change the angle it appears at. Say I want the player model to appear lying on its back facing upwards - shouldn't angle -1 do this? 

Also it seems like some models work and others dont. The soldier.mdl doesn't seem to work at all and the map wont compile.

Could this be something to do with quakespasm having less models in its pak0.pak and having them in a pak1.pak instead?

It seems to have the paks reversed compared the original quake paks 

Include at least one monster_army in your map.

Set yaw like normal to rotate the corpse.

-1 won't do anything since that is a special case for doors. Set the frame correctly and the model will be in one of its lying poses. You may want to check out the qc files to see which frames are death poses. 

ok cool, thanks. I tried adding a monster_army but now I seem to be having a problem of the entities disappearing when I select something else. Using TB2. None of the entities I've created are visible (I tried show all in the view) and the map is still failing to compile and citing lack of precache)

Here's the map file:
http://www.mediafire.com/file/hqd3m3bwq3qe61n/Outpost17.map

as soon as I deselect the func_illusionary entities they seem to disappear... 

"angle" is typically 0-359 like degrees for non-door/non-platform entities and operates as yaw (like pitch/yaw/roll, the 3 different x-y-z axis in Quake). 

func_illusionary was only really expected to work on inline models (ie: those submodels baked into the map). As a result it doesn't bother to precache the model (these are implicitly precached by the server).

The exact set of models that are already precached depends on the order that entities are loaded. So for instance you can use progs/soldier.mdl ONLY if there was a monster_army entity preceding it. the player's various models (player.mdl, eyes, backpacks, projectiles, gibs, etc) are precached inside the worldspawn entity's spawnfunction which is normally guaranteed to come first.

while there are engines that will automatically precache stuff on demand (ie: dp+fte+qss), these engines will generally warn, so its not something you want to do other than as a last resort, plus people hate engine dependencies.

func_illusionary forces angles to '0 0 0'. You cannot change the angles without qc.
If you want that then there's a more complex way using info_notnull, but figuring out the correct value for the modelindex field is a nightmare. 

ah ok cool. That should solve the caching problem. Not sure why the entities are disappearing though... 

Also how do I work out which frame to use from QME? QME gives me frame names like "deathc11", but the frame key needs a number. Is there a good way to work out what the frame number will be - I tried counting down from the top but it didn't give me the frame I was looking for. Say I want to use frame "deathc11" from the soldier.mdl - which number would I enter in the frame key? 

QME: Bottom Left corner when you select a frame, it says "Frame: 005 walk1". You have to click on the frame otherwise it doesn't say, haha. 

Ah yep, perfect. thanks! it works.

Now I just need to work out why the entities disappear after I select something else... seems very strange 

Maybe TB2 doesn't see func_illusionary in its fgd file as a point entity since ot is only defined as a brush entity...and deletes it! Protect you sillt users from yourself. Ha, no its probly just a bug...ask about it on the TB thread. 

as soon as I deselect the func_illusionary entities they seem to disappear...

Check the View menu upper left side of 3d window. Make sure you somehow didn't accidentally uncheck func_liiusiionary. 

So here's a conundrum: there's two map hacks I'd like to combine, namely the one for delayed/dynamic entity spawning (https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/) and the one for rotating brush models in stock id1 (http://www.celephais.net/board/view_thread.php?id=37116&start=330&end=339). Both of them work properly on their own, but combining doesn't quite work as it means trying to turn an info_notnull into another info_notnull (to expand, the entity doesn't stay hidden until triggered like it should because it's already an info_notnull with the proper fields to act as a rotating, visible brush).

I even tried a number of hackier methods, like making a specific texture for the brush entity with the starting texture completely transparent and the secondary (+a) texture, then triggering the func_wall so it would change texture- no go. The original model will change but the 'cloned' rotating one doesn't copy it, and triggering the rotating model does nothing. Am I totally out of luck here? 

^To add on to that, after a bit of fiddling it turns out you *can* change the texture from the +0,1,2... set to the +a,b,c... set on the cloned model by adding 'func_wall_use' to the 'use' field on the info_notnull. That would normally make things very simple, as one texture set could be made transparent, but apparently animated textures with alpha masking isn't possible (at least in Quakespasm) due to conflicts between the required first character- { tells it to take color 256 and turn it invisible, but then ignores any other special character; likewise, + allows for an animated texture but doesn't allow alpha masking.

Back to square one, I guess. 

{
classname info_notnull
avelocity "0 90 0" //spinning the whole time
nextthink "999999999" //otherwise func_wall(read: movetype_push) will not spin/move. this persists through both spawn functions.
think "SUB_Null" //just in case someone leaves the map running that long. note that it'll stop spinning, but at least it won't crash.
model "*1" //not visible until func_wall uses it
modelindex "" //MUST be omitted/blank/0, otherwise it'll be visible as something BEFORE its triggered.
use "func_wall" //what to call when triggered
targetname "spawnit" //what to trigger
}


will give you an invisible info_notnull that effectively becomes a rotating func_wall when triggered, is the theory.
(if you killtarget a normal func_wall at the same spot, you can make it appear as though it simply started rotating).

note that if there are any entities inside your pusher at the time that its triggered then those ents will get trapped and maybe block the rotation.
due to engines that don't support proper rotation physics, you should probably just make sure the player can't walk through it with eg a clip brush surrounding the area. 

Works in theory but doesn't quite work in-game, unfortunately. Copied it exactly other than the targetname- it acts like a standard delayed func_wall, solid with no rotation at all; including the
'movetype' '8'
field from the rotating brush hack was my first thought but that didn't change anything. 

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.