The corpse removal in Chapters works exactly as you appear to have implemented it yourself. If you check out any monster that dies on a walkway in Chapters ( the ogre above the GL in chapter_secret for example ) you'll see his corpse sink through the wooden boards and turn black before disappearing.

Preventing the model showing through is basically impossible in Quake as far as I can tell.
Trying to skim the bottom off the model like a deck of cards would require that the polys be rendered individually and relative to world polys, which Quake simply doesn't do. I think that would need an engine mod. DP could maybe do it.

re: chapters progs. No word from necros, guess I'll have to email him again. Unless he responds here. 

OK, thanks. I'll carry on the way I'm going. 

What you could do is make an extra animation sequence where the model itself sinks down, but that any vertex that is more than 2 quake units below the floor gets flattened. That way nothing would show through a floor more than 2 quake units thick. Of course, doing that kind of animation wouldn't be smooth on an engine without interpolation, so perhaps what you want is to move the model down as you animate it, flatten the vertices at -2, undo the motion downwards, then code it to move at the same rate you originally animated it at. Urrgh. But it should would.

Except...this kind of calculation is assuming the corpse is on a single flat surface. None of this would be valid on a slope. There would be work arounds to minimise that problem, like doing a traceline down, and using the trace_plane_normal to calcluate how far to put it down before playing the animation. And nothing you can do will help if the corpse hangs off the edge of a ledge. So yeah, it's never gonna be great, but it could work better 

nt 

I have tried to use the vermis from lost chapters in one of my maps.
It looks like the vermis dosn't respond to the flags 'delay spawn'. Since it is a void map the vermis is visible all over the map.
Is this a bug or haven't you given the vermis the spawn- delay/silent/alert flags? 

I'm working on a mod to help people who are pushing the limit of entites in maps. So far I've got rid of all info_player_starts, up to 16 of each of info_player_deathmatch, info_player_coop and info_intermissions. The entites are loaded in the map, but then the position/facing of each is stored in memory and the entites freed up.(thanks to the natural selection mod team for the idea of doing this, they do a similar thing to keep their mod running in half life). At this point I'd like to express my dislike for the original quake mappers who used info_player_starts as teleport destinations, it complicates the removal code.

Speaking of teleports, the mod also gets rid of info_teleport_destinations, by a similar method. Since you have another entity to store the location of the destination in, namely the trigger_teleport that sends you there, the method works for any number of teleports in a map. This is all automatic, build the teleport as you usually would and the mod does the fix. I'll probably get round to adding the teleporting monsters by a flag code soon.

I'm also hoping to add a few options for corpse removal. The options should be setable in worldspawn, and possibly per monster as well(overriding the general level preference). The options I'm considering are:

Never remove corpses(current behavior)
Remove corpses when running low on entites
Remove corpses when running low on entites, but attempt to make static corpses first.
Always remove corpses after x seconds
along with
Fade away on removal
Sink away on removal
Burn away(think doom3) on removal

The remove when running low on entites needs a bit more explanation. I now have an entity counter running in the mod, that will know when there are few entities left, and when you get close to the limit, the mod will start removing 'expendable' entites. This includes things like explosions, flying lavaballs(although not the spawners) and if you set the flags to do so, corpses. Corpses would probably be the only things to have an effect applied when removed, the others would just disappear. The list of expendable entites would be adjustable, so if you felt backpacks belonged on there, or had rubble spawned from an explodewall you added, then this could be made expendable.

The static entites for corpses is something else I just came up with. There are three reasons why you wouldn't just make every corpse static. One is that, in deathmatch, corpses disappear after a while, so they aren't static, although this only applies to players. The second is that there are only 127 static entities available, and some are already used for torches. The third is that sometimes corpses aren't static, for example if they are on lifts they should move.

The second problem is easy to fix, you keep track of how many static entities you make and stop once you reach 127. I thought the third wasn't fixable, but then I discovered a poorly documented feature in defs.qc - .groundentity. It tells you which entity another is resting on. So wait for the entity to land, then any that land on world can be made static safely.

The final thing is that freeing up entities afterwards isn't much help if you don't use them again. Some of them will be useful for projectiles and the like. To really take advantage of them though, I'll add group spawners like kinn did in Bastion, so you can spawn many monsters from a single entity 'in formation'. You'd have to make sure that enough monsters were killed in previous sections, but then it should work alright.

So, is there a demand for a mod like this? Or anything else that belongs in the project? The scope of it is making it easier to map/work around limitations in the engine without changing the gameplay. Like adding the option to set a player's starting ammo/health/armour/weapons from the spawn point, rather than putting entities on top of the spawnpoint to achieve the same effect. 

Well, what I thought was working last night, was not working last night as I thought!

With a SUB_Corpse_removal added to subs.qc I had what I thought was a nice gentle sinking of the monster: it looked real good. What I didn't realise at the time was that it continued sinking... on and on throughout the map.

When I introduced a SUB_Remove it removed the monster but so fast that you didn't see the sinking action.

What I have ended up with is this after the final monster death frame:-

{
if (!self.corpse_delay) // if no corpse delay set in map
self.nextthink = time + 120; // remove after 120 secs anyway ( may not want this???)

else
self.nextthink = time + (self.corpse_delay); // remove after corpse_delay seconds

{self.think = SUB_Corpse_sink;}

};


And this as the new SUB:-

.float counter;
void() SUB_Null = {};
void() SUB_Remove = {remove(self);};

void() SUB_Corpse_sink =
{
self.counter = 0;
{while (self.counter < 16)
{
self.origin_z = self.origin_z -(1);
self.nextthink = time + 0.1;
self.counter = self.counter + 1;
}

self.think = SUB_Remove;
}
};

The counter was supposed to give me a 'sink' of 16 units. Adjusting the nextthink time has no visible effect.

Are you able to spot my newbie mistake here? 

the while loop runs until it is finished. It doesn't pause at the nextthink line. What you should do is change the while to an if, and then put a return; after the self.counter = self.counter + 1; line.

Also, try to reuse an unused entity field instead of adding a new one. (.counter.) I believe there's a .count and .cnt field that monsters don't use.

Finally, you might have to call setOrigin on the monster, because I'm not sure the direct origin change is reflected in the game. 

Move the line self.counter = 0; to somewhere it isn't called everytime SUB_Corpse_sink is called. As it is now it is reset every time the function is called and the monster sinks forever. 

Add a self.nextthink = time + 0.1; before the final self.think = SUB_Remove; line. self.nextthink is already at time when it gets there. 

Thanks, I'm on to it right away. 

All done and working. Thanks.

I haven't altered the origin changing as I had already seen that that part was OK.
I had already been down the 'if/then' route but the two main errors were: resetting the counter wrongly, and the missing self.nextthink before the SUB_Remove.

Once again, thanks. Now, back to mapping... 

I thought .cnt was a nice safe field for monsters, I was wrong. It's actually used for checking the refire rate in nightmare skill. So it's probably safe to use here once the monster is dead, and won't cause terrible problems if you use it for storing properties like spawnflags(it'll get reset after one pass through the ai system - at most two shots). But don't use it for something that needs to persist throughout the lifetime of the monster, or it'll break in skill 3. A few safer fields for monsters are

.worldtype (only used by the world, a total waste in the original code)

.light_lev and .style (only used for lights, and even then mostly for the compilers)

Nearly any of the player only fields are safe for storing things, although super_damage_finished does actually work on monsters apparently(this field is how long quad damage lasts). Confusingly enough, .count works fine on monsters, as it's only used for triggers. 

What are the points against using new entity fields?

As a by-the-way Preach, 'style' is already in use via your teleporting monsters routine. 

Well, of models anyway.

Following-on from some previous postings, I still couldn't figure out the origin of the model and how to calculate the bounding box for the editor. In addition, I had noted the some models required to be off-set in the editor to appear correctly in-game, which I find quite annoying.

So, a couple of points have now just sunk in (it's his age doctor, his age), and being the kindly benefactor that I am (as long as money is not involved), I will share with... well, anyone else who couldn't figure it out (unless I am the only one. Mmmm, that would make me totally unique :-)

One, the model's origin is set by the model editor (I am using Qme).

Two, the origin is at 0,0,0 in the editor view

Three, beware (and this is why it took me so long to work it out) there is an Eye Position in the editor that can enable the model to be viewed off-origin but without altering the origin.

Four, the upper and lower box bounds shown in the Model Properties window are correctly shown relative to the origin, regardless of the Eye Position. This is vitally important when placing light sources.

So it boiled down to not realising that there was an Eye Position and that if one had been set, the origin was not as it appeared to be in the Frame Editor window.

All of this means that I can now place my models correctly. Phew! 

Now, the logic gate thing is very nice and all, it's very flexable and all, but it's a bit of a hack, and the fact that the projectile has to move a distance means you'll never get an instant reaction. So, if you want to know a way to do a simple trick - having a trigger that you can't touch until you fire another trigger to activate it - using the bare minimum of entities, read on.

The switchable trigger starts life as a info_notnull, that most versatile of quake entity. The whole thing hinges on making one that is not a point entity, but a brush entity(in fact, the brush should be the trigger you desire once it's switched on). There may be an easy way to do this if you mess with your config files for the editor, but I did it by hacking the entities with adquedit. The way to do that is to create a point entity info_notnull with the required properties, and a trigger_once with the required size. Then, use adquedit to extract the entities, and open the ents file in notepad.

Then find the trigger_once, and copy the "model" line. Paste said line over the origin for the info_notnull, replacing it completely. Then delete all the lines about the trigger_once, you don't need it.

So, what properties do you have to give the info_notnull? Basically these:
{
"model" "*2"
"touch" "multi_touch"
"use" "InitTrigger"
"target" "door1"
"targetname" "activatetrigger"
"wait" "3"
"classname" "info_notnull"
}

Quick explanations. The model is what we just hacked to make it a touchable thing. The touch is the same touch function as a trigger_multiple - but the info_notnull initially has no size, and so can't be touched, until you fire InitTrigger, in the use slot. The target and targetname are pretty obvious. Wait works the same as normal, set it to -1 to get a trigger_once.

You can also set noise directly here to the wav file you want to play. Bear in mind that it won't get precached by this entity, so you must make sure there's another entity in the map that uses and precaches this sound, even the regular trigger sounds. Most trigger_multiple stuff should just work, except targetting the trigger with another event. Since you have to target it with an event to make it a touchable trigger, targetting it again doesn't do anything.

One more thing to note is that this isn't a toggleable thing. It starts off, you can turn it on, and if you killtarget it you can turn it off again, but that's it. The only solution so far to a proper toggle would be a logic gate, but I'll work on it. There are lots of...interesting hacks you can do with an info_notnull, including a wall mounted ammo dispenser, (kinda reusable) gib fountains without telefrags, teleport flashes, and the classic explosion hack. Maybe I should put a page up about 'em or something. 

Maybe I should put a page up about 'em or something.

I think that would be a very good idea. 

Hello there :)

I'm currently building a map, and I'd like to implement explosions in it. They would be created by a missile launcher with a button, and when this button is pressed, an explosion (that always explose at the same place) happens. I use a func_explosive, but the problem is that, it only explose once and can't explose again even if I push the button again. That's pure logic, but I'd like it to create an explosion everytime I press the button. Is there a way to make reappears a destroyed block, or something else that would simply make an explosion everytime the button is pressed.

Oh and I have another problem. I use the target_earthquake function. It will imitate the explosion effect, but the problem is that it only happen once. It is activated by a button, I press it once, it works, but if I press it again, it doesn't work. Is there any ways to fix this?

Thanks a lot for your help!

Have a nice day 

Hello, I am having trouble with triggers in my map, what I want to do is have two trigger_once's and a trigger_teleport be useable as soon as the player grabs the gold key and not before that. What I've done is that I've put a trigger_once brush around the gold key, which has the target 'idiotkey', I've made a trigger_relay with the targetname 'idiotkey' and the target 'longwalk', and the two trigger_once and the trigger_teleport have the targetnames 'longwalk'. All of the trigger_once's fire at any time, even though 'idiotkey' hasn't been triggered, and the trigger_teleport never triggers.

Help, please? 

it seems the trigger_once (or you could put the target in the key directly too) is triggered on the moment you pick the key but not after that. So the teleport works only if you are inside the trigger_teleport brush at the same time you pick the key - i.e. the key is inside the teleport.

That is not what we intended.

How to "enable" or "disable" the trigger_teleport brush is the original main question here - if it's possible at all? Kind of an opposite to killtarget, like "enabletarget". 

The reason the trigger_teleport doesn't trigger is because if you give a teleporter a target, it only teleports things that are in the trigger at the instant it is teleported. That's how you do teleports for monsters, the teleporter isn't permanently switched on, just for the next 0.2 seconds. That value is hard coded into quake.

But, rejoice, there is a way to do it. Read a few posts up(3923) to my bit on how to activate a trigger using a hack based on the info_notnull entity. Following that guide exactly tells you how to make the trigger_once that turn on, make sure to set the wait of the info_notnull to -1.

You can also use the same trick to turn an info_notnull into a teleporter. Follow the same method as before, but instead of setting the touch function of the info_notnull to multi_touch, set it to teleport_touch. You will also have to set the target of the info_notnull to the info_teleport_destination as you would for a normal trigger_teleport.

Oh, one last thing I realised just before I posted, the whole thing won't work, unless you set the teleport trigger's .nextthink to 9999999, basically as large as you can. Of course, in theory somebody could play the map longer than this time, but plenty of other things in the quake engine will break before this time, so don't worry : -).

While I'm posting, there's a slightly easier way to make brush entities with a classname of info_notnull. Just make a new brush entity in your map, make it a trigger_blah(ie. a type of trigger that doesn't exist). Then give it all the fields the info_notnull is meant to have. Finally use adquedit to extract the entity file, and just rename the trigger from trigger_blah to info_notnull. You still need to go through all the hassle of extracting, editing and replacing the entities, but it's less easy to screw up if you're just changing one classname.

CrAzYCoW: What mod are you using for these effects? I'm sure it's a fairly easy fix in the source code, but since I don't know which mod you're using, I can't look at the code. I had a look at doing it with a hack in normal quake, but all I can do is fire player rockets from an info_notnull. I'm guessing you have the rocket already as a brush model or similar? 

Phait, you still need the levitating zombie, right? I got off my arse and completed something for a change, here's how you do it.

First, edit the zombie model. Duplicate the last scene, the crucified animation, and make it into a framegroup (right click and select 'Group frames for scene' in QMe). Then save the model.

Open plats.qc, and go to the very bottom. Duplicate the function misc_teleporttrain and rename the copy as misc_zombietrain. Delete the line that reads

self.avelocity = '100 200 300';

replace the lines

precache_model2 ("progs/teleport.mdl");
setmodel (self, "progs/teleport.mdl");

with

precache_model ("progs/zombie.mdl");
setmodel (self, "progs/zombie.mdl");

and finally add

self.frame = 198;

to the bottom of the function. And that's all, just set it up like you would a normal train. It really shouldn't have taken me this long to figure that one out. I'd copied the function for a func_train instead and was modifying that, for some reason the line

self.classname = "train";

causes Bad Things to happen if you use it for a zombietrain. So now it's fixed and works and I got another double-post in this thread. 

I will see how it works, appreciate your help :) 

but we decided yesternight to pursue the spikeshooter & door AND logic gate route for now... 

on another note, couldn't one do that enableable trigger inbuilt into quake.fgd so it works straight in worldcraft?