The GUIEditor allows for the creation of GUI Control Prototypes, in a WYSIWYG visual format. After a prototype has been created, a script can be written which creates nodes based on the prototype. Different developers dive into things in different ways, so this page is the overview of the GUI Editor, but there is also a step by step Tutorial: GUI_Window_Tutorial.
This image shows the layout of the GUI Editor.
- GUI Editor panel is the list of all GUI Control Prototypes.
- Any GUI Control prototype with a leading underscore should not be changed as it is part of Clean Engine. For example: "_panel".
- GUI Control Tree View displays and allows editing of the hierarchy of child GUI Control's for the GUI Control being edited.
- GUI Control Properties is a list of all of the properties of the selected GUI Control that change how it looks and behaves.
- When the name of a property is grayed out that means the property cannot be edited. For example: "type" in the Data category.
- GUI Editor Toolbar is used primarily to save the GUI Control and close the GUI Editor.
- The GUI Control being edited is previewed in the Viewport.
Starting the Editor
In older versions of HeroEngine, the GUI Editor needed to be started from the GUI Editor Toolbar.
In current versions, the GUI Editor is accessed by:
- Opening the GUI Editor panel from the HeroScript menu
- It may take a moment for prototypes to load
- Choose a prototype to edit
- Double-click on the prototype to go into edit mode for it.
Using the Editor
The GUI Editor is used to modify the default value of a GUI Control's fields. The value of these fields are stored in a client-side prototype which is generated from GUIXML files. These fields are edited in the Properties Panel. When a prototype is opened for editing the Properties Panel will automatically open.
When editing a GUI Control prototype the layout of the Properties Panel is similar to how it looks if a Model was selected except the listed properties are different and there is a GUI Control Hierarchy Tree View at the top of the panel. The properties can be displayed in two ways, Categorized and Alphabetical. The Categorized view will split the properties into the following collapsible sections: Appearance, Behavior, Data, Layout, Misc and Presentation States. The Alphabetical view will list all of the properties in alphabetical order.
GUI Control Tree View
The topmost parent GUI Control of the GUI Control Tree View is the GUI Control Prototype being edited and is listed in the GUI Editor panel. Every other GUI Control is considered a child GUI Control. Every GUI Control has one parent control and can have multiple child controls. The GUI Control hierarchy can be changed by dragging and dropping a GUI Control onto another GUI Control in the hierarchy. When a GUI Control is moved in the hierarchy all of it's children controls will be moved with it.
As you click on the name of each one, the Properties Panel reflects the GUIXML properties for it, and a different section of the created window is highlighted, to show which part you are dealing with. Only some properties may be changed on inherited children. For example, you can never change the name of an inherited control, nor can you change their order in their parent's children list. However, you can change many other useful properties, such as their layout (size, position, texture, color, et al) and script. Clicking on the name of the control that you created results in the entire control being highlighted in the viewport. Note that the selected control can be moved and resized, by dragging it around the screen. You can add new children to whatever control you have selected (caveat: GUILabel controls can not display children) by double-clicking the name of the desired child in the GUI Editor panel. Controls are added to whichever control is currently selected in the directory tree. Any children associated with the new control's prototype are added as well. The newly added control will be automatically selected when added, so if you are adding multiple controls to the same parent, be sure to reselect it each time (this is easily done by right-clicking in the GUI Editor area).
The Appearance section of properties controls how the GUI Control's texture is displayed to all of the state presentation properties as well as the texture property, which is the Fully Qualified Name (FQN) of the texture file in the Repository.
Art for GUI Controls must be stored in the Repository in the form of a DirectDraw Surface (.DDS) or .PNG file. To assign a texture to be used by a GUI Control you can use the Texture Viewer accessible from a state presentation field or the texture field.
A GUI control's State Presentation determines its appearance in various predefined states. There are five state presentations available to work with:
- defaultStatePresentation - how the control appears when no other state applies
- disabledStatePresentation - how the control appears when enabled=false
- hoverStatePresentation - how the control appears while the mouse is within its boundaries, and not within the boundaries of a child of the control (in which case the hover state transfers to the child). Note that the control must be receiving mouse events to activate the hover state. This includes transparency-related conditions: a control whose alpha at a given moused-over pixel is less than 10% will ignore the mouse unless specifically prohibited from doing so by means of the skipTextureAlphaTest flag.
- selectedStatePresentation - how the control appears while checked=true or selected=true. The selected flag applies to all controls, while checked applies only to controls which possess or inherit from the GUIRadioButton or GUICheckBox classes. Whichever flag has been set most recently will take precedence.
- selectedDisabledStatePresentation - a checked/selected=true control which is also enabled=false, such as an unavailable checkbox.
State presentations are complex fields with three subfields: size, position, and color. You will typically only be concerned with either size and position, or color, but will sometimes want to use all three.
Note that GUILabel class controls are treated differently by their state presentations. Changing the color of a GUILabel's state presentation will actually affect the text of the label, not provide a background color. Adding a texture to a GUILabel-based control will do nothing of interest.
Texture Mapping in a state presentation
While state presentations may (and frequently will) use different areas of a .dds file to determine a control's appearance, they must all use the same texture file. You cannot have your hover states in one .dds file, and your disabled states in another. The size and position fields of a state presentation refer to the image specified by the control's texture field. If a control has no texture field declared, size and position will do nothing. Used in conjunction, these two fields determine the placement and size of a rectangular slice of the image, to be applied to the control. The texture viewer can be pulled up by clicking in the texture field in the GUI Editor, or on any of the state presentation fields or subfields, with the exception of color.
- Position is an xy field which determines the upper left corner of the rectangle, measured in pixels, where (0,0) is the upper left corner of the image itself.
- Size describes a rectangular portion of the texture of width (size.x) and height (size.y) to be applied to the control.
In both cases, positive-x points toward the right edge of the image, while positive-y points towards the bottom. However, if either of the size xy fields are given negative values, the image will appear reversed along that axis, making it possible to reuse a single piece of a texture up to four different ways.
Note that one approach taken by some art departments is to create their GUI art at double the intended size, to allow for less pixelization when a control is scaled. In a situation such as this, the state presentation dimensions would still follow the same procedure as with a normal-sized texture, as the size field of the control still dictates its displayed appearance. For example, an icon whose art is created at 128x128 pixels may still be displayed as a 64x64 icon, simply by setting its state presentation size to 128x128, and its actual size to 64x64.
Color in a state presentation
Color, a complex field of type rgba, is most often used to set the background color of a control which has no texture applied to it. This simply fills the control with a solid color, such as the titlebar of the texture viewer to the right. If you are familiar with the 0 to 255 scale for RGB, rgba simply translates that into a float of range 0 to 1, with alpha (color.a) equating to completely transparent at 0, completely opaque at 1.
If a given state presentation has all three fields set, the texture's colors will be multiplied on a per-pixel basis by the RGBA you specify via the color field, essentially adding a tint to the texture. Texture multiplication is beyond the scope of this document, but here are a few simple guides:
- The darker the original texture, the less it will appear to be affected by multiplication.
- Conversely, pixels which are pure white will take on the exact color they are being multiplied by
- A disabled state can often be created by simply using the texture map from the defaultStatePresentation and applying roughly a 50% grey to it. This will simply grey out the original control. You may have to play with the rgb values to get a good look, depending on your texture. Don't be fooled into lowering the alpha to increase the darkness, as that will only work on a black/dark background.
- An rgba of 1,1,1,1 will result in the texture's appearance being unchanged from the original.
- As you might guess from that, the default rgba for any given state presentation is 1,1,1,1.
The Behavior properties determine how the control processes GUI Events, whether it appears on the screen, the GUI Animations the control uses and if the control is selected. If IgnoreMouseEvents is FALSE then the control will process mouse input events. The value of IgnoreMouseEvents does not affect the control's parent or children.
The Data of a GUI Control contains its name, what prototype it is created from and what GUIXML file its data is stored in. The control's name is used to uniquely identify it among all others in its control hierarchy. If the FindGUIControlByName is used to find the control then the control's name must be unique among all other children control's of the
The Layout properties of a GUI Control determine its position and size as well as how it's moved and resized based off of its parent control. The position property determines the control's offset relative to its parent. A GUI Control's anchor determines how the control is positioned and sized when its parent is resized. For whichever one is TRUE, resizing the parent will also move or size the child in relation. Having just one of the top/bottom or left/right pairs set to TRUE will move the child, and having both of a pair set to TRUE will cause the child to resize. The positioning due to anchoring is overridden by autoCenter (horizontal,vertical). When TRUE, the corresponding part of its position (x,y) will always be set so the control is centered in its parent. DockMode determines how the control docks to its parent and will override the autoCenter and anchor settings. Options are NONE (no docking, and position is determined exclusively by the x/y coordinates), LEFT, RIGHT, TOP, BOTTOM and FILL (which uses all available space). If this were set to RIGHT, then the GUI Control would do its best to dock itself flush to the far right of its parent control taking up all available vertical space.
Any additional properties that are defined in the GUI Control's type class will appear in the Misc category. The layer property determines which Layer the GUI Control will appear on. Only the layer of the top-most parent, as seen in the GUI Control Hierarchy, will be taken into account when determining what layer each GUI Control is on. The gluedtonode, worldspaceoffset and fadeDistance properties are used when Gluing a GUI Control to a node.
- To save your changes, press the XML button on the GUI Editor Toolbar to create the GUIXML code. The language will appear in the console window, along with a message that it has been copied to the clipboard. This is purely informational, however, as your GUIXML will have been automatically written to an .xml file in the repository.
- Exit the GUI Editor by clicking on the button in the GUI Editor Toolbar that says "Close Editor".
Create a New Prototype
- Click the Create New link at the bottom of the GUI Editor panel. This should open a window. It will have four inputs on it:
- Prototype Name
- This is the name of your window as it appears in the GUI Editor panel. This namespace is shared amongst all GUI Control prototypes, so should be reasonably unique.
- This is a textual description of the purpose of the control, such as "Hero's Journey inventory window".
- Inherit From
- This is where you choose what base control/window to use to create your control.
- It is advised that you create one base window control, and inherit from it to create more specific types such as an inventory window.
- Similar to inheritance, it is advisable to create one base window class, and create new classes to inherit from that as necessary. For more information on creating a class, see the Dom Editor. You should ensure that any classes you create for GUI Controls use the guicontrol archetype, as opposed to data.
- Prototype Name
- Click the "Okay" button in the Window. The window will now be placed on the screen in its editable state.
- Whenever possible, try to coordinate with coworkers so that you are not creating a new prototype simultaneously, as only one client at a time can currently write to the XML .lst files.
- Note that the Properties Panel is now populated with the control's properties.
- If you have inherited from an existing prototype such as "_window", you might click on the "+" next to the name of your new window in the GUI Control tree view at the top section of the Properties Panel. Note that it has several child controls, some of which may have their own children.