Template talk:O

Empirically determining !activator and !caller

It's easy enough to guess oftentimes, but I was wondering if there was a more error-proof way of determining them (be it reading source code or setting up an I/O chain).
— SirYodaJedi (talk) 09:23, 24 April 2025 (PDT)

Reading the source code is mostly error proof by just checking what parameters is .FireOutput or .Set called with for example. Checking out activator and caller in IO can be done like this

Example with checking activator and caller of OnTakeDamage output of prop_physics. I aimed at it and used !picker to target it and addoutput to it first in this case. Then paused the IO. Shot the prop_physics and checked with dumpeventqueue command.

] ent_fire !picker addoutput "OnTakeDamage whatever"
] ent_pause 
Pausing entity I/O events
] dumpeventqueue 
Dumping event queue. Current time is: 941.23
   (940.83) Target: 'whatever', Input: 'Use', Parameter ''. Activator: 'Nescius', Caller 'prop_physics'.  

Or also in games with vscript can use something like ent_fire !picker AddOutput "OnSomething !caller:RunScriptCode:printl(self)" which will print the caller

Example of checking OnUser1 output.

] ent_fire !picker addoutput "OnUser1 whatever"
] ent_pause 
Pausing entity I/O events
] ent_fire !picker fireuser1
] dumpeventqueue 
Dumping event queue. Current time is: 955.63
   (955.63) Target: '!picker', Input: 'fireuser1', Parameter ''. Activator: 'Nescius', Caller 'Nescius'.  
Finished dump.
] ent_step 1
] dumpeventqueue 
Dumping event queue. Current time is: 955.63
   (955.63) Target: 'whatever', Input: 'Use', Parameter ''. Activator: 'Nescius', Caller 'prop_physics'.  
Finished dump.

--Nescius (talk) 09:55, 24 April 2025 (PDT)

Reading the source code is mostly error proof by just checking what parameters is .FireOutput or .Set called with for example.

Okay, if I'm reading CBaseEntityOutput::FireOutput() correctly, it looks like it's .FireOutput(value,!activator,!caller,delay), with value and delay being optional. If I remember C correctly, "this" should be !self.
— SirYodaJedi (talk) 11:08, 24 April 2025 (PDT)

This code for example

void CBaseEntity::InputFireUser1( inputdata_t& inputdata )
{
	m_OnUser1.FireOutput( inputdata.pActivator, this );
}

Will cause !activator to be the activator of the FireUser1 input that was sent and !caller and !self to be equal to the this entity (the one that FireUser1 was sent to). Check also stuff I just mentioned here Talk:Targetname#!caller_is_weirdly_incosistent --Nescius (talk) 11:34, 24 April 2025 (PDT)

Yeah, I saw that post. A lot of entities seem to use m_Whatever.FireOutput(this,this) even when they shouldn't.
— SirYodaJedi (talk) 12:06, 24 April 2025 (PDT)

woifurawiufiuwaofiwunaw

This still feels kinda confusing at the moment. Because the !activator/!caller/!self currently only specifies how 'Target entity' behaves. I am not sure how to make this clear and ensure that someone won't think it also applies to some random input's parameters. --Nescius (talk) 14:03, 25 April 2025 (PDT)

Hopefully all makes sense now with only activator and caller being specified on outputs and addition of Targetname#Concept_of_activator_/_caller --Nescius (talk) 01:36, 26 April 2025 (PDT)

thinking out loud idk

Outputs don't have concept of targetting !self. Outputs only specify events that are to be added to the event queue when the given output fires. Maybe that is what's making it harder to think about then it should be.

• OnUser1 !self:DoWhatever:666 - should be considered a bad practice because events in the event queue don't have information about who created the event and therefore !self is flawed concept. Events only have information about who is considered activator and who is considered caller which both can be arbitrarily set in FireOutput method. (just why didn't valve simply put that information into the event!?)

• OnUser1 some_entity_maker:ForceSpawnAtOrigin:!self - In case !self is used as input parameter we are fine because when entity is accepting an input that entity knows !self and also knows who was the caller and activator of the input so can work with all 3.

Or maybe I am just dumb --Nescius (talk) 14:26, 25 April 2025 (PDT)