Closed Thread
Page 5 of 24 FirstFirst 1 2 3 4 5 6 7 8 9 15 ... LastLast
Results 61 to 75 of 357
Like Tree30Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Changelog Discussion

  1. #61
    Rift Chaser
    Join Date
    Oct 2011
    Posts
    398

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Because NPSee doesn't have a dedicated location for "the thing groupmember 2 is targeting". When it's showing a list of known NPCs, those could be in any order.
    Ah I see.
    But, if it connected the group member number with the NPC frame, then it could be done with the aforementioned macro?

  2. #62
    Telaran
    Join Date
    Nov 2010
    Posts
    59

    Default

    Quote Originally Posted by TimeBomb View Post
    Ah I see.
    But, if it connected the group member number with the NPC frame, then it could be done with the aforementioned macro?
    Then you would need to have static frames for all possible unit specifiers (you can't have ALL but to some extent, most that are relevant), which would take up A LOT of screen real estate.

    For example, we can set up a grid of frames for all of your groups' targets, although it would be static and take up lots of space; even if you're only targeting one or two enemies, you still have 20 frames that can't be moved or clicked through.
    The frames wouldn't care whether the unit is hostile either.
    Last edited by Sunspotsy; 11-13-2011 at 09:00 PM.

  3. #63
    Rift Chaser
    Join Date
    Oct 2011
    Posts
    398

    Default

    Quote Originally Posted by Sunspotsy View Post
    Then you would need to have static frames for all possible unit specifiers (you can't have ALL but to some extent, most that are relevant), which would take up A LOT of screen real estate.

    For example, we can set up a grid of frames for all of your groups' targets, although it would be static and take up lots of space; even if you're only targeting one or two enemies, you still have 20 frames that can't be moved or clicked through.
    The frames wouldn't care whether the unit is hostile either.
    Why not just add some sort of "group id" property to the target object/frame, so that it only sets the group member ID, and only when a target frame is added/changed.

  4. #64
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    Quote Originally Posted by TimeBomb View Post
    Why not just add some sort of "group id" property to the target object/frame, so that it only sets the group member ID, and only when a target frame is added/changed.
    Isn't the point that even if you did set a "group id" as you suggest you MUST do that outside combat and hence the suggestion that you'd need 20 static frames one for each groupXX.target.

    You specifically cannot change the unit the frame references in combat and thus you cannot change it when a target is added/changed in the manner I think you are meaning.

    The reason is simple enough. If you had a frame that could change target you could have a frame that changed & lit up whenever NPC XXX was casting YYY so that you could interrupt. Or you could have a set of frames that always showed the raid members with the least health. etc ie: it becomes easy to automate things and remove player decision making if you allow the frame to change its specifier in combat.

  5. #65
    Rift Chaser
    Join Date
    Oct 2011
    Posts
    398

    Default

    Quote Originally Posted by Levva View Post
    Isn't the point that even if you did set a "group id" as you suggest you MUST do that outside combat and hence the suggestion that you'd need 20 static frames one for each groupXX.target.

    You specifically cannot change the unit the frame references in combat and thus you cannot change it when a target is added/changed in the manner I think you are meaning.

    The reason is simple enough. If you had a frame that could change target you could have a frame that changed & lit up whenever NPC XXX was casting YYY so that you could interrupt. Or you could have a set of frames that always showed the raid members with the least health. etc ie: it becomes easy to automate things and remove player decision making if you allow the frame to change its specifier in combat.
    Alright so essentially not only can you not change addon macros in combat, but you can't change variables/properties attached to the frames in combat? Good to know. Sorry for all the confusion.

  6. #66
    RIFT Fan Site Operator Aieny's Avatar
    Join Date
    Feb 2011
    Location
    Earth
    Posts
    472

    Default

    Quote Originally Posted by TimeBomb View Post
    Alright so essentially not only can you not change addon macros in combat, but you can't change variables/properties attached to the frames in combat? Good to know. Sorry for all the confusion.
    Yup, but this system actually allowed HealBot functionality by attaching different macros to different events on a single frame. In other words, you create your 20 static frames, then you set an event listeners where
    • LeftClick = "/cast @group01 Quickie Heal"
    • RightClick = "/cast @group01 Bombad Heal"
    • Mouse3Click = "/cast @group01 Mega Buff"
    • Mouse4Click = "/cast @group01 Purge"
    Then, the player simply uses the appropriate click on the frame to cast the specified spell on that target. In fact, a more interesting feature of a HealBot Addon would be to modify the frames based on Inspect.Unit.Detail("group01").role, changing the appearance of the frames based on tank, heal, dps, or support, with a configurable option to emphasis the tanks (main tank healer) or the raid (support heals).
    a community-oriented site for all things Rift

  7.   Click here to go to the next Rift Team post in this thread.   #67
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    This is now officially a Discussion thread, a new thread has been started for the bare PTS changelog. I'll keep posting the changelists in both places.

    NEW FEATURES:

    * Added new frame type, "RiftScrollbar".

    BUGFIXES:

    * Inspect.Item.Split() will now function properly on guildbank items.
    * Fix a crash caused by logging into a party with pets.
    * Fix several errors dealing with the inventory and bank of people who don't place their bags in order from left to right.
    * Fix glitch causing slot specifiers to often not be determined properly.
    * Fix crash in Inspect.Item.Find() when searching for missing items.

    DIFF:

    Code:
    UI:
    	RiftScrollbar: Inherits from Frame
    		Members:
    			GetEnabled
    			GetOrientation
    			GetPosition
    			GetRange
    			GetThickness
    			Nudge
    			NudgeDown
    			NudgeUp
    			SetEnabled
    			SetOrientation
    			SetPosition
    			SetRange
    			SetThickness
    		Events:
    			ScrollbarChange
    			ScrollbarGrab
    			ScrollbarRelease

  8. #68
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Quote Originally Posted by ZorbaTHut View Post
    * Added new frame type, "RiftScrollbar".
    Om nom nom.

  9. #69
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by ZorbaTHut View Post
    * Fix several errors dealing with the inventory and bank of people who don't place their bags in order from left to right.
    I am really curious about this. I never had any inventory issues that I know of, and my bags are in an order that totally made sense when they were all 10-slot bags.

    Events:
    ScrollbarChange
    ScrollbarGrab
    ScrollbarRelease
    Maybe I am clue-deficient, but I don't see where the documentation is for what event handlers for these get for args.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  10.   Click here to go to the next Rift Team post in this thread.   #70
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by the_real_seebs View Post
    I am really curious about this. I never had any inventory issues that I know of, and my bags are in an order that totally made sense when they were all 10-slot bags.
    In some of the early test code, I figured out how many bags the player had by simply iterating through the bags and stopping the first time you didn't find a valid bag.

    Make a new character. Drag the bag in slot #1 to slot #2. Tada, slot #1 is empty, so the old system no longer thinks you have any bags. Same bug happened with the bank if you decided to leave the first bag slot empty for some reason.

    It actually took us a while to figure out what was going on - the main addon guy in QA has his character consistently set up that way to flush out bugs, but he didn't realize it was triggering this bug, so we had a confusing back-and-forth until he figured out the cause of the problem and I had a head-desk moment.

    Fixed now, anyway.

    Quote Originally Posted by the_real_seebs View Post
    Maybe I am clue-deficient, but I don't see where the documentation is for what event handlers for these get for args.
    No arguments at this time. They signal that things have changed, but if you want to see what the actual change is, you call the appropriate function to find out.

  11. #71
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by ZorbaTHut View Post
    No arguments at this time. They signal that things have changed, but if you want to see what the actual change is, you call the appropriate function to find out.
    Fair enough. I'd love to see args on those that tell the receiver what happened, but in general we can presumably do without it.

    I just have horrible memories from a certain game's "mailbox updated" event which gave no information about what the update was, and fired a nearly-deterministic number of times per time a mail item got touched.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  12.   Click here to go to the next Rift Team post in this thread.   #72
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by the_real_seebs View Post
    Fair enough. I'd love to see args on those that tell the receiver what happened, but in general we can presumably do without it.

    I just have horrible memories from a certain game's "mailbox updated" event which gave no information about what the update was, and fired a nearly-deterministic number of times per time a mail item got touched.
    If it's actually ambiguous at any point, we'll start adding in more parameters, but it should be rather unambiguous.

  13. #73
    Ascendant the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    What's scary is that I actually trust you to fix it if it becomes a problem. :P
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

  14.   Click here to go to the next Rift Team post in this thread.   #74
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Here's the 1.5 to 1.6 changelist:

    NEW FEATURES:

    BIG THINGS:
    * Added *.Achievement.*, for inspecting everything achievement-related.
    * Added *.Item.*, for inspecting inventory and banks, as well as equipping and reorganizing items.
    * Added Inspect.Cursor(), Command.Cursor(), and Event.Cursor. These functions allow addons to monitor and modify the item or ability that the player has "picked up".
    * Added Command.Tooltip(). This allows addons to set the current tooltip.
    * Added new frame type, "RiftScrollbar".
    * Macros can now be added to frame event handlers. Ensure that the frame is restricted and that the player is out of combat, then simply set the event to a string (for example, myframe.Event.LeftDown = "cast Planar Lure"). Commands can be separated by newlines up to the addon line limit.
    * Addon-style unit specifiers can now be used in macros while the addon system is running (for example, "target @focus.target").

    INSPECTION AND EVENTS:
    * Added Inspect.Addon.List() and Inspect.Addon.Detail(), allowing addons to get information about loaded items and inspect values from the TOC.
    * Added a .toc member to the information table provided as a parameter to each file.
    * Added Inspect.System.Secure(), which returns the current secure state.
    * Added Event.Mouse.Move, allowing for global notification when the mouse pointer is moved.
    * Added damageDeflected member to Event.Combat.Damage.
    * Added description and rune members to Inspect.Buff.Detail.
    * Added description member to Inspect.Ability.Detail.

    UNITS:
    * Added .combat member to the result from Inspect.Unit.Detail(), added Event.Unit.Detail.Combat.
    * Added new race, raceName, tag, tagName, locationName, publicSize, faction, factionId, factionName, tagged, and tier members to Inspect.Unit.Detail. Added Event.Unit.Detail.LocationName, Event.Unit.Detail.PublicSize, and Event.Unit.Detail.Tagged.
    * Added .type member to the result of Inspect.Unit.Detail. This is a unique unit type ID, which can be used for identifying NPC types without carrying around large translation tables.
    * Added titlePrefixId, titlePrefixName, titleSuffixId, and titleSuffixName members to Inspect.Unit.Detail(), along with equivalent events. This gives access to language-agnostic title prefixes and suffixes.
    * Added Event.Unit.Detail.Ready to monitor readycheck status.
    * Unit specifiers can now be chained off of unit IDs. For example, Inspect.Unit.Detail(Inspect.Unit.Lookup("player") .. ".target") is now equivalent to Inspect.Unit.Detail("player.target").

    LAYOUT:
    * Added Layout:GetType(), which returns a string indicating the actual type of that layout or frame.
    * Introduced a new frame type "Element", replacing the old "FrameReadonly". Conceptually, Frame inherits from Element and Element inherits from Layout. Elements differ from Layouts in that an Element can have child Frames. Elements cannot be directly created by addons. Many of Frame's functions, as well as all of Frame's events, are provided in Element. The return values of RiftWindow's :GetBorder() and :GetContent() functions are now Elements.
    * Errors have been added for several common frame layout mistakes, including circular dependencies and NaN offsets.
    * Added RiftButton:SetSkin(), giving the ability to change the standard text button into a close button.

    BREAKING CHANGES:

    * Errors have been added for several common frame layout mistakes, including circular dependencies and NaN offsets. This may cause addons that previously accidentally functioned to break.
    * A restricted frame's events may no longer be changed while in combat.

    NONBREAKING CHANGES:

    * Added "1.6" as a valid environment.
    * Added "1.7" as a known, but not valid, environment.
    * Clean up stacktraces. Stacktraces will no longer include internal Rift functions. This process may not be completely reliable - please report any incorrect stacktraces.
    * Rendering CPU usage will now be credited to the owner of the context. This means that the reported addon CPU usage may increase significantly.
    * Security-related error messages will now have a header that refers to security, instead of the old parameter error message.
    * Many behavior improvements to RiftTextfield.
    * Deprecated functions and events will now say so in the documentation.
    * The .planar, .planarMax, and .vitality members of Inspect.Unit.Detail() are now available for groupmembers. The equivalent events will also now fire for groupmembers.
    * Inspect.Unit.Detail("player") is now guaranteed to return at least the player's name.
    * Text frames will now set their default size to perfectly fit their text.
    * Texture frames will now set their default size to perfectly fit whatever texture they have been set to.

    BUGFIXES:

    * Add documentation for the .ability member returned by Inspect.Buff.Detail().
    * UI.CreateFrame will now give a correct error message if called with an invalid frame type.
    * Fix misleading error message when passing nil for an event handler.
    * Frames with "limited" MouseMasking will now pass mouse events all the way through to the environment, not just to other frames.
    * Teleporting will now properly trigger messages indicating that the player unit is not available.
    * Fixed .role missing from raidmembers who are outside your group.
    * Slider handles will no longer become invisible.
    * Fix mouse events showing up with dramatically negative numbers when clicking an element inside a mask, then dragging outside the mask.
    * RiftTextfield:SetSelection(), with no parameters, will no longer cause errors.
    * RiftTextfield:GetSelection() will now properly return nil when there is no selection.
    * Improved the reliability of the Open Addon Directory button.
    * Fixed a memory leak caused by overwriting frame events without setting them to nil first.
    * Updated UI.CreateFrame() documentation to include all current frame types.

    DIFF:

    Code:
    Inspectors:
    	Inspect.Achievement.Category.Detail
    	Inspect.Achievement.Category.List
    	Inspect.Achievement.Detail
    	Inspect.Achievement.List
    	Inspect.Addon.Detail
    	Inspect.Addon.List
    	Inspect.Cursor
    	Inspect.Item.Detail
    	Inspect.Item.Find
    	Inspect.Item.List
    	Inspect.System.Secure
     
    Commands:
    	Command.Cursor
    	Command.Item.Destroy
    	Command.Item.Move
    	Command.Item.Split
    	Command.Tooltip
     
    Utilities:
    	Utility.Item.Slot.All
    	Utility.Item.Slot.Bank
    	Utility.Item.Slot.Equipment
    	Utility.Item.Slot.Guild
    	Utility.Item.Slot.Inventory
    	Utility.Item.Slot.Parse
    	Utility.Item.Slot.Quest
    	Utility.Item.Slot.Wardrobe
     
    Events:
    	Event.Achievement.Complete
    	Event.Achievement.Update
    	Event.Cursor
    	Event.Item.Slot
    	Event.Item.Update
    	Event.Mouse.Move
    	Event.Unit.Detail.Combat
    	Event.Unit.Detail.LocationName
    	Event.Unit.Detail.PublicSize
    	Event.Unit.Detail.Ready
    	Event.Unit.Detail.Tagged
    	Event.Unit.Detail.TitlePrefixId
    	Event.Unit.Detail.TitlePrefixName
    	Event.Unit.Detail.TitleSuffixId
    	Event.Unit.Detail.TitleSuffixName
     
    UI:
    	Layout:
    		Members:
    			GetType
    		Events:
    	Element: Inherits from Layout
    		Members:
    			GetAlpha
    			GetBackgroundColor
    			GetKeyFocus
    			GetMouseMasking
    			GetVisible
    			SetAlpha
    			SetBackgroundColor
    			SetKeyFocus
    			SetMouseMasking
    			SetVisible
    		Events:
    			KeyDown
    			KeyFocusGain
    			KeyFocusLoss
    			KeyType
    			KeyUp
    			LeftClick
    			LeftDown
    			LeftUp
    			LeftUpoutside
    			MiddleClick
    			MiddleDown
    			MiddleUp
    			MiddleUpoutside
    			Mouse4Click
    			Mouse4Down
    			Mouse4Up
    			Mouse4Upoutside
    			Mouse5Click
    			Mouse5Down
    			Mouse5Up
    			Mouse5Upoutside
    			MouseIn
    			MouseMove
    			MouseOut
    			RightClick
    			RightDown
    			RightUp
    			RightUpoutside
    			WheelBack
    			WheelForward
    	RiftButton: Inherits from Frame
    		Members:
    			GetSkin
    			SetSkin
    	RiftScrollbar: Inherits from Frame
    		Members:
    			GetEnabled
    			GetOrientation
    			GetPosition
    			GetRange
    			GetThickness
    			Nudge
    			NudgeDown
    			NudgeUp
    			SetEnabled
    			SetOrientation
    			SetPosition
    			SetRange
    			SetThickness
    		Events:
    			ScrollbarChange
    			ScrollbarGrab
    			ScrollbarRelease
    UPCOMING BREAKING CHANGES:

    * The titlePrefix/titleSuffix members of Inspect.Unit.Detail() will be removed. Use titlePrefixName/titleSuffixName instead.
    * Inspect.Event.TitlePrefix and Inspect.Event.TitleSuffix will be removed. Use Inspect.Event.TitlePrefixName and Inspect.Event.TitleSuffixName instead.
    * All GetDefaultWidth/GetDefaultHeight/GetFullWidth/GetFullHeight/ResizeTo* functions have been deprecated and will be removed. Frames now default to those sizes.

  15. #75
    Telaran
    Join Date
    Jun 2011
    Posts
    65

    Default SetPoint error?

    Came across this in my addon.

    Y Axis: An axis with a set size cannot have more than one unique set point.
    Anyone else get this error? I'm kinda puzzled by it.

    Code:
    cti.target.epbar:SetPoint("BOTTOMLEFT",cti.target.hpbar,"TOPLEFT")
    is what's throwing the error out of context.
    Thuggernaught / Isha / Adracamas

    Troll?
    /grin
    Kill it with Fire

Closed Thread
Page 5 of 24 FirstFirst 1 2 3 4 5 6 7 8 9 15 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts