At the start of the script kissassist would process plugins, their attach points, and their priority. The higher priority the earlier the code in that section would be ran. IE priority 10 or 100 would be ran before priority 0.
#Plugin <plugin name> [optional priority default to 0]
Here is an example plugin
Kiss would need to store plugins in a sub directory which could be parsed on startup and a command to add and remove a plugin or perhaps a plugin section in individual ini files.
Attach points could be like Mainloop, Zoned, Medding, Buffing, CreatePet Healing, Burn, Dps, Moving, CombatStart, CombatLoop, CombatStop, Slain, GainedExp, Resurrected, Death, Leveled, Tell, Guild, Raid, Group. And any others that you want to create. Once the skeleton is created kiss could then add functionality the same way. What I am describing would set up a standard skeleton at the core that would allow plugin programmers to take advantage of kiss to expand it's functionality without having to modifiy the core software.
The reason for the request is each time a new version of Kissassist comes out I have to make over a dozen edits to the script in order to add custom modifications I have made to my client. This system would allow these to be independent of the core software and would also likely result in performance increases for the macro overall.
What do you all think?
#Plugin <plugin name> [optional priority default to 0]
Here is an example plugin
Code:
#Plugin Mobwarn 0
#attach {
CombatLoop {
/if ((${Select[${Zone.ID},799]}) && (${IAmABard})) {
/call MobWarn rs "a pool of corrupted blood" 180
/call MobWarn rs "living corrupted blood" 180
}
}
MainLoop {
/if ((${Select[${Zone.ID},814]}) && (${IAmABard})) {
/call MobWarn g "a skyash drake" 400
/call MobWarn g "a skyfall drake" 400
/call MobWarn g "a skycinder drake" 400
} else /if ((${Select[${Zone.ID},792]}) && (${IAmABard})) {
/call MobWarn g "a cinder skywing" 250
}
}
}
Sub MobWarn(string method, string mob, int radius)
/if (!${Defined[IsClose${Spawn[${mob}].ID}]}) /declare IsClose${Spawn[${mob}].ID} bool outer FLASE
/if (${SpawnCount[${mob} radius ${radius} zradius ${radius}]} && !${IsClose${Spawn[${mob}].ID}}) {
/varset IsClose${Spawn[${mob}].ID} TRUE
/if (${method.Equal[rs]}) {
/rs >>> Warning! <<< ${mob} is near the raid!
} else /if (${method.Equal[g]}) {
/echo Warning! ${mob} is near the group!
/beep
/beep
/beep
}
} else /if (!${SpawnCount[${mob} radius ${radius} zradius ${radius}]} && ${IsClose${Spawn[${mob}].ID}}) {
/varset IsClose${Spawn[${mob}].ID} FALSE
/echo \ag${mob} has moved out of range!
}
/delay 5
/returnKiss would need to store plugins in a sub directory which could be parsed on startup and a command to add and remove a plugin or perhaps a plugin section in individual ini files.
Attach points could be like Mainloop, Zoned, Medding, Buffing, CreatePet Healing, Burn, Dps, Moving, CombatStart, CombatLoop, CombatStop, Slain, GainedExp, Resurrected, Death, Leveled, Tell, Guild, Raid, Group. And any others that you want to create. Once the skeleton is created kiss could then add functionality the same way. What I am describing would set up a standard skeleton at the core that would allow plugin programmers to take advantage of kiss to expand it's functionality without having to modifiy the core software.
The reason for the request is each time a new version of Kissassist comes out I have to make over a dozen edits to the script in order to add custom modifications I have made to my client. This system would allow these to be independent of the core software and would also likely result in performance increases for the macro overall.
What do you all think?
Last edited:
