Is there a hacky way to use trigger_push entities that only work after having been triggered themselves? The standard use/touch "SUB_Null" hack doesn't seem to work, but maybe there's another method.. 

Not got time to test, but I suspect it would if you set movedir manually to the unit vector in the direction you want to move them. Sorry if you've tried that already... 

http://negative.net.tc/images/fitz0000.jpg
The left trigger lowers the lift (toggle door), the four small ones are fake buttons on the lift itself. Is there a way to trigger them so they'll wait until the lift has made its move (so it doesn't go down again immediately when touching the upper triggers while moving up)?
Simply triggering them restults in a crash. I couldn't think of a workaround (maybe there is none). Of course, if everything else fails, I'll resort to a regular button solution, but I wanted to try the fancy way first. 

There's a hacky way to do it. Basically mimic the usual logic gate setup, so each of the four small triggers fires a trap_shooter at a trigger_multiple with health somewhere away from the main map. You'd need one shooter for the top pair of buttons and a different one for the lower buttons. The trigger with health targets the lift.

You then have another toggle door with the same targetname as the lift which blocks the shots appropriately. So while the lift is moving up, this door must block shots from both shooters. When the lift has reached the upper position, only the shooter linked to the top 'buttons' can see the trigger with health, and vice versa.

You can probably simplify the setup a bit by thinking about how long the trigger with health takes to reset after it takes damage. If you make this amount of time the duration of one movement of the lift, then it doesn't matter whether the shooters can see the trigger with health while the lift is in motion.

As a final nice touch, you can make the 4 mini triggers silent, and have the button sounds played by another entity, triggered with the same name as the lift. That way the feedback to the player is better, as they'll only hear trigger sounds when the button has actually worked. 

Works perfectly, thanks. 

I'm checking out Quoth at the moment, and combined Necros' bunch of .def files into a unified Quake/Quoth .def for me to use (there were a lot of duplicates, and some missing entities, and no references to models, so Quest suddenly didn't draw the models anymore.) I think I got most of it right, but there are some blank spots.

The missing ones:

monster_vermis
weapon_bomb
weapon_plasmagun
weapon_hammer

I think that's all.

Could one of the Quoth guys post the .def entries for those entities? Especially the bounding box stuff.

I know your time is limited, but I could safely use Quoth for my project then. 

But why not copy another weapon and rename it - they're all the same apart from name.

The Vermis is

(-64 -64 -448, 64 64 256)

with the 'bulb' being in the centre of that box. It's pretty good at clipping the player with its throw attack, so give it around 256 units in each direction to throw the player; or stick it in the middle of a pit.

Also try and make sure it clips as little as possible with the floor; there's a bug where it can throw the player through walls. 

Thanks :-) 

I got the following message while loading my map:

"Error: Too many static entites"

What am I suppose to remove from the map in order to solve it ?

Thanks in advance... 

torches/flames, illusionaries, globes/bubbles 

Thanks, I loaded the map with aguirRe's engine, and it shown that I exceeded by the limits by 3... I just made a test removing 4 lights: I hope it will work now ;)
In anyway, thanks for the reply: you rock ! 

If you want, you can quite easily modify the qc so that torches have a spawnflag for not being static entities, if you want those three torches back, and have the dynamic entities to spare. 

Bubbles are not static, I think. 

Even simpler: use the info_notnull modelindex hack for dynamic torch models along with three independent light entities. 

.. it's not my cup of tea... and maybe I will have to split the map in order to avoid such problems... I'll see...
Anyway, thanks a lot for helping ;) 

what advantage does an entity actually gain from being static?

i've had the problem before and have noticed the 'makestatic' function in qc.. thinking how simple it would be to remove it altogether. but would that cause problems further down the line? 

They don't ever get sent over the network once the client receives them, which saves bandwidth and protects a little from packet overflow, although since the entities don't change it's not much good. The main advantage is that it saves you a conventional entity slot, and there are only 600 of them. 

Well, the whole thing is academic, since these limits were put in place for PC's made ten years ago.

It's why I prefer to work in AguirRe's engines. 

Windows was put in place for PCs made 10 years ago :-D

It's not good if OS-specific code is introduced into originally multiplatform software, or if projects (including their dependencies) depend on specific OSs. Windows development environments seem to have a tendency to automatically introduce Windows dependencies in the code...

I don't think that is an academic question at all because you can't assume that everybody on the globe uses Windows in the year 2007.

Platform independency == User friendliness! 

Fair enough, I suppose its far from academic if you can't run the stuff yourself.

I've always used windows (Mac a few times) mainly because it's what everyone else has ie. few compatability problems. 

"everybody else has (Windows)"

see? that's the problem. Once someone else is using Linux, you've got a huge compatibility problem.

It's not a law of nature that the Linux user accepts your proprietary .doc files for example. Unix has been around longer than Windows, so I could very well tell Windows users to "read the f* manpage."

I'm really not trying to start an argument, just pointing out that that ("everybody uses Windows") is subjective perception. That was a practical argument in 1998 in most of the USA and western Europe, but it isn't anymore.

I'm not "nobody."

Just the same you could say "everybody has 3D hardware and a recent computer, so we should get rid of software rendering" or "everybody has DSL so we should make Quake demos AVI format."

Same thing; I could imagine a dozen cases where someone has good reasons for not meeting those criteria.

:-) The world is bigger you know. 

I was agreeing - it's a misconception - 'everyone' 

since these limits were put in place for PC's made ten years ago.

i had a question about that, actually.

iD had self imposed limits on maps (like total texture size), so why did they also have engine limits? if they had made quake to have a max of 5 billion edicts, but only used max 256, would it have mattered? is there some actual programming reason behind it, or was it an arbitrary choice? 

if you use linux you are a pederast 

Small number ranges require less memory. In particular, integers in the range 0..256 will fit in C's unsigned char type, which takes up less memory than short/int/long integer types (on most machines).

If you only have a few megabytes in which to fit everything, cramming numbers into these tiny ranges becomes crucial. For another example, see Quake's wobbly animations - you can clearly see vertices snapping from one value to the next.