Hi,
Say I have for example:
- \Plugins\Author_1\Plugin_1\Fil e_1.lua <and other .lua files>
- \Plugins\Author_1\Plugin_2\<mo re .lua files>
- \Plugins\Author_2\Plugin_3\<mo re .lua files>
- \Plugins\Author_3\Plugin_4\<mo re .lua files>
Can I make a function in File_1.lua available to all other .lua files?
I've tried following Garan's tip regarding the use of __int__.lua files but haven't been able to figure it out.
Any advice please?
Yes and no. There are two separate issues with regard to environment and variables, Apartments and Environments. This is touched upon in the Noobs thread in the sample "It's my Party and I'll cry if I want to... ", https://www.lotro.com/forums/showthr...12#post5839512, and the later discussion with Astleigh about the Unload event handler.
An Apartment is an entire instance of a Lua implementation in LotRO with one or more plugins loaded. There can be multiple simultaneous Apartments, allowing a plugin author to specify which plugins share the Apartment. Each Apartment contains its own copy of the Lua _G global environment and all of the Turbine shared objects. When unloading plugins, you don't unload an individual plugin, rather you unload an entire Apartment. So, two plugins that are in the same Apartment have access to the same global environment and thus access to all of the objects that exist within that environment but plugins in different Apartments can not access anything from the other Apartment. The Apartment that a plugin uses is defined by the Apartment property of the Configuration tag in the .plugin XML file.
The second issue has to do with Environments which is more of a scoping issue and can be resolved by understanding the structure of the Lua namespace. Lua allows threads to specify which Environment they run in, that is what is the root namespace for their variables and functions and the Environment can even be dynamically changed at runtime using the setfenv function. In LotRO, each plugin natively runs functions in the _G.username.pluginname where username is the directory that contains the .plugin XML file and .lua files and pluginname is the name of the plugin from the .plugin XML file. So, AltInventory runs in the _G.GaranStuff.AltInventory environment. All variables and functions (remember, functions are stored and referenced as tables) created by a plugin thus automatically inherit the _G.username.pluginname namespace unless specifically assigned another. So, there are two ways to reference something between plugins, either assign it as a global by specifically creating it as "_G.myfunction" which can then be accessed as "myfunction" or _G.myfunction (by any plugin in the same Apartment) or reference the function using it's fully qualified name - Plugin_1 by Author_1 referencing "myfunction" in Plugin_2 by Author_2 would use _G.Author_2.Plugin_2.myfunctio n to reference the function. Note, you have to be sure the function is defined before attempting to reference it or you will get an error so it is fairly important to control the loading order of the plugins or add a conditional test like:
See http://www.lua.org/manual/5.1/manual.html#2.9 for more info on Lua Environments.Code:if _G.Author_2~=nil and _G.Author_2.Plugin_2~=nil and _G.Author_2.Pluigin_2.myfunction~=nil then
_G.Author_2.Plugin_2.myfunction()
else
Turbine.Shell.Writeline("Error: Author_2.Plugin_2 not available")
end
If you have ever accessed the Debug window in any of my plugins you will see an example of the setfenv function at work. There is an Environment option in the top section for specifying whether to run the code snippet in the Global or current plugin environment. The treeview at the bottom of the window demonstrates sharing info between plugins by displaying all of the plugins (and their objects) in the same Apartment. You can even set watch values for variables in other plugins (in the same Apartment) in the middle section.
Hi Garan,
Essentially, I've been trying to create a simple debug routine so I can output a plugin's variables/tables to the chat window, and after re-investigating the usage of __init__.lua I found a solution for myself using Galuhad's code (though I'm not entirely satisfied with my adaptation).
Regarding your debug window and associated plugins and my coding, I have other questions to ask and will post in the appropriate forum threads.
Thanks again.