1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

[Suggestions Welcome] An explanation of the Summoning API

Discussion in 'Announcements' started by Cloud, May 15, 2014.

Thread Status:
Not open for further replies.
  1. Cloud

    Cloud Engineer

    Joined:
    Jul 28, 2013
    Messages:
    2,777
    Likes Received:
    1,124
    Traditional Summoning API's are rather self contained. They include a Summoning class and a Familiar enum, and then have support methods such as Summoning.getFamiliar or Summoning.getSummonedNpc. I've decided to take a modified approach that was influenced by it, but also expanded the concept.

    There is still a Summoning class and a Summoning.Familiar enum, it contains various data related to each type of familiar.

    This is where things begin to change, instead of having a method like Summoning.getSummonedNpc, I've added an entire Familiars class similar to what I did with banking. This class includes methods such as getLoaded(), getLoaded(Summoning.Familiar... types), and getLoadedWithin(Area, Summoning.Familiar... types). These methods will return all loaded familiars that meet the given conditions.

    Here's the next twist, instead of just returning a list of Npcs, these methods return a list of SummonedFamiliar. The SummonedFamiliar class extends Npc, so you have all the visibility, interaction, and other information available, but it also adds a getInfo method which returns the Summoning.Familiar instance for this type of familiar. New summoning familiar exclusive methods will likely also be added in the future.

    You can also determine which familiar belongs to which player in an extremely easy way. The Player class now contains a getFamiliar method, so you can easily call Player#getFamiliar to find it. This works for all players, including your local player (the alternative was a Familiars.getBySummoner(Player) method).

    Information regarding your familiar that isn't available for other familiars will still be included in the Summoning class, however I've yet to decide the implementation details for it just yet, however expect a clean implementation.

    Suggestions are welcome as always, especially in regards to the names of the methods. I hope you guys will enjoy it :)
     
    Viewer and Black Fire like this.
  2. Arbiter

    Arbiter Mod Automation

    Joined:
    Jul 26, 2013
    Messages:
    2,938
    Likes Received:
    1,266
    The Player <-> Familiar relationship should be bi-directional; one should be able to identify a Player's Familiar (Player#getFamiliar) and vice versa (Familiar's Player). Thus I'd like to suggest/ensure the creation of something along the lines of Familiar#getPlayer (of course modified to fit the structure).
     
  3. Salvation

    Salvation First Bot Author

    Joined:
    Aug 7, 2013
    Messages:
    262
    Likes Received:
    68
    The problem lies where familiars rarely show as the interacting entity. When in combat (or even better: the familiar's in combat), how would you get the player? You'd have to at least cache a lot of entities it interacted with and return the most-frequent entity that is a player to know the player that summoned it =/
     
  4. Cloud

    Cloud Engineer

    Joined:
    Jul 28, 2013
    Messages:
    2,777
    Likes Received:
    1,124
    The only time I wouldn't be able to identify it is likely when the familiar is in combat, in almost all other situations I can map it to a player. It would have at-least the same reliability that all other clients have in regards to mapping familiars to players, but it will probably be higher.
     
    #4 Cloud, May 16, 2014
    Last edited: May 16, 2014
Thread Status:
Not open for further replies.

Share This Page

Loading...