imported>Kyoma |
imported>Kyoma |
| Line 6: |
Line 6: |
| In order for modders to easily mark an element as a TileSystem they need to use a specific string-constant for the <id> trait of the element in question. Then, whenever the game processes that particular XML the code will pick up on the desired tile system, create the needed background stuff and attach it to the element. | | In order for modders to easily mark an element as a TileSystem they need to use a specific string-constant for the <id> trait of the element in question. Then, whenever the game processes that particular XML the code will pick up on the desired tile system, create the needed background stuff and attach it to the element. |
|
| |
|
| There can be only one per element but a menu can contain any number of systems, even with the same type.
| | Only one system can be associated with a single element but there are no limits to the total amount. Atleast, not practical ones. |
| <pre>
| |
| <menu name="DemoMenu">
| |
| <class> &GenericMenu; </class>
| |
| <stackingtype> &no_click_past; </stackingtype>
| |
| <locus> &true; </locus>
| |
| <explorefade> 0.25 </explorefade>
| |
|
| |
| <rect name="background">
| |
| <include src="generic_background.xml" />
| |
|
| |
|
| <id> &TileSystemType; </id> <!-- this will mark the element as a TileSystem -->
| |
| <visible> &true; </visible>
| |
| <depth> 15 </depth>
| |
| <locus> &true; </locus>
| |
| <target> &true; </target>
| |
| <user0> 400 </user0>
| |
| <user1> 580 </user1>
| |
| <x>
| |
| <copy src="screen()" trait="width" />
| |
| <sub src="me()" trait="width" />
| |
| <div> 2 </div>
| |
| </x>
| |
| <y>
| |
| <copy src="screen()" trait="height" />
| |
| <sub src="me()" trait="height" />
| |
| <div> 2 </div>
| |
| </y>
| |
| </rect>
| |
|
| |
| </menu>
| |
| </pre>
| |
|
| |
|
| ==Types== | | ==Types== |
| There are a number of different types of TileSystems, each one dealing with a different aspect of user-to-UI interaction. Depending on the system an element will also need to have certain <userX> traits in order to function properly. | | There are a number of different types of TileSystems, each one dealing with a different aspect of user-to-UI interaction. Some have required traits for specific input data and some have optional traits for additional configuration. |
|
| |
|
| ===Scroll===
| | A short list (more details on each induvidual system can be found below: |
| This will respond to the mousewheel and increment or decrement the <user5> trait. Most common use would be for custom scrollbars but how this value is used makes no difference. REQUIRES: <user5> trait. | | * Scroll System - This system responds to the mouse wheel movement and will increment or decrement a specific trait accordingly. |
| | ** ID is: '''&Scroll;''' |
| | ** (required) <user5> - the trait that gets altered by code. |
|
| |
|
| * A scroll system is only considered active (and thus invoked) when it is visible and targetable. When a menu has more than one scroll system (including the default scrolling behaviour) it will use the first active one it finds. Scroll systems always take precedence over the default scrolling behaviour. | | * Drag System - This system responds to the mouse movement while the left mouse button is held down over the element. There are three different types of movement: horizontal, vertical or both. |
| * The code does not check for boundaries when it detects scrolling, that should be done in the XML using the <max> and <min> traits. | | ** IDs are: '''&DragHorizontal;''' and '''&DragVertical;''' and '''&DragRect;''' respectively |
| | ** (required) <user8> - controls the step-distance for dragging. |
| | ** (required) <user9> - the trait that gets altered by code. |
|
| |
|
| Here is a quick template, when you see a trait with ... then that means it is of no importance to this system in particular and should be filled with whatever value you need it to be. They are listed for completeness and to better illustrate things.
| | * TextEdit System - This system provides a simple field where the user, after clicking the element, can type in. |
| <pre>...
| | ** ID is: '''&TextEdit;''' |
| <image name="scroll_bar">
| | ** (optional) <user0> - controls the initial text upon activating, if desired to be different than what is displayed before it was activated. |
| <include src="vertical_scroll.xml" />
| | ** (optional) <user1> - controls the default text, which is displayed when the textedit ends and the input string is empty. It does not affect the input string, when it is activated again it will be empty again. |
| <id> &Scroll; </id>
| |
| <target> &true; </target>
| |
| <locus> &true; </locus>
| |
| <depth> 15 </depth>
| |
| <user1> ... </user1>
| |
| <user2> ... </user2>
| |
| <user3> ... </user3> <!-- step distance -->
| |
| <user4> ... </user4> <!-- jump distance -->
| |
| <user5> 0 </user5> <!-- code set - scroll force value (must be 0 here) -->
| |
| <!-- user7 --> <!-- current value -->
| |
| <user8> ... </user8> <!-- num visible -->
| |
| </image>
| |
| ... | |
| </pre>
| |
|
| |
|
| ===Drag===
| | * FocusBox System - This system will adjust the size and position of the designated element to match that of the active element, provided its <focus>, <target> and <visible> traits are true. |
| These will respond to the mouse movement while holding down the left mouse button. There are three versions, two for movement along a single axis and one movement along both axis. There is a small limitation in that the moving of the dragged element should not affect the position of its parent element (or anything else higher up the chain).
| | ** ID is: '''&FocusBox;''' |
| | ** (optional) <user15> - used as a static depth adjustment. |
|
| |
|
| The element itself does not have to move though. REQUIRES: <user8> and <user9> for horizontal -or- vertical dragging and <user11>, <user12>, <user13> and <user14> for dragging along both axis.
| |
|
| |
| ===FocusBox===
| |
| A focus system will react to the active element (e.g. the mouse is over it). It will then get the same <width>,<height>, <x> and <y> traits as the active element. But this only happens if the active element has a "&true;" <focus> and a "&true;" <target> trait. The position offset can be adjusted with the <focusinset> trait. The difference in size can be adjusted with the <focussize> trait.
| |
|
| |
| A quick template
| |
| <pre>...
| |
| <rect name="focus_box">
| |
| <include src="focus_box.xml"/>
| |
| <id> &FocusBox; </id>
| |
| <visible> &false; </visible>
| |
| </rect>
| |
| ...
| |
| <rect name="some_element">
| |
| <width> ... </width>
| |
| <height> ... </height>
| |
| <x> ... </x>
| |
| <y> ... </y>
| |
|
| |
| <!-- when the mouse is over this element its dimension
| |
| and position will be copied to the focus box -->
| |
| <focus> &true; </focus>
| |
|
| |
| <!-- this gets added to the width and height before they are copied.
| |
| And half of it gets substracted from X and Y to even the increase in size
| |
| between the outline. -->
| |
| <focussize> 20 </focussize>
| |
|
| |
| <!-- this gets added to the X and Y before they are copied -->
| |
| <focusinset> 0 </focusinset>
| |
| </rect>
| |
| </pre>To put things in a couple of simple formulas:
| |
| focusBox_X = (element_X - (focussize / 2) + focusinset)
| |
| focusBox_Y = (element_Y - (focussize / 2) + focusinset)
| |
| focusBox_Width = (element_Width + focussize)
| |
| focusBox_Height = (element_Height + focussize)
| |
|
| |
| ===TextEdit===
| |
| A textedit system allows simple boxes that can be typed in. Although not as powerful as OBSE's TextInput it is much more flexible in terms of layout and can be added to any menu, even those that have a textedit box by default. It will match the default typing behaviour as seen in some menus.
| |
|
| |
| * The initial value is determined by the <string> trait when it gets activated, any changes once it is active are ignored.
| |
| * The textedit is activated by clicking on either the element itself or the parent element.
| |
| * To terminate the textedit the user has to click on any element (that can be targeted).
| |
| * The use of the Enter key will terminate the textedit.
| |
|
| |
| Here is a quick template, when you see a trait with ... then that means it is of no importance to this system in particular and should be filled with whatever value you need it to be. They are listed for completeness and to better illustrate things.
| |
| <pre>
| |
| ...
| |
| <rect name="textedit">
| |
| <locus> &true; </locus>
| |
| <target> &true; </target>
| |
| <x> ... </x>
| |
| <y> ... </y>
| |
| <width> 240 </width>
| |
| <height> 40 </height>
| |
| <depth> 3 </depth>
| |
|
| |
| <text name="textedit_text">
| |
| <id> &TextEdit; </id>
| |
| <string> My Initial Text </string>
| |
| <depth> 3 </depth>
| |
| <locus> &true; </locus>
| |
| <target> &true; </target>
| |
| ...
| |
| </text>
| |
| </rect>
| |
| ...
| |
| </pre>
| |
|
| |
|
| == See Also == | | == See Also == |