khabalox wrote:
That makes sense - I can see the advantages (although I thought I read somewhere that it is recommended to only have one onCampaignLoad() as having multiples can sometimes produce unexpected results).
My understanding is that this is because there's no reliable way to know in which order the onCampaignLoad macros will run when the campaign loads. Thus, you can't write each onCampaignLoad expecting another one to run beforehand. You could force things into a particular order by having a single onCampaignLoad macro that calls macros on other lib:tokens to load their stuff in a particular order, but then they would no longer be "stand-alone".
This shouldn't be a problem if each lib: token is defining different functions in a way that is not dependent on other functions (running them can be dependent, but as long as you are just defining them, that's not a problem).
Note that you can do other things in OnCampaignLoad besides defining functions: this is where I load a default language library into lib:token properties, for example.
khabalox wrote:Does your way mean having duplicated macros on multiple Lib:tokens?
Absolutely Not. See below.
khabalox wrote:
How do others usually organize their Lib:tokens? Is having multiple onCampaingLoad() functions a problem? Even if they are defining functions of the same name on different tokens?
I have one Lib:token with generic utility functions (
debugging,
math, json manipulation, etc.), another with the core system mechanic (d20, Pathfinder, Fudge, etc.), though this could certainly be split up into things like
Inventory, Combat, or other largely independent aspects of the system. I'm also thinking of putting together another one for time keeping (effects during inititiative as well as a campaign calendar). So, each lib:token is essentially independent of the others, although they just about all use functions defined on Lib:Utilities, though the onCampaignLoad macros are simple enough that they can run in any order without running into problems.
The point is that by using mostly UDFs (User-defined functions), those lib:tokens can have just about any name, and it won't matter. Having duplicates of such tokens would be a problem, because they are trying to define the same thing multiple times (this can be really problematic with
Wiki: oldFunction() ). But, why would you intentionally have duplicate lib:tokens, or define the same function in multiple places?