Storing GUI-related Variables Outside Global Script

Started by SilverSpook, Thu 07/05/2015 11:35:47

Previous topic - Next topic

SilverSpook

I have some GUIs that are pretty specific minigames in certain rooms, and so they don't seem to belong in the Global script.  Is there a way to store GUI-related variables inside a room rather than the global script? 

Thanks

Crimson Wizard

#1
Similarily as you declare them in global script, you can declare them in room script.

Well, it's a straight logical answer, although I am not sure this is really what you were asking about...

If you mean GUI script names, then no, they always will be available globally.

SilverSpook

Hm, is there a way to get to room variables from the global script, then?

Crimson Wizard

Quote from: SilverSpook on Thu 07/05/2015 12:55:41
Hm, is there a way to get to room variables from the global script, then?
Not directly.
You could probably know, in AGS, there is a rule of upper scripts being able to share their contents to lower (literally - lower in the list), but not opposite:
Quote from: http://www.adventuregamestudio.co.uk/wiki/Multiple_Scripts
The order of the scripts is important. A script can only use functionality from other scripts that come before it in the list, so the Move Up and Move Down options allow you to adjust the order. The global script is always at the bottom so that it can access all other scripts, and room scripts are automatically provided with access to all the scripts.
The room scripts are not part of that list, but they are considered to be at the bottom (and separated, so that room A cannot known the contents of room B).

There is an indirect way to share contents of the room script to other scripts: if you make a variable in global script, you can assign a value in room one's, and this value will be available to global and room scripts too.

I think it would be easier if you give an example of what you are trying to achieve.

Snarky

Quote from: Crimson Wizard on Thu 07/05/2015 13:01:13
Quote from: SilverSpook on Thu 07/05/2015 12:55:41
Hm, is there a way to get to room variables from the global script, then?
I think it would be easier if you give an example of what you are trying to achieve.

Definitely. The question is a bit worrying, since it sounds as if you're trying to head down a very wrong path.

For a minigame-GUI, I would almost certainly write it as a separate script module, with all state kept internally in the script, and an API to start the minigame and to query the outcome, which you can call from the room code. Unfortunately any action handlers for the buttons and other controls need to be in the GlobalScript, but I would simply have them call corresponding functions on the script module, to keep all the logic in one place.

Monsieur OUXX

Yes, it's a good idea to move your minigame to a module.
You can also move the buttons code from the global script into the minigame module (or the room module if you're lazy), but that requires slightly more work. If you look at my "standalone click" module, you'll see how I do it (I would tell you to use it as-is, since it's what it was made for, but I can't remember if I found bugs in it since I released it).

Basically at each game cycle you manage manually if the mouse has been down then up, and you check if it was above a button and/or a gui, and if so, which one.

 

SilverSpook

#6
Thanks for the helpful tips, guys.

Well basically, there's a part of the room where you "zoom in" to a device, and need to do things like unscrew screws, remove parts, lubricate things, solder circuits, etc.  I just want the device to temporarily display over the room so the player cannot interact with anything but the device itself, until they finish fixing it.  Then the device display closes and you resume in the room.  I believe something like this happens in Primordia, where you click an area of a machine and you get a closeup, where you must perform repairs etc..

I tried doing this by having a room object with the zoomed-in view of the device become visible, with several other objects (screws, parts, etc) becoming visible as well.  It seemed simpler at the time to use GUI because of the extra work required in setting up each individual object in the minigame, hiding the normal room objects so the player can't interact with them, then re-hiding each room object and re-showing all of the normal objects after the game is completed.  With GUIs it's just one "gui.Visible = true" line to show the minigame and disable all background images, and then one more "gui.Visible = false" line to hide it again.

The game works right now, I'm mostly just thinking of the simplest way to move variables / functions out of the Global Script so it isn't cluttered.  Maybe I'll see about Snarky's solution of moving game logic into another module.

SMF spam blocked by CleanTalk