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

  Click here to go to the first Rift Team post in this thread.   Thread: Addon documentation

  1. #61
    Soulwalker
    Join Date
    Feb 2011
    Posts
    5

    Default

    I have tried it on frames that only have backgroundcolor and are visible otherwise. If I use an alpha value in the backgroundcolor it works fine but not if i set it through SetAlpha.

  2. #62
    Telaran phoenik's Avatar
    Join Date
    Jan 2011
    Location
    Under your bed
    Posts
    83

    Default

    Quote Originally Posted by Luivatra View Post
    I have tried it on frames that only have backgroundcolor and are visible otherwise. If I use an alpha value in the backgroundcolor it works fine but not if i set it through SetAlpha.
    It's either a bug in implementation, or a mistype in the documentation.

    Frame:SetAlpha() bug:
    Code:
    local context = UI.CreateContext("Phoenik")
    
    local start = Inspect.System.Time()
    local prev = Inspect.System.Time()
    
    local duration = 10
    
    local framea = UI.CreateFrame("Frame", "FrameA", context)
    local frameb = UI.CreateFrame("Frame", "FrameB", context)
    
    framea:SetWidth(320)
    frameb:SetWidth(320)
    
    framea:SetPoint("TOPCENTER", UIParent, "TOPCENTER")
    frameb:SetPoint("TOPLEFT", framea, "BOTTOMLEFT")
    
    framea:SetBackgroundColor(1,1,1,1)
    frameb:SetBackgroundColor(0,0,0,1)
    
    local function transparencyTest()
    	prev = Inspect.System.Time() - start
    	local eval = 1 - (prev/duration)
    	framea:SetAlpha(100*eval)
    	frameb:SetBackgroundColor(0,0,0,eval)
    end
    
    table.insert(Event.System.Update.Begin, {transparencyTest, "PhoeniKDev", "transparencyTest"})
    Currently framea:SetAlpha() does not take in a multiplier, but rather it takes in a percentage. So the above code should have a fade effect of 10 seconds with each box fading out at the same rate.

    Try multiplying the alpha you want to set by 100 and see if that works for you (it should).
    Last edited by phoenik; 06-13-2011 at 10:16 AM.

  3. #63
    Soulwalker
    Join Date
    Feb 2011
    Posts
    5

    Default

    Hah nice find. I tried with high values like 150 in case it was a value ranging from 0-255 but that of course gave full opaque. That together with 1.0 resulting in opaque let me to believe it was bugged.

    It is a bit strange but at least it is working

  4. #64
    Telaran phoenik's Avatar
    Join Date
    Jan 2011
    Location
    Under your bed
    Posts
    83

    Default

    I'm wondering if this is intended behavior or not: If an addon already has a saved variable file created, if you introduce a new saved variable, it will set it to nil regardless of what is in your files for a default value.

    The way to catch is is to check Event.Addon.SavedVariables.Load.End, then set it to default values if it's nil.

    I'll try to explain this as best I can..

    Running an addon for the first time will create a file in SavedVariables/AddonName.lua, with the default values that are in our addon's code, for example
    Code:
    TestAddonSaved = "a"
    In an addon update, you introduce a new SavedVariable called TestAddonSavedB
    Code:
    TestAddonSaved = "a"
    TestAddonSavedB = "b"
    When the addon is loaded, instead of appending TestAddonSavedB to SavedVariables/AddonName.lua because it doesn't exist yet, it instead sets TestAddonSavedB to nil.

    So my question is, is not appending new SavedVariables to the addon's saved variable file intended behavior?
    Last edited by phoenik; 06-13-2011 at 10:35 PM.

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

    Default

    Quote Originally Posted by phoenik View Post
    I'm wondering if this is intended behavior or not: If an addon already has a saved variable file created, if you introduce a new saved variable, it will set it to nil regardless of what is in your files for a default value.

    So my question is, is not appending new SavedVariables to the addon's saved variable file intended behavior?
    Also a bug. Thanks again

  6. #66
    Ascendant ShalarLight's Avatar
    Join Date
    Mar 2011
    Posts
    2,852

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Here's a list of available functions, followed by the same list with extra documentation. Keep in mind that the addon system is a work in progress and the vast majority of the time spent so far has been spent on the framework, not the API. More functionality will be showing up as the system is improved.

    Rift API functions are self-documenting via Development.Documentation and will also dump their documentation if used incorrectly.

    Note that this is the exact output that is generated by the Trion Development Tools addon.

    Detailed function documentation is currently on Pastebin.
    awsome, been waiting for something like this, now to find the inspiration to make something from it.


    Quote Originally Posted by Rizaz View Post
    FYI Riftstalker running isn't even pve. .... You might as well call riftstalker running PVE.

  7. #67
    Rift Disciple
    Join Date
    Feb 2011
    Posts
    132

    Default

    I have some questions/feedback about the intended usage of some of the events.


    Specifically...

    1) Should we be loading our Saved Variables on the SavedVariables.Load.Begin or SavedVariables.Load.End events?

    On one hand it could be that the variables are loaded from the file starting at .Begin, but it doesn't complete until .End. If that were the case, then attempting to load Variables on the .Begin event would be incorrect. On the other hand it could be that Begin is the first time the variables have been loaded from file and it starts to run the handlers for loading and End is when all of the handlers are expected to be done.

    2) Same question for SavedVariables.Save.Begin or SavedVariables.Save.End.

    This one seems a little more intuitive, as writing out data at the end of savedVariables Saving doesn't seem right, but want to confirm.

    3) As a general rule, should we be attaching to the *.Begin events?

    4) If so, what is the intended use for the *.End events?

    5) What is the intended purpose of the Event.Addon.Finalizing event? When and how does that event get fired?

    6) What is the difference between Addon.Starting and Addon.Load ?

    7) Is Addon.Starting related to Addon.Finalizing?

    8) Can you tell us the proper sequence of Events that happens when an addon is loaded & started? In what order do those events occur?

    9) Should we be utilizing the Addon.Load event to do some first-load initializaiton? Or should we use Addon.Starting for that?

    10) When I keyed on the SavedVariables.Load.Begin event it fired 3 separate times when I did a /reloadui. I also had 3 total addons installed. Is that event being fired for each addon? If so, should we be filtering the event to our specific Addon? I only expect it to fire once, but that is not what I am seeing.
    "The only constant in all your failed warfronts is you."
    Malorn, Cleric of The Enclave

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

    Thumbs up

    Quote Originally Posted by Malvir View Post
    I have some questions/feedback about the intended usage of some of the events.


    Specifically...

    1) Should we be loading our Saved Variables on the SavedVariables.Load.Begin or SavedVariables.Load.End events?

    On one hand it could be that the variables are loaded from the file starting at .Begin, but it doesn't complete until .End. If that were the case, then attempting to load Variables on the .Begin event would be incorrect. On the other hand it could be that Begin is the first time the variables have been loaded from file and it starts to run the handlers for loading and End is when all of the handlers are expected to be done.

    2) Same question for SavedVariables.Save.Begin or SavedVariables.Save.End.

    This one seems a little more intuitive, as writing out data at the end of savedVariables Saving doesn't seem right, but want to confirm.

    3) As a general rule, should we be attaching to the *.Begin events?

    4) If so, what is the intended use for the *.End events?

    5) What is the intended purpose of the Event.Addon.Finalizing event? When and how does that event get fired?

    6) What is the difference between Addon.Starting and Addon.Load ?

    7) Is Addon.Starting related to Addon.Finalizing?

    8) Can you tell us the proper sequence of Events that happens when an addon is loaded & started? In what order do those events occur?

    9) Should we be utilizing the Addon.Load event to do some first-load initializaiton? Or should we use Addon.Starting for that?

    10) When I keyed on the SavedVariables.Load.Begin event it fired 3 separate times when I did a /reloadui. I also had 3 total addons installed. Is that event being fired for each addon? If so, should we be filtering the event to our specific Addon? I only expect it to fire once, but that is not what I am seeing.
    In general, Begin events are provided so that, if you need to do something immediately before the thing occurs, you can. The End event will follow immediately after and will be the first event after the thing occurs. In the case of SavedVariables you'll want to use the End event, as that will be the first opportunity after things have been loaded. I can't think of a reasonable use for either the SavedVariables.Load.Begin or the SavedVariables.Save.End events, but they're provided anyway just for completeness's sake.

    Most of the Addon.* events include the name of the addon as the first parameter, which is why they're being called multiple times.

    A few of these functions are being changed in the near future, so I'm describing what they will look like soon.

    The addon loading flow looks like this:

    Code:
    -- Addon.Startup.Begin() -- This event doesn't exist, because if it did, it would be triggered before any addon code, and would therefore be useless. But it conceptually does because there's an Addon.Startup.End().
    For each addon:
      Addon.Load.Begin(addon) -- Signals that an addon is about to start loading. If you want to hook functions in order to change the behavior of that addon, this is the time to do it.
      (All of that addon's files are loaded here)
      Addon.SavedVariables.Load.Begin(addon) -- Signals that SavedVariables are about to be loaded.
      (SavedVariables get loaded here)
      Addon.SavedVariables.Load.End(addon) -- Signals that SavedVariables have just been loaded.
      (If we add more loading stages to addons, they'll either occur here, or before Addon.SavedVariables.*)
      Addon.Load.End(addon) -- Signals that the addon has completed its loading sequence.
    Addon.Startup.End() -- Signals that all addons have completed their loading sequence. At the moment, this is Addon.Starting().
    
    (This is where the player plays the game)
    
    Addon.Shutdown.Begin() -- Signals that the addon system is about to be shut down. At the moment, this is Addon.Shutdown().
    For each addon:
      Addon.SavedVariables.Save.Begin(addon) -- About to save an addon's savedvariables.
      (SavedVariables get saved here)
      Addon.SavedVariables.Save.End(addon) -- Finished saving an addon's savedvariables.
    Addon.Shutdown.End() -- The last event sent before the addon environment goes away. At the moment, this is Addon.Finalize(). Also, at the moment, this is useless to hook since an addon can no longer do anything useful.

  9. #69
    Rift Disciple
    Join Date
    Feb 2011
    Posts
    132

    Default

    Very informative, brings a lot of clarity to the events and the load sequence. Thanks Zorba!

    The bit about the Addon* events all passing the Addon name as an argument was particularly helpful and got me to try something.

    So in my addon I use SavedVariables. I did a quick test by adding a SavedVariables.Load.End event handler to your buffbars and then when the handler fired I had it test for my addon's loading of saved variables. Then I changed my addon's saved variables through your addon...which means the saved variables are global. I had expected them to be local and only in the scope of the addon that used them.

    The result of this is that SavedVariables can be tapped by any addon, addons can modify other addons' state. Is this intended?


    (At any rate, I fixed up my addon to the Load.End instead of Load.Begin and filtered on Addon name for those events )
    "The only constant in all your failed warfronts is you."
    Malorn, Cleric of The Enclave

  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 Malvir View Post
    The result of this is that SavedVariables can be tapped by any addon, addons can modify other addons' state. Is this intended?
    Yes, it is. If anything, we're explicitly trying to make it easy for addons to access and modify each others' data. It's extremely useful (and, from a sheer practicality standpoint, near-impossible to stop), so we may as well make it convenient.

  11. #71
    Rift Disciple
    Join Date
    Feb 2011
    Posts
    132

    Default

    Cool, inter-addon communication is certainly easy in Rift. I foresee a library for easy inter-addon event handling in the not-too-distant future.
    "The only constant in all your failed warfronts is you."
    Malorn, Cleric of The Enclave

  12. #72
    Telaran phoenik's Avatar
    Join Date
    Jan 2011
    Location
    Under your bed
    Posts
    83

    Default

    Am I correct in assuming that UIParent:GetBottom() and UIParent:GetHeight() should return the height of the user's screen resolution?

    If that's the case there might be a bug as the value never goes below 1024. Is there something I'm missing?

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

    Default

    Quote Originally Posted by phoenik View Post
    Am I correct in assuming that UIParent:GetBottom() and UIParent:GetHeight() should return the height of the user's screen resolution?

    If that's the case there might be a bug as the value never goes below 1024. Is there something I'm missing?
    This is correct. And you're also correct in that it never goes below 1024. The game keeps the virtual screen resolution at a minimum of 1280x1024 (as I remember). If either size goes below that, it will simply downscale the UI to still believe it's at that resolution or higher.

    We may at some point add a pixel-locked UIParent.

  14. #74
    Telaran phoenik's Avatar
    Join Date
    Jan 2011
    Location
    Under your bed
    Posts
    83

    Default

    Good to know, thanks!

  15. #75
    Soulwalker
    Join Date
    Jun 2011
    Posts
    3

    Default Coder needed

    Hello gang,

    I was wondering if any knowledgeable coder here would be interested on taking on a project?
    We can discuss the details in private.
    Send me a PM

    Sincerely,

    Dimiana

Closed Thread
Page 5 of 15 FirstFirst 1 2 3 4 5 6 7 8 9 ... 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