Just trying to revive an old add... need a little help
Not sure what all has changed, but i was trying to revive my old level announcer addon, and i haven't really touched it since probably BC... anyways... For the most part most of my functions work... I just dont know why i cant access global variables any more.. havent kept up with that.
simple lua file
if i run the functions in wow doing /run GLUA_XXX most of them work. Only thing is OnEvent when its actually called by game (I simply call it /Run GLUA_OnEvent("player","PLAYER_LEVEL_UP); it doesnt error) where when its auto called im getting:
1x [ADDON_ACTION_BLOCKED] AddOn 'GLUA' tried to call the protected function 'UNKNOWN()'.
!BugGrabber\BugGrabber.lua:519: in function <!BugGrabber\BugGrabber.lua:519>
[C]: in function `SendChatMessage'
GLUA\GLUA-220.127.116.11.lua:70: in function `GLUA_Message'
GLUA\GLUA-18.104.22.168.lua:115: in function `GLUA_OnEvent'
[string "*:OnEvent"]:1: in function <[string "*:OnEvent"]:1>
This is the new go to place for API help for WoW
I would suggest looking at some small recent addons to see how things are coded now to give you a start and then slowly relearn some of the addon stuff thats still hidden somewhere in your programming memory :)
What I find useful is to create a template addon so to speak that has the pure basics and then build any specifics into it for any addon I want to write.
This is a simple addon template that nearly all of my addons have used as their starting point. Feel free to utilise yourself if you want.
Thanks appreciate that. With covid and free time im looking to get back into coding. Its just hard trying to find a good source.
Just out of curiosity what does the frame in your template do? Is that like a wrapper for the code? And your functions are just kind of listening?
Other question is if you look at my list of quotes they used a global variable previously but it doesnt seem i can update say lvl, without doing it like i am. Which i dont think is a problem, but im trying to figure out how i woulm thanks
Yes its an invisible frame that handles event management.
It can easily be replaced with a visual and functional frame.
UnitLevel("player") will only work after the Player has Logged into the game so the PLAYER_LOGIN or PLAYER_ENTERING_WORLD event will give you access to the players level, so adding 1 to a nil value could cause an error or set it to 1 or keep it at nil ( I've never tried +1 on a nil value ). The UNIT_LEVEL event will allow you to track the changes when they happen. Just use arg1 of the events parameters rather than UnitLevel("player") in the UNIT_LEVEL event code.
So i still have to be doing something wrong... when i call EventWatcher (/run EventWatcher("PLAYER_LEVEL_UP");) i get the message as i am supposed to. I can see the addon loaded, etc.
My problem seems to be when i call my GLUA_Message function, which calls to my table and randomly picks a quote, then says to send that message to self, party, bg, raid, and guild if in one. im getting the protected function unknown.... So from looking at your link it spears SendChatMessage is a protected function now...
Because i can get it to print "Player Leveled up = PLAYER_LEVEL_UP. meaning i get to line 121 of my code . I can add print("calling SendChatMessage with "..quote_to_share.." on channel number "..chan_number.."!") to line 126 unter ocal chan_number=GLUA_Channel() and see that its call the quote and level properly, just cant send the chat message. and by adding print(quotes) and print(channel) i can see that it passes the correct values to it..
The only thing i can think is that Locals:InCombatSkipped in the error, may not be letting me pass it to a secure function.. i guess i would need to check out of combat?
SendChatMessage needs a hardware event (key press or mouse click) for the SAY channel (and YELL but you're not using that). It cannot be called from code just based on an event or some other condition.
The code you have should work OK for Party, Raid and Guild shoutouts... for now, as those channels don't require the hardware event..
You are duplicating some areas .. You have your GLUA global table which has its own frame which has an event watcher .. so rather than call the event watch function I gave you as a template you can just use your own event watcher function.
Also, as a side note. Unless you want other addons to use GLUA in their own addons you can make GLUA either local or a part of the addonData table which is just for your addons.
The following is why I use local and addon wide values and rarely use globals.
If you don't have these functions as local functions you could break addons that have similar names in their *global* function names and you could be overriding their functionality with yours.
If the functionality/data is only needed in the file local is the best situation.
If the functionality/data is needed across your whole addon and you want more manageable files you can split your files up and have different types of functionality stored in different files and all share the same data.
EG. Translation Files
This could be your enUS translate file
This would be one of your foreign languages
Just rinse and repeat your supported languages with your chosen default as the main translation file and any supported in additional files.
The addonData.Locale is set in the main translation file and is accessible in all files loaded after.
Your main code then only has to call addonData.Translate["Translate Key 1"] for this example and it will automatically pick the correct language for the user if it is supported or fall back to the default language.
This multi file system relies on loading order to work properly so you will have to identify which files need to be loaded before another one so that any functions/values etc are in the addons memory before they are called.
So to reiterate...
You have global values/functions that are accessible by any addon and could inadvertently override another addons functionality or break it altogether.
You have addon wide values/functions that are accessible by the addon it is placed in. Think of it as local to your addon rather than local to a file/function etc.
You have local values/functions that are only available in the confines of the code blocks they are used in. Either a file wide local value or a function wide local value or even a loop wide local value.
Local values are always your best option if you only want that block of code to access it.
Addon wide values are your next best option if you want those values accessible amongst multiple files in a bigger or more manageable addon.
Global values should only be used if you intend to override a functionality in another addon or blizzards own functionality. Bear in mind that unless these were intended to be overridden you may have unintended problems.
In my latest addon project I intend to have global functions with unique names that will allow other addons to be plugins to my addon project to modify certain elements.
So I would have a bunch of *untouchable* local or addon wide functionality and then a global function say for example :
This could be used for example to allow users of your addon to create translation plugins to your addon that will be accessible by your addon via their addon registering their data for your addons use. Or to replace the layout of your addons default UI with one that think would work better for themselves and other people.
|All times are GMT -6. The time now is 05:19 AM.|
vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI