Make "function key press execute mouse.Mode on Hotspot.GetAtScreenXY"? [SOLVED]

[iamlowlikeyou]

I'm not sure if the headline makes any sense

What I want to do:
Press a key --> execute mouse.Mode on the hotspot which player is standing on...

[Khris]

Inside on_key_press, add a line for the key:

Code: ags

  if (k == eKeyC) {
    Hotspot*h = Hotspot.GetAtScreenXY(player.x - GetViewportX(), player.y - GetViewportY());
    if (h.ID > 0) h.RunInteraction(mouse.Mode);
  }

Btw, what about the interface I wrote for you? Do you want to switch back to hotspots for everything?

[iamlowlikeyou]

Thanks again!
Yeah I'm sorry I never got back to you - I've been trying to figure it out very hard, but I'm simply not skilled enough yet to fully understand it. Which is why I've started studying general basic programming lately

In the meantime I've been trying to decide which interface is best; the one you wrote for me, or one where interaction becomes possible whenever on a hotspot, and then interaction makes player walk to position before interacting. The result will be almost the same, but maybe the latter is a little more user-friendly - and a LOT easier for me to work with.

If you have the time, can you try to explain the code you just provided?
I don't really understand what GetViewport does even though I have read the description...
Also what does the "Hotspot*h" mean? and the ID?

EDIT: Well, I think I understand what GetViewport does, but I don't understand why it's in this code... What would happen it was just "player.x, player.y"?

[Khris]

Hotspot.GetAtScreenXY requires Screen coordinates whereas player.x and player.y are room coordinates.
In other words, in a lowres game, the coordinates supposed to go into Something.GetAtScreenXY are 0-319, 0-239. In a scrolling room, the player might stand at 410, 350 though.

If the room isn't a scrolling room I don't need to subtract the Viewport coordinates, but to be on the safe side I always do that, otherwise the code will break as soon as the author starts using scrolling rooms.

Hotspot*h declares a so-called pointer, it's of the type Hotspot i.e. points at a Hotspot, namely the one I assign to it (in this case the hotspot at the player's position). It's like a variable, only it doesn't hold a discreet value like 24 or 0.23 or "Meh", instead it holds an object (a code object, not an AGS object).

Say the player stands on hTree. h now points at hTree. As long as that is the case, h.ID is the same as hTree.ID, h.Name is the same as hTree.Name, and so on. I can access all the hotspot's attributes and functions without having to know which one exactly I'm currently handling.

"h" is just an arbitrary name I chose.
h.ID is the ID number of the hotspot, the one you can see in the editor. Since hotspot 0 isn't an actual, drawn hotspot but all the area that isn't one, I want to make sure the ID is 1 or greater.
If that's the case, I run the Interaction event associated with Hotspot h and the current mouse.Mode.

and a LOT easier for me to work with.

Not sure why that'd be the case; you don't need to understand how my code works at all; all you do is place hotspots, characters and objects the usual way, and the rest will be handled automatically.
You can relocate the foot point of an object or a hotspot by entering it in the properties if you want, but all that remains to do then is add events just like before.

[iamlowlikeyou]

Ah, thanks for the explanation.

Anyway, my room IS scrolling and IS lowres, so it's a good thing you included the GetViewport element then...

Well, perhaps I should try again with your interface... The thing is I feel a little bad using code that I don't understand, but I guess I'll just have to bite the apple.
I'm really terrible at understanding logics, but I'm working hard on it, because I want to be able to do my own programming.