The Thread For Small Problems And Requests
Quote from CamBen on September 5, 2014, 1:59 amThe prop should not be the parent of the func_rotating. The func_rotating is the parent of the fan model.
The prop should not be the parent of the func_rotating. The func_rotating is the parent of the fan model.
Aperture Science: We do our science asbestos we can!
Quote from Lunch on September 5, 2014, 9:03 amCamBen 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?
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?
Quote from FelixGriffin on September 5, 2014, 9:16 amPanel_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?
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?
Quote from Lunch on September 5, 2014, 10:10 amYes. 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.
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.
Quote from CamBen on September 5, 2014, 10:17 amYou 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.
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.
Aperture Science: We do our science asbestos we can!
Quote from Lunch on September 5, 2014, 11:20 amCamBen 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?
So what would tell the engine to spin the fan model along with the func_rotating?
Quote from RustyDios on September 5, 2014, 4:50 pmLunch 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.
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.
Quote from Lunch on September 13, 2014, 9:07 amWhy 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.
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.
Quote from TeamSpen210 on September 13, 2014, 12:05 pmTry 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.
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.
[spoiler]- BEE2 Addons | (BEE2)
- Hammer Addons
Maps:
- Crushed Gel
- Gel is Not Always Helpful[/spoiler]
Quote from RustyDios on September 13, 2014, 6:25 pmDepending 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.
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.