Talk:Entity Article Template

Wouldn't these templated entity pages become somewhat redundant with quasi-tutorial pages like Assaults? Or should these entity pages be kept as placeholders until more expansive pages can be written? --Demented 15:25, 4 Jul 2005 (PDT)

Feedback

I think this template could use some improvements.

• First off, it's missing a Flags section, which I think most entities have.
• The entity name under the description isn't needed. The name is right at the top of the page already, and duplicating it just takes up more space.
• I think it could use some horizontal rules between the Entity Data sections. I looked at Env_fire -- it looks easier to read to me. Is the Entity Data section headline needed at all? It makes the article layout and the table of contents noisier, but that's debatable I guess. The format of the keys in the template seems better though, where the whole thing isn't bold, only the name of the key.

--IanL 11:58, 9 Jul 2005 (PDT)

Hooray! Constructive criticism! :-)

Ideally, I'd write a script to convert stuff from the FGD into the correct format, but that of course depends on me assigning some of my copious free time to the task. The current arrangement of headers and things makes a bit more semantic sense to me, but visually it's not so great. I think returning to ==These Headings== might improve that, as per your suggestion...

Flags? The text isn't present in the copied-and-pasted 'Help' text in Hammer, but can almost certainly be extracted by my hypothetical script.

Anyhow, when some final design is decided on (feel free to edit!), I can do some batch conversion with my fabled, non-existent script and make everyone happy. While the FGD-based information is hardly sufficient for a complete Wiki, I do feel it's useful data that can be used as a basis for more extensive work.. --Cargo Cult 12:08, 9 Jul 2005 (PDT)

OK, I'll make a couple edits. Yeah, the flags aren't in the help output. I just looked in an FGD, and the info is in there. I wonder why they didn't do that. Must be a formatting thing or something. It seems like there's a lot less flags in Source than there was in Half-Life 1, anyway.

I'm really unsure on the header thing myself. The one thing the extra level of heading does is give room to add new larger section to the article later, like a tutorial or usage section. --IanL 12:23, 9 Jul 2005 (PDT)

I'm probably going to get an unbelievable amount of stick for suggesting this (as most entities have already been documented with this template) but shouldn't the Entity description be under the headline, above the TOC? In contrast to how it is positioned now, under the TOC, having its own header. Most of the descriptions seem to.. well.. describe what the entity is and how it behaves, this IMO should be right in the opening "intro" paragraph of the entity article. Jupix 06:06, 4 Feb 2007 (PST)

User inputs and outputs

The FireUserX inputs & corresponding OnUserX outputs are valid on every single entity in the game, and actually have nothing to do with the particular entity itself. Instead of bloating every entity description with them, it might be good to link to a single article that explains how they work and what they're for. -- Robin Walker 13:53, 9 Jul 2005 (PDT)

Yeah, that seems like a good idea. The help built-in to Hammer should do that, too. ;)

The only question is where to put the link. Should we just add it to the base Entity category page, or add the link to every entity description? I lean towards the former. The problem is, I don't think these outputs are used very often, but they're very visible. --IanL 14:02, 9 Jul 2005 (PDT)

Heh, and I'd been religiously copy-and-pasting the formatted versions from my entity article template... Silly question, though - what do the OnUsern things actually do? I've yet to figure it out! :-)

The FireUserN input simply causes the corresponding OnUserN output to fire. They're useful for forwarding messages through an entity where the desired target is known to the forwarding entity, but not to the firing entity. For example, say you have 3 trains moving along the same set of path_tracks. Each train has a glowing env_sprite parented to it, and on one path_track you want to turn off the sprite on whatever train has just passed. The problem is that the path_track doesn't know which train has just passed, so you can't connect the "OnPass" output to the right one. So, you solve this by connecting the path_track's "OnPass" output to the !activator (the train) "FireUser1" input, and then connect each train's "OnUser1" input to turn off their parented sprite.

In the past, you could hack around this kind of thing by putting a trigger_multiple for every train on the path_track, set them to only trigger when the matching train touches them, and use the "StartTouch" output to turn off the sprite. Unfortunately, that method doesn't scale to large numbers of trains (as seen in the citadel). -- Robin Walker 18:17, 9 Jul 2005 (PDT)

I shamelessly ripped off this explanation as the basis for User Inputs and Outputs. It is a subject that can be a little tough to wrap your head around at first, but when you need it, it's invaluable. --JeffLane 21:16, 9 Jul 2005 (PDT)

Oooh, excellent. Thanks for that - and many thanks for all the other bits and pieces of Half-Life 2 and Source that you're documenting! --Cargo Cult 11:46, 11 Jul 2005 (PDT)

With regard to oft-duplicated content, there's also a lot of stuff for the NPCs which gets spread around, like AI node information for snipers. Any thoughts on that? --Cargo Cult 14:14, 9 Jul 2005 (PDT)

It looks like someone is making templates for some of the common keyvalues right now. --JeffLane 21:16, 9 Jul 2005 (PDT)

SmartEdit values

I can't find my way around these keyvalues because I (probably along with most people) use SmartEdit. I'd like to list the SmartEdit keyvalues for the entities instead, but need to run this by you to make some kind of new standard. Preferably I'd like to list the values as "SmartEdit keyvalue (FGD keyvalue)". For logic_auto, that would probably be "Global State to Read (globalstate)". What do you think? --Andreasen 17:15, 29 Jan 2006 (PST)

this is most likely not okay because we already have hundreds of entities documented...this would be ok if anyone wanted to run through all of them and fix them up—ts2do 18:03, 29 Jan 2006 (PST)

I know it would be really hard work to convert them all, but it would probably improve things a great deal for beginners. If we could make some kind of small note to the new or old standard pages, linking them to this Entity_Article_Template article to inform them of a new standard, the wiki community might just be able to convert the pages gradually without confusion. I mean the old values would still be there, as a part of the new format too, but just in another position. --Andreasen 09:55, 31 Jan 2006 (PST)

I agree with this. The entity help built into Hammer lists boths the SmartEdit names and the "real" keyvalue entries for this exact reason. I don't see any reason why this formatting couldn't be added incrementally, and I think it's worthwhile, but it is up to the community to decide whether they wish to take task on. There is a fair amount of the basic data shared in templates, which would shorten the time needed. --JeffLane 12:01, 31 Jan 2006 (PST)