Talk:Floor button

From Valve Developer Community
Jump to: navigation, search

I plan on finishing this up over the weekend...hopefully. --Remmiz 01:15, 17 Nov 2007 (PST)

Why can't you use one trigger_multiple with "client" and "physics" checked? --Darthkillyou 21:04, 21 Nov 2007 (PST)

Because then it will trigger off any knocked down cameras. --Remmiz 22:18, 21 Nov 2007 (PST)
Also the cube sets off triggers if it is touching the trigger volume, while the client only does so if the vertical centerline is touching the trigger. If you used only one, it would either be too sensitive for the player (would have to stand in center of button) or it would be not sensitive enough for the cube (the cube could be resting on the base and still be activating the button)--volt 01:37, 23 Nov 2007 (PST)

A few critiques on this page:

  • Is it really necessary for the movement brush to be any particular shape, so long as it's 9 units tall?
  • Wouldn't it be more accurate if the player trigger brush were cylinder? (I use 12 sides, 48x48)

The way that you describe is exactly how Valve does it, however the fact that the button is circular but the trigger is not annoys me.

Note:did anyone notice in TestChamber 16 you can use a turret to weigh down the button?--volt 01:37, 23 Nov 2007 (PST)
Technically either would work, but I think having the player trigger being a little big larger helps the player by not requiring them to stand directly on it, which can be harder in a fast paced scene. And I didn't notice that in 16...looks like someone made a mistake! --Remmiz 10:28, 23 Nov 2007 (PST)

This is driving me mad. In-game, some buttons fade to dark when they are pressed down. Some buttons do not. Any button I make fades to nearly complete black, but your (Remmiz) door-button-tutorial button doesn't fade at all. In my case, I found that if the center of the button-top is beneath the floor, it will fade to black, and if I move the origin so that it barely stays above the floor, it will maintain its color. HOWEVER your button in the tutorial VMF doesn't fade at all and it's constructed identically! WHAT! --volt 01:31, 24 Nov 2007 (PST)

There is a light underneath it, so when it is pushed down, the light will be above the button and lights it up. --Remmiz 01:46, 24 Nov 2007 (PST)
I had the light as well, attempted both in the same position as yours as well as slightly higher. At one point I did a copy-paste on all of the elements of your button and put it in my vmf and it didn't act the same as the one in your vmf. Pretty strange. --volt 03:21, 24 Nov 2007 (PST)
I'm having the same "fade-to-black" issue, and moving the button doesn't seem to help much. Can anyone offer any advice? Walliard 22:45, 11 May 2008 (PDT)

Introduction

I lol'ed at the introduction. a genius must hape pressed some buttons -- alexanderpas 08:06, 18 Dec 2007 (PST)

That's what they're called in the game, you know :3 Day32 23:47, 21 February 2009 (UTC)

1500-Megawatt Aperture Science Heavy-Duty Super-Colliding Super Button =3 -- Paddymay 03:16, 18 September 2009 (UTC)

A hole in the wall

I'd like to point out that telling the user to carve the wall is a pretty bad idea. You should explain how to do it with, say, clipping. --Baliame (talk) 01:59, 15 Aug 2008 (PDT)

article rewrite?

I think this article needs to be rewritten. mainly the end.

the outputs to open the door should be on the button door thing (the func_door that makes the button go down). that way, multiple cubes won't set the trigger off twice.

EG, if there were 2 buttons, and two boxes, and the counter is set to the trigger, the counter can be triggered twice, should 2 cubes touch the button at once.

but, if onopen/onclose were the triggers, well, you can't open a door multiple times, so the counter can only count as 1, no matter how many cubes are added onto the trigger.

thoughts? Kizzycocoa 19:24, 7 December 2009 (UTC)

