Thread title "Teaching Old Progs.Dat New Tricks" means needs to work with original progs.dat, typically via entity/think/field abuse.

It's a shame you don't play single player maps, some like negke manage to do seemingly impossible things in maps that work in original Quake. 

Is there a way to place a static corpse in vanilla quake? Like a 3D model of a killed grunt or something? Is there a way to add custom entities? if so is there a place that has models of dead grunts or enemies?

Thanks 

You can do a corpse in a map. Do a func_illusionary and set the model (like progs/player.mdl")and frame number (like 169).

In vanilla quake there is no way to add custom entities. 

Interesting, thanks. I'll have a play around :) 

So i create a brush entity, set it as func_illusionary, and then add the keys "model" and "frame" ?

Like this?
http://imgur.com/7bNARAr 

Create a point entity, set the type to func_illusionary and yes change the "model" and "frame" (it *may* be "mdl" if "model" doesn't work).

Like if you were creating a monster. 

(There are differences between TrenchBroom and Jackhammer. In Jackhammer, you create a point entity and change the entity type. I would assume you can do that in TrenchBroom, but couldn't swear to it.) 

Ah yep it works! great. Is there a place that shows the various model names? like gibs for example? 

Open up pak1.pak in Pakscape 0.11 and look in the progs folder. To find out frames, you would have use QME to look at the different model frames.

https://www.quaddicted.com/files/tools/qme31.zip

Without opening a model in QME, it's gonna be hard to pick the frames for most models as all the monsters have dozens of frames.

You also may want to set "angle". 

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.