[cloud]

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

 

[arbiter]

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).

 

[salvation]

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 =/

 

[cloud]

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 =/

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.