Permalink
Browse files

init

  • Loading branch information...
0 parents commit aed0280143f9623f824b447facf270ef57a83809 @raposalorx committed Jul 31, 2009
Showing with 3,497 additions and 0 deletions.
  1. +12 −0 RougeMUD-Client/being.h
  2. BIN RougeMUD-Client/data/dwarf.bmp
  3. +2 −0 RougeMUD-Client/data/img.init
  4. BIN RougeMUD-Client/data/menu.bmp
  5. +124 −0 RougeMUD-Client/doc/Lua Environment.txt
  6. +11 −0 RougeMUD-Client/doc/UI Mods.txt
  7. +108 −0 RougeMUD-Client/doc/UI Objects Overview.txt
  8. +14 −0 RougeMUD-Client/doc/interface.txt
  9. +155 −0 RougeMUD-Client/game.cpp
  10. +52 −0 RougeMUD-Client/game.h
  11. +219 −0 RougeMUD-Client/luaenv.cpp
  12. +31 −0 RougeMUD-Client/luaenv.h
  13. +154 −0 RougeMUD-Client/main.cpp
  14. +93 −0 RougeMUD-Client/ns_game.cpp
  15. +47 −0 RougeMUD-Client/ns_game.h
  16. +5 −0 RougeMUD-Client/ns_state_game.cpp
  17. +28 −0 RougeMUD-Client/ns_state_game.h
  18. +45 −0 RougeMUD-Client/object.cpp
  19. +37 −0 RougeMUD-Client/object.h
  20. +25 −0 RougeMUD-Client/object_button.cpp
  21. +18 −0 RougeMUD-Client/object_button.h
  22. +262 −0 RougeMUD-Client/object_frame.cpp
  23. +24 −0 RougeMUD-Client/object_frame.h
  24. +124 −0 RougeMUD-Client/object_globalregion.cpp
  25. +22 −0 RougeMUD-Client/object_globalregion.h
  26. +30 −0 RougeMUD-Client/object_image.cpp
  27. +19 −0 RougeMUD-Client/object_image.h
  28. +765 −0 RougeMUD-Client/object_region.cpp
  29. +42 −0 RougeMUD-Client/object_region.h
  30. +25 −0 RougeMUD-Client/object_secure.cpp
  31. +18 −0 RougeMUD-Client/object_secure.h
  32. +34 −0 RougeMUD-Client/object_surface.cpp
  33. +22 −0 RougeMUD-Client/object_surface.h
  34. +30 −0 RougeMUD-Client/object_text.cpp
  35. +19 −0 RougeMUD-Client/object_text.h
  36. +25 −0 RougeMUD-Client/object_worldview.cpp
  37. +19 −0 RougeMUD-Client/object_worldview.h
  38. +24 −0 RougeMUD-Client/state.cpp
  39. +23 −0 RougeMUD-Client/state.h
  40. +132 −0 RougeMUD-Client/state_game.cpp
  41. +35 −0 RougeMUD-Client/state_game.h
  42. +83 −0 RougeMUD-Client/state_login.cpp
  43. +25 −0 RougeMUD-Client/state_login.h
  44. +58 −0 RougeMUD-Client/test.lua
  45. +13 −0 RougeMUD-Client/texture.h
  46. +35 −0 RougeMUD-Client/timer.cpp
  47. +20 −0 RougeMUD-Client/timer.h
  48. +13 −0 RougeMUD-server/being.h
  49. +88 −0 RougeMUD-server/game.cpp
  50. +37 −0 RougeMUD-server/game.h
  51. +81 −0 RougeMUD-server/main.cpp
  52. +87 −0 RougeMUD-server/ns_game.cpp
  53. +26 −0 RougeMUD-server/ns_game.h
  54. +35 −0 RougeMUD-server/timer.cpp
  55. +22 −0 RougeMUD-server/timer.h
