- Use generalized animations to do basic, repeatable functions in your GUIs. For example, if you're using popups in your menu, create a single animation or named event that brings the generic popup graphics up, and then set a desktop float that will be checked in an if statement to determine which message to show on top of it.
Organize your GUIs and use the parent-child relationship of nested windowDefs to keep things organized. For example, if you have several animation windowDefs, house them all under a parent windowDef marked "p_anims" or something similar.
If you plan to resize windowDefs through transitions frequently, it's helpful to create an invisible windowDef that is sized to the new size and then using this windowDef in your transition command accordingly, where "window1_newsize" is the invisible windowDef:
transition "window1::rect" "$window1::rect" "$window1_newsize::rect" "250" ;
If your menus get large, it's helpful to create a few reset animations or named events that sets everything in a particular group of windowDefs back to a default value. For example, you may want to reset a screen of buttons back to an unhighlighted default state.
Use animations when you know you need something to happen over time steps. Use named events when you just want to set properties instantly.
- Statements in a script in the GUI system are executed simultaneously. If you want certain steps to happen before others, you must use an animation.
- Avoid calling named events or using the set "cmd" or consoleCmd statements in animations. If a frame gets dropped and your command or named event call is in that frame, it won't be executed and will break the GUI.
If your GUIEditor crashes when you try to load a GUI, it's probably because of an error in your scripting. The most common culprits are brace errors or bad if statements. Since the GUIEditor lacks an error feedback system, it's best to save different versions of your gui files in case one becomes corrupted. Try to remember which area you were working in and if possible use an advanced editor such as Ultra Edit so that you can compare files against each other to spot differences that might have caused the crash/corruption.
It's possible to use math statements in your Desktop header and element properties to achieve certain effects, such as dynamic placement. For examples of this, look at scoreboard.gui and mpmain.gui. But be careful! The GUIEditor has been known to corrupt Desktop headers with math statements in them if you open the Desktop scripting window in the editor. Saving a copy of your Desktop header to copy and paste in if this happens is usually helpful.
Example, A desktop header script such as this:
windowDef Desktop { rect 0,0,640,480 visible 1 nocursor 1 menugui 1 float "igOffset" 282-((32*"gui::ig_awards")/2) float "aim_fade_time" 10000 - "gui::main_notice_duration"
Will turn into this: (note the quotes that were stripped, this will break these script arguments)
windowDef Desktop { rect 0,0,640,480 visible 1 nocursor 1 menugui 1 float "igOffset" 282-((32*gui::ig_awards)/2) float "aim_fade_time" 10000-gui::main_notice_duration
The Desktop is a windowDef just like all the others, and its properties can be modified as such. For instance, if you want to bring up a semi-transparent overlay, give the Desktop of your GUI a backcolor of 0,0,0,0.5.
All elements in an GUI must have a unique name. When duplicating elements or creating new ones, the GUIEditor will sometimes give them unique names, but sometimes will not. If your elements don't have unique names the functionality of your GUI will likely be broken. If you save and close a gui that has multiple windows with the same name, it is possible to hand-edit the gui to fix this. However, if you instead save and close the GUIEditor, your work can be lost.
- GUI variables must be explicitly sent to each GUI that references them. If your GUI variable isn't working, try checking the code to be sure it's sending it to the right GUI.