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. 

So I was mapping away and hit ctrl+s to save my map. However, instead of hitting it once, I hit it twice by accident and WC crashed (presumably whilst saving the map). I was a bit worried, but the map seemed to have saved fine and loaded up ok. The filesize wasn't weird either, so I assumed all was ok.

I continue mapping...

...hours pass...

...then I try to compile my map. It works, but I get a warning about a brush with 0 faces. It tells me the texture used on the brush, so I assume this is 0 faces after plane conversion. The error pops up twice more, once for each hull.

I did notice later whilst mapping that some unimportant brushes had vanished from my map when I reloaded it. Presumably, one of these brushes was half saved or something. Perhaps it's just a dodgy brush I managed to create with the clipper - but this normally crashes qbsp, so perhaps not.

Anyway, the question: How the fuck do I find and eliminate this brush? I could copy all the changes from the new version of my map into an older version, which would probably eliminate the warning, but it seems like lots of hassle for nothing. I won't convert to .map and find it in radiant, because I need the .rmf file for visgroup info as the map is very big and impossible to work with without them.

Can I find the coordinates of this brush with qbsp at all? The only info I got was that it was a brush with no faces and that it was using the texture hstn0. There are a lot of other brushes using that texture, and I can't find it using a text editor because I don't know exactly what I'm looking for and the .map file is huge.

Currently it is not a major problem (I hope), but if you, the A-team, or anyone else can help me, please reply. 

Holy crap, 8000 brushes in 1 Q1 map file? Haven't you run into map size/face/etc limits by now? How long does the beast take to fullvis? Also, screenshots plz. 

I pwn! Of course, I should probably have tried harder to fix it before posting the above message.

For other people having problems with Rogue brushes, esp. those using Worldcraft, here are some tips:

1. Check to see if there is a brush with centre on the origin - in Worldcraft there should be a cross handle if there is. This could be the culprit.

2. In WC it is entirely possible to create invalid brushes if you don't know what you are doing, and often when you do. The worst kind are thin slivers created by cutting along a plane of a brush using the clipper. Try to be careful not to do this, because the slivers will crash bsp and can be hard to track down.

3. If you can't find a problem then try exporting only visible stuff to a map file and compiling. At first hide large chunks of the level. Once the problem dissapears, you know roughly which area the problem is in. Gradually export less and less visible brushes until you get something manageable containing the error - maybe a few hundred brushes at the most. This is easy to look through in the editor, and can also be checked with notepad without problems. 

Tyrann has more in his map :)

I will probably be adding another 3000-4000 brushes. Hopefully it won't fuck up. The only thing I have to watch out for is the lightmap size and model precache problems. I want this to run on fitzquake, so don't want to exceed any limits like that.

The level isn't THAT big. It isn't small by any means, and packs a lot of gameplay into it, but it's no Marcher Fortress. It's not in a large style either, so no massive areas filled with 3478327 monsters and a quad - I wanted to make something a little simpler and small scale. I'm kind of regretting it now, but I think that I can still make it fun without changing what I have much.

If I can be bothered to make the planned follow up maps, then they will be on a larger scale (as with most current big maps).

It takes about 15-20 minutes to fully compile (light extra, not extra 4) I think. I have a pentium-m 2ghz 512mb system. When it is finally released, you will see that it isn't particularly spectacular scale wise, and that is probably why it doesn't take a long time to compile. That and perhaps my brushwork is decent. I dunno.

There are some old shots on my website http://than.leveldesign.org/ Maybe you can see from the screens that it has a fairly detailed look? There are lots of areas, and the detail level is fairly consistent. r_speeds don't really top 1000, but they are probably higher than usual.