Talk:Physics prop

Poll

Due to the constant edit wars and the stalemated discussion below, I have decided to cast a poll to decide the verdict. I would request that anyone who sees this to vote instead of staying silent.

Should this page be on its own independent page OR redirected and merged into the prop_physics page? Note that this will also apply to other pages with the same problem, such as dynamic_prop.

Vote Yes for independent page, vote No for redirected/merged page. I am voting for Yes. --Ficool2 (talk) 10:45, 7 August 2018 (UTC)

Poll finished, results are majority No. Time to redirect pages.

Yes Pinsplash (talk) 10:48, 7 August 2018 (UTC)

No --SCell555 (talk) 10:48, 7 August 2018 (UTC)

No And this is stupid, the facts are clear. Solokiller (talk) 10:50, 7 August 2018 (UTC)

"No" --TeamSpen210 (talk) 10:52, 7 August 2018 (UTC)

No Avanate (talk) 12:05, 7 August 2018 (UTC)

No SharpOB (talk) 11:30, 7 August 2018 (UTC)

No JoshuaAshton (talk) 12:01, 7 August 2018 (UTC)

No Slartibarty (talk) 12:27, 7 August 2018 (UTC)

No --Blixibon (talk) 13:32, 7 August 2018 (UTC)

Yes FIRE-Buzzard (talk) 13:37, 7 August 2018 (UTC)

No, but include a note on the prop_physics page that it is the same as physics_prop to avoid confusion. Practical Problems (talk) 14:50, 7 August 2018 (UTC)

Speaking of that: Template:AltNames. Pinsplash (talk) 14:52, 7 August 2018 (UTC)

They're so few and far between that its not necessary. Use the note format that has been around on other pages and is in place now. That way it gives more info too. JoshuaAshton (talk) 14:59, 7 August 2018 (UTC)

I would support the usage of this template on the pages. Just replace the note with the alternative names. SharpOB (talk) 15:27, 7 August 2018 (UTC)

No, I like the idea of a redirect and a mention on the prop_physics page. Especially considering physics_prop turns into prop_physics and are identical. I support the Template:AltNames solution, as long as it's somewhere at the top of the page like the rest of the notes. So users can see it immediately. Kidnation (talk) 17:58, 7 August 2018 (UTC)

No, redirect is fine. DankParrot (talk) 18:43, 7 August 2018 (UTC)

This whole poll was a waste of time. It was clear nobody wanted this from the get-go if you know... you actually read any of the discussion what was had. :) JoshuaAshton (talk) 03:00, 8 August 2018 (UTC)

Certainly no need for the last word syndrome you have going on, Josh. Pinsplash (talk) 03:24, 8 August 2018 (UTC)

It's impossible to make that comment without also being a hypocrite. JoshuaAshton (talk) 03:31, 8 August 2018 (UTC)

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)

...except that they are not different. I thought I got that point across. They are two classnames tied to the same entity. Having a separate article--let alone listed in categories--is unnecessary. Can you explain why redirecting physics_prop to prop_physics would be confusing? --Blixibon (talk) 22:57, 6 August 2018 (UTC)

The difference is ALL in the name, and it is a significant difference because even things such as dumpentityfactories consider them separate entities. Redirecting would be confusing because they are different names. These are entities we are talking about, the classname of an entity doesn't just change. In fact, I'd almost say this is notable by itself solely for the fact that the classname does change, which is a very uncommon thing. As I said before: 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 (because they were just redirected to a page that, at first, would appear to be at least partly irrelevant) and does not realize that they are looking for said note) may get pushed quite far down from the top. Pinsplash (talk) 23:15, 6 August 2018 (UTC)

And if you doubt me about the "legacy note" crap being hard to find, check this edit made just a bit ago. Pinsplash (talk) 23:20, 6 August 2018 (UTC)

Ugh, don't undo the redirects. They're the same entity. JoshuaAshton (talk) 23:29, 6 August 2018 (UTC)

