Template talk:This is a

This is the discussion page of Template:This is a. To add a comment, use the Edit button near the headline of the appropriate section. To create a new section, you can use the Add topic button at the top of this page.
Comments on talk pages should be signed with "~~~~", which will be converted into your signature and a timestamp.

Archives

Archive 1

Auto category feature is quite problematic

This template automatically adds pages to categories based on the "game" parameter, however if you set the game parameter as tf2, it won't try to add it to "Team Fortress 2 entities", it'll try to add it to "tf2 entities"! Surely there's someway the acronyms could be converted to the full names? Isn't that pretty simple template stuff? There's also some other quite big problems, which I mentioned here. --Wisdurm (talk) 13:28, 7 Jan 2024

Minor grammar nitpick

Not sure if it's something that should really be bothered with fixing (since it seems quite difficult and not very important) but the line "...is a internal point entity..." is incorrect grammar and should instead be "is an internal point entity" since "internal" starts with a vowel. Again, very minor thing that would be annoying to figure out since only some of the entity types start with vowels. Now that you point that out, it bugs me to. Should be an easy fix; just move the the a/an, so you have "this is" + "a thingy" instead of "this is a" + "thingy". --SirYodaJedi (talk) 0:04, 20 May 2024 --Wisdurm (talk) 21:45, 19 May 2024

That's a good solution for English rules that I'm not against implementing, but I feel like there should be a more general method for the type having an effect on the other strings; for example, the Spanish strings for "This", "cut", and "internal" all depend on the grammatical gender of the noun. I'd also note that if we can get a version of  template:delink working, then {{a or an}} could be used. Unfortunately, since Wikipedia switched their delink template to use a module, they deleted  Template:Delink/phase_1_a, so I have no idea how the template works. However, I bet a version of it is floating around some wiki somewhere. --Pee (talk) 0:27, 20 May 2024

The other option I see that I think makes the most sense is to make separate subpages for different clauses in different languages, such as {{this is a/a or an}} or {{this is a/Spanish gender}} that get called in {{this is a/strings|this is a}}. This system should scale for an arbitrary number of languages. --Pee (talk) 1:03, 20 May 2024

Categories

Is sorting entities by game AND type really necessary? For instance env_skypaint, which would previously have been in Category:List of Garry's Mod entities, is now added to Category:Garry's Mod point entities. I feel like having a category just for entities for a specific game is much more helpful & practical since most games don't add hundreds of entities, though I guess in theory if you wanted to you could have both. I do realize this was mentioned in rewrite, so sorry for not saying anything about it back then. Also entity list pages on the wiki are kind of a mess in general right now, they should probably all be redone using the script. --Wisdurm (talk) 17:07, 24 May 2024

I decided to split the subcategorization into several different parts. A page with the template {{this is a|point entity|cut=1|internal=1}} will now be in the categories Cut Source base entities, Internal Source base entities, Source base entities, and Source base point entities. I'd assume all but Source base entities would be hidden categories. --Pee (talk) 21:20, 24 May 2024

Possible removal of {{game icon}}

