trigger_push Created 17 years ago2006-11-01 01:32:52 UTC by S.O.T.E.

Ok, small question here for CZ:
I read the entity tut already, but I still can't make the trigger push up.
I set the compass to "up" but it didn't work.
In "pitch yaw roll" i set it to 90 0 0 but also didn't work.
Thanks in advance!

Perhaps it's not strong enough?
What is it that you want it to push?

Ingame, walk into the trigger_push, then jump up. There you go. Kind of weird you need to jump in order be pushed up by it.

You can solve this by removing 1 unit of height in the ground where the trigger_push is, thereby making the player "fall" for 1 unit. That should push him up.

That should fix it. And then fill it up with a brush, 1 unit thick, func_illusionary.

Ahh, ok, i'll try.

The strength must be stronger then 1000 in order for it to push upward. Check my example map about the great leap. I encountered the same difficulty but then found the answer I mentioned earlier.

Another problem is that it doesn't push the player if he is on the ground. Lower the strength of the trigger in my example map to 1000 and you'll soon notice that if you hit the floor the trigger stops affecting you, but jump and it'll push you upward.

I tried func_firiction but it didn't work. Maybe an invisible func_illuosinary with the volumetric light flag on will do. This way the brush will act like water, keeping you away from the floor. If the push can push somebody while he is in the water it is bound to work... if not...

Ahh, so that's why!
My push was always set to 300!
Thanks!
Btw, I want the player to jump to get him to get pushed, so i won't need the illusionary, but thanks anyway!

***Edit***
OK, the push works fine (thanx guys!), but now I have a new problem.
My env_beam is deactivated when the bomb blows, and the next round it stays off. I know this question has been asked before but I can't find the post. So how do I reset my entities each round?
Also, is there anyway to make a train rotate 90 degrees when it reaches a path_corner?
Thanks!

Set a door somewhere off the map inaccessible by players, and set the target of the door to a multimanager.

Since doors are resetted every round in CS, it will trigger the MM. Set the MM to target a trigger_relay (with target state of "on") which targets your env_beam.

I think.... it should be right =

Oh, cool, ok thx!
Wait, can't i just target the trigger_relay directly from the door?

You could do that. I prefer to target the MM from the door as it is triggered every round restart, so maybe if I need to reset other entities I can simply add it to the MM....

Ohhh, ok thx.

Hmm, ok, everything works well, except I have this trigger_hurt and i set the delay to 5 but it still whacks me once I step into the hurt zone. Please advise...
Oh yeah, also, is it possible to rotate a model?
Thx!

***Edit***
Argh!!!
Sorry!
I double-posted!!!
I only remembered after posting...

1) Use a multisource to disable the trigger_hurt. Type the name of the multisource in the trigger's master value. When the multisource is oporational so will the trigger be, and if the multisource is'nt so will the trigger wont work. Simple enough. But make sure you tick the trigger_hurt's start on flag, or else it wont work. The multisource starts initialy off so when the level will start the trigger will be disabled.

2) Use the cycler's pitch yaw roll value. If there is no such value then create one.

Almost speaking of trigger_push, I have a small question to add here. When ever I use a trigger push to shoot the player up in the air it doesn't matter if he falls on it, I still fall unless I reach the ground and then jump. It's a major problem in a map Im working on. What is the problem? And yes, I've tried all different settings and hights for the player to fall and all that, even tried to set the push to insane values as 10000, but I still need to jump.

Try placing a thin nulled func_illusiounary with the volumetric light flag on. This way it will act as water and keep you off the ground. Don't know if it'll work, never tried it myself.

Thanks anyway

Wow, complicated...
What is the pitch yaw and roll?
I know pitch:
-90 = down
90 = up

Check the name of the value in a diffrent entity(turn smart edit off, of course) and copy the name to the cycler entity(smart edit off) then type the value you want.

Ahh, ok.
1 more thing (i hope):
Why does my map always appear as full-brite even though there is 1 light_enviro and 1 light???

There's a leak somewhere in the map, check the compile log.

Nope, no leak.
I would know. I have a lot of experience with leaks.
My first 4 maps had over 100 leaks.
Will it work if i put a light with brightness 1?

