One entity pointing to another

[Mexicouger]

I have an arrow that is spawned in front of a player, and I want it to point to a certain entity in the world all the time, regardless of a players position. I have looked at ai_face, and tried to apply the same principles, but it didn't have any impact whatsoever.

So here is my current code. Keep in mind that this is for a top-down style game, and I don't need the arrow to point to any X or Z values.

s_flagb is the entity I want to point to. This was my first method, and I have tried Multiple.

Code: Select all

void() waypoint_update =
{
if (self.owner.health <= 0)
{
remove(self);
return;
}
makevectors(self.owner.v_angle);
self.origin = self.owner.origin + v_forward * 100;

   self.angles_y = s_flagb.origin_y;

self.think = waypoint_update;
self.nextthink = time + 0.01;
};

void() Waypoint =
{
local entity pointer;
if (deathmatch != CTF || self.ishuman == FALSE)
{
remove(pointer);
return;
}
pointer = spawn();
pointer.owner = self;
pointer.movetype = MOVETYPE_NONE;
pointer.solid = SOLID_NOT;
pointer.classname = "Waypoint";

pointer.angles_y = s_flagb.origin_y;

makevectors(self.v_angle);
setsize(pointer, '0 0 0', '0 0 0');
setmodel (pointer, "progs/arrow.mdl");
setorigin (pointer, self.origin + v_forward * 100);


pointer.think = waypoint_update;
pointer.nextthink = time + 0.1;
};

[Sajt]

Could you explain exactly what your thinking is when you try something like "self.angles_y = s_flagb.origin_y"? Because it looks like you're just typing in completely random stuff and hoping it will magically work. Taking a position coordinate and copying its value into an angle field makes no sense.

Anyway, what you want is this:

self.angles_y = vectoyaw(s_flagb.origin - self.origin);

How it works is basically magic, unless you learn a bit about vectors (and trigonometry). I'm too lazy to explain it though. I learned vectors just by doing QuakeC a lot, trial and error until it made sense.

[Mexicouger]

Could you explain exactly what your thinking is when you try something like "self.angles_y = s_flagb.origin_y"? Because it looks like you're just typing in completely random stuff and hoping it will magically work. Taking a position coordinate and copying its value into an angle field makes no sense.

Anyway, what you want is this:

self.angles_y = vectoyaw(s_flagb.origin - self.origin);

How it works is basically magic, unless you learn a bit about vectors (and trigonometry). I'm too lazy to explain it though. I learned vectors just by doing QuakeC a lot, trial and error until it made sense.

I tried using that. I studied The vecto angles, but I didn't get any results at all.
I see that one small value can change alot.
And setting the angles to the origin did give me some of the results I was looking for. 1 more thing, I was just trying things.

[Mexicouger]

Could you explain exactly what your thinking is when you try something like "self.angles_y = s_flagb.origin_y"? Because it looks like you're just typing in completely random stuff and hoping it will magically work. Taking a position coordinate and copying its value into an angle field makes no sense.

Anyway, what you want is this:

self.angles_y = vectoyaw(s_flagb.origin - self.origin);

How it works is basically magic, unless you learn a bit about vectors (and trigonometry). I'm too lazy to explain it though. I learned vectors just by doing QuakeC a lot, trial and error until it made sense.

I tried using that. I studied The vecto angles, but I didn't get any results at all.
I see that one small value can change alot.
And setting the angles to the origin did give me some of the results I was looking for. 1 more thing, I was just trying things.

PostPosted: Sat Jan 22, 2011 3:47 am Post subject: Reply with quote
Could you explain exactly what your thinking is when you try something like "self.angles_y = s_flagb.origin_y"? Because it looks like you're just typing in completely random stuff and hoping it will magically work. Taking a position coordinate and copying its value into an angle field makes no sense.

Anyway, what you want is this:

self.angles_y = vectoyaw(s_flagb.origin - self.origin);

How it works is basically magic, unless you learn a bit about vectors (and trigonometry). I'm too lazy to explain it though. I learned vectors just by doing QuakeC a lot, trial and error until it made sense.

I was using Trial and error and Studying the AI code and how they face the player when using ai_face; I don't understand how it points to the player when it's enemy is world though

[ceriux]

im not sure if its what your looking for. but in this npc code, the npc faces the player when hes in a close enough range to i think . or maybe when you interact with him. either way. he faces another entity (the player/activator.)

http://www.indiedb.com/groups/quakedb/d ... -src-files

[Team Xlink]

You could do a trace from the entity thats supposed to be pointing, and keep rotating the entity until the trace collides with the player.

[Sajt]

I tried using that. I studied The vecto angles, but I didn't get any results at all.
I see that one small value can change alot.
And setting the angles to the origin did give me some of the results I was looking for. 1 more thing, I was just trying things.

Well, the vectoyaw line of code I posted is what you want. If it doesn't work, some of the rest of the code is broken.

[frag.machine]

You could do a trace from the entity thats supposed to be pointing, and keep rotating the entity until the trace collides with the player.

That's a good way to waste CPU cycles. traceline is one of the most expensive built-ins in QuakeC because it relies heavily in SV_RecursiveHullCheck(). Sajt's suggestion is a much more efficient and elegant solution.

[Team Xlink]

You could do a trace from the entity thats supposed to be pointing, and keep rotating the entity until the trace collides with the player.

That's a good way to waste CPU cycles. traceline is one of the most expensive built-ins in QuakeC because it relies heavily in SV_RecursiveHullCheck(). Sajt's suggestion is a much more efficient and elegant solution.

You are correct.

I was just mentioning a possibility, I wasn't suggesting that he should use a way, but saying that was a possible way.