Messages

Short of A-B-A recursion, there's not really any reason why a script function should have to call a function that is defined after it.

Hey Monkey,

I rencently got a stack overflow error...I looked it up on Google and in the AGS forums and it seems those errors can be related to recursive calls? What would be the best way for me check my code to see if I have those, and where?

Using "nodes" and an enum to keep track of them helped a bit.

I found this thread pretty helpful, but what do you mean by "nodes"?

[oCup]

Would it be possible to be use room objects "project-wide" in scripts by their real names set in the room? (right now it seems we can only use their real names in the room script). Same thing with hotspots (can't get the real names outside of the room script).

**NOTE: Im not talking about having access to the object's description "name" (.Name) but the actual object's real name in the room, like oCup, for example.

[Since this is Draconian thread]

Not so difficult, I am merging 3.3.0 to customres right now, and then merge the joint code to 3.4.0 when I got time.
Since this is Draconian thread (hint hint), I might mention that we will probably get most interesting things from Draconian to 3.4.0 too, or maybe some 3.3.1, whichever will be coming first.

Oh yeah! 

Hey just one more question, is 1600x900 a "weird" resolution to create a game in? I like the 16:9 aspect ratio, and it is smaller than full-blown 1980x1080, but still bigger than 1280x720. What kind of issues could I run into if I were to create a game at that resolution? Im checking google right now but it seems so far (that I can see) there arent any games made in that res.

While updating 3.4 (when you have the time of course), is it long/difficult to also perhaps merge the custom resolution build into it as well?

Yeah I can set and check enabled and clickable no probs, its just that I would rather not have to initially set those buttons disabled one by one at game_start. Im re-using the same "base" graphic for multiple GUIs where only some areas are different (I just change certain button graphics to make the overall GUI different for each one). Those "buttons" will never have any actions, ever.

I just thought I could save scripting time if I could access the editor properties on various objects/controls. If its not possible, maybe in another ags version we could access all editor properties via script?

Right now I'm implementing a system that if a button is set to non-clickable and you try to click it, the current mouse cursor graphic gets an "x" overlayed on top.

I have to manually set a butt-load of certain buttons Clickable = false...is there a way to query if a button's "ClickAction" has the value "NoAction" set in the editor? Would save me some time!

Something like (pseudo-code):

Code: ags

oCg = GUIControl.GetAtScreenXY(mouse.x, mouse.y); 
if (!oCg.HasAction) ShowXClickOverlay();

I get a pop-up box saying, "The publisher could not be verified Are you sure you want to run this software?"

I'm pretty sure all you have to do is right-click properties for acwin.exe and in the compatibility tab select "run as administrator"

Grrrr, crap how did I miss that command...right in the manual too...

Yeah, if I can change the GUI, then changing the color is not really necessary (but still would be cool)

Thanks Khris

Hi,

I've searched the forums and found many topics on changing text color for the Display command but nothing really seems to help in my situation. It seems that the only way to change the Display text color is by changing the text color value in the editor for the custom text-window GUI, or by changing the GUI number in General Settings for "Text output: Custom text-window GUI". That's fine if you only have 1 version for your text windows though.

I'd like to give the player the option to choose the type of text window they would want, and each version also has a different color for the Display text. I can change colors OK with the Say command, but not with the Display command.

I just can't seem to set the text color or the gui number via script. Is there a way to get around this without having to use "dirty hacks" that I missed somewhere in the manual/forums?

[Game.DisplayTextColor = 15;]

I'm wondering if it would be possible to set the Display text color globally via script, something like:
Game.DisplayTextColor = 15;

...or make it possible to at least change the text color for text windows, like this:
gMyTextWindow.TextColor = 15;

Seems this could be something that could be fairly easy to implement instead of using the current workarounds, am I right?

Erm... you guys can't be serious. This is irony, right?

Ha! Well if that guy thinks 720p is low-rez and the majority of gamers today think the same thing, well yea I have to admit that does suck (for me anyways).

Alas, supposedly 720p is low res for indie adventure games in 2013

Man that's a downer!

Just wanted to pop back in to say thanks Crimson, this is a lot easier than I thought it would be, thanks to your tutorial. I'm currently breaking up big chunks of code into smaller modules now and making "helper functions". I can finally "see the light", hehe!

I guess I'll use Monkey's script for now, in conjunction with Khris' suggestion (only add labels with a height of say 14 into the array). I can live with that

@Monsieur OUXX: The whole thing? That's quite a generous offer there...Ok, I'll send you a PM.

**EDIT**
Ok I added this line, seems to do the trick. I'll just make sure all hotspot labels are 14 in height, and all the others never have that value.

Code: ags

      if (gui[g].Controls[c].AsLabel != null && gui[g].Controls[c].AsLabel.Height == 14) // found a Label with 14 as height, the hotspot labels
      {
        tmp[labelCount] = gui[g].Controls[c].AsLabel;
        labelCount++;
      }
      c++;

[lblMyGui_Hotspot]

Yeah, I just ran into that actually...heh.

Is there a way I can add to the list ONLY the labels that contain the word "_Hotspot" in their name? Naming convention is: lblMyGui_Hotspot

Its for a game feature where if the user turns "hints" off in the general settings, all labels on GUIs that offer hints will just be made invisible.

I know Id have to tokenize the name once  the script has found a label and if "_Hotspot" is found, than add it to the list...only thing is, how do I query the actual label's name? Seems I can only grab the ID.

**EDIT**

Perhaps using properties may help to distinguish labels, or guis with special labels.

Can we add custom properties to GUI controls? That would be awesome!
(I already reached my properties limit so I have to wait until 3.4 is more stable to do any tests.)

Hey Monkey!

This works perfect! I'll be recycling your code for other purposes too, got to start chopping down that ugly monster I created.

I'm not sure what this means, but does "exposing" gui controls in the engine make the calculation faster or something? Personally I'm content with just using your script if changing the engine is too time consuming just to get a little gain in speed or efficiency or something.

I've got a script that makes a list of labels visible, or invisible depending on the mode I enter. Since I'm not sure how many labels will exist in the game, is there a way to loop through all existing labels? Right now I'm manually adding all labels into the script, then setting the visibility to true or false.

Pseudo code example:

Code: ags

void toggleLabels(int iMode)
{
  if (iMode == 0) //HIDE ALL LABELS
  {
    int i;
    while (i < Game.LabelCount) //PSEUDO CODE
    {
      Label[i].Visible = false; //PSEUDO CODE
      i++;
    }
  }
  else if (iMode == 1) //SHOW ALL LABELS
  {
    int i;
    while (i < Game.LabelCount) //PSEUDO CODE
    {
      Label[i].Visible = true; //PSEUDO CODE
      i++;
    }
  } 
}

[@Knox]

@Knox, sorry, I've read your post in other thread, but could not find time to look into this until now.

NO problem Crimson! Thanks so much for your work. I tested the new acwin and it works perfectly! Yes!