Post your compile log, a -LEAK- isn't the only cause to full brightness.

hlcsg v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlcsg ---
Command line: D:SierraExtrasZHLThlcsg.exe "D:SierraMap Testde_zero-gravity_cz"
Entering D:SierraMap Testde_zero-gravity_cz.map

Current hlcsg Settings
Name | Setting | Default
--------------------|-----------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ legacy ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]

Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]

73 brushes (totalling 438 sides) discarded from clipping hulls
CreateBrush:
(0.25 seconds)
SetModelCenters:
(0.00 seconds)
CSGBrush:
(0.36 seconds)

Using Wadfile: sierracondition zerovalvehalflife.wad

• Contains 44 used textures, 100.00 percent of map (3116 textures in wad)

Using Wadfile: sierracondition zeroczerodecals.wad

• Contains 0 used textures, 0.00 percent of map (237 textures in wad)

added 5 additional animating textures.
Texture usage is at 0.61 mb (of 4.00 mb MAX)
0.83 seconds elapsed

--- END hlcsg ---

hlbsp v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: D:SierraExtrasZHLThlbsp.exe "D:SierraMap Testde_zero-gravity_cz"

Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Normal ] [ Normal ]

noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 8192)

SolidBSP [hull 0] 500...723 (0.05 seconds)
BSP generation successful, writing portal file 'D:SierraMap Testde_zero-gravity_cz.prt'
SolidBSP [hull 1] 500...1000...1122 (0.08 seconds)
SolidBSP [hull 2] 500...1000...1053 (0.08 seconds)
SolidBSP [hull 3] 500...1000...1112 (0.08 seconds)
0.86 seconds elapsed

--- END hlbsp ---

Is that the whole log? If so you forgot to run vis and rad. Vis is resposible for creating leafs that determine from which place each face will be rendered. Running it lowers drasticly the r_speeds since it unrenders many faces that are unseen during the game. Rad calculated the lighting and in order for it to work, vis must first make it's culculations.
So if you have a fullbrightness problem it is usally connected with vis, rad or both. In a leak the problem is that vis and rad wont run, and if they did it would still be very problematic, from other prespective.(like preformence and long compile time)

