Scripts can only be executed if they are named:
"gui_*"
If they do not start with gui_ in the name, the server will reject the request to fire the script. This will help prevent clients from firing off whatever script they want to just by knowing the name of it. It will be up to the script writers themselves to make sure that the gui_ scripts are written in such a way that clients can't abuse them by calling them whenever they want.
A few script functions exist to give some basic control over the GUI.
**Bring up a GUI on the client. In order for a GUI to be accessible in script, it has to be defined in a certain way in an .ini file (more details later)
DisplayGuiScreen( oPlayer, sScreenID, bModal );
**Display a message box. Allows you to define the message text, the text for the 'okay' button, the text for the 'cancel' button, whether or not cancel is displayed, and the scripts to execute if the user clicks okay or cancel. Scripts must again be named with "gui_"
DisplayMessageBox( oPlayer, nMessageStrRef
sMessage, sOkCallback,
sCancelCB, bShowCancel,
sScreenID,
nOkStrRef, sOkString,
nCancelStrRef, sCancelString );
**Determines if a specific object on a UI on that client is visible or not. This gives script some limited control on altering the appearance of a GUI window by toggling things visible or invisible. This has the same restrictions as 'DisplayGUIScreen', in that there are some restrictions on which GUIs you can affect with this function.
SetGUIObjectHidden( oPlayer, sScreenID, sUIObjectName,
bHidden );
**Close the screen on the client. Again, there are restrictions on which GUIs you can affect with this.
CloseGUIScreen( oPlayer, sScreenID );
**This function is a bit more advanced in its use. But briefly, there is a set of 'local variables' on every GUI window. The GUI layer interacts with these variables at times. And with this script function, scripts can as well. This script function can be used in combination with certain GUI callback functions.
For example, there is a GUI callback for 'OnUpdate' that will display the contents of a local variable. So you can pipe strings across from the server that you want to appear in the player's GUI in a custom window you've made or something.
Or there is a GUI callback that will set a UI Object as 'disabled' if a local variable contains a certain value. So you can disable a certain button on your custom screen if the local GUI variable on that screen has a certain value.
And so forth.
SetLocalGUIVariable( oPlayer, sScreenID, nVarIndex, sVarValue );
These are the basics right now. It isn't as robust a system as I've thought about (Where you could create full screens completely in script), but it does give you enough control over custom GUI screens to do some interesting stuff, I think.
The one area I hope to improve on is some way for the client to send GUI local variables along as script parameters to a gui_ script. That will enable the client to provide some information back the other way, since right now variable data can pretty much only go from server --> client, except when it comes to clicking on buttons on the client.
Anyway, figured I'd give people a heads up on where things are at for now.
Read the thread here
