Anyone know why desk_curved.mdl isn't solid in-game? I can walk right through it. I have Collisions set to "use Vphysics", as opposed to "not solid" (duh) and "use bounding box" (I don't know what the latter is).

I have the same problem with a chair I placed near the desk, but two file cabinets and a floor lamp are properly solid.

Valve sometimes doesn't add a collision mesh to some items. To fix this make a nodraw func_brush that matches the shape as that'll block players and objects. Use invisible if you want portal/bullet shots to pass through the object. Player_clip (just use as a func_detail/world brush) is useful to stop players jumping on little details (it doesn't affect physics objects like cubes, so it's fine to make it big wall).

TeamSpen210 wrote:
Valve sometimes doesn't add a collision mesh to some items. To fix this make a nodraw func_brush that matches the shape as that'll block players and objects. Use invisible if you want portal/bullet shots to pass through the object. Player_clip (just use as a func_detail/world brush) is useful to stop players jumping on little details (it doesn't affect physics objects like cubes, so it's fine to make it big wall).

Thanks!

I'm having a problem where some props are placed nicely in Hammer, but when I compile and run the map, I can't see them. For example, models/a4_destruction/fin4_fencegrate_dyn.mdl and some hanging cables.

Anyone know what's up? I have them as prop_static if that makes a difference.

EDIT: I switched them to prop_dynamic and now they're there. I hope that was the right move.

There are three categories of model types (static, dynamic, physics). Most models are restricted to certain types only. See the "info" tab in Hammer's model browser to check what a certain model supports. If a prop has animations (.like doors) it can't be used as a prop_static, and if it has physics data it can't be used as a prop_physics. If you really need a physics/dynamic version of a model, use prop_dynamic_override/prop_physics_override (it ignores the flags, and for the physics it lets you specify the mass and similar factors).

Thanks. I've got it now.

Anyone know if there's a fan instance, or even a .mdl I can animate? The bigger the better.

Okay, I found a fan as a prop that works (I take back "the bigger the better", because the first one I found was bigger than my whole map). Now I need to know how to edit it. Is there some kind of func that rotates something?

Found it! https://www.youtube.com/watch?v=4wugEudz4Q0

There's three sounds you probably want to use - one for it spinning up, one for slowing down and a loop for when on.

I can't get the gorram thing to spin. I have a little 8x8 func_rotating at the center of the fan prop, and I have the prop as the parent of the func_rotating. I have a logic_auto with an output to panel_attach the fan to the func_rotating. I have it flagged to start enabled. But it won't spin!

The prop should not be the parent of the func_rotating. The func_rotating is the parent of the fan model.

CamBen wrote:
The prop should not be the parent of the func_rotating. The func_rotating is the parent of the fan model.

I was excited that that would solve it, but I fired up Hammer and that's unfortunately already how I have it (I just explained it backwards last night).

My func_rotating is nodraw. You think that's okay?

The tutorial I linked to on YouTube has the guy making his fan blades out of a brush and then making THAT a func_rotating. If it gets to that, I'll scrap the fan prop and do it that way, but the model looks so much better.

EDIT: Solved it. You were basically right. I just had it the parent name wrong (I forgot that I called my func_rotating "fan_turner"). Thanks!

New problem: I know I can't have two env_projectedtextures at the same time. I have one upstairs, and the way I'm trying to do it is when a button gets pressed, it has an output to turn that env_projectedtexture off and to start one that's on the level below. Is that something that SHOULD work?

Panel_attach is only used for panels (to stick them to the right part of the model), don't use that here.

What entity type is your fan? Prop_dynamic?

Yes. panel_attach is working, though. I'll definitely switch it if you have a better idea, but it's working.

Also, starting and stopping env_projectedtexture with button outputs is working fine.

You don't need to use an attachment point like panel_attach on anything except a panel prop. The reason it still works for a fan or a func_rotating is because it's invalid and ignored, so it get parented to the base attachment point.

CamBen wrote:
You don't need to use an attachment point like panel_attach on anything except a panel prop. The reason it still works for a fan or a func_rotating is because it's invalid and ignored, so it get parented to the base attachment point.

So what would tell the engine to spin the fan model along with the func_rotating?

Lunch wrote:
CamBen wrote:

You don't need to use an attachment point like panel_attach on anything except a panel prop. The reason it still works for a fan or a func_rotating is because it's invalid and ignored, so it get parented to the base attachment point.

So what would tell the engine to spin the fan model along with the func_rotating?

An "child" object moves with its "parent" .... Hammer basics 101.

Why is it so difficult to portal through my grates? I have a few points in the map where there's a portalable panel visible through a grate, but maybe the first five times you attempt to place a portal, it gets blocked by the grate, and then finally, as you're trying different angles, it will work. I hate this, and I want it to be easier. You see the panel through the grate, you fire the portal, and it works.

Suggestions? Also, is there a grate texture that's maybe MOST conducive to this? Maybe I'm not using the ideal option.

Edit: It appears to have something to do with angles. If I'm pointing my portal gun at a 90 degree angle to the grate, it's much easier to place a portal through it. However, I have situations where the grate is higher or lower than the player on the Z plane, and therefore you're viewing it on an angle.

Also, I found from reading some other threads that metalgrate018c is better than metalgrate018, which I was using before. So that's progress.

Try adding a placement helper to force portal placement, or make the grating larger than 128*128 so there's a bit more room on the sides.

Depending on what you want your grate to do, you could always set it up as a non-solid func_brush, with a player clip textured worldbrush and a func_clip_vphysics. (Also known as a fake wall). I've never had any problems in my maps with grate textures not doing what they are suppose to do. So that is the first idea that came into my head.

It might also depend on the size of your grate, and maybe the texture scale of the grate.