Difference between revisions of "Talk:Property Element"
imported>JRoush |
imported>Nonsanity |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
[[User:JRoush|JRoush]] 21:17, 22 May 2009 (EDT) | [[User:JRoush|JRoush]] 21:17, 22 May 2009 (EDT) | ||
[[user:Nonsanity|Nonsanity]]: That speculation is correct. I wanted the menus to be as completely moddable as possible, so the game code couldn't be given detailed knowledge about a menu's internal structure - Something it would have to have if it were to set the display strings directly. So instead the game code set traits on the menu object, and the menu itself would copy them to wherever they needed to be. Then the string object could be anywhere in the menu and have any name. [[User:Nonsanity|Nonsanity]] 16:45, 19 May 2011 (EDT) | |||
== Properties that haven't been explained == | == Properties that haven't been explained == | ||
| Line 22: | Line 24: | ||
*xbuttonb | *xbuttonb | ||
*xbuttona | *xbuttona | ||
*wraplimit | *wraplimit | ||
*shiftclicked | *shiftclicked | ||
| Line 28: | Line 29: | ||
*repeathorizontal | *repeathorizontal | ||
*repeatvertical | *repeatvertical | ||
*listindex | *listindex | ||
*listclip | *listclip | ||
*linecount | *linecount | ||
*focusinset | *focusinset | ||
*explorefade | *explorefade | ||
*depth3d | *depth3d | ||
| Line 47: | Line 42: | ||
*clickcountbefore | *clickcountbefore | ||
*clickcountafter | *clickcountafter | ||
*child_count | *child_count | ||
*animation | *animation | ||
Latest revision as of 15:45, 19 May 2011
On User# type elements: I'm not sure why Bethesda didn't have the menu classes set things like magicka cost directly into the String properties of the Text elements that display them. I'm reluctant to speculate in the article itself, but if anyone has some insight, let it be heard here.
I suspect it's linked to the fact that the src trait of Operator elements doesn't handle relative paths like "me()\some_child_element\some_other_child_element\someproperty." They probably would've had to assign unique indexes to every text element they needed to update, and it was just easier to create these intermediate properties in an element with an existing index.
JRoush 21:17, 22 May 2009 (EDT)
Nonsanity: That speculation is correct. I wanted the menus to be as completely moddable as possible, so the game code couldn't be given detailed knowledge about a menu's internal structure - Something it would have to have if it were to set the display strings directly. So instead the game code set traits on the menu object, and the menu itself would copy them to wherever they needed to be. Then the string object could be anywhere in the menu and have any name. Nonsanity 16:45, 19 May 2011 (EDT)
Properties that haven't been explained[edit source]
- xscroll
- xright
- xleft
- xdown
- xup
- xlist
- xdefault
- xbuttonstart
- xbuttonrb
- xbuttonlb
- xbuttonrt
- xbuttonlt
- xbuttony
- xbuttonx
- xbuttonb
- xbuttona
- wraplimit
- shiftclicked
- returnvalue
- repeathorizontal
- repeatvertical
- listindex
- listclip
- linecount
- focusinset
- explorefade
- depth3d
- clipwindow
- cropoffsety
- cropoffsetx
- disablefade
- clickedfunc
- clickcountbefore
- clickcountafter
- child_count
- animation