Talk:Prop door rotating

Discussion towards Creating/Modifying Compatible Door Models

Some minor observations on the topic,

Most know the error when using another door model not compatible where it will rotate around its middle; this isn't so much an error but rather how the entity works from what I gather. The model's origin in 'modelspace' I guess you'd call it, is along its left edge whereas for most models it would be the centre of the model(default root location). At the origin in modelspace was a 'door' bone and then along the front face of the door there were two more bones - 'handle' and 'handle 2' - for the handle and pushbar models. These three bones exist in all models.

My guess is that when you load a non-compatible model it will try and use the 'root' in lieu of the 'door' bone being available to do the animations which are nothing more than 90^o open/close anims.

Note:Does this mean we can just move the bone for the model to left edge of the model and be able to use it 'as is' regarless of console errors? Would someone be willing to test this because that would be a quick and easy solution

- Not all models have a bone, but the model will rotate around position 0,0,0 in the model editor, so to make a fully functional rotation, place the model in the model editor so the door's rotation axis is positioned at 0,0,0 --Pandaboy 01:26, 12 October 2011 (PDT)

The door and each handle/hardware option are in separate .smd files but get merged together in the qc like so:

$model "Body" "door01_left_door_reference.smd"		//Door Model Itself
$model "handle01" "nohandlesmdfile.smd"			//Hardware Option 1
$model "handle01" "door01_left_handle01_reference.smd" 	//Hardware Option 2
$model "handle01" "door01_left_handle02_reference.smd" 	//Hardware Option 3

The door options seen in the keyvalues block seem to only deal with what sound to play for each skin/hardware type. From what I understand anyway.

$keyvalues
{ 	
	door_options 
	{	
		"default" 
		{ 
			"open" "Doors.FullOpen1" 
			"close" "Doors.FullClose1" 
			"move" "Doors.Move1"  
		} 
		
		"hardware#" //Replace # with hardware option. 
		{ 
			"locked" "DoorHandles.Locked1" //Sound Name
			"unlocked" "DoorHandles.Unlocked1"  
		} 
 	} 
}

Aside from these extra additions it seems to be nothing more than an animated prop with its own prop_* type rather than using triggers and prop_dynamics. Maybe look into the props .cpp file for confirmation or a better understanding on what its looking for.

If someone manages to create a nice step by step on how to create their own door models I'd love to see it, maybe some of my thoughts here will help towards that end. --Lost 23:07, 3 November 2009 (UTC)

- I've almost managed to create my own door model (A normal model, except the origin of the model's hinge is placed at the origin in the model editor). It opens and closes correctly in game, although it's not using a door handle since it's more of a hatch... I've gotten a problem though - The sounds does not function properly. No matter how I change them in sound_options for the different hardware types, they seem to all have a preset sound behaviour. --Pandaboy 10:10, 12 October 2011 (UTC)

The info about compiling door handles above appears wrong

. When I compile a decompile like that, all hardware is displayed always regardless of hardware options. This worked for me.

$model "Body" "door01_left_door_reference.smd"      //Door Model Itself
$bodygroup "handles" 
{
    studio "nohandlesmdfile.smd"         //Hardware Option 1
    studio "door01_left_handle01_reference.smd"  //Hardware Option 2
    studio "door01_left_handle02_reference.smd"  //Hardware Option 3
}

--Shotgunefx 17:12, 1 October 2012 (PDT)

Portal Issue

In Portal, using a prop_door_rotating seems to create errors when you shoot the portal gun at it. I've tried surrounding the door with a nodraw surface and even func_noportal_volume, however I can't figure out how to make it function properly: to have the door absorb the portal attempt and give the invalid surface response.

Notes: If you are standing on the ground, usually the portal particles that shoot from the gun fly and hit the door, then bounce to a random surface, which, in my experience, has been in the general direction of the origin of the world. If you are jumping or noclipped into the air, the particle effect normally shot from the gun does not move at all - it stays stationary wherever you initially fired the portalgun, and Console reports:

DataTable warning: [unknown]: Out-of-range value (4403068369862833900000000000000000000.000000) in SendPropFloat 'm_vStart[2]', clamping.

And you end up with a glowing blue or orange stationary permanent particle effect in the position that you fired the portal gun.

Can someone else please verify that the above is what happens? And if there are any known fixes, please let me know.

Other notes: A decompiled escape_02 shows that the Portal devs did not use any apparent methods to prevent the above from happening. (On the door leading from catwalks to Glados) --volt 22:25, 30 Nov 2007 (PST)

Just so you guys know, this happens in official Portal maps as well, take this screenshot for example (this is of the stationary particle effect)

This is on the end of the map testchmb_a_15, before you jump into the cube transporter. --volt 08:46, 1 Dec 2007 (PST)

Link to sdknuts/wisedoor changed

I have changed link to sdknuts/wisedoor as the tutorials on the site has been taken down Eventually the tutorials will be added to the wiki with marks permission --Peter [AGHL] 12:19, 5 Feb 2008 (PST)

Lock a door open

Would it be possible to lock a door open (in place)?

IE: force a door to stay open until an event happens (like the player pressing a button to make it movable again)

I have two doors in a row (one that slides and one that rotates) and i want to make it so that the rotating door cant open without the sliding door being open. Also, I want the sliding door to not be able to close without the rotating door being closed.

My thought was that I could unlock the rotating door when the sliding door is opened, and lock the rotating door when the sliding door is closed. The problem comes when the player tries to close the sliding door while the rotating door is open. The doors would collide, so that must be avoided. If i could lock a door open, then when the player tried to close the sliding door while the rotating door was open, it simply wouldn't allow them.

.

Locked door completely passable by players

I'm very new to to the source SDK, but I have noticed something strange. On my map, one of my doors, I set the flag lockable to true (I want a trigger to unlock it) and it makes the door passable, as in a player could just walk through. Any help would be appreciated. The current flags set are "uses closes" and "lockable"

Check to make sure the door's collision isn't set to "Not Solid". What other values/flags did you set that aren't default? —Mattshu 09:42, 6 July 2012 (PDT)