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)

---

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)

---

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)

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)