algorithm for " characters turn to face direction " ?

Started by Monsieur OUXX, Tue 12/12/2006 19:43:37

Previous topic - Next topic

Monsieur OUXX

Hello,

I've created a character with no diagonals, and with "characters turn to face direction" and " characters turn before walking" enabled.

Unfortunately, When my character looks/speeches/interacts with an object/hotspot, it doesn't face the object/hotspot.

I'm wondering what I did wrong. I've been looking in the forum for some common beginner's mistake, but I haven't found anything.

I was wondering how the relative facings are evaluated by the engine. Because my sprite's width is a bit big, maybe there's a "conflict" between object's position and character's position?
 

Ashen

Even with 'characters turn to face direction' enabled, AFAIK the character won't automatically look at the object. I think the option only sets whether you see the character 'turn' - showing all loops in between - or whether it just jumps to the right loop (same functioning as 'turn before walking'). It's a little unclear in the manual on this, I know, so I'm not totally certain about that.

So, you'll probably still need to include Character.FaceLocation commands in your script somewhere. If you HAVE done, and it still doesn't work, can you show the code you used?
I know what you're thinking ... Don't think that.

Monsieur OUXX

#2
Quote from: Ashen on Tue 12/12/2006 21:02:25
So, you'll probably still need to include Character.FaceLocation commands in your script somewhere.

OK... It's a bit heavy! I've already automatized this method for objects (using Character.FaceObject), but what about hotspots?

I mean, I think the code below would be pointless, because if the character first walks to the hotspot , then he IS already the hotspot's coordinates, so the FaceLocation has an undefined result...
Code: ags

cEgo.FaceLocation(
    hotspots[hotspot_index].WalkToX,
    hotspots[hotspot_index].WalkToY
);


And this other code would also be useless, because I want the character to automatically turn toward the appropriate direction:
Code: ags

cEgo.FaceLocation(
    cEgo.x+offset_used_for_orienting_character,
    cEgo.y
);



Quote from: Ashen on Tue 12/12/2006 21:02:25
If you HAVE done, and it still doesn't work, can you show the code you used?
I've done it for a little particular script, and it works fine. But, as I said, only for objects...
 

Khris

Making the character face the pixel/location he is standing at won't turn him, obviously.

A quick & dirty solution: at the beginning of on_mouse_click, store the mouse coords in global variables, then make the player face those as soon as he has reached the WalkTo point.

Another solution is to use Custom properties. Enter the direction's number (e.g. 0=down, 1=right, 2=left, 3=up), then turn the player accordingly.
Code: ags
function turn_player(int dir) {
  int x=player.x;
  int y=player.y;
  if (dir==1 || dir==2) x=x-dir*2+3;
  else y=y-dir+1;
  player.FaceLocation(x, y);
}

// walk to object
turn_player(object[object_index].GetProperty("dir"));

Sadistyk

You could put this in the script interactions:

cEgo.FaceLocation(mouse.x, mouse.y);
cEgo.Say("xxxxxxxxxxx");

Monsieur OUXX

Quote from: Sadistyk on Wed 13/12/2006 01:30:18
You could put cEgo.FaceLocation(mouse.x, mouse.y);

This doesn't seem to work well, because for some reason the mouse coordinates are misevaluated between character's start and character's arrival at hotspot (inbetween, the user has moved the mouse, so the result is random - even if the mouse hasn't been moved).

Anyway, KhrisMUC's solution (storing mouse coordinates at click) should work fine. I'm going to try it. I don't like the idea of using the properties (I had thought about it), because one loses all benefits of automation.
 

Ashen

Quote
This doesn't seem to work well, because for some reason the mouse coordinates are misevaluated between character's start

Do you have scrolling rooms? Because FaceLocation uses Room coordinates (so it works with player.x + 10, [player.y - 150[/i], etc), while mouse.x/y are Screen coordinates (will never be greater than 320,2*0 - 400,300 if you're using 800x600 res). This might be why the results seem to change, even if the mouse hasn't moved.

Storing the coordinates on click is definately a good idea, but to allow for scrolling rooms store, e.g.:
Code: ags

int LookX = mouse.x + GetViewportX();
int LookY = mouse.y + GetViewportY();

I know what you're thinking ... Don't think that.

Monsieur OUXX

Here is my final code for turning toward hotspots :
(targetx is the variable where I stored the coordinates of the mouse when the ayer clicked)

Code: ags

cEgo.FaceLocation(targetx, cEgo.y);
int direction = cEgo.loop;
int view=MAIN_GRABVIEW;

cEgo.LockView(view);
cEgo.Animate(direction, 10, 0, eBlock, eForwards);
cEgo.UnlockView();


note : this code didn't behave correctly if I passed targetx AND targety as parameters. The character faced the opposite direction everytime it interacted the hotspot (once left, one right, once left...)
 

Ashen

Where and how are you setting targetx (and targety, for that matter)?

Do you use the direction and view parameters later? If not, you should be able to use MAIN_GRABVIEW and cEgo.Loop directly, i.e.:
Code: ags

cEgo.LockView(MAIN_GRABVIEW);
cEgo.Animate(cEgo.Loop,10,eOnce); // eBlock and eForwards are the defaults - no need to enter them here.
I know what you're thinking ... Don't think that.

Monsieur OUXX

Quote from: Ashen on Wed 13/12/2006 12:02:22
Where and how are you setting targetx (and targety, for that matter)?

It's when the player releases the mouse button.
I handle this event by myself because I use the Monkey Island 3 template.

Quote from: Ashen on Wed 13/12/2006 12:02:22
Do you use the direction and view parameters later? If not, you should be able to use MAIN_GRABVIEW and cEgo.Loop directly

Yes, I know, but this is only an extract of the code, so I didn't want other actions (executed inbetween) to parasite these ones.
 

SMF spam blocked by CleanTalk