It's probably a good idea to remove the suggestion to use the carve tool while you're at it, nobody really uses it unless they're a beginner. Solokiller 20:42, 7 December 2009 (UTC)
never noticed that. I agree on that.
I'll try to edit it tomorrow, unless anyone (gear) has anything against it? Kizzycocoa 20:57, 7 December 2009 (UTC)
I say go ahead. Please just make sure to look over your edit for mistakes before committing. --cheesemoo0 03:16, 8 December 2009 (UTC)
there we go. I changed the carving part.
it seems that the part involving the func_door was written, but I though it meant the trigger, not the door. my bad. Kizzycocoa 08:50, 8 December 2009 (UTC)


Vandalism?

The latest Revision appears to be a modified version of the original's correct outputs - an act of vanadlism? I've reverted the recent changes. If this is in error, then please revert the changes. --Cred-Injuries 06:09, 14 April 2010 (UTC)

Clipping...

When ever I try to clip around the round door frame to make the frame for the door frame it only lets me draw one line so i don't see how i could "trace" around it... any assistance is appreciated.

You can change modes in the clipping tool by clicking it again. --Omnicoder 00:04, 18 June 2010 (UTC)

I think what Sourcemann is trying to do is create a segmented line which changes direction in order to cut out a section. Unfortunately, the Hammer Clipping Tool doesn't work that way...you only get to create one line. That one line is then converted into a cutting plane then the object you selected will be sheared through by the entire plane. So, the tool only works with one plane at a time...no matter how many times you click it.
In order to cut-out a round section of wall as if you carved it with a cylinder:
1) Select the wall you want to cut a round section out of.
2) Select the Clipping Tool.
3) Draw the line you want to define the first plane to cut the wall.
4) Click on the Clipping Tool button again until sections of the wall on both sides of the cutting plane are white.
5) Press Enter...both sides will remain if they were both white by step 4.
5a) Optionally...you can ungroup the pieces so that subsequent planes don't cut through all the pieces...to minimize the brush count.
6) Draw the next line you want to define the next plane to cut the wall.
7) Press Enter.
8) Repeat steps 6 through 7 until you have circumscribed the area that you want to remove.
9) Ungroup the brush then select the "inside" area that you want to cut out then press Delete.
10) Re-integrate and Group all the pieces so they are all one wall again...with a cut-out where the door goes. Rockn-Roll 19:37, 15 February 2011 (UTC)

Successes and Failures

OK...I was able to get the button and door to work nicely. I tried creating my own wall surrounding the door; however, the textures weren't lining up properly. So, I eventually copied the one from the supplied testchmb_a_05 provided in the SDK to use for now. I'll take another stab at it for the next door I make.

The failure is that the doors will close on objects such as the radio, table, or cube and go right through them. I've made sure all the properties are set to exactly what the testchmb_a_05 sample has, but it still happens. There must be some step or tweak that isn't in the tutorial? Something that isn't in the properties? Beginners, such as myself (for Portal that is), will be following these tutorials verbatem.Rockn-Roll 10:02, 15 February 2011 (UTC)

