Some new useful ingame functions
 

Found some new ingame functions. Feel free to document and use them :)

Misc

1. zo_binaryinsert (item, searchData, dataList, comparator)
   
2. zo_binaryremove (searchData, dataList, comparator)
   
3. zo_binarysearch (searchData, dataList, comparator)
   
4. zo_callHandler (object, handler, ...)
   
5. zo_clamp(value, minimum, maximum)
   
6. zo_deltaNormalizedLerp (from, to, amount)
   
7. zo_iconFormat(path, width, height)
   
8. zo_iconTextFormat(path, width, height, text)
   
9. zo_round(value)
   
10. zo_roundToNearest(value, nearest)
    
11. zo_roundToZero(value)
    
12. zo_strtrim(str)

Tree node:

1. ZO_TreeNode:New(myTree, controlData, myParent, childIndent)
   return node
   
2. ZO_TreeNode:SetExpandedCallback(callback)
   
3. ZO_TreeNode:ToggleExpanded(expanded)
   
4. ZO_TreeNode:IsExpanded()
   
5. ZO_TreeNode:IsShowing()
   
6. ZO_TreeNode:HasChildren()
   
7. ZO_TreeNode:GetNestingLevel()
   return nestingLevel
   
8. ZO_TreeNode:GetControl()
   return self.m_Control
   
9. ZO_TreeNode:GetOwningTree()
   return self.m_OwningTree
   
10. ZO_TreeNode:GetNextSibling()
    return self.m_Sibling
    
11. ZO_TreeNode:GetParent()
    return self.m_Parent
    
12. ZO_TreeNode:GetChildIndent()
    return self.m_ChildIndent
    
13. ZO_TreeNode:SetOffsetY(offsetY)

Tree control:

1. ZO_TreeControl:New(initialAnchor, indentXOffset, verticalSpacing)
   return tree
   
2. ZO_TreeControl:AddChild(atNode, insertedControl, childIndent)
   return ?
   
3. ZO_TreeControl:AddSibling(atNode, insertedControl, childIndent)
   return ?
   
4. ZO_TreeControl:AddSiblingAfterNode(atNode, insertedControl, childIndent)
   return ?
   
5. ZO_TreeControl:RemoveNode(node)
   
6. ZO_TreeControl:Clear()
   
7. ZO_TreeControl:Update(updateFromNode, indent, anchor, firstControl)
   return anchor, indent

Table functions:

1. NonContiguousCount(tableObject)
   return count
   
2. ZO_TableOrderingFunction(entry1, entry2, sortKey, sortKeys, sortOrder)
   return: bool
   
   Arguments:
   entry1 (table) An entry in the table being sorted
   entry2 (table) Another entry in the table being sorted
   sortKey (non nil) A key in the entry arguments (tableX[sortKey]) to be used for sorting.
   sortKeys (table) A table whose keys are all keys in entryX and whose values are all tables
   (optionally containing tiebreaker and isNumeric)
   sortOrder (number) Must be ZO_SORT_ORDER_UP or ZO_SORT_ORDER_DOWN
   
   Return:
   When sortOrder is ZO_SORT_ORDER_UP: entry1[sortKey] < entry2[sortKey]
   When sortOrder is ZO_SORT_ORDER_DOWN: entry1[sortKey] > entry2[sortKey]
   
   
3. ZO_ClearNumericallyIndexedTable(t)
   
4. ZO_ClearTable(t)
   
5. ZO_ShallowTableCopy(source, dest)
   return table
   
6. ZO_DeepTableCopy(source, dest)
   return table

Hooking API
Install a handler that will be called before the original function and whose return value will decide if the original even needs to be called.
If the hook returns true it means that the hook handled the call entirely, and the original doesn't need calling.
ZO_PreHook can be called with or without an objectTable; if the argument is a string (the function name), it just uses _G

1. ZO_PreHook(objectTable, existingFunctionName, hookFunction)
   return function (?)
   
2. ZO_PreHookHandler(control, handlerName, hookFunction)
   return function (?)

Callback Manager

1. ZO_CallbackObject:New()
2. ZO_CallbackObject:RegisterCallback(eventName, callback, arg)
   Registers a callback to be executed when eventName is triggered.
   You may optionally specify an argument to be passed to the callback.
   
   
3. ZO_CallbackObject:UnregisterCallback(eventName, callback)
   
4. ZO_CallbackObject:FireCallbacks(eventName, ...)
   return result(?)
   Executes all callbacks registered on this object with this event name
   Accepts the event name, and a list of arguments to be passed to the callbacks
   The return value is from the callbacks, the most recently registered non-nil non-false callback return value is returned
   
   
5. ZO_CallbackObject:Clean(eventName)

http://wiki.esoui.com/Raw_globals_dump
search for ZO_

If you use Zgoo, another good way.

OR! game0000.dat ....




https://www.dropbox.com/s/9tbzbcgw7goxwh6/treenode.JPG





https://www.dropbox.com/s/3n6uqn9y0n59eg5/tree.JPG

I have no clue why the links wont work, copy by hand

And we still have no idea how can we use it :(

Quote:

Originally Posted by BadVolt (Post 5177) And we still have no idea how can we use it :(

Not sure what you mean. I am staring at how to use the ZO_Dialogs:

-- To show a dialog, call this function.
-- The first parameter should be the name of the dialog (as definied in either InGameDialogs or PreGameDialogs).
-- The second parameter should be an array table, containing any data that will be needed in the callback functions in the dialog
-- you want to display.
-- The third parameter is a table, which contains parameters used when filling out the strings in your dialog.
--
-- If the main text in the dialog has 2 parameters (e.g "Hello <<1>> <<2>>"), then the 3rd parameter should contain a subtable called
-- mainTextParams which itself contains 2 members, the first will go into the <<1>> and the second will go into the <<2>>. The 3rd parameter
-- in ZO_Dialogs_ShowDialog can also contain a titleParams subtable which is used to fill in the parameters in the title, if needed.
--
-- So as an example, let's say you had defined a dialog in InGameDialogs called "TEST_DIALOG" with
-- title = { text = "Dialog <<1>>" } and mainText = { text = "Main <<1>> Text <<2>>" }
-- And you called
-- ZO_Dialogs_ShowDialog("TEST_DIALOG", {5}, {titleParams={"Test1"}, mainTextParams={"Test2", "Test3"}})
-- The resulting dialog would have a title that read "Dialog Test1" and a main text field that read "Main Test2 Text Test3".
-- The 5 passed in the second parameter could be used by the callback functions to perform various tasks based on this value.

-- Dialogs themselves (see InGameDialogs.lua, etc.) must contain at least a "mainText" table, with at least the "text" member.
-- mainText.text is filled in using the mainTextParams subtable of the table passed in the 3rd parameter to ZO_Dialogs_ShowDialog.

-- The mainText table can also optionally contain:
-- An "align" member to set the alignment of the text (TEXT_ALIGN_LEFT, TEXT_ALIGN_RIGHT, or TEXT_ALIGN_CENTER....left is default).
-- A "timer" field, which indicates that a certain parameter should be treated as a sceonds in a timer, and converted to time format
-- (so if mainText contains "timer = 1", the 1st parameter in mainText.text is converted to time format before being placed
-- in the string).
--
-- Dialogs can also optionally contain:
--
-- A "title" table, which works the same way as "mainText" ("text", "align" and "title" fields are allowed), no title is shown if "title" is not set.
-- A "noChoiceCallback" field, which is executed when the dialog is closed without making a choice first.
-- An "updateFn" field, which should be a function. If present, this function is called on each update when this dialog is showing.
-- An "editBox" field, which adds an edit box to the dialog. It can specify:
-- textType = The type of input the edit box accepts.
-- To get the value in the editbox, use ZO_Dialogs_GetEditBoxText.
-- Finally, the is a "buttons" table, in which each member corresponds to a button. Dialogs support a maximum of 2 buttons.
-- If the buttons table is present, each of it's members in turn MUST contain a "text" field. Also, each button can optionally contain:
-- A "callback" function field (whose first parameter should always be "dialog"....use "dialog.data[i]" to reference the ith data member passed in).
-- A "clickSound" field that defines what sound to play when the button is clicked.
-- An option to show an animated loading icon near the main text, called "showLoadingIcon"
--
-- See the "DESTROY_AUGMENT_PROMPT" and "DEATH_PROMPT" dialogs in InGameDialogs.lua for examples of dialogs that use these various fields.
function ZO_Dialogs_ShowDialog(name, data, textParams)

That's nice, but
1) not all of them are documented as well as ZO_Dialogs
2) not everyone can open gamearchives

Right, but arent you asking for documentation?


So, if someone "can" snapshot the actual headers, why not use those. And if there is the off chance of documentation, have it extracted.


My assumption is this will all go on the wiki? anyway? So, regardless of where the information comes from, it is still the information =)