Search results

One thing to bear in mind about the decompiler: it doesn't correctly tie the func_areaportal (or areaportalwindow or occluder) entities to their brushes. Currently, those brushes appear as regular world brushes. So don't blindly copy what you see in a decompiled map, it's not the correct way of...

Point_spotlights also count as dynamic lights (if you don't set the dynamic light off with the spawnflag) and also, I've heard, certain models (props) have dynamic lights built-in.

There certainly seems to be options for at least VVIS so that it'll run on a distributed array of computers. However, I don't know if that ability has been enabled on the version of the compile tools that we get.

That's a good question, and I don't know. There's probably a good reason for that data to be in there, otherwise it would be removed by the compile process. (For example, the "portal" data, which is used to construct the map's vis information, is removed after it's used by the VVIS program)...

Unlike HL1 maps, HL2 bsp files contain almost all information that was in the original vmf file. HL1 bsps contain mostly "face" data, and store only faces that have been through the BSP splitting stage, so many brush sides are split into multiple pieces. The compiling process also throws away...

You might want to look at this thread over on VERC: http://www.chatbear.com/board.plm?a=viewthread&t=651,1108495694,20229&id=796757&b=4989&v=flatold Particularly the posts by Jeff Lane. There's no real way to make the static lighting react properly to dynamic changes like opening doors...

Lights with different colours and brightnesses don't matter. When it says "light styles" its talking about (a) switchablity (having a unque name) and (b) the "Appearance" setting for the light entity (normal, flicker, pulse, strobe, etc.) So you can have hundreds of lights, each with a...

Also, as I understand it, you can use wildcards in the "Filter name" field. So if you have it set to "box*", then any entity name matching that (box1, box2, box_fred, etc.) will active it.

Assuming the entity "test" you're targeting is a phys_thruster, I think its "Scale" input takes a number between 1.0 and 0.0, the number being a fraction of the thruster's "Force" setting. So I'd change that to OnTrigger, test, Scale, 0.0, Delay 0 and OnTrigger, test, Scale, 1.0, Delay 5...

Yep, thrusters would probably work fine. Or phys_torque, I should think.

Multiplay with the player on a moving object is extremely laggy/jerky at the moment. I hope Valve will fix this eventually. You might be able to make the scenery a (very large) func_tracktrain that moves past a stationary train. Use the "teleport to here" option on the path_corner to make the...

Odd. Perhaps rotate the whole thing (lamp+light) a few degrees around the pivot so that it starts off swinging very slightly? That way it will be moving already on map start.

Hmm, I guess I never realised that you could respawn constraints like that. Not sure they'll work properly with func_door_rotating, though, since that entity seems to mostly belong to "old" physics. But it'll be worth a try.

Actually quite a tricky problem because of the reseting aspect. Most of the constraints can be set to break on too much force/weight, but I think they all break permanently, and can't be reset. Maybe make "physics" doors (func_physboxes with phys_hinges), and hold them up with a phys_spring...

Parent a point_spotlight to the light model, aligned so it is facing downwards. You can overlap the point_spotlight and the "bulb" of the light model to a certain extent. This will give you a visible light cone and a dynamic light illuminating whatever the spotlight is pointing at. (You might...

Rather than parenting the point_viewcontrol to a tracktrain, the entity can follow it's own set of path_corners, just like a tracktrain will, using its "path corner" property.

Set the "$surfaceprop" in the .vmt file to the correct surface property. e.g. "$surfaceprop" "metal" You'll probably want to use "carpet". There's a list of valid surfaceprops on the wiki-which-must-not-be-linked.

Because it doesn't do nothing. What vis is doing is calculating which parts of your map can see which other parts. If you don't run vis, the engine has to draw all of your map all of the time(*), which is slow. It might look fine for a small map, but once you put in enough detail you'll see bad...

OK, here's the most versatile way, courtesy of Raeven0's good idea. To reiterate, you only need to do it this way for CS:S. Make the thing you want to hang. This could be a func_physbox (for a brush-based object), or a prop_physics or prop_physics_override, etc. for a model-based object. Give...

Indeed it does work. There's some slight issues with where the attachment point goes, but that might be caused by the object moving slightly before the logic_auto fires. It could probably be worked around. Strange bug. The fact that SetParent works while standard parenting doesn't is actually...