Closed Thread
Page 3 of 15 FirstFirst 1 2 3 4 5 6 7 13 ... LastLast
Results 31 to 45 of 223
Like Tree9Likes

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

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

    Default

    Quote Originally Posted by hp94 View Post
    Zorba, I can't remember where you said this, but I remember you were asking for 'official' suggestions for API/functionality. I would personally like to see an AddOn Channel that lets AddOns use a psuedo hidden channel for 'talking' to each other, and "RunScript(script)" command. And, perhaps, a way to play music from sound files in the AddOn folder.
    We're not asking for official suggestions yet, we've got a long enough TODO queue that we don't really need them If you want to post suggestions, we recommend using one of the main forum threads, but note that we already have many things planned and anything outside those plans may take some time to be implemented.

    That said, your "RunScript" idea is already provided as part of base Lua, under the name "loadstring".
    Last edited by ZorbaTHut; 06-08-2011 at 03:18 PM.

  2. #32
    Champion
    Join Date
    Jan 2011
    Posts
    517

    Default

    Quote Originally Posted by ZorbaTHut View Post
    I've actually been using this name for something like fifteen years now
    I'd have to look at the copyright on the book to see if Zorba was mentioned in SW lore before you chose it!

  3. #33
    Rift Disciple
    Join Date
    Feb 2011
    Posts
    101

    Default

    Are addons gonna be allowed to pull data from combatlog? making it possible to have in-game parser, or are you happy with the current 3rd party parsers?

  4. #34
    Soulwalker
    Join Date
    Jan 2011
    Posts
    14

    Default

    As soon as I saw the API announced my mind ran directly towards DKP addons as I feel in-game DKP management is one of the major challenges most guilds face.

    I started mocking up some ideas and it lead me to a question. Would you consider allowing the API to write messages to chat/combat logs? Having a way to export the DKP info in real time would be a huge help.

    I wrote my own DKP management addon very early on in vanilla wow and the biggest issue I ran into was not being able to persist the information to a more stable environment than the game. Any time WoW would crash I would lose any in memory information about the current raid.

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

    Default

    Quote Originally Posted by Daragust View Post
    I started mocking up some ideas and it lead me to a question. Would you consider allowing the API to write messages to chat/combat logs? Having a way to export the DKP info in real time would be a huge help.

    I wrote my own DKP management addon very early on in vanilla wow and the biggest issue I ran into was not being able to persist the information to a more stable environment than the game. Any time WoW would crash I would lose any in memory information about the current raid.
    This is already doable in a somewhat hacky sense - results from print() will go to the chat log, if it's turned on. I'm mulling over a better solution but it may take quite some time for it to become a priority.

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

    Default

    Quote Originally Posted by Daragust View Post
    As soon as I saw the API announced my mind ran directly towards DKP addons as I feel in-game DKP management is one of the major challenges most guilds face.

    I started mocking up some ideas and it lead me to a question. Would you consider allowing the API to write messages to chat/combat logs? Having a way to export the DKP info in real time would be a huge help.

    I wrote my own DKP management addon very early on in vanilla wow and the biggest issue I ran into was not being able to persist the information to a more stable environment than the game. Any time WoW would crash I would lose any in memory information about the current raid.
    A combination of chat logging [with print("DKPer:" .. intDKP) ] and an external chat log parser to look for any lines starting with "DKPer:") would do the trick, until or unless Trion offers AddOn logging capability (which could be dangerous if not controlled properly).

    Edit: now that I think about it, saving DKP to SavedVariables should work (once they enable saving variables) to keep a more permanent record. An external app could still be used for processing the SavedVariables for the AddOn, similar to how Wowhead processes tons of information from thousands of users.
    Last edited by Aieny; 06-09-2011 at 08:38 AM.
    a community-oriented site for all things Rift

  7. #37
    RIFT Fan Site Operator
    Join Date
    Mar 2011
    Posts
    35

    Default

    @Aieny:theres no point writing stuff like that to the chat log when you could just stick it in a data structure and just wait for the SavedVariables functionality to work, as that would be alot easier to deal with and have the same functionality of storing data from in game
    Creator of RiftDB.com

  8. #38
    Shadowlander diidnath's Avatar
    Join Date
    Mar 2011
    Posts
    30

    Default

    Quote Originally Posted by sanktanglian View Post
    @Aieny:theres no point writing stuff like that to the chat log when you could just stick it in a data structure and just wait for the SavedVariables functionality to work, as that would be alot easier to deal with and have the same functionality of storing data from in game
    We're looking for a solution more persistent than the SavedVariables store (perhaps in addition to, rather than instead of, the saved variables storage); that's likely going to be written to at most on every UI reload or zone change. What happens when the boss dies, loot gets distributed, and you get a crash to desktop? With realtime logging, you'd at least have a journaled account of your DKP spend/acquisition/etc.

  9. #39
    RIFT Fan Site Operator
    Join Date
    Mar 2011
    Posts
    35

    Default

    im not 100% sure, but i didnt think the chat log output was on demand, i thought it only output to the file when you logged out/off, could be wrong though havent tested it specifically myself
    Creator of RiftDB.com

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

    Default

    Quote Originally Posted by sanktanglian View Post
    im not 100% sure, but i didnt think the chat log output was on demand, i thought it only output to the file when you logged out/off, could be wrong though havent tested it specifically myself
    I'd have to do more testing, but I'm pretty confident the chat log is written to the file similar to the combat log. A crash-to-desktop might prevent the last bit from being saved to the log file (buffered data not written), but that's easy to fix by just turning off chat logging as soon as everything is finished, since that'll force a buffer flush and close the chat log file.

    What I was proposing above was similar to the current combat log parsers, only doing so with DKP data. The raid leader, raid assists, or any raid member could run the AddOn, turn on chat logging at the beginning of the raid, then the external parser would extract anything from the chat log that started with a key phrase (the "DKPer:" in my example above) and display information based on what the in-game AddOn posted to the chat log.
    Last edited by Aieny; 06-09-2011 at 12:18 PM.
    a community-oriented site for all things Rift

  11. #41
    Soulwalker
    Join Date
    Mar 2011
    Posts
    7

    Default

    I had a chance to hop on the PTS today for the first time to take a peek at the framework of the addon API and it looks like it's coming along nicely. I'm also happy to see we've a nice core of people following it closely. I know one of the big things people wanted in the addon API for other games was the ability for addons to be able to communicate with the web. Obviously there are major security risks involved in a system that allows this, but I was wondering if there was any plan to implement something like that?

    Perhaps even just a 1-way communication model that could submit data to a url/port and not look for or accept a response. I know there's a lot of people (players and otherwise) who would like to see a web/remote application being able to accept live in-game data. There's a lot of pros that could come with a system like that, but imagine the wonders of 2-way communication. A site like guildlaunch specific to RIFT where you can log onto your guild's site from a computer or smart phone and chat with them in-game even though you can't be on RIFT at the present time. A guild leader could watch the raid activity in real-time on the website, or on a smartphone, even though he's not there in-game.

    A system like that would also provide the ability for in-game & web-based DKP-type management systems that can span both without the need to generate files that have to be uploaded/downloaded to/from the website to keep things in sync. No need to download and run potentially insecure EXE files that are meant to "sync" your data for a specific addon.

    I noticed that you guys are requiring addon developers to include an email address in their addon in case you wish to contact them. Perhaps you could provide an apple-like system to "secure" a domain that the addon can post to? You provide a system by which a player with a valid Trion account can generate a url "certificate" like an SSL cert for an addon. The user would have to verify domain/server/site ownership by creating a file called trion.txt at the root of the site and paste a validation key into it. Then click the link to confirm where your server could access the url, verify the key, and link that domain to the user's account. At this time it would generate a secure "certificate" the user can include in their .toc file configuration. The certificate can be decoded by the client and will enable that addon to communicate with any URL under the domain name encoded into the certificate. Each addon can only use 1 URL, but multiple addons can use the same URL.

    The communication to the URL would not be direct from the user's system. Instead the communication goes through a portal run by you guys. The addon sends data to your server which then relays it based on the addon's certificate. In this way the user's IP is never exposed to the addon developer's server eliminating potential for IP address-related security breaches on the user's end. Trion's addon server would be an authenticated proxy protecting the user, while enabling the addons to communicate with a web-based service. This way the addon developer could implement security on their web application as well by restricting access to their gateways to only originate from Trion IP addresses.

    As an additional/alternate possibility, the developer could be required to register their addon with you in order to enable communication. Your server could take a hash of the addon as a whole and use that as a basis of comparison to make sure that the communications from various game clients is in fact coming from the addon. Each additional version would have to be re-registered and a new hash taken. Additionally this system could provide the user a cipher/key that your server will use to encode data being sent to the addon's gateway(s) running on the developer's server. This hashing/cipher/key addition would provide the security needed for the addon developer's server to "trust" the data it received.

    This would eliminate the need for the url "certificate" to be presented in plain text in the TOC file. All in all I think this is something that could drastically improve addon functionality. I know the typical groaning responses to this issue are centered around data mining, reverse engineering spawn points, loot tables, etc. Fact of the matter is that will happen with or without addon->web communication. RIFT is dynamic enough to combat the "revelation" of it's content structure. Why not let the game's addons be equally dynamic?

    Sure someone will make a "wowhead" that runs in-game and tells players where to get the item they're hovering over while inspecting someone else. Let's not forget that even without web communication, that was achieved in world of borecraft. Once they have the data, it's only a matter of packaging it with the addon at which point regular addon updates emulate the connection to the web directly.

    Anyway that's just my evening rant on the concept. I know that sounds like a lot of work, and it is, but the end result would enable a whole new world of possibilities for the addons and the game.

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

    Default

    Quote Originally Posted by Aerewen View Post
    I had a chance to hop on the PTS today for the first time to take a peek at the framework of the addon API and it looks like it's coming along nicely. I'm also happy to see we've a nice core of people following it closely. I know one of the big things people wanted in the addon API for other games was the ability for addons to be able to communicate with the web. Obviously there are major security risks involved in a system that allows this, but I was wondering if there was any plan to implement something like that?
    This is a very good detailed post on a subject I've thought about as well. I personally like the idea, but as you say, there are major potential security issues, and fleshing out the main API is much higher priority. We'd also have to seriously consider the possible effects on gameplay, which would be quite extensive.

    I plan to revisit this idea in detail later on, but right now it's very far down on the TODO list. And note that this is neither a guarantee that it will happen nor a guarantee that it won't - it's buried in the realm of "I don't know yet".

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

    Default

    The new PTS build has a few new features. Here's the additions:

    Code:
    Inspectors:
    	Inspect.Ability.Detail
    	Inspect.Ability.List
    Events:
    	Event.Ability.AvailabilityChange
    	Event.Ability.Cooldown.Begin
    	Event.Ability.Cooldown.End
    Inspect.Buff.Detail includes a new .icon member, giving the filename of the buff's icon. Texture has gained some major performance and memory improvements and will now also resize textures based on the frame size. Finally, this build includes SavedVariable support, and I'll be posting an addon with example code shortly.

    Edit: Just remembered a bit more. The "unit specifier" used to only support "player", "player.target", "player.target.target", and so forth. It's gained some capability in this patch.

    It can now start with:

    player
    focus
    mouseover
    group01 through group20

    Modifiers now include:

    .target
    .pet
    .owner

    So, yes, if you want, you can do group03.pet.target.target.owner, and if the pet of your third groupmember is targeting something which, itself, is targeting someone's pet, then you'll get the owner of that pet.
    Last edited by ZorbaTHut; 06-10-2011 at 12:44 PM.

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

    Default

    oh so sexy

  15. #45
    Rift Disciple
    Join Date
    Feb 2011
    Posts
    163

    Default

    Sweet, more detail docs too!

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