Self? Other? Owner?

[toneddu2000]

[taniwha]

To be asking questions like this, you actually do get the concepts of quakec .

Anyway:
self: the currently active entity. for think functions, it's the entity doing the thinking. in touch functions, it's the entity being touched (eg, doors). Set by the engine.
other: the other entity in touch functions. ie, the entity doing the touching (eg, the player). Set by the engine.
owner: the entity that "owns" the entity in question. Used mostly for missiles so grenades/rockets won't explode on the firing player, but also for paired doors (doorent.owner is the "master" door). Set by QC.

For self and other, there are times where QC sets the field, but these are rare, and the field is usually restored to its previous contents after doing something fancy.

[Seven]

Hello toneddu2000,

For me, it helped a lot to read and understand the items.qc.
It helped me to proper understand what is "self" and "other".

Items.qc handles the powerups and keys and stuff.
So, all the models, that do nothing, but are touchable (!).
The players or monsters, who walk around and touch these models are always: "other" in the viewpoint of the powerups.

Example:
The health boxes functions have a lot of "other." in them, because they give the others health points, right ?
They do not give the health points them'selves'.
The "other" is the player who touch them.

One more important thing:
Look into Throwgib function (in player.qc) for example.
You can spawn new local entities and give them ANY 'name.' you want.
Example in throwgib: 'new.'
So all declarations start with 'new.' then.
But as soon as you jump into the next function that handles these entities,
you must use 'self.' for them (if it is not a global).
If you make these entities touchable, the player/monster that touches these passive ents are the 'other.' again (like described above).

I put my mind "into" the entities view to better understand who is self and who is the other.
That helps me to understand it better.
All powerups/keys and stuff in items.qc will help you to get a "feeling" for it.

Or another example are the projectiles (like rocket, grenade, ...) :
They give the 'other.' the damage (they do not give it them'self' (!)).
The other is the monster/player who gets touched...
In their function, they use:
if (other.health)
{
.....
}
So only 'others' with health (like players, monsters) get the damage.


... I guess what I just wrote is kind of a mess (grammar-wise and context-wise), but maybe this helps you bit.

Best wishes,
Seven

[toneddu2000]

[Spike]

'self' is to qc as 'this' is to c++
it is merely the 'active' entity that your code is currently talking about.

saving self into oldself (and restoring later) is a way to refer to a different entity in various function calls, without breaking things in the function that called you (which still expects self to be what it was when the current function was called).
thus you'll find functions that notify other entities of events on that entity switching self to the entity that's being notified then calling whatever notification function required, whether thats one of the th_foo functions or a direct function call.

[Baker]

This was always on my list of things I didn't know. Good question. I kept forgetting to ask.

[mh]

If you know some C it's helpful to look at the engine source here. Search for calls to PR_ExecuteProgram and you'll find that it's always preceded by pr_global_struct->self = whatever, and the same for other. Have a look at which entity is being set to self, have a think about what's happening there, and it starts to come together.

[toneddu2000]

@Spike, thanks a lot, now it's more clear.

@mh, yeah I'd like to learn more "serious" programming but I'm bit stuck with pointers! I'll try to search what you post it, thanks!

It would be great if it was available a "complete quakec guide for beginners"!

[taniwha]

toneddu2000: think of pointers as "entity" and the fields as (eg) ".float health", and ignore the difference between -> and . (even the designers of C regret that one). Pointers are really quite easy once you realize they're just a way to have one variable refer (point) to another. No different than asking one friend for another friend's phone number .

[toneddu2000]

wow taniwha! I never seen pointer in this way! It's more clear, like this, thanks!

[taniwha]

I'm glad I could help