Sorry, do they have different classnames? Pinsplash (talk) 23:30, 6 August 2018 (UTC)

Yes but they're the exact same entity. Another page is not useful, and you're not being very useful who want quick reference here either. Please reconsider your decisions and the impact you have on people trying to quickly find how things link together. JoshuaAshton (talk) 23:33, 6 August 2018 (UTC)

Can you clarify what you mean EXACTLY by "not useful"? Also stop bringing in this unrelated stuff, we are talking about an entity and not a user. --Ficool2 (talk) 23:37, 6 August 2018 (UTC)

I mean that its not useful. What do you want me to say. It's better than a crappy stub page that I need to click on something AGAIN to get to the information I want. JoshuaAshton (talk) 23:40, 6 August 2018 (UTC)

I believe he means that, for people looking on information about the entity, and for differences between that and the main page, the stub article is useless - it only says that it's the same, but a different name. For people wanting information on the entity itself, the redirect helps. For people wanting to know more about the differences, the redirect tells them that they're the same. I've also added information on the different names to the main articles of this and dynamic_prop, to bring it in line with how combine_mine does it. SharpOB (talk) 23:46, 6 August 2018 (UTC)

Reading one or two sentences on a small page actually would be more convenient than being redirected to a page that at first would appear to be at least partly irrelevant, followed by being expected to notice the TOC (which has been put on the right-hand side for no discernible reason) or being expected to randomly decide to scroll all the way to the bottom of the page (about 10 times my screen height). Pinsplash (talk) 23:42, 6 August 2018 (UTC)

Its not partially irrelevant ITS THE SAME ENTITY. What about that do you NOT understand? JoshuaAshton (talk) 23:46, 6 August 2018 (UTC)

It is not the same because they have different classnames. If they had the same classname, we wouldn't be arguing about redirecting it because they would have the same page name as well, but they do not, now do they? Pinsplash (talk) 23:51, 6 August 2018 (UTC)

Look at my wording. It would APPEAR to be at least partially irrelevant. That's because the pages have different names, and if you're looking for info on what a physics_prop is, the first thing you get is info on prop_physics instead, with no immediate explanation of what you're actually looking for, which is physics_prop. Pinsplash (talk) 00:00, 7 August 2018 (UTC)

They are the same. They have the same classname after spawning. They are the same entity. They use the same code. They have the same parameters. It's just a name change with fallback. Stop trying to argue otherwise, you look like you really do not know what you are talking about. I bet you're the type of person to say Water_DX8 should have its own page and not be incorporated into the Water shader page JoshuaAshton (talk) 23:56, 6 August 2018 (UTC)

They are not created with the same classname. This is irrefutable. Pinsplash (talk) 00:00, 7 August 2018 (UTC)

Its the same yes, but its interesting that its found in HL2 beta maps, and that it has special code to change its classname.--Ficool2 (talk) 23:49, 6 August 2018 (UTC)

OK So you admit its the same. Then put it on THE SAME wiki page JoshuaAshton (talk) 23:51, 6 August 2018 (UTC)

Did you just ignore what I said? The entity has some interesting information about it, this alone is acceptable for it to be its own page. Its easier and cleaner to see this information on its own page than merging it into the prop_physics page which will make it cluttered.--Ficool2 (talk) 23:54, 6 August 2018 (UTC)

Strong disagree.JoshuaAshton (talk) 23:56, 6 August 2018 (UTC)

Surely, though, for it to be most useful, you'd want the information about this on the main page? So, why remove that and put it into a stub article? SharpOB (talk) 23:57, 6 August 2018 (UTC)

They are the same. They have the same classname after spawning. They are the same entity. They use the same code. They have the same parameters. It's just a name change with fallback. Stop trying to argue otherwise, you look like you really do not know what you are talking about. I bet you're the type of person to say Water_DX8 should have its own page and not be incorporated into the Water shader page. This got burried so highlighting this for discussion JoshuaAshton (talk) 23:57, 6 August 2018 (UTC)