Check the properties of each door. Is the Collisions key set to the Use VPhysics value? --Mattshu 20:56, 15 February 2011 (UTC)
Yes...that's the default and I didn't change it. I followed the tutorial verbatem. I did manage to make it work by changing the entity type on the cube and radio to prop_physics_override. Is this the right thing to do? Rockn-Roll 10:42, 16 February 2011 (UTC)
Should be prop_, but I'm hoping that was a typo. The cube and the radio are allowed to be prop_physics. prop_physics_override is for dynamic props that will be used as physics props. Either way, it shouldn't affect whether or not they pass right through the door unless their collision is set to Not Solid. --Mattshu 20:16, 16 February 2011 (UTC)
Yeah...prop_physics_override...I fixed it. Hmmm...it did make a difference. OK...my map started to leak for no reason (the leak was way outside of the map) and other odd things like GLaDOS stopped speaking and the button sometimes would get stuck in the down position, so I started from scratch and everything worked using prop_physics. Another problem I'm having is when I rotate the door and frame as a group the collision hull is not rotating with it i.e. if I rotate the door 90º and then run the map and walk across the face of the door I get stopped as if there was an invisible door at 90º to the visible door.
Compile the leaking map without running it (and without vrad, saves some time to find the leak) and check the compile log. Near the top it will tell you which entity leaked and what its coordinates are. Copy the coordinates, click View, then click Go to Coordinates.... Make sure the entity's origin isn't in the void or inside of a brush that's sealing the map. And for the door issue, make sure you update the door's movement direction whenever you rotate it as a group. --Mattshu 23:16, 16 February 2011 (UTC)
I wish there was someway to fix the map, but there isn't that I can see. Here's the message: **** leaked ****
Entity info_player_start (256.00 16.00 1.00) leaked! The player is well within the map...in fact, just to make sure I moved the player up 1 unit and ran it a second time. I haven't touched anywhere near there since I built the map. I'm also getting an unknown number of the following messages:
FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (1024.0 -544.0 52.0)
Leaf 0 contents: CONTENTS_SOLID
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_SOLID
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_SOLID
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_SOLID
Candidate brush IDs:
The coordinates given are way outside the map...the Go To Coordinates menu item put me like 500 units away from everything and looking back at the outside of my map...the compiler has no business trying to determine whether a portal can be created outside of the map...I believe this is being caused by the false leak. Don't worry about it...I've made sequential saves (having 27 years of development experience has empowered me with some very useful habits) and just dropping back to a previous version.
Actually, by portal, it isn't talking about Aperture Science jargon. That has something to do with any map, probably with leafs, which is why the portal file won't build if there is a leak. I've had issues where I've leaked and tried finding the source, only finding that the trace in the point file seems to start randomly in the middle of the void. I'm too tired to try remembering what was causing it right now, but I'll get back to you on that. --Mattshu 13:23, 17 February 2011 (UTC)

My focus today has been on my button functionality which occasionally sticks down. I started with a fresh map this time and copied the button and door from the testchmb_a_05 provided in the SDK and got it working...and omg...when idle it sits there and vibrates like the button is moving down 1 grid unit then moving back up 1 grid unit. It stops when I put a cube on it. I played around with the location of all parts...mostly; func_door, top, and trigger_multiple and actually got it to behave like my button as well as getting my button to behave in a vibratory state. Another inspiration hit me...I copied over the platform which the button sits on...EUREKA! Apparently the functionality of the button provided in testchmb_a_05 requires that it be on that base...at least when I tried it. I've made a determination that the button is actually a delicate piece of equipment and if it's off by just a little it won't work right, and even in some circumstances a good working button will behave erratically.

Another success though, I managed to figure out that my button is getting stuck down when I walk off the button over the clamps on the base...I changed the orientation of all the other parts and it always gets stuck when I walk over the clamps, so the problem is with the base clamps for some unknown reason. I tried putting it on the platform from the sample, but that didn't fix it. I spent all day trying to get it to work, so I wouldn't have to borrow the one from the sample, and only just now figured out a fix (I still don't know exactly why). When the models/props/button_top_reference.mdl is applied to an entity the height of the entity is initialized to 13.9 units, but what I didn't know was that with this model the height can be changed. So, I changed the height to 12.9 units (moving the bottom of the entity up 1 unit) and now it works nice and smooth. I'll probably spend all day tomorrow testing it, but I think my button is ready. Which means after about a week I finally have a working button and door. I'll run some more experiments and see if this procedure needs to be worked into this tutorial.Rockn-Roll 05:02, 17 February 2011 (UTC)

Update...the height only temporarily changed to 12.9...the button reverts back to 13.9, but 1 grid unit up from where it was after I let go (the magnification was too high for me to see the left edge of the selection box to see the height). So, the fix was to move the top up 1 grid unit.Rockn-Roll 20:51, 17 February 2011 (UTC)

Tutorial creating the Portal Door Frame using Clipping Tool

I've developed the beginnning of a tutorial for creating the Portal Door Frame using the Clipping Tool. I've put it in my user space for now until I get an opinion on whether it's the correct procedure...still feeling the sting from creating overlapping brushes in my attempt to update the Beginner Portal Map Tutorial. You can see the work in progress at User:Rockn-Roll/Portal Door Frame Using the Clipping Tool. Rockn-Roll 10:42, 16 February 2011 (UTC)