problem with ProcessClick()

Started by Windenwart, Thu 05/04/2007 08:48:21

Previous topic - Next topic

Windenwart

Hi,

look at this code:

Code: ags

	...
	mouse.Mode = eModeLOOK;
	ProcessClick(target_x, target_y, mouse.Mode);
	mouse.Mode = eModeWALK;
	...


In this case ProcessClick() is using eModeWALK and not eModeLOOK. I have called ProcessClick() with eModeLOOK and I expect that ProcessClick() runs with eModeLOOK. What's wrong?

Ashen

Hm, works OK for me (as in, runs the eModeLookAt interaction). Where is it in the script?

Or, what if you try:
Code: ags

        ...
	ProcessClick(target_x, target_y, eModeLOOK);
	mouse.Mode = eModeWALK;
	...
I know what you're thinking ... Don't think that.

Khris

For all I know, ProcessClick *will* use eModeLOOK. The problem must be something else.
IIRC, you're using your own cursor modes only, so are eModeLook and eModeWalk still in the list? They might interfere with your modes.

I'm pretty sure that mouse.Mode and eMode* are ints, so you could make use of that for debugging purposes.
Also, what happens if you put this before the ProcessClick-line?
Code: ags
  if (mouse.Mode==eModeLOOK)

monkey0506

[Khris:]
They're both of the enumerated type CursorMode.

The way AGS handles enums they're basically just ints though. ;)

[Regarding the problem though:]
Do you by any chance have "Walk to hotspot in Look mode" checked in your General Settings pane? Just a thought, but perhaps it is running the look mode and it's just walking there first? I don't know how it would respond if there wasn't a walk-to point set where you clicked (more specifically if there was no interaction defined)...but it might be worth looking at.

Windenwart

#4
1. My cursor modes are own cursor modes only (I don't use the standard cursor modes 1-9):

eModeWALK = 10,
eModeLOOK = 11,
...
eModeTALK = 16,

2. My code from the first post is a simplified code.

Code: ags

...
mouse.Mode = eModeWALK;
if (action == 1) mouse.Mode = eModeLOOK;
if (action == 2) ...
...
if (action == 6) mouse.Mode = eModeTALK;
...
Display("%d", mouse.Mode);
ProcessClick(target_x, target_y, mouse.Mode);
Display("%d", mouse.Mode);

mouse.Mode = eModeWALK;


This is the one and only ProcessClick() call in all of my code. When I check the mouse.Mode before and after ProcessClick(), then I see correct numbers from 11 to 16. But the ProcessClick() sends "eModeWALK"(=10).  ???

When I edit the last line to : mouse.Mode = eModeTALK; then ProcessClick() sends "eModeTALK" in all times. The problem ist the last line after call ProcessClick(). When I remove this line ProcessClick() works fine with the correct Mode...

Windenwart

I have it!  ;D

In "Process" I check the "Any click on hotspot/objekt/character" Interaction with:

Code: ags

...
// global
...
ProcessClick(target_x, target_y, mouse.Mode);
mouse.Mode = eModeWALK;
...
// lokal
...
if (mouse.Mode == eModeLOOK) {....}
else if (mouse.Mode == eModePICK) {....}
....
else Default();
...


this is the way:

Code: ags

...
// global
...
ProcessClick(target_x, target_y, mouse.Mode);
MyProcessMode = mouse.Mode;
mouse.Mode = eModeWALK;
...
// lokal
...
if (MyProcessMode == eModeLOOK) {....}
else if (MyProcessMode == eModePICK) {....}
....
else Default();
...


Sorry.

Khris

So ProcessClick won't be executed until on_mouse_click has finished?
Or, rather, the RunInteraction(mouse.Mode) command eventually invoked by ProcessClick gets queued and the parameter is changed by your command before it is run.

This behaviour of AGS makes me feel slightly uncomfortable :P

Scorpiorus

Yep, queueing may take place here. However, it's not interaction editor's actions that get queued but the event script itself which is invoked by the Run Script action.

So if one, for some reason, is urgent to do things while ProcessClick() is running they may organize it as interaction editor actions but without Run Script.

SMF spam blocked by CleanTalk