Now you are just being pathethic, you are giving short answers with no reasonings, and literally COPY PASTING the same statements. Please properly justify your reasonings, and dont bring other unrelated stuff into this.--Ficool2 (talk) 23:59, 6 August 2018 (UTC)

Excuse me? My reasonings are perfectly justified. I copied it so it didnt get buried from before and highlighted it for future discussion (as I stated). Stop with your foolish nonsense, seriously.

Let's try to stay civil here. A short page isn't necessarily a stub. Pinsplash (talk) 00:03, 7 August 2018 (UTC)

It was a stub.JoshuaAshton (talk)

It was not, as it had everything it needed. Pinsplash (talk) 00:06, 7 August 2018 (UTC)

You're crazy, it had no entity information or paramaters, io etc on there. The page was fundamentally uselessJoshuaAshton (talk) 00:07, 7 August 2018 (UTC)

Well, good thing we had linked to the page that had stored all the things it used on there. I myself wouldn't mind if the information that's on prop_physics was pasted onto there, no skin off my nose. Pinsplash (talk) 00:10, 7 August 2018 (UTC)

You wouldn't mind, that's such a relevant point. But its still more clicks and more work and objectively annoying, especially for people wanting to find relevant information. Please do not change it again.JoshuaAshton (talk) 00:12, 7 August 2018 (UTC)

It is one extra click to go to the information about prop_physics. This page is for information regarding physics_prop instead, which previously did have all the information about physics_prop that was needed to cover it in an arguably effective manner. If you want information about prop_phsyics, go to the prop_physics page instead. Pinsplash (talk) 00:17, 7 August 2018 (UTC)

THE INFORMATION IS THE SAME. THEY ARE LITERALLY THE SAME ENTITY. YOUR STUB PAGE DID NOT HAVE ANY INFORMATION. JoshuaAshton (talk) 00:18, 7 August 2018 (UTC)

---

Moving messages back over to the left because they were getting a little cramped. This message is in response to User:JoshuaAshton's message from 00:18, 7 August 2018 (UTC).

We actually did have some information on there though. We noted that this is from HL2 beta, and that it gets renamed to prop_physics after it spawns. (We also noted that it's, you know, an entity but that's a given.) Pinsplash (talk) 00:24, 7 August 2018 (UTC)

There was no need for this to be its own page, just have an aside on the prop_physics page like there there is added now.JoshuaAshton (talk) 00:27, 7 August 2018 (UTC)

You put that at the very BOTTOM of the page, which was very out-of-the-way. Pinsplash (talk) 00:30, 7 August 2018 (UTC)

It got changed with something at the top like the other pages until someone made the bad decision to remove itJoshuaAshton (talk) 00:33, 7 August 2018 (UTC)

What do you mean? Link this. Pinsplash (talk) 00:34, 7 August 2018 (UTC)

This revision https://developer.valvesoftware.com/w/index.php?title=Prop_physics&oldid=216790 JoshuaAshton (talk) 00:37, 7 August 2018 (UTC)

That note, I have no problem with. My problem is that you're still deleting information for a totally justified page (pages, actually). Pinsplash (talk) 00:39, 7 August 2018 (UTC)

I literally am not. Let's face it. We aren't going to reach a "verdict" because you're so stubborn. I'm just going to undo your changes. JoshuaAshton (talk) 00:44, 7 August 2018 (UTC)

This is a fucking ENTITY. It's even reported as it's own separate thing by dumpentityfactories! Even a console command is more correct than you. Pinsplash (talk) 00:47, 7 August 2018 (UTC)

As I have said before, it's a classname alias and does not warrant its own page. It's clear to me from this you haven't taken 10 seconds to look at the code. JoshuaAshton (talk) 00:49, 7 August 2018 (UTC)

