Talk:Physics prop

From Valve Developer Community
Revision as of 15:49, 6 August 2018 by Pinsplash (talk | contribs) (response)
Jump to navigation Jump to search

This is literally another name for prop_physics

LINK_ENTITY_TO_CLASS( physics_prop, CPhysicsProp );

LINK_ENTITY_TO_CLASS( prop_physics, CPhysicsProp );

LINK_ENTITY_TO_CLASS( prop_physics_override, CPhysicsProp );

Not only that, but its classname is changed back to prop_physics after spawning:

if ( FClassnameIs( this, "physics_prop" ) )

{

SetClassname( "prop_physics" );

}

Why do we need an entirely different article for this, exactly? --Blixibon (talk) 14:39, 6 August 2018 (UTC)

Didn't know that its classname is changed to prop_physics actually, but its being kept since this entity is present in nearly all Half Life 2 beta maps, along with dynamic_prop. This can be compared to func_wall, its likely only kept for backwards compatibility, but its obsolete.--Ficool2 (talk) 14:43, 6 August 2018 (UTC)
func_wall is its own entity, as is func_illusionary. Both are obsolete entities that have been overall replaced by func_brush. physics_prop, however, is not an obsolete entity; it is the deprecated former name of prop_physics. It was changed at some point in development, likely when they decided to create more prop classes and wanted to keep their names consistent. I don't know if there is any behavior to document from the Half-Life 2 beta that is any different from prop_physics in retail. In fact, the code class for prop_physics, CPhysicsProp, still bears the physics_prop name. We could easily use this as a redirect to prop_physics and mention the "physics_prop" legacy there. --Blixibon (talk) 18:12, 6 August 2018 (UTC)
It really doesn't hurt anything to give this its own page. I'm quite convinced the behavior is essentially identical, but this is a unique classname. I don't think we should rely solely on a "legacy note" because readers will be confused as to why they're suddenly on a page for a similarly named yet different entity, and knowing how pages are sometimes, important information (in this case a note being looked for by a reader who is already confused and does not realize that they are looking for said note) may get pushed quite far down from the top. Pinsplash (talk) 22:11, 6 August 2018 (UTC)
This is not an obsolete entity. This is an alternative name for prop_physics. They do not have identical behavior, they are identical. They are not unique classes, only two names tied to the same class. This is like two different roads going to the same place, or two different links going to the same page. It's not that physics_prop is irrelevant, it's the fact the class it is tied to is already documented with its current name, prop_physics. There is nothing to say about the name physics_prop except that it is the original classname of prop_physics and can today be used as another way to spawn prop_physics, both of which could easily go on the original entity's article. Having a separate page for this gives the wiki unnecessary clutter, especially seeing this is being done for other alternative names like dynamic_prop and bounce_bomb. I don't know what you mean by confusion being caused by using a legacy note on the original page. That would be a lot less confusing than this. --Blixibon (talk) 22:36, 6 August 2018 (UTC)
True, calling this obsolete is kind of not justified. They are different though, by their classnames. How does this cause any clutter? The most this page does to "clutter" anything is one extra line on four categories. Redirecting would be confusing because these actually are different things, if only minimally. Pinsplash (talk) 22:49, 6 August 2018 (UTC)