player Inputs and Outputs

[Phisionary]

I was intrigued by the input/output possibilities of !activator (thanks to Raeven0, btw), so I played around some. I'd like to make a map using some of this stuff, but unless you did it right, I bet it would be kind of gimmicky and un-fun.

But, since I haven't seen this anywhere yet, here is a list of all player inputs and outputs, in CS:S
I have good reason to believe that the commands for HL2 and HL2:DM are a little bit different.

These could be useful in combination with some special entity names. Here's a list of some (not all related to this, but nice nonetheless): www.editlife.net
also of note: using entity name player refers to all players on the server.

output: OnIgnite // When the player cathes on fire. Easy.
output: OnUser1 // One of four user triggerable output events.
output: OnUser2
output: OnUser3
output: OnUser4
input: OnRescueZoneTouch // Dunno haven't played with it.
input: SetHealth // sets player (or NPC, incidentally) health, locked from 0-100
input: physdamagescale // scale of damage done by physics objects. Useful for some specialty physics maps maybe.
input: KilledNPC // dunno
input: skin // did nothing that I could tell
input: SetBodyGroup // something to do with animation, apparently can alter NPC appearance.
input: Ignite // burn, baby, burn!
input: SetLightingOriginHack // ??
input: TeamNum // ??
input: SetTeam // changes player team. 1- spectator , 2- terrorist, 3-counterterrorist -- other values allowed but do appeara as spec.
input: Kill // I tried this and it was not good *!crash!*
input: KillHierarchy // didn't try this
input: Use // hmm, maybe for npc's
input: Alpha // sets transparency. didn't work for players. I think the smoke gren I threw through an !activator trigger got transparent, but it was shorty after too smokey to tell.
input: Color // also, doesn't work for players. The blend mode doesn't seem to be right, the color would change a bit, but each change would make them very dark.
input: SetParent // parents to another entity. I was still affected by gravity, and player motion got decidedly wonky.
input: SetParentAttachment // ?
input: ClearParent // self-explanitory
input: SetDamageFilter // This seemed very cool. you can filter what forces can apply damage to the player (or any other object that has this input). I made it so I couldn't hurt myself with my own grenade... Could also make a temporary invulerability on your map if you wished. IgnoreFallDamage does not work with CS:S
input: EnableDamageForces // don't know. supposedly, this alters whether getting damaged applies a physics force. No effect noticed on a player entity.
input: DisableDamageForces // ...
input: DispatchEffect // unknown, has something to do with spcial graphical effects, but couldn't find anything about it not related to sdk coding.
input: DispatchResponse // ???
input: AddContext // ???
input: RemoveContext // ???
input: ClearContext // ???
input: DisableShadow // didn't seem to affect players
input: EnableShadow // ...
input: AddOutput // super powerful, but less so for the player, due to teh lack of useful player output triggers.
input: FireUser1 // I see how you could use these to save information with a player. like, you'd have to get a 'key' to go through a certain door on your map... I'm not sure, but it has possibility. Tied to the OnUser1 output.
input: FireUser2
input: FireUser3
input: FireUser4

I should mention that these settings do not (neccesarily) reset after a round has ended. I noticed some odd instability at round ends when playing with SetParent, and Color changes stayed as well. Most notably, added outputs (via AddOutput, surprisingly) carried over from round to round.

Lastly, if you want to examine the traits of some other object (or other mod), you can do it from the console, with the ent_info <entity class> command. For example, I entered ent_info player to get this list. Other commands useful for fiddling with such things? ent_text, ent_fire, ent_setName (for interacting in realtime with unnamed single entities) and others in the ent_ branch of commands.

Hope someone finds this useful.

 

[Raeven0]

OnRescueZoneTouch should've been coded as an output, not an input. Ignore; useless.

KilledNPC is fired when a player kills an NPC or another player. Again, should've been coded as an output. Suggest ignoring.

Skin allows you to change the skin of models that have more than one skin. Ignore for players.

SetLightingOriginHack is a broken feature allowing a moving entity, such as a player or a prop_physics, to take on the lightdata of a different area of the map, in the same way a prop_static uses an info_lighting to do that. Valve included some code for this, but never finished it.

It is definitely not good to Kill or KillHierarchy the player. He doesn't like being removed entirely.

I thought SetDamageFilter would allow you to choose a filter_damage_type entity to filter out damage forces. It didn't work when I tried to use it that way.

Effects, responses, and contexts are entity-specific settings that require the entity to have certain properties or keys before they can perform certain actions, such as speak.

 

[Phisionary]

OnRescueZoneTouch should've been coded as an output, not an input. Ignore; useless.

KilledNPC is fired when a player kills an NPC or another player. Again, should've been coded as an output. Suggest ignoring.

Thx for the clarifications on these. I cut and pasted these right from the console. Interesting. [Edit]Wait... so these should be outputs, and don't work because they aren't coded properly, or just don't show up right? :? Nm, I guess I'll find out if I need to. :|[/Edit]

Skin allows you to change the skin of models that have more than one skin. Ignore for players.

If you're aware, who/what does have skins that can be changed with this? Just curious.

...
It is definitely not good to Kill or KillHierarchy the player. He doesn't like being removed entirely.

Apparently not :cheese:

I thought SetDamageFilter would allow you to choose a filter_damage_type entity to filter out damage forces. It didn't work when I tried to use it that way.

Hmm. That is interesting. I forgot that entity existed :E I used a filter_activator_team, set to allow only terrorist. As a CT, I could not hurt myself after triggered, as a T, I could. I tried one other combination that didn't work, but that was most likely due to human error.

Effects, responses, and contexts are entity-specific settings that require the entity to have certain properties or keys before they can perform certain actions, such as speak.

Do you know of any place that has a table of valid stuff of this type, in case any of them are usefully cool enough to be used? Or perhaps it's not used at all in CS:S.

 

[Raeven0]

Thx for the clarifications on these. I cut and pasted these right from the console. Interesting. [Edit]Wait... so these should be outputs, and don't work because they aren't coded properly, or just don't show up right? :? Nm, I guess I'll find out if I need to. :|[/Edit]

They should be outputs, but for some reason Valve saw fit to make them inputs instead.

If you're aware, who/what does have skins that can be changed with this? Just curious.

Players don't, but some light models have a skin for On and a skin for Off. The oildrum has a brown skin and a white skin.

Hmm. That is interesting. I forgot that entity existed :E I used a filter_activator_team, set to allow only ist. As a CT, I could not hurt myself after triggered, as a T, I could. I tried one other combination that didn't work, but that was most likely due to human error.

Aha, I had forgotten that the activator filters could be used as damage filters.

Do you know of any place that has a table of valid stuff of this type, in case any of them are usefully cool enough to be used? Or perhaps it's not used at all in CS:S.

Well, somewhere in the GCF (I've forgotten where) is a long file that gives a lot of data about contexts and such as that. It's difficult to understand much of it from a purely mapping perspective, but I gathered that the "Response Contexts" property of NPCs allows the mapper to set certain conditions that must be true for the NPC to be able to speak.

Ah, here. <source engine>\hl2\scripts\talker\response_rules.txt.