I actually have looked over props.cpp, and not just the snippets that started this fuckfest discussion. A classname "alias" isn't even a thing, physics_prop is literally created and defined through the exact same method as prop_physics. The language used in the code only argues more in my favor by calling physics_prop an entity (LINK_ENTITY_TO_CLASS). Pinsplash (talk) 00:54, 7 August 2018 (UTC)

It's not a different entity. We call this a classname alias. JoshuaAshton (talk) 00:56, 7 August 2018 (UTC)

It is, backed by every piece of code, a different entity. You also cannot make up new terms willy nilly, Joshua. Pinsplash (talk) 00:58, 7 August 2018 (UTC)

No, it objectively isn't. I'm not talking out my ass here. It's literally just a fallback for older maps. Stop trying to make it out to be more than it is, you look incredibly silly. JoshuaAshton (talk) 01:03, 7 August 2018 (UTC)

That is simply not true. I'm pretty certain you're making this "classname alias" crap up. Literally the entire engine agrees with me and ficool. dumpentityfactories agrees, report_entities agrees, dump_entity_sizes agrees, the code agrees in that it creates multiple classnames, the code agrees in that it must change the classname, and even the wiki itself will agree with me.

That's right, the entire MediaWiki software, AGREES. Here's how:

#ifeq

This is an equality parser (see that page for details on it), used by the wiki mostly on templates. We can use this aaaaaaaany wiki page, however. It takes in two strings, and if they match, it gives a positive response. If they don't match, it gives a negative response. Here's what we're about to try out:

