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)

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)