GotThere problem, still works?

[Chomba]

Hello people,

today I bring you something from the past (2008), but I was looking for a way to be able to interrupt the walk eblock for when you are going to do some interaction/look at specific coordinates and cancel the action if you want to. I found that the solution would be Khris's GotThere module... although it's been around for a while.

Anyway, I downloaded it, imported the script and tried to use it according to Khris' instructions in this forum topic. But I get an error.

The instructions:


The error:


(you can download the module from here):

https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/eblock-enoblock-and-looking-at-an-object/msg477380/#msg477380

Also keep in mind that I'm using AGS 3.6 - BASS template, and this is from.... I don't know which version, but I don't think that's the problem.
Any ideas? Can this be solved or is it because the script is obsolete by now?

[eri0o]

Looking at the module code "GotThere" just means you have to code your check for whatever means that character is there.

Example

Code: ags

// module header

import bool IsInPosition(this Character*, int x, int y, int pad = 2);

Code: ags

// module script

bool IsInPosition(this Character*, int x, int y, int pad)
{
  return (this.x > x - pad) && (this.x < x + pad) && (this.y > y - pad) && (this.y < y + pad);
}

and then use this to check if the character is in position.

[Khris]

I rewrote the module to make it easier to use; since I kept updating the Google Drive file which to my knowledge retains the share link, you've probably ended up with the latest version but outdated instructions.

Here's the latest thread:
https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/graphicalfunctional-questions-for-cmi-style-guiinventorymenus/msg636639852/#msg636639852

In short you need:

Code: ags

  if (WalkFace(123, 45, eDirectionLeft)) {
    // what happens when the player reachers those coordinates goes in here
  }

eri0o: the module doesn't just check for a character's position, it also runs the interaction as soon as they arrive at the target coordinates.

[Chomba]

Thanks for the answers,
I downloaded the version you posted now and use the code as in the example, but it still doesn't work.



The character walks to the position, but does not execute the command.
I also tried the "look" function, only here it didn't even walk to the coordinates. If I clicked to look with the character standing still, it would directly say its phrase, but if I made the character walk (to any side) and clicked to look while doing it, it would walk to the coordinates of the code, but it wouldn't execute the final action either. Very strange...

Could it be that there are incompatibilities of the code with AGS version 3.6 directly? Am I doing something wrong? I'm testing all this in the BASS template demo game.

[Khris]

Yeah, I did the same test and noticed that the BASS template uses the walk-to cursor for everything for some reason. The mode used doesn't matter for the BASS code but the GotThere module relies on a proper cursor mode being used.
The solution is to simply run mouse.Mode = eModeInteract; in game_start.

[Chomba]

Great! it worked for when the action is "interact", but if the function is "look" it doesn't walk to a certain place to wait to say the assigned phrase. I guess it's intended for interact actions only and the "look" thing can still be handled as usual.

[Khris]

The problem with the BASS template is that it doesn't rely on cursor modes, it calls the correct interaction based on what was clicked and the button that was used.
My module was built for the Sierra template, i.e. is completely based on cursor modes. It should be relatively simply to re-write for the BASS interface. Or to amend the BASS code to use the actual cursor modes.

[Chomba]

My module was built for the Sierra template

That explains it all! Well, it's still great to have it running somehow. It'll come in handy for when I do a singleclick type game.

Thanks again Khris!

[Khris]

I managed to find a solution for this that so far, seems to work:

1. Move TwoClickHandler above the GotThere module in the script tree (drag and drop the former on the latter)

2. Open the GotThere script and change the first line (31) of on_mouse_click to

