Arma: GUI Configuration: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
Line 8: Line 8:


Dialogs are one way to provide custom graphical user interface in your missions and allow interaction with the player aswell as they are able to run [[Code|code]]. They are defined as classes in the [[Description.ext|description.ext]] file.
Dialogs are one way to provide custom graphical user interface in your missions and allow interaction with the player aswell as they are able to run [[Code|code]]. They are defined as classes in the [[Description.ext|description.ext]] file.
Most of these definitions work with numeric constants, which are presented in [[#Constants|the following section]]. For readability purposes you should consider favoring them instead of the actual integers.


'''Notice:''' If you change your description.ext file while the mission is still open in the editor, you will have to restart the editor and load the mission again so the changes actually take effect.
'''Notice:''' If you change your description.ext file while the mission is still open in the editor, you will have to restart the editor and load the mission again so the changes actually take effect.
'''Warning:''' If there are syntactic errors in your description.ext file (e.g. incorrect spelling of keywords), then the game will simply crash while processing the file, stating the nature and location of the error that caused it.


== Dialogs ==
== Dialogs ==

Revision as of 16:14, 6 May 2007

Template:Stub

This article is classified as work in progress and is likely to change very often before it will be moved or merged to Dialogs once it has reached a certain degree of maturity.

Feel free to make changes though, even if it currently resides in Manny's personal namespace.

-- Manny 15:49, 6 May 2007 (CEST)

Introduction

Dialogs are one way to provide custom graphical user interface in your missions and allow interaction with the player aswell as they are able to run code. They are defined as classes in the description.ext file.

Most of these definitions work with numeric constants, which are presented in the following section. For readability purposes you should consider favoring them instead of the actual integers.

Notice: If you change your description.ext file while the mission is still open in the editor, you will have to restart the editor and load the mission again so the changes actually take effect.

Warning: If there are syntactic errors in your description.ext file (e.g. incorrect spelling of keywords), then the game will simply crash while processing the file, stating the nature and location of the error that caused it.

Dialogs

Dialogs are parent containers for the actual controls it contains. Their definition contains several properties on the controls it contains, how the dialog can be addressed, and whether or not the player is able to continue regular movement while the dialog is shown.

They can be defined in the description.ext file or externalized to seperate hpp-files, which are included in the description.ext file using the #include preprocessor directive. The latter method is generally a good idea to split a large description.ext file into several small chunks in order to keep track of what's where.

Most often, controls of a dialog are defined within the definition of the dialog itself, though it's a good practice to generalize common controls in a base definition in the global scope. See best practice for details. For simplicity we won't apply this practice in the following code examples.


Properties
Name Type Remark
idd integer the unique ID number of this dialog. can be -1 if you don't require access to the dialog itself from within a script.
movingEnable boolean sets whether or not the player is hindered from aiming or moving while the dialog is open.
controlsBackground array contains class names of all background controls associated to this dialog.
controls array contains class names of all foreground controls associated to this dialog.
objects array


Example of a dialog that will only display Hello world in the top right corner of the screen. If you get confused by the MyHelloText class, just ignore it for the moment until you have read details on the definition of controls in the following chapter, Controls.

class MyHelloWorldDialog { idd = -1; // set to -1, because we don't require a unique ID movingEnable = false; // no movement while the dialog is shown controlsBackground[] = { }; // no background controls needed objects[] = { }; // no objects needed controls[] = { MyHelloText }; // our Hello World text as seen below: class MyHelloText { type = 0; // CT_STATIC constant style = 0; // ST_LEFT constant text = "Hello world"; font = "TahomaB"; sizeEx = 0.023; colorBackground[] = { 1, 1, 1, 0.3 }; colorText[] = { 0, 0, 0, 1 }; x = 0.8; y = 0.1; w = 0.2; h = 0.05; }; };

Once you have defined (or prototyped) dialogs you want to use, be sure to reload the mission in the editor if it is already running.

Dialogs can then be created and shown using the createDialog function. If you do so by script and await a responsive action from the user, you might also want to wait until the user has closed the dialog by using the dialog function, if you intend to handle the dialog result in the same script: _ok = createDialog "MyHelloWorldDialog"; waitUntil { !dialog };

Controls

A few words about controls, as well as defining one. Crossreference to #Best Practice. IDCs, usage, etc.

Static

Text

Hello world text with semi-transparent background

Solid rectangles

Semi-transparent background

Pictures

Button

Active text

Structured text

Text box

Slider

Combobox

Listbox

Toolbox

Checkbox

Progress bar

Context menu

HTML

Tree

Static skew

Controls group

Animated texture

3D Objects

Map

Best practice

Polymorphism