I was wondering whether or not keeping {{game icon}} would be a good choice. Ultimately at the end of the day it relies on {{game icon name}}, which is just another template that needs constant updates. In the current form of this template you could remove all instances of {{game icon}} and things would mostly work fine. Of course this would necessitate the creation of templates like Template:Garry's Mod and Template:Left 4 Dead Series, but overall I think it'd just be less of a pain.
This is of course simply a matter of preference and I don't really mind either way, just curious to see other opinions. --Wisdurm (talk) 8:47, 7 Jun 2024 I think I created that template back then because there were/are cases where you have the full game name but you need its shortcut in order to get its icon. {{game icon}} was supposed to separate the name list template and a template that you can use that simply puts that result into template brackets for direct use. Now, if I understood you correctly, the idea is to instead create the templates {{Half-Life 2}} etc. that have the same effect (or are a redirect to) {{hl2}}, etc.? Well, I think the idea may be good because it causes less (expensive) template calls, but that's not much that I can tell. The idea doesn't seem bad to me, or would we pollute the existing pages more if we created that number of "duplicates"? I don't know whether that is a problem or not. But what I would appreciate is if we can reduce page load times by getting all those template calls more efficient. (Although I'm not sure to what extent this may be caused by templates related to either games or i18n or...) --Popcorn (talk) 14:26, 8 Jun 2024

I'd prefer the default to be no icons AND no colours, so game/engine links parsed into the template would just cause it to render plain links (in bold). Looking at so many pages is just like reading posts from someone who uses emojis 3 times per sentence. Cvoxalury (talk) 13:29, 21 June 2024 (PDT)

The issue with removing the template entirely is that it gets rid of automatically translated titles. For example, this will render differently in English and Chinese: Half-Life 2. The most efficient way to redo this would be to create a template called {{Half-Life 2}} with the following as its contents:

{{#switch:{{intlang}} |#default = [[Half-Life 2]] |zh = [[Half-Life 2|半衰期2]] }}

From here, there are 2 ways to go:

1. Force {{this is a}} to link to {{Half-Life 2}}. A red template link will appear if the template doesn't exist, so it's easier for people to figure out what's going on.

2. Check if {{Half-Life 2}} exists, and if it doesn't, then instead just link to the raw text of the parameter game. The issue with this solution is that it a template with 5 games will have 5 #ifexist functions on it, which could contribute significantly to the limit of 100. There's a way to implement it without #ifexist, but it turns out that it's actually slower than #ifexist. ―Pee (talk) 20:02, 21 June 2024 (PDT)

Since the recent changes to the language handling (prefixes, LanguageBar, L-template etc), did it affect this situation? Can putting the icons away be brought up again? Cvoxalury (talk) 11:10, 20 July 2024 (PDT)

I don't think there needs to be a change in regards to icons and colored text in 'This is a' template. It's quick way to see what game/engine the given thing is in without having to really read it and it looks fine Nescius (talk) 12:03, 20 July 2024 (PDT)

The coloured text has different contrast on each title, with some like Ricochet, Xengine, Vance, or Trenchbroom being quite bad. The reds, purples and browns are generally bad. There's even grey text ones like VBSP, VVIS, VRAD, VHLT, with both dark grey icon and grey text, which staggers the mind. If it's icons and no text ("only in", "since") it requires memorising what they are or waiting for hover on each. Cvoxalury (talk) 12:43, 20 July 2024 (PDT)

I guess I'll at least try to tweak some of these colours a bit so they're not so neon bright or dull (I'll be careful). Still think the icons were a mistake to begin with, especially why have them at the very beginning of articles when it's already about the subject. Cvoxalury (talk) 12:49, 20 July 2024 (PDT)

Entities that can be either brush or point entities

Some entities, such as func_tank (GoldSrc) and func_team_wall can be used as either a brush entity or a point entity; there should be some way of properly noting this.
— SirYodaJedi (talk) 12:11, 29 June 2024 (PDT)

Non-fgd entities

So the distinction between point/brush entity is purely a FGD thing if I understand correctly. It would be probably worth having a param for entities that are not in fgd at all Nescius (talk) 16:57, 29 July 2024 (PDT)

Why not. What would it be called, just "non-fgd entity", or "undefined" entity perhaps? "non-fgd" is a bit inelegant (and translation could be an issue) but otherwise gets the point across...

Would it remove the need for a separate little banner about non-fgd entities?

(the distinction between point and brush depends on whether it's engine-centric POV, fgd/hammer-centric, compiler-centric, but there's no need to get into it really. For purposes of this it's enough to call it "purely FGD thing", lest we find ourselves questioning if areaportals and occluders are brush entities (in editor) or point entities (by the time they're processed in the game, they are)) Cvoxalury (talk) 08:49, 30 July 2024 (PDT)

What I went with on few pages is simply "This is a entity" but non-fgd entity sounds also good considering that can get rid of the non fgd notice at top of the page for such entities. The notice will still be used for entities that are in fgd only for certain games because it contains info about which games is the given entity not in fgd.

Or maybe create a new name for it like "technical entity" because really stuff like cs_team_manager, spraycan or even just player which are not usable in any way by adding them to the map in hammer. Though there are still some entities that are not in fgd but are usable if added to fgd like weapon_smg

On another topic it would be also worth adding info about server side entity like "This is a server-side point entity" for example which is very useful to know considering there are 2 limits one for edicts which crashes the game when exceeded and the other for server side entities which doesn't crash the game but only leaves warning in console --Nescius (talk) 09:20, 30 July 2024 (PDT)

Since non-fgd entities can be still be added to FGDs, I think it'd make more sense to treat them like so:

• Has bmodel? Brush entity.
• Has origin KV but no brushwork? Point entity.
• Doesn't normally have brushwork or origin KV? Just entity.

This is basically how map editors distinguish between brush and point entities already.
— SirYodaJedi (talk) 07:57, 14 September 2024 (PDT)

Every entity has origin keyvalue so not sure what you mean there. Entity that uses a brush and is not in any fgd indeed feels correct to call brush entity but it's not really if we consider brush entity = entity defined in fgd as brush entity. And if it's not defined in any official fgd I think it's fine to keep as just entity and all such cases will probably be entities not really meant to be placed by hammer. There are several entities that are brush entities but would also work by setting their mins/maxs and solid keyvalue to 2 instead of using a brush. Maybe wouldn't be bad to just call them non-fgd entities ? Or something new like technical entity since they are not meant for hammer use but are automatically created by other means --Nescius (talk) 10:17, 14 September 2024 (PDT)

Every entity has origin keyvalue so not sure what you mean there.

Keyword "normally", as in the KV actually being written to (either in the BSP itself or when dynamically created in RAM), and not defaulting to triple zero. For example (IMO), info_ladder should just be "entity" like it currently is, since it isn't written with an origin. func_simpleladder, by comparison, contains a bmodel, so it should be "brush entity" instead.
— SirYodaJedi (talk) 13:45, 5 April 2025 (PDT)

internal entities

Internal entities should probably say something different than "available in games". After all they are not really available in any game but just in the compilers. Can be argued that prop_static is available in-game but thing like func_viscluster is in no way represented in-game--Nescius (talk) 08:11, 2 September 2024 (PDT)

Add multiple "name" parameters.

Code is hard to understand and i don't even have time either so can somebody add multiple "name" parameters (name1, name2, and so on, like engine1), so this template can be added on pages like counterterrorist_team_intro and info_player_counterterrorist. --leonidakarlach (talk) 04:46, 10 February 2025 (PST)

Done. --N0one (talk) 11:21, 10 February 2025 (PST)

Internal "shader parameters"

When making %alphatexture, I noticed that using the internal flag added it to the list of "Internal Garry's Mod entities". Is there a better way of handling VMT parameters that aren't used by the material system?
— SirYodaJedi (talk) 14:50, 20 March 2025 (PDT)

multiple names not working properly for qc commands

See $keepbone_and_$protected_(GoldSrc). I can set {{{name0}}}, in which case the "this is a" text renders correctly but the title is wrong, or I can set {{{name0}}}, in which case the title is correct but the "this is a" text says "this are QC commands"^[sic].
— SirYodaJedi (talk) 12:01, 25 March 2025 (PDT)

notitlechange param is available for this template --Nescius (talk) 12:04, 25 March 2025 (PDT)

point and brush entities

So I wonder what if it would be good idea for "point entity" and "brush entity" options to say

• "xxx is available in FGD as point entity in/since etc. ..."
• "xxx is available in FGD as brush entity in/since etc. ..."

while entities that are non-fgd would simply specify "entity" and say what is says now

• "xxx is an entity available in/since etc. ..."

pros:

• makes it clear what being point/brush entity means
• when somebody makes a page with some technical non-fgd entity they will realize they shouldn't say it's "point entity"
• gives better idea in which games the entity is actually more useful or intended for use like trigger_auto_crouch
• FGD link right in first sentence and could probably link to a page that would list all official fgds so any fgd is 2 clicks away

cons:

• bunch of pages would need updating like env_global which says in all source games currently. (all such pages are those that transclude {{Ent not in fgd}})
• maybe some confusion in some cases ?

--Nescius (talk) 12:42, 5 April 2025 (PDT)

Possibly confusing because it's much more spotty which entities are available in the FGD, whereas in-game availability is more consistent.
— SirYodaJedi (talk) 13:50, 5 April 2025 (PDT)

What about separation into brush, model, logical and point entity ? This article written by valve employee supports that but doesn't include the point entity though which would in this case mean "uses its origin for something" like info_target,

• brush entity - uses a brush
• model entity - uses studio model (basically all derived from CBaseAnimating)
• logical entity - its origin is not used for anything (not necessarily derived from CLogicalEntity as logic_auto, info_gamemode, shadow_control would still fall into this category, even auto spawned entities used for managing some stuff like soundent, terror_gamerules could fall here)
• point entity - its origin is used for something (info_target, info_player_start, env_sprite, info_particle_system pretty much all of these would be derived from CPointEntity)
  --Nescius (talk) 13:18, 9 April 2025 (PDT)

That seems like a good way of splitting it for Source, although it becomes fuzzier when you apply the same template to GoldSrc (env_sprite is often used for studio models, MDLs can be used on brush entities with zhlt_usemodel [which really just rearranges the entity lump so that the model is precached with a different entity first], CBaseAnimating is used by func_door and func_illusionary, DMC items don't use CBaseAnimating, etc).
— SirYodaJedi (talk) 13:58, 9 April 2025 (PDT)

Not sure how to deal with that in regards to goldsrc but I assume those rather hacky way to use those entities. Being model entity doesn't strictly needs to mean it's using CBaseAnimating but rather that it's meant to render a studio model which would in I assume 99.9% cases using CBaseAnimating--Nescius (talk) 15:27, 9 April 2025 (PDT)

It is somewhat hacky, yes, but sometimes it's intended behavior, like in , where func_tank actually precaches MDLs defined in its model KV, and they actually used it that way in the vanilla game (instead of the obvious solution of making an env_tank alias, but I guess Radiant was less picky about brush entities being used as point entities than Worldcraft).
Looking at env_sprite's code, it is basically a model entity, even in Source.
— SirYodaJedi (talk) 06:25, 10 April 2025 (PDT)

The main purpose entity was made for is usually clear and if entity can be meaningfully used differently it can be noted. The func_tank case also precaches the model so they also modified the entity further for . It would be possible for example for logic_auto to draw a brush model too as it's derived directly from CBaseEntity and nothing in code is stopping it, but it's without a doubt logical entity --Nescius (talk) 11:14, 10 April 2025 (PDT)

In case it was unclear, I don't think your suggestion was a bad idea; I just needed to play devils advocate to clarify edge cases.
— SirYodaJedi (talk) 06:44, 11 April 2025 (PDT)

This is the idea kinda User:Nescius/entity. Also added type "semi-internal" there which might be useful --Nescius (talk) 18:59, 14 April 2025 (PDT)

semi-internal

Thinking of adding semi-internal as a type of entity. This would signify that the entity is non-internal but huge portion of its functionality is taken care of by compiler and the entity is pretty much useless without compiler doing its job. So for example light entities which are taken care of mostly by vrad along most of their keyvalues, func_detail_blocker which is used to block detail sprite during compile and the entity doesn't do anything in-game other than exist, func_areaportal which is effectively point entity in game and has no brush, probably also info_overlay_accessor but haven't looked much into that one. --Nescius (talk) 12:35, 20 April 2025 (PDT)

Sounds like a good idea. Would info_null also count, since it's deleted as soon as it spawns?
— SirYodaJedi (talk) 13:09, 20 April 2025 (PDT)

No because compiler doesn't do anything special with info_null and just puts it in entity lump --Nescius (talk) 13:12, 20 April 2025 (PDT)

Okay, that makes sense. I think info_overlay_accessor would indeed qualify then.
— SirYodaJedi (talk) 13:12, 20 April 2025 (PDT)

Still not sure about that one. Because it seems compiler only checks if info_overlay has targetname and then creates info_overlay_accessor with that overlays' ID which is something that can be done manually after compile as well by checking desired overlay id and spawning the info_overlay_accessor via vscript. Which would be very similar to how func_simpleladder works in which case compiler simply checks which side of func_ladder has laddertexture and adds func_simpleladder with normal.x/y/z keyvalue being set based on that. Now if compiler somehow modified named info_overlay to allow info_overlay_accessor to work (and otherwise would not be usable) it would be indeed semi-internal without question --Nescius (talk) 13:22, 20 April 2025 (PDT)

since

Maybe in case of engine branches it would be good to abandon the word since and have something like "based on/using". "This is a available in games based on/using Team Fortress 2 branch." But I almost surely can't be bothered to do such edit or give it too much though so just an idea if someone finds it plausible. --Nescius (talk) 15:10, 10 May 2025 (PDT)

cut parameter

The cut parameter is kinda weird to read. "This is a cut entity available in <whatever game>" --Nescius (talk) 08:59, 11 May 2025 (PDT)

Concur. Scrapping the "available" would fix it. Heck, I don't think the "available" is really necessary for non-cut items.
— SirYodaJedi (talk) 09:01, 11 May 2025 (PDT)

Preview readability

The previews look all squished in the table, so i made an example on the Template:This is a/sandbox page that is on a new row. --N0one (talk) 09:20, 11 May 2025 (PDT)

Lot better --Nescius (talk) 09:23, 11 May 2025 (PDT)