Ahh. well, that is the full log, but its the latest (and the one that's causing my problems) cos somtimes, I'm able to run the full compile but other times, it runs halfway and then hangs. But i still have the .bsp though i have to hardkill Hammer. When that happens, my .bsp is 500+ kb but if it works properly it gets close to 1.6mb
Normally, how long does it take to compile 2mb map?
Btw, here are the pics.error1 = all the "invisible coulours" (blue) appear visible. I assume its the vis...error2 = yeah, the fullbrite. The only light in that vent is supposed to come from the blue emergency lights at the ceiling, but even that is supposed to be blue and have a brightness of 100.

The reason the blue parts appear ingame is because you didn't tie them to a func_wall and set the render properties properly.
Render mode: Solid
Render amount: 255

You just didn't run rad and vis.

BTW: Vis has nothing to do with texturing. Here is a full explantion on what each phase in the compile does:

CSG:Creates all brushes, faces, textures and entities in the bsp.

BSP:Creates the 4 hulls the level must have. The first one(number 0) is the visible hull and the rest(number 1-3) are colusion hulls and determine what is passable and whats solid. A leak in a first only hull is a small one that the other hulls can still be completed. A leak in the other hulls is larger then the player, hence no hull can be completed.

Vis:Creates leafs and portals. They determine from which point each face is visible. All not visible faces from that certain point wont be rendered, to some extent... With leafs a face wont be rendered if you are on the other side of the map while without, it will be, hence the major preformence loss when you are not running vis.

Rad:Does all light calculations, where it is dark and where it is bright. It needs vis' calcultions in order to work.

OK, I'll try recompiling again. Thx about the func_wall thing and the explanation on all the compiling phases. But I just need to know is it normal for a map to take 10++ min to compile???

Yes.

Ahh, OK!!!
MY MAP WORKS.
It took a friggin record time to compile!
34.26 min. What the
I timed the stupid thing.
Anyway, thanks a LOT guys, you were a great help!
All the lights are beautiful, and it stopped lagging!
Only ONE more thing now.
I realised something EXTREMELY stupid bout CZ.
When there is an amoury_entity on top of a func_breakable, and you break that object, the weapon remains where it is.
BUT when you place a weapon on a TRAIN, and the train moves away, THE WEAPON FALLS!
And that screws up my map cos the weapons are HIGh and HARD TO REACH, but once they fall, Ts get the immediate advantage cos the weapons fall in their spawn...
Anyway to either stop the falling or reset the weapons.
I doubt resetting will work, and im too lazy to try cos it takes 30min++ to compile...
***Edit***
Oh yeah, nvm, I thought of it! I'll put block below the weapons and give it an {invisible texture. Now why didn't i think of that...
Besides, it doesn't matter if objects overlap right?
Oh yeah, and here are some pics.
The lights, T base and inside a spaceship (with an awp, hehe)
Thanks again guys!
Love this website!

The compile takes a long time because you didn't make anything complex a func_wall.

It took such a long time because of the big open spaces. The Hl1 engine isn't really good in those and sometimes it gets really annoying. Especially in my maps, nearly every room or corridor has two or more floors.

Not to mention that each little square on those buildings counts as a FACE! I asume the texture's scale is 1.00x1.00 and I know the size of that particular texture is 16x16 so that means you have about 1000 faces on each building.
Leafs are calculated from each face and if one of these buildings is a world brush... (entities are ignored by vis) The number of leafs will probebly exceed the maximum limit by a lot.

OMG. I used a texture for those "buildings" that is the size of just 1 little green/blue/red spot.
Damn, no wonder...

Not to mention that each little square on those buildings counts as a FACE!

What? Since when did one texture tile equal one face? They would be faces if you had the texture misaligned and put it on a 16x16 block, then copied it a bunch of times to get the reuslt you see, but putting a small texture on a a large face doesn't make the poly's any higher than they would normally be.

Oh phew!
Yeah, about my models, I used a cycler and selected couch_leather_black.mdl but in game, the couch is there but its not solid. Only a small part in the center is solid, and when i shoot it, it bleeds black and white blood...
Any ideas?

Models are not solid when placed ingame, you need to add a clip brush around it.

What? Since when did one texture tile equal one face? They would be faces if you had the texture misaligned and put it on a 16x16 block, then copied it a bunch of times to get the reuslt you see, but putting a small texture on a a large face doesn't make the poly's any higher than they would normally be.

Srry, they are. Thats the reason why larger texture scales lower the r_speeds, thats why scaling a texture to 0.1 raises the r_speeds. Just check Andy's tutorial on R_speeds and you'll see it does count. I know what I'm taking about, next time make sure you do.

Oh, ok then, I'm back in deep shit.
Cos there are gonna be more buildings like that...
Anyway, are you guys SURE that models can't be solid, cos a lot of CZ maps have very good models that sure seem solid...

Elon, I don't think you get what I'm saying. I know scaling textures higher will reduce r_speeds, but that doesn't mean every tile of texture is a face. They just aren't broken up like that. Look at this picture, and you can see what I mean. I gave gl_wireframe set to 1, so you can see where the faces are split up, and it's not at the edge of any texture.

S.O.T.E, all they did was put CLIP brushes around the models to make them seem solid. You can't make a model solid unless you're using Spirit or DoD. Also, if you want to lower your r_speeds, you should probably upscale your textures (in Hammer), but don't worry about the size of the texture itself.

Srry's right, Elon's wrong.

Scaling a texture higher (any texture size) than x 1.00 y 1.00 will decrease r_speeds, since the engine has less polygons to draw (they are bigger) and there are less light patches to be calculated and drawn.

Oh, ok, thanks guys, I got frightened for a moment there...
As for the models, wow, its gonna be hard work...
***Edit***
Oh, I figured that every time I make a major part of my map, I'll compile it but without vis and all the other stuff, just the bsp.
It'll be fullbrite but i dun care cos its just to see how everything looks etc.
Final compile will take an estimated 1hr with vis.

Damn you muzzle, can't you let me have some fun and frighten him a bit.

You bastard...