@@ -0,0 +1,12 @@
+#ifndef BEING_STRUCT
+#define BEING_STRUCT
+
+#include <string>
+using namespace std;
+
+typedef struct
+{
+ int x, y;
+}Being;
+
+#endif
Binary file not shown.
@@ -0,0 +1,2 @@
+data/dwarf.bmp 8 11
+data/menu.bmp 247 46
Binary file not shown.
@@ -0,0 +1,124 @@
+_G =
+{
+ ["Print"] = function,
+ ["CreateFrame"] = function,
+ ["GetFrame"] = function,
+ ["GlobalRegion"] =
+ {
+ ["Show"] = function,
+ ["Hide"] = function,
+ ["SetPoint"] = function,
+ ["DelPoint"] = function,
+ ["GetPoint"] = function,
+ ["GetPointCount"] = function,
+ },
+ ["WorldView"] =
+ {
+ },
+ [typical object] =
+ {
+ [0] = userdata,
+ ["SetEventHandler"] = function,
+ ["NoticeEvent"] = function,
+ ["NoticeAllEvents"] = function,
+ ["IgnoreEvent"] = function,
+ ["IgnoreAllEvents"] = function,
+ ["SetPoint"] = function,
+ ["GetPoint"] = function,
+ ["GetPointCount"] = function,
+ ["DelPoint"] = function,
+ ["SetAnchor"] = function,
+ ["GetAnchor"] = function,
+ ["GetAnchorCount"] = function,
+ ["ClearAnchors"] = function,
+ ["Show"] = function,
+ ["Hide"] = function,
+ ["DeleteFrame"] = function,
+ },
+ ...
+}
+
+LUA_REGISTRYINDEX =
+{
+ ["EVENT"] =
+ {
+ ["HANDLER"] =
+ {
+ [userdata] = function,
+ ...
+ },
+ [event name] =
+ {
+ [userdata] = true,
+ ...
+ },
+ ...
+ },
+ ["OBJECT"] =
+ {
+ [userdata] =
+ {
+ ["NAME"] = string,
+ ["POINT"] =
+ {
+ [0] = number, -- number of points the region has
+ [1, 2, 3, ...] =
+ {
+ ["NAME"] = string,
+ ["X"] = number,
+ ["Y"] = number,
+ ["ANCHORS"] = number, -- number of anchors set to this point; deletable only if equal to 0
+ },
+ [point name] = table, -- reverse lookup for points, used in L_GetPoint
+ },
+ ["ANCHOR"] =
+ {
+ [1, 2, 3, 4] =
+ {
+ ["SOURCE"] = string,
+ ["AXES"] = string,
+ ["X"] = number,
+ ["Y"] = number,
+ ["DEST_OBJECT"] = userdata,
+ ["DEST_POINT"] = string,
+ },
+ ["X1", "X2", "Y1", "Y2"] =
+ {
+ ["SOURCE"] = string,
+ ["OFFSET"] = number,
+ ["DEST_OBJECT"] = userdata,
+ ["DEST_POINT"] = string,
+ },
+ ["COMPLETE"] = boolean,
+ ["VALID"] = boolean,
+ },
+ ["EVENT"] =
+ {
+ [event name] = true,
+ ...
+ },
+ },
+ ...
+ [object name] = table, -- for looking up frames by name
+ ...
+ },
+}
+
+class Object_All
+{
+ public:
+ int depth, x, y, width, height;
+ bool visible;
+ protected:
+ private:
+};
+
+r:SetPoint("name", #x, #y) = nil
+r:DelPoint(#point) = nil
+r:GetPoint(#point) = "name", #x, #y, #anchors
+r:GetPointCount() = #points
+
+r:SetAnchor("source", destobj, "dest", "type", #off1[, #off2]) = nil
+r:ClearAnchors() = nil
+r:GetAnchor(#anchor) = "source", destobj, "dest", "type", #off1[, #off2]
+r:GetAnchorCount() = #anchors
@@ -0,0 +1,11 @@
+-mods are kept in one folder, and each is in its own folder inside there
+
+-RogueMUD -> Mods -> SomeMod
+ -> Some_Other Mod
+ -> A Different Mod
+
+The mod's folder contains all the files needed for the mod to run, which includes images, sound files, lua code files, and the mod definition file.
+
+MOD DEFINITION FILE
+-identified by having the same name as the mod's folder, with the file extension .mdf (eg. SomeMod.mdf)
+-
@@ -0,0 +1,108 @@
+ USER INTERFACE OBJECTS OVERVIEW/CHEATSHEET
+TERMS:
+base object
+ -a UI object that is not createable by CreateFrame, but its methods are inherited through its derivatives
+complex object
+ -a UI object that is made up of multiple simple objects
+simple object
+ -a UI object that is a base type
+system object
+ -a UI object that is only created by developer code
+widget
+ -a component of the UI that the user can interact with, user made or developer made
+
+HEIRARCHY OF SIMPLE OBJECTS:
+Object* -> Frame -> Region -> Surface* -> Text -> FText???
+ -> Image
+ -> Secure* -> Button
+ -> Grip
+ -> WorldView*
+ -> GlobalRegion*
+*base/system object; uncreateable by CreateFrame
+
+DESCRIPTIONS OF SIMPLE OBJECTS:
+Button:
+ An object that can tell when it is clicked upon. Used in widgets that have mouse interaction.
+Frame:
+ A basic object, currently used for event interaction and as a base for event interaction, more to come...
+GlobalRegion:
+ A region, minus the ability to change its shape and position, that takes up the whole screen. Used as a base for anchoring objects, and is used to determine the position of every other region.
+Grip:
+ An object that can tell when it is dragged. Used in widgets that are to be dragged around or resized by the user.
+Image:
+ A high-use object that displays an image on the screen.
+Object:
+ Used as the base object for all interface objects.
+Region:
+ Used as the base object for all objects that have shape, visibility, position, and render priority. Also used as the parent for widgets, as an
+ invisible surface for controlling the shape and position of the entire widget.
+Secure:
+ Used as the base object for all objects that interact with the user. Blocks Lua access (via hooking) to certain functions at certain times, to
+ prevent cheating. The security of objects works upwards through descendance, so a secure object's descendants would not necessarily be secure, but
+ its ancestors always will be.
+Surface:
+ Used as the base object for all drawable objects.
+Text:
+ Another high-use object that displays a string of text on the screen.
+WorldView:
+ The main object of the game, displays the world as the character can see it. Is heavily hardcoded, and is a simple object from a UI perspective.
+ It is also a base object, making it uncreatable by CreateFrame. There is only one of it in the UI at any time, and the only interaction mods can
+ have on it are changing its dimensions. Otherwise, all of its work is accomplished through C++ code.
+
+not yet sorted...
+Font:
+ Holds settings for font implementation. Used by Text objects to control what font is used to render the text. Allows much more powerful control
+ over font usage, and provides methods to set font size, colour, justification, spacing, etc.
+
+METHODS AND TARGETTED EVENTS ADDED BY SIMPLE OBJECTS:
+Button:
+ events -
+ methods -
+Frame:
+ events -
+ methods -
+Image:
+ events -
+ methods -
+Object:
+ events - n/a
+ methods -
+Region:
+ events - n/a
+ methods - SetAnchor, SetAllAnchors, ClearAnchors, GetAnchor, GetAnchorCount, SetHeight, GetHeight, SetWidth, GetWidth
+Secure:
+ events -
+ methods -
+Surface:
+ events -
+ methods -
+Text:
+ events -
+ methods -
+note: only objects that derive from Frame have events, as Frame introduces event handling to the system
+
+DESCRIPTIONS OF COMPLEX OBJECTS:
+
+OVERVIEW OF OBJECT SECURITY:
+Object security is necessary for the environment, to prevent such cheating as making a mod that plays the game the player, to whatever extent. While all objects can be made secure, the main bulk of security is implemented in the Secure base object. The simple objects that inherit from the Secure object all interact directly with the user, such as clickable buttons.
+Security only kicks in during times when interface cheating would provide an unfair advantage, the primary example of which being combat. During a lockdown, which is declared by the C++ code, all objects that descend from Secure, and their ancenstors, lock themselves down to being programatically altered, moved, resized, etc. This makes it so that the only interaction with secure objects at this point is necessary use. Eg. the player can still drag around secure widgets themselves, and click buttons, but such actions as a mod loading keybindings from a stored profile are blocked.
+When secure objects are created and destroyed, the security status of their ancestors is re-evaluated. The security status of an object is stored in the C++ data, as an integer, with a value equal to the number of objects causing it to become secure, 0 meaning it is unsecure. So, when a secure object is created, all its ancestors have their security status value incremented once, and when a secure object is destroyed, its ancestors' security status value is decremented once. The calling or clearing of a lockdown causes all objects with a security status with a value over 0 to be locked down.
+There is also passive security built into the system, such as the architecture built up around the sending of commands. Secure commands, such as combat-related ones, can only be run through a button or keybinding, and the player must activate these. However, non-secure commands, such as whois requests and chat sends can be done automatically by mods.
+
+DESCRIPTIONS OF RENDERING LAYERS:
+LAYER_NORMAL:
+ Currently the only rendering layer.
+
+OVERVIEW OF RENDERING PROCESS:
+All objects of type Region, and its descendants, are placed in groups known as 'layers'. These layers are used during rendering to decide render priority. Layers that have a higher depth value are drawn sooner. Within a layer, the objects it includes also have a depth setting for inside that layer. This allows for easy grouping of similarily depthed objects, without needing a standard for which depth values to use.
+Not only are layers used for deciding the order in which to draw images to the screen, they are also used to decide which order elements should be checked in to see if they have been clicked upon. So if two clickable elements are on top of each other, and both cover the spot that was clicked, the one with less depth will be sent the event. However, if the top object receives click events, the bottom object receives drag events, and the user initiated a drag event, the bottom object will receive the event.
+
+OVERVIEW OF SHAPE AND ANCHOR POINTS OF REGION OBJECTS
+Another property of Region-type objects is that they have shape. This shape is defined in C++ with a simple x, y, width, height set of values, but in Lua, there is a much more in-depth set of variables to use, in the form of anchor points. Each region has nine anchor points (four corners, four edges, one center), as well as height and width values, that can all be set independently of each other. Width and height are simple numerical values, but anchor points are much more complex. They each hold an x and y offset value, as well as two values (point name and frame) used to point to the anchor point of any region that it will anchor to. This allows regions to be moved together easily and conveniently. Any frame with no anchors will treated as if its center is anchored to the center of the screen, using whatever offset it already had relative to the center.
+To control the anchor points, functions are available to region objects to set one anchor, delete one anchor, delete all anchors, or set all anchors to those of another object. When an anchor is set, what actually happens is based on what kind of anchor was set:
+Corner - anchors its two adjacent edges (overwrites adjacent corner anchors, and height+width+center anchors)
+Edge - the edge is anchored like normal (overwrites adjacent corner anchors, and height/width+center anchors)
+Center - all edges are anchored, using current height and width values for offset (overwrites all corner anchors)
+Height - changes top and bottom edge anchor offsets, based on which one was set more recently (more recent remains stationary, if set by a center anchor, they are moved equally) (this setting is like an anchor, in that it is persistant, until overwritten)
+Width - changes left and right edge anchor offsets, based on which one was set more recently (more recent remains stationary, if set by a center anchor, they are moved equally) (this setting is like an anchor, in that it is persistant, until overwritten)
+So in actuality, the only settings that matter are the edge anchors, width, and height values, as the corner and center anchors are simply there for convenience's sake. To send results through GetPoint(), a list is kept of the set anchor points, in the order that they were set. When some anchors are set, they delete other anchor entries in the list, as indicated above. If a point is set that is already in the list, the old entry is deleted. Height and width values are not on the list, instead when they are set they add edge anchors relative to the region's own center. This list is consulted when the C++ values for shape are determined.
@@ -0,0 +1,14 @@
+-- INTERFACE
+UI made up of parts called objects.
+There are various types of objects; only textures are visible
+
+-- EVENTS
+UI functions by calling events, and objects handling them.
+Events are either called globally, over all objects, or is sent to one certain object
+
+-- global events
+UI_STEP
+UI_LOAD
+UI_QUIT
+
+-- targetted events
Oops, something went wrong.

0 comments on commit aed0280

Please sign in to comment.