put it this way, use it when you need to use it ;) 

I was wondering how the skybox is used in Quake1 maps. Not the regular one, but the same as in Q2. 

Is your email working? 

Is there an easy way to allow monsters to use this: I do not want to use trigger_monsterjump? 

Monsters are effected by trigger_push by default.
They won't actively seek it out in any way, but when they touch it they will be sucked in. 

I'm dropping a spawned ogre onto a trigger_push and he just does his own thing?

If I go onto it, everything is fine... whoosh. But he just runs up and down the length of the trigger and even stops in the middle of it if I no_clip and hover above him.

Any ideas? 

:( 

Oh dear :( 

I'm guessing (wildly) that it might be a conflict of sorts between the movetype of monsters and the monster being on the ground.
Perhaps try throwing the monster into the trigger with a monsterjump?
Also, if the monsters starts inside the trigger, there is a minute chance (or any chance at all?) that the touch isn't registered. I doubt this though.

I remember the good old map grc4beta had a fiend traveling down a windtunnel early on in the map, but I'm not sure if the trigger_push was overlayed by a trigger_monsterjump there or something. 

but never an ogre.

I have only ever gotten a monster to jump with a trigger_monsterjump. In fact, the only other things I have ever successfully seen respond to a trigger_push (besides the player) are grenades.

Let me know if you get it working :) 

CZG - Whats your email?
I tried the one in czg07 readme . . . I�d post the message here but I�ve goofed before on spoilers.

Website - how do I review old threads? (ie. not on the main page)

Thanks 

Looking at the triggers.qc it seems as though this works by use of 'velocity', which is not how monsters move. Therefore, it does not affect monsters; therefore, there is no easy way to use it for monsters without writing some code. 

OK, I'm getting there. I can now get monsters using the trigger-push, but it now leads to another problem...

How does the 'angle' entered in the editor get converted to the self.angles vector used by the qc code? (I'm making this assumption because 'angle' is not seen in the code) 

The trigger_push uses the movedir vector for the direction that the velocity is added in. Movedir is set in the function SetMovedir() in subs.qc. SetMovedir() is always called by InitTrigger. The function setmovedir is quite self explanatory once you understand how .angles is set. Essentially the editor sets angles to '0 a 0' where a is the value of angle(note the absence of the s). This only allows you directions in the xy plane, so there's an extra hack added. If the angle is -1, Setmovedir converts this to a vertical vector pointing up. Similarly -2 produces an vector pointing down.

It's not a great way of doing it, since you can't have motion that's diagonally up and across. A good fix that would be backwards compatible would be to have a check before calling SetMovedir to see if movedir is already set. If it is, then normalise it but leave it otherwise unchanged. If it's not, call SetMovedir. That way you can choose to set the angle normally or override it with a custom movedir. 

There are copious enemies in RPGSP1 that use trigger_push. When I tried it again years later, I too had difficulty. The fact that it works in RPGSP1 might be because I simultaneously spawned the monsters into the trigger_push and woke up them up at the same time. I.E.:

"classname" "trigger_relay"
"target" "m1_1"

"classname" "monster_ogre"
"targetname" "m1_1"

"classname" "trigger_teleport"
"targetname" "m1_1"

The monster was in the teleport, and the teleport targetted a destination hovering in the trigger_push.

Best wishes. 

My ADSL line is still down at home... sorry for the delay... you have mail ;) 

Well, rpgsp1 certainly works. (I enjoyed replaying it just now :)

It's interesting that you had problems 'years' later. I wonder if the progs.dat has evolved so much over the years that it has affected this particular area?

The most obvious thing that has changed with my progs.dat is that I no longer spawn monsters via the trigger_teleport method.

I have the (now, somewhat amended) 'style' flag option first put forward by Preach, and I have added an 'anger' flag to ensure transported monsters can be made angry as soon as they arrive if necessary to avoid extra triggers.

As I have now resolved my trigger_push problem by further qc enhancements (mmm... I use that word very reservedly in the light of this issue) I don't have the enthusiasm to revert to an old progs.dat to prove/disprove any of this. I am confident that what I am now doing is working OK, so I will press on with the map regardless.

But as always, it great talking to you guys and great fun trying to overcome these problems. Thanks for joining in.

Now all I've got to do is perfect the random trigger_monsterjump height/speed aspect and we're all cooking on gas... 

The error is pretty easy to understand:

---- GrowRegions ----
model : *160
classname : func_door
*** ERROR 13: Entity with no valid brushes or textures

I used the problem checker in Worldcraft, and it also found some doors without brushes. I deleted them and recompiled, but got the exact same error. I opened the .map in a text editor and searched for all instances for func_door. There were a lot, but none of them were lacking brushes.

My map was compiling with no problems yesterday. I made some small alterations today and I get this shit. I haven't even modified or added any func_doors.

Could this be a WC glitch? The map is over 8000 brushes now - anyone else gone over that in WC 1.6?

There are 160 solid ents in the map, so presumably entity 160 is the problematic door that apparently doesn't exist.

Anyone got any ideas? 

The error is pretty easy to understand:

---- GrowRegions ----
model : *160
classname : func_door
*** ERROR 13: Entity with no valid brushes or textures

I used the problem checker in Worldcraft, and it also found some doors without brushes. I deleted them and recompiled, but got the exact same error. I opened the .map in a text editor and searched for all instances for func_door. There were a lot, but none of them were lacking brushes.

My map was compiling with no problems yesterday. I made some small alterations today and I get this shit. I haven't even modified or added any func_doors.

Could this be a WC glitch? The map is over 8000 brushes now - anyone else gone over that in WC 1.6?

There are 160 solid ents in the map, so presumably entity 160 is the problematic door that apparently doesn't exist.

Anyone got any ideas? 

definitely only pressed submit once.

I tried removing the last entity I added (a func_wall), which didn't help. The door became ent 159. However, saving only visible objects with my funcs visgroup turned on allowed the map to compile, so perhaps there is a brush somewhere that has fucked up, or a rogue func in another visgroup that is causing the problem. 

problem fixed.

It was a fucking clip brush that I had accidentally tied to an entity. Thank god for being able to export only visible and visgroups, eh? 

was no valid brushes (or in this case their textures) ... 

It should be possible for qbsp to create doors out of clip brushes. However, due to an engine bug they wouldn't actually work :) 

do work if they include at least one brush (face?) with a visible texture. i made such a door by accident in sm108. 

yes, but even then, there's an engine bug where the physics bounding box of the door will only include the visible brushes. So to make it work reliably, you can't have any clip brushes sticking out past the bounding box of the combined visible brushes.