{{#ifeq: physics_prop | prop_physics | Pinsplash shut the hell up | Joshua shut the hell up }}

Let's find out what MediaWiki thinks:

Joshua shut the hell up Pinsplash (talk) 01:19, 7 August 2018 (UTC)

This is getting a bit silly now, let's clear this up. In the code, the singular entity cPhysicsProp is linked to two classnames, this is one entity, that can be spawned into the game world using either of those classnames. It's like two light entities, one is called "light1" and the other is called "light2", although they have different targetnames, they are still the same entity in every shape and form. Not only that, but look at this from an outsider's perspective, they will have almost certainly come here for information on prop_physics; or perhaps they looked at the HL2 beta maps and wondered what physics_prop was. If they came here exclusively for info on prop_physics, there is a chance they may type physics_prop on accident, an extra page for that classname would massively confuse things. As for someone looking for info on physics_prop from the HL2 beta, the redirect from physics_prop to prop_physics will tell them a lot: that physics_prop is the same as prop_physics in all ways except for classname, the little note that is also near the top of the page informs them that it is an early classname for prop_physics, if they didn't catch it before. You can't deny the facts produced by the source code. Slartibarty (talk) 01:25, 7 August 2018 (UTC)

There's also many completely different entities that use CAI_BaseNPC. We sort things by classnames, not classes, otherwise everything would go to hell, in short. Typing in a name wrong is kind of... on the user. Pinsplash (talk) 01:35, 7 August 2018 (UTC)

I'm going to agree with Josh on the renaming business. `LINK_ENTITY_TO_CLASS` does not define anything. It just adds an entry in a table so entities with that classname get directed to use the specified class. It's not a seperate "thing", it has no properties in and of itself. It doesn't duplicate the actual class or anything either, both point to the same data. Using either in your map will produce an entity with exactly the same behaviour in every possible way, even the classname is overridden so both show the same thing. It doesn't need it's own page, especially if the page is almost identical to the normal prop - they're likely to start getting out of sync. Aliasing is a rather common thing in programming, especially search "pointer aliasing" - where two names refer to the same object. --TeamSpen210 (talk) 01:29, 7 August 2018 (UTC)

Pinsplash that was incredibly cringy and you should be ashamed at your reasoning and logic in this sitation. It was completely irrelevant to anything and unnecessary - I'd classify it as spam. Thank you for your condescending explanation of how your flawed logic works. Running console commands and arguing semantics on their naming means nothing. Neither does your attempt to be an ass with the comparison of their names being false. Maybe I should do a condescending explanation about how LINK_ENTITY_TO_CLASS works? I'm not as low as you though, and certainly not as childish and stuborn. I will continue to undo any changes you make to these pages regarding this issue. I'm going to bed night night <3 JoshuaAshton (talk) 01:40, 7 August 2018 (UTC)

I'd actually love to hear it. According to the last few messages this completely hinges on me misunderstanding what LINK_ENTITY_TO_CLASS() does, so you are more than welcome. Pinsplash (talk) 01:52, 7 August 2018 (UTC)

Might I also add, according to Sharp (...of all people), you carried this on so long just as a trolling attempt. Pinsplash (talk) 02:15, 7 August 2018 (UTC)

I'm pretty sure I was joking. SharpOB (talk) 02:23, 7 August 2018 (UTC)

I agree with Josh, since most of the stuff you said here doesn't prove anything. LINK_ENTITY_TO_CLASS does create a "link"/factory between a entity name and a class in code, so when engine tries to create an entity with specific name, it looks inside a entity factory dictionary, then, if it finds factory for that entity name, then the factory creates a new instance of class that it was "linked" to. So prop_physics and physics_prop are "linked" both to the same class in code, CPhysicsProp. When game calls spawn function on CPhysicsProp (CPhysicsProp::Spawn), it checks whether its classname is physics_prop, and if it is then it sets its own classname to prop_physics.--SCell555 (talk) 01:59, 7 August 2018 (UTC)

This isn't a trolling attempt I guarantee it Pinsplash. JoshuaAshton (talk) 02:22, 7 August 2018 (UTC)

Ok, so prop_physics and physics_prop are both just factories for CPhysicsProp, the exact same entity. As SCell said, the code in CPhysicsProp::Spawn literally manually changes all physics_prop entities to prop_physics entities. Obviously physics_prop should redirect to prop_physics DankParrot (talk) 02:24, 7 August 2018 (UTC)

I'm well aware of what you're saying, SCell555 and DankParrot, and TeamSpen210, but I still think it should be its own page. Since this is going to start going in circles, I've asked a Valve employee to comment as a verdict. Pinsplash (talk) 02:29, 7 August 2018 (UTC)

We have a verdict already from the overwhelming support against you and the fact that you're just plain wrong. Your decision was bad. The end. JoshuaAshton (talk) 02:36, 7 August 2018 (UTC)

I say we haven't, as I'm not the only person to think this page should not be a redirect. (Among other reasons which I stated.) Pinsplash (talk) 02:40, 7 August 2018 (UTC)

Addendum and reset indents: You really just cannot admit when you are wrong, and now you're going to cry for help because you didn't get your own way. Which is quite sad really. I expected better of you, especially with quite a few of your changes being relatively good. I feel like you're kind of wasting a lot of people's time with this though. Mine, yours, all the other people, and now Valve's just because you can't admit you were wrong.JoshuaAshton (talk) 02:42, 7 August 2018 (UTC)

Kind of oddly personal but I've already admitted I'm wrong once. For the record I originally did have the list of pages in a similar situation to physics_prop (ones created by me at least) as redirects, Ficool was the one who enlightened me that we should do it different. Anyway, let's all shut up about this for now because we all have lives it seems, and this page is more than 85 times the amount of bytes we're fussing over, and we've been at this for over 11 hours. Pinsplash (talk) 02:55, 7 August 2018 (UTC)

Just to be clear, I contacted Valve solely for conflict resolution. I still think I am right, but I really do not care what happens past this point; just want this stupid headache of an argument to be officially over. If there's no comment from Valve after a while, assume I have nothing else to say about this page and all classnames in a similar situation. Pinsplash (talk) 08:49, 7 August 2018 (UTC)

Make sure you send them this talk page too. :) JoshuaAshton (talk) 09:21, 7 August 2018 (UTC)

Valve doesn't comment on what happens here. Solokiller (talk) 09:23, 7 August 2018 (UTC)

Thanks for muting me in your Discord. I have no interest discussing this further with you. As I said before I'm just going to undo your changes. JoshuaAshton (talk) 09:55, 7 August 2018 (UTC)

I muted the entire Verified User role dude. Can we all just stop? Pinsplash (talk) 10:10, 7 August 2018 (UTC)

Revert warring is not an answer to this debate. Pinsplash (talk) 10:17, 7 August 2018 (UTC)

Let's settle this by looking at how Wikipedia handles a similar situation: Harry Potter and the Philosopher's Stone was released in the US as Harry Potter and the Sorcerer's Stone.

Here are the pages for both:

https://en.wikipedia.org/wiki/Harry_Potter_and_the_Philosopher%27s_Stone

https://en.wikipedia.org/w/index.php?title=Harry_potter_and_the_sorcerer%27s_stone&redirect=no

Sorcerer's Stone is a redirect because they're the same book and movie, in the same way that prop_physics and physics_prop are the same entity. It's just a different name.

Case closed, leave it as a redirect, argument over. Nobody has to be banned or muted, and Valve doesn't have to (and never will) intervene. Solokiller (talk) 10:39, 7 August 2018 (UTC)

Guys how do you make those tabs with those : do you use a pre rendered edit version or what? karl-police (talk) 15:55, 7 August 2018 (UTC)

Just put : at the start of your message. More : means more indents. Pinsplash (talk) 15:57, 7 August 2018 (UTC)

AltNames isn't that useful

So I think altname is kinda flawed notice. It's often irrelevant information what other entity is tied to the same c++ class as the entity we are reading about. On entity pages what mainly matters is the usage of the entity not what other entities are implemented similarly. Also when there are multiple entities tied to single class there can still be differences and very often are. The difference can be for example different FGD entry (info_null/func_null, move_rope/keyframe_rope only difference in FGD) or there is a piece of code that is checking the classname keyvalue and changing the behaviour based on that which is often the case (light entities for example which vrad treats differently, physics/dynamic _override, CNodeEnt that has 6 node entities tied to it all for different purposes).

Let's take prop_physics for example. prop_physics_override is also tied to the same c++ class name but listing it as altname is not correct as the usage is completely different.

physics_prop does make more sense to list as altname but there are other issue with this. The main issue I think is that the information is completely useless to anyone using prop_physics and despite that it has shiny notice at top of the page about it. That information is just trivia that should be at the bottom of the page in context of prop_physics. But being at the bottom of the page has other problem. Because physics_prop page is just a redirect to prop_physics this makes it not a good idea to move that to the bottom of the page because it would cause confusion to people being redirected. Another issue is there are some notable things about physics_prop that has no place being on prop_physics page and that is info about its obsolesence/deprecation, inavailability in fgd, where it was even used/reason it even exists and the name fixup to prop_physics upon spawn. All that feels like useless information if it was put on prop_physics page and that's why I think it should be its own page instead of redirect. Based on some comments here people think it's clutter and just one more click away from prop_physics but I don't see how. I doubt anyone that voted NO here ever used that physics_prop redirect. Anyone who isn't Memento protagonist will remember that prop_physics is the entity they want to use and that's what they will search. Anyone searching for physics_prop is more likely to be curious what that is instead of mistakenly wanting prop_physics. The information about what entities are tied to a single class is relevant on the c++ class page like this CNodeEnt.

In conclusion entities being tied to same c++ class is not as relevant and they are still considered different entities and should have their own pages (of course there may be exceptions but I don't think physics_prop is one of those).

Maybe I am exaggerating the clutter a single notice is causing on a prop_physics page but I think for sure a separate page for it is a lot less clutter --Nescius (talk) 05:53, 24 September 2024 (PDT)