LUA Framework needed

While it is exciting that Lua is being integrated into SOTA, I'm worried about it being done in a hodge-podge fashion without a lot of detailed thought on how it should look/behave structurally.

For example, today I see this tweet:

This appears to mean that modular design/packaging is not being considered. What do I mean by that? It should be possible to write an entirely self contained LUA addon and deploy it in its own sub folder in the lua location. For example:

datafolder/lua/NewCraftingUI
datafolder/lua/InventoryUImanager

In the above theoretical examples, I have two addons installed, one named "NewCraftingUI" and another named "InventoryUImanager". These addons are fully self contained, and all lua, etc, is contained within them.

I touched on this some at https://www.shroudoftheavatar.com/forum/index.php?threads/lua-requests.160033/page-2#post-1265823 as well.

Additionally hopefully some thought will be put into making some default objects global, similarly as is done with WoW. For example, the "player" unit object should be directly accessible and usable. For example (again with WoW), you can do things like:

UnitName("player") to get the name of the player or
local mapID = C_Map.GetBestMapForUnit("player") to find what map the player is in, etc. In both these cases, "player" is a global provided via Blizzard.

Also, there needs to be a way to enable/disable specific mods. Again, this is a default part of the WoW interface when you log in -- You can pull up a list of all the lua addons you have installed, and selectively enable/disable them as needed.

 

@Chris Hope you will read this. And even maybe add a few hours just getting familiar with how other games have solved these issues, since it's not just about having Lua support. It's about supporting Lua in a sustainable way for players and the game.

 

I would like to track these issues separately.

The issue of being prepared to launch a given feature to QA is a complex one, tied up with the history of the project, player expectation of response to their requests, the very individual tolerance (or lack of tolerance) for ambiguity. I think it is fair to say that this project is well down the path of launching first, and learning from what they toss out. I'm not sure how much we will be able to walk that back, or even to what extent we should. We can fill a forum with the differing viewpoints that apply to our shared endeavor here. I do think we should do more to improve the quality of the systems we see released. I just do not want to try to tackle that subject in a forum dedicated to LUA. The folk that are here are already committed to the feature.

I think naming exposure to constant static data "global" is an unfortunate anachronism in WoW. We do not have to name it that, but it does look like we are getting a number of those things exposed. The key takeaway for me is that it is important to differentiate between static and dynamic data.

To the final issue, i do think we both can and should immediately review and lay out priorities for the features other online projects have learned work. From WoW and ESO the two most important are user control over script registration as Mishikal mentions, and some sort of version mechanism to flag and exclude out of date scripts. As an engineer with many years experience crafting libraries and APIs i strongly suggest the API be versioned, and that the version mechanism expose breaking changes in the API from as early a stage as possible.