Hotspot Over Gui ? [ SOLVED ]

[T-Pr]

Hi everyone , i want to make a simple Skill Point System , and i wanna make the gui of it . So , i made sumthing like that ; ( of course more cool  8) )



This my gui background. In my gui , i made a background from this for example . So there is no button or labels , just image. I want this :

When mouse comes over " fighting " there will be description of the fighting in description box. I simply thought , if it was a room , i can make a hotspot on somewhere and label on gui , and enter @HOTSPOT@ to text of the label . But there is no room this is just a gui and it's image so i can not do any hotspots. So how can i do this ? I thought maybe i can make a real gui button instead of the button in the image but there will be no difference i think there is no function to write something on the label when you come over the gui button . So please help me .

And also i thought , eLocationNothing , but i just couldn't figure out how to use it in this situation.

( Simply : How can i write something on the label in gui1 when you come over a specific area on the background image of gui1 ? )



Greetings , T-Pr

[Gudforby]

You can make gui buttons, and change the text on a given label (here named Label_Description). Then run that function from the repetedly_execute part of the script

function DescriptionHover(){ //whatever you want to call the function
if (GUIControl.GetAtScreenXY(mouse.x, mouse.y) == ButtonFighting) { // if the mouse is over the GUI button ButtonFighting
   Label_Description.Text=("write whatever you want here");
 }
 else if (GUIControl.GetAtScreenXY(mouse.x, mouse.y) == ButtonTechnical) { // if the mouse is over the GUI button ButtonTechnical
   Label_Description.Text=("write whatever you want here");
 }
 else {   // if it's not on either of the buttons
   Label_Status.Text=(""); //display nothing
 }
}

[monkey0506]

There isn't, as you've said, a function to determine this automatically, but you can use repeatedly_execute to do it yourself.

It would be simplest if the areas that you want to be able to mouse-over (I'm guessing "Fighting" and "Technical") were in fact on Button controls. This would greatly simplify things if the positioning ever got moved around, but if you don't want to use Buttons then you could also just simply do some boundary checking.

Code: ags

// GlobalScript.asc, Button method

function repeatedly_execute()
{
  GUIControl *gcat = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
  if (gcat == btnFighting)
  {
    // put some text about btnFighting into the label here..
  }
  else if (gcat == btnTechnical)
  {
    // put some text about btnTechnical into the label here..
  }
}

Note that I haven't actually used GUIControl.AsButton. You can compare a GUIControl* to a derived control type, such as Button*, directly such as this. If you want to be able to use any of the Button properties though, such as NormalGraphic or Text, then you'd have to use the AsButton property.

Code: ags

// GlobalScript.asc, No button method

function repeatedly_execute()
{
  GUI *gat = GUI.GetAtScreenXY(mouse.x, mouse.y);
  if (gat != gSkillPoint) return; // we're only looking at this one GUI here..
  if ((mouse.x >= FIGHTING_X_POS) && (mouse.x <= (FIGHTING_X_POS + FIGHTING_WIDTH)) && (mouse.y >= FIGHTING_Y_POS) && (mouse.y <= (FIGHTING_Y_POS + FIGHTING_HEIGHT)))
  {
    // put some text about Fighting into the label here..
  }
  else if ((mouse.x >= TECHNICAL_X_POS) && (mouse.x <= (TECHNICAL_X_POS + TECHNICAL_WIDTH)) && (mouse.y >= TECHNICAL_Y_POS) && (mouse.y <= (TECHNICAL_Y_POS + TECHNICAL_HEIGHT)))
  {
    // put some text about Technical into the label here..
  }
}

In this example FIGHTING_X_POS, FIGHTING_Y_POS, TECHNICAL_X_POS, and TECHNICAL_Y_POS represent the coordinates within the GUI that the text is displayed at (top-left aligned), increased by the position of the GUI itself. So if "Fighting" were positioned at (20, 35) within the GUI and the GUI itself were set to a position of (100, 50) then FIGHTING_X_POS would be 120 and FIGHTING_Y_POS would be 85.

FIGHTING_WIDTH, FIGHTING_HEIGHT, TECHNICAL_WIDTH, and TECHNICAL_HEIGHT represent the width and height of the text when rendered in this font.

As you can see, using Buttons is significantly simpler, but I figured I'd present you with both methods so you may do as you wish.

Gudforby beat me to the punch..but I'm posting this anyway!!

[T-Pr]

OMG! Thank you both very much , i used both of the codes and they worked , thank you both .

[monkey0506]

Glad you got it working.

Oh, and Gudfordby, just a few notes:

- If you're comparing it multiple times, it's more efficient to store the GUIControl* (or whatever type of pointer you're working with). You probably wouldn't notice any real difference just by doing this, but if you were doing a lot of intensive processes in your game, it could potentially create an impact over time (particularly on older systems).

- There's no reason to enclose text (known as string-literals) in parenthesis every time you use them. You're already enclosing them in double-quotes (as you should be), so this just creates extra work for you.

- When you're posting code to the forums, you can help make it more readable by enclosing the entire code-block like this:

[code]your code here[/code]

If you put that in a post you'd see:

Code: ags

your code here

[Gudforby]

Thanks for the tips, monkey.

What exactly is the difference between storing the pointer compared to not storing it? Since I'm not the most experienced coder around, I'm always eager to improve my skills and knowledge of how the engine works.

[monkey0506]

When you're calling a command like GUIControl.GetAtScreenXY you are querying the engine to determine which, if any, GUIControl is displayed at the given coordinates. If you're then comparing that against several items, the way you were doing it you were querying the engine multiple times. If you store the result in a pointer then you only have to query the engine once.

As I said, not necessarily the most expensive operation in the grand scheme of things, but simple steps like this can improve the efficiency of your game in the long run, which can be impacting, particularly, as I said, on older systems.

[Khris]

Since efficient, optimized coding doesn't have a downside, there's no reason not to use it, even in a situation where it doesn't make a difference. And it's good practice.

[Gudforby]

It's always easier to understand it when it's explained properly. So again, thank you.