Code: ags

  if (button == eMouseLeft || button == eMouseRight) {

3. Open the TwoClickHandler script and find the do_room_action function's first and main if block. In there, whenever it says Room.ProcessClick(mouse.x, mouse.y, eModeSomeMode);, replace that with just setting the mode instead, i.e. mouse.Mode = eModeSomeMode; (should be lines 126, 131 and 139).

4. Assign a cursor image to the interact and look cursors.


What happens is the BASS code now only changes the mode according to the type of click, but the actual click is now processed by GotThere. I haven't tested it thoroughly though.

[Chomba]

Ok, I applied it!
I had to delete the "i.e" because it took them as "undefined token" and change the eModeSomeMode to eModeLookat. Now it does all the functions well.

The only problem now is that (using the BASS demo) when I use an object with the hotspot, instead of doing the action defined for it (an unhandled_event), it performs the lookat action.
I didn't test assigning an action to use that item in that hotspot because I tested it in a free time. I will do more tests later.

[Khris]

"i.e." is an expression meaning "in other words", it was not part of the code obviously 

And eModeSomeMode was a fictional generic mode illustrating you were supposed to use the mode from the Room Click command.

Anyway, using an inventory item with a hotspot works fine for me (I guess that's what you meant?) but one should probably insert a ClaimEvent() at certain places into do_room_action to prevent the click from also triggering the GotThere code.

For instance if you have an active inventory item, the mouse is over a hotspot and you right-click, what's supposed to happen? Should that always deselect the inv item, then do nothing further? Or still trigger a look at?

[cat]

I found two issues with the GotThere module and I wanted to share how I solved them. Since there is no thread about this module in the "Modules, Plugins & Tools" board, I'll just post it here. ( @Khris maybe you could create a thread for it, I think it would be useful. People keep digging up old threads for this module because it has no "home".)

1) I was using an old project as base for my new game. This project was created with an older version of AGS and had a MaskResolution of 1:2. This caused the character not end up on the required coordinates and so the event was not fired. Changing the resolution to 1:1 fixed this. (see https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-1-beta/msg636659137/#msg636659137 ).


2) I was having problems with events fired twice for objects where I didn't use WalkFace. The situation was: ObjectA clickhandler uses WalkFace. After the played walked there, I clicked another ObjectB. ObjectB clickhandler does not use WalkFace and was called twice.
I solved this by adding tgx = -1000; to the code:

Code: ags

function on_mouse_click(MouseButton button) {
  if (button == eMouseLeft) {
    lt = GetLocationType(mouse.x, mouse.y);
    if (lt == eLocationNothing) return;
    ClaimEvent();
    __arrived = false;
    tgx = -1000;
    if (lt == eLocationHotspot) {
      Hotspot*h = Hotspot.GetAtScreenXY(mouse.x, mouse.y);
      lid = h.ID;
    }
    else if (lt == eLocationObject) {
      Object*o = Object.GetAtScreenXY(mouse.x, mouse.y);
      lid = o.ID;
    }
    else if (lt == eLocationCharacter) {
      Character*c = Character.GetAtScreenXY(mouse.x, mouse.y);
      lid = c.ID;
    }
    mm = mouse.Mode;
    Room.ProcessClick(mouse.x, mouse.y, mm);
  }
}

[Crimson Wizard]

1) I was using an old project as base for my new game. This project was created with an older version of AGS and had a MaskResolution of 1:2. This caused the character not end up on the required coordinates and so the event was not fired. Changing the resolution to 1:1 fixed this. (see https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-1-beta/msg636659137/#msg636659137 ).

1:2 mask resolution was a common thing in high-res games prior to AGS 3.5.0.
If the game has this as a intentional part of its design, then the solution is to check not precise coordinates, but a range +/-1 around the target.

There's no direct way to get "mask resolution" property in script, but one may calculate it by retrieving walkable mask's size and dividing on room size (see GetDrawingSurfaceForWalkableArea).

EDIT: by the way, because of how AGS walking works prior to 3.6.1, there are cases when character may end up few pixels away from the requested position too, when they walk diagonally.

[Khris]

@cat Finally made a module thread

If the 1:2 thing turns out to be an issue for more users I will look into addressing it.