What's preventing ProcessClick?

Started by Trapezoid, Sun 15/02/2015 05:34:13

Previous topic - Next topic

Trapezoid

I have a custom system for interactions that involves Room.ProcessClick when the character reaches their destination. For some reason, there are a couple of hotspots in one particular room whose interactions don't run some of the time. I'm having trouble figuring out exactly what determines whether or not it happens.

Anyway, in my custom system, it runs Room.ProcessClick(x, y, eModeInteract) at one point. It's just not happening! The section of code it's in definitely is running. There's nothing disabling the hotspots.

To debug, I tried sticking the following code right above ProcessClick:
Code: ags

InventoryItem *currentINV = InventoryItem.GetAtScreenXY(x, y);
Hotspot *currentHS = Hotspot.GetAtScreenXY(x, y);
GUI *currentGUI = GUI.GetAtScreenXY(x, y);
Object *currentOBJ = Object.GetAtScreenXY(x, y);
Character *currentCHR = Character.GetAtScreenXY(x, y);
if (currentGUI!=null) Display("GUI %d",currentGUI.ID);
if (currentINV!=null) Display("INV %d",currentINV.ID);
if (currentOBJ!=null) Display("OBJ %d",currentOBJ.ID);
if (currentCHR!=null) Display("CHR %d",currentCHR.ID);
if (currentHS!=null) Display("HS %d",currentHS.ID);
This should tell me if there are any other hidden elements somehow stealing the click. Nope, none of them popup except the HS one, which displays the appropriate ID. By all means, ProcessClick should be succeeding every time, and I can't figure out what might be blocking it. I've also tried termporarily using currentHS.RunInteraction instead, but it's the same thing.

Running 3.4.0.4, so there could be some issue I'd need to take with the devs.

Crimson Wizard

1. Just to be sure, are there actually script functions for these hotspots and properly linked on events pane?
2. Can you show the script part that does ProcessClick? Are there any commands following (in the same function)?

Trapezoid

1. Yup. The interaction works sometimes (for example, if the character is already standing at the hotspot's walkto point, it works. But if I move her away and then use the hotspot, it fails about 50% of the time.)
2. Here's the full function:

Code: ags
function ProcessMenuClick(int x, int y, int action) {

  InventoryItem *currentINV = InventoryItem.GetAtScreenXY(x, y);
	
  actionvalue = GetActions(x, y, action);
  if (GetLocationType(x, y)!=eLocationNothing) {
    SetActions(x, y, action, actionvalue+1);
    ActionClicked = action;
    if (action < 98) Room.ProcessClick(x, y, eModeInteract);
    else if (action==100) Room.ProcessClick(x, y, eModeInteract);
    else  Room.ProcessClick(x, y, eModeUseinv);
  }
  else if (currentINV != null) {
    if (action==1) {
      verbmenu.Visible = false;
      player.ActiveInventory = currentINV;
      player.ActiveInventory.CursorGraphic = player.ActiveInventory.GetProperty("cursor");
      
      int invitemcheck = Inventory.TopItem;
      int invitemsinrow = Inventory.ItemCount;
      
      while (invitemcheck < (Inventory.TopItem + invitemsinrow)) {
        if (Inventory.ItemAtIndex[invitemcheck]!=null) {
          if (Inventory.ItemAtIndex[invitemcheck].ID == player.ActiveInventory.ID) {
            MouseSetPos(HUD.X+(Inventory.X + (invitemcheck - Inventory.TopItem)*Inventory.ItemWidth) + (Inventory.ItemWidth/2) , HUD.Y + Inventory.Y + (Inventory.ItemHeight/2) );
            invitemcheck = invitemsinrow+99;
          }
        }
        invitemcheck++;      
      }      
      
      }
    else {
      SetActions(x, y, action, actionvalue+1);
      ActionClicked = action;
      if (action < 98) currentINV.RunInteraction(eModeInteract);
      else currentINV.RunInteraction(eModeUseinv);
    }
  }
}


The instance in question is the one after "if (action < 98)". Logically, nothing else in the script should be running. In any case, what functions following ProcessClick/RunInteraction could "cancel" it?

Trapezoid

I found a recent topic with a very similar problem: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51557.0 Unfortunately, they never solved it, they just ditched the template they were using.
It's a recent post, so they're probably using a newer version of AGS. I know ProcessClick recently renamed to Room.ProcessClick; was anything else about its functionality changed, or the script order it runs in?

Trapezoid

Figured out a workaround:
In the part of my global repeatedly_execute that checks whether the player's reached the walkto points, instead of running ProcessMenuClick right there, I made it set a "ProcessFlag" variable to true. Then, *above* that part of the code, I check to see if ProcessFlag is true, and only then does it run ProcessMenuClick-- thus delaying ProcessClick by a game cycle. It works every time now, although I still don't really know why.

Crimson Wizard

#5
Quote from: Trapezoid on Sun 15/02/2015 19:46:08
Figured out a workaround:
In the part of my global repeatedly_execute that checks whether the player's reached the walkto points, instead of running ProcessMenuClick right there, I made it set a "ProcessFlag" variable to true. Then, *above* that part of the code, I check to see if ProcessFlag is true, and only then does it run ProcessMenuClick-- thus delaying ProcessClick by a game cycle. It works every time now, although I still don't really know why.
ProcessMenuClick, ProcessFlag - are these from some template or script module?

I cannot tell what's wrong there for sure; however I was examining the related part of the engine recently, and to tell the truth, it is pretty messed up. Some actions cannot be executed right away, instead they get saved in memory until current script ends, but if you call two or more "ProcessClicks" or "RunInteraction" in a sequence, the latter will override the first ones (or so I remember).
I think Wait(1) may usually force push the queued action to execution.

Crimson Wizard

Is it possible to test if same problem happening in previous versions of AGS (like 3.2.1)?

Trapezoid

I checked a backup of my game (still in 3.4.0.4), and the problem wasn't there, so it must have been a mistake in my script, not an error of AGS. I use ProcessClick at other points in the global script (eModeLook interactions, for example, are repurposed to set verb names, like "open" on a door.) One of these must have been overriding the eModeInteract ones.

SMF spam blocked by CleanTalk