Scorpio A new addon framework
Scorpio is my new addon framework, its non-ui part is finished, so I can share it now.
I have some posts about changing code environment, in the Scorpio, I had provide some special code style based on the environment control like : Lua Code:
You can find more details in the Page. Here is an example addon : Enhance BattlefieldMinimap |
Quote:
Considering you're developing this since 2009 and still have no other addons using it, that gives me some doubts. |
Quote:
If you means IGAS, I should say, it's very powerful(Take the IGAS_UI's Action bar as example), but too heavy for others. The first step is learning the PLoop, it is a poweful OOP System with plenty features, but not many authors will try it - Addon is too simple, why should I learn a language that I won't use in other places. Besides the PLoop, there are more than 200 features defined in the IGAS, it also make it hard to learn. There are still some authors using it in China, but since they don't share, there is nothing to talk about. Since the IGAS is developed a long time ago, I decided to create a new frame work. In the Scorpio, I try to hide the details and provide those features directly. I'll still introduce the PLoop System with many widgets from the IGAS, but with a more smooth way. So in the non-ui part, You'll only see some attributes like __Async__, __SystemEvent__, but won't care whats behind it. BTW. Since the register and handle are bound together, it's clearly the code should be more readable. You also may find some useful tools to simple the code in the Task scheduling system, it provide some simple ways to using the threads. |
Hi kurapica.igas,
Just to let you know, I am not sure if this is because I am using a super old desktop with Windows XP installed on it (not my PC), but those images on IGAS page aren't showing properly. (I could just manually look at those images tho...) Could you please check that out please? Thank you. EDIT: Had a look with my mobile, but images aren't showing on it as well. |
Quote:
https://wow.curseforge.com/projects/igas/images And the introductions in http://wow.curseforge.com/addons/igas/forum/ has all been remvoed through the updating. It's hard to recover them. Since I'm moving to the Scorpio, the IGAS'll be abandoned when the Scorpio is finished, all features in IGAS will be re-designed or moved to the Scorpio. And the learning curve should be more smooth in the Scorpio, you can stop whenever you want and may still enjoy some features of it. |
That's interesting to hear!
Few questions here. 1. Could PLoop and Scorpio be embedded into an addon like other libraries instead of being separated? (I think I've seen your words talking about this, but not quite sure :confused:) 2. Any estimated time plan for those ui parts being completed? Thank you. |
Quote:
The PLoop & Scorpio are designed to be platforms, there are big files and many features defined in them, so the cost can't be ignored if I made them as embed libs, (you still can make embed libs based on Scorpio). Also the curse app will download your addon's dependencies automatically. The UI'll be released within several parts :
Well, if you are interesting, in the 2009, I also created an IDE https://wow.curseforge.com/projects/igas_studio/images, although I abandoned it very soon, when I turn my interesting into the PLoop. After the Scorpio, it may be my next project. |
So, you are saying that PLoop and Scorpio could still be embedded like other libraries, but is not recommended due to its file size. Am I getting it right?
Also, with current release of Scorpio (non-UI parts), I can make UIs in pure Lua, but logics in Scorpio, can't I? Last but not least, if possible could you please briefly explain some advantages of using PLoop and Scorpio over pure lua? As a C++ & Java studied person, I am glad to see OOP style coding in Lua. (Well... I know there were some OOP plugins existed from the past, but most of them are outdated or not easy to follow, and they were basically not for WoW) But, also would like to know how efficient it would be (like pros and cons). Thanks! P.S: Sorry if I am taking too much of your time |
Quote:
Lua Code:
Quote:
Quote:
But object accessing is few in an addon, as you can see in the Scorpio, normally all codes are defined in the functions with simple lua datas, you won't face many objects in the non-ui part. For the UI part, the ui elements created from CreateFrame also use meta-method to access it's api like frm:SetPoint(), so the cost is all the same with the Scorpio's objects. Besides the efficiency of running,I care more about the efficiency of development and the code style. Take one line code from the trilliax-scrubber(I hope DevSkamer don't mind) : Lua Code:
Convert it to pure lua Lua Code:
Maybe it's not a good example, but I think you may find the first one will be more clear when you look it back after several times. |
Can you explain why you want to use OOP for addon development?
I remember this thread about it https://forums.wowace.com/showthread.php?t=20400 |
Quote:
Use ace like LibStub("AceAddon-3.0"):NewAddon(name), it's no diff to Scorpio("MyTestAddon"). So, using the OOP for addon development is not the problem. From the 7.0, the Mixin system also is an OOP system, it has multi-inheritance and stackable event handlers, but it's too complex and require the XML system. Take the AdventureMap_CombatAllyMissionPinTemplate as example : XML Code:
Lua Code:
In my system, it'd be defined like : Lua Code:
It'd be more clearly for their definitions. |
Have you ever heard the expression kill your darlings? Honestly, I agree with most of the sentiments in the old thread that Ketho posted. It seems you've put years of work into this project and I can tell you're proud of the result, but it's very unlikely this will gain any considerable traction among other developers. I'm not trying to be mean or anything; it's just not a very useful system in my honest opinion.
I don't think your code is easier to read or understand compared to the Lua most of us are used to. In fact, I'm struggling to even understand the syntax of it because it's so alien compared to how Lua normally looks. You obviously enjoy developing this framework, but I think this pretty solid case of overengineering is more for your own amusement as a programmer than it is a framework to be used by others. |
Quote:
The PLoop isn't designed for WOW, although it's started from the WOW, most features of it are designed for real life projects like web services. In an industry project, most workers shouldn't know details of the frameworks, they only need to know how to use it. You are using the Lua, but did you read it's C code. So, forget the PLoop, it's used to provide low level features, the Scorpio is the addon framework, authors still can enjoy it no matter how it's working. In the Scorpio's non-UI part, the main focus is how to organize codes around functions, there is nothing about the OOP. For the UI part, the most codes will be just like : Lua Code:
If you know how to use the ui elements, there is no different for the Scorpio's UI. |
I hinted at a key problem when discussing IGAS.
Quote:
When you place one layer of abstraction on top of another, you increase the overhead cost of running code. While this would be an interesting project using the standalone interpreter, it's a completely different situation implementing this in an environment where performance is critical. |
Quote:
The main issues here is accessing features in the function, if the feature is defined as local or existed in the module, the performance's the same like the global functions(no __index call). If the feature not existed, the module should access it from its parent module or the _G, it's the condition that would hit the performance(has __index call) So the module will save the features to itself when it get them from parent module or _G. And it'll get it directly at the next time, there is no performance loss again(no __index call next time). Those features are commonly functions, tables and some const values. Call object's methods always would cost a little more than pure Lua tables, but does it really matter, in a Scorpio module, the main logics are normally pure Lua codes(the functions for events, hook, slash cmd and etc, they are also registered to the core system as functions, they are called directly). Another part for the performance is about the FPS, to gain a good performance, we need control the running time between two frames, if some functions run too long, the game will freeze, so we need to control how they working no matter it's pure Lua or not. An important system in Scorpio is the task scheduling system, it provide several functions used to control threads, also will control the performance of those thread tasks based on their running times. |
One example of the task scheduling system is the container-view in my IGAS_UI.
The user can create multi-views for the container items, each view is used to show items within several groups, one item can be shown on several views. Each view has one thread used to refreshing it under the rules, some of my users have more than 10 views and it still don't hit the game's performance. |
The problem isn't really with Scorpio itself, it's running PLoop in a game, which Scorpio is an extension of. You're trying to answer the question of "Why should I use PLoop when I already know how to do this in baseline Lua?" The obvious answer is, you shouldn't.
The entire PLoop system is involved around using functions that appear as tags to set internal flags and intercept global environment writes to process the given function. Besides being terribly inefficient in doing so, there's an extremely likely situation that would cause a major problem for PLoop. PLoop was designed to be used in a single project environment where you have control of every variable and their values. The problem being is WoW isn't like that. The same Lua environment is shared among all addons and the default UI. The relatively open access and the way PLoop is designed to work makes it extremely vulnerable to global leaks from other addons and existing globals set by the default UI. This is why there's a common rule when developing addons to at least prepend your addon's name to the name of any global you create. It lessens the chances of conflictions with other addons and even the default UI. Why is PLoop vulnerable? Earlier, I explained how it uses functions as tags that intercept and modify an attempt to write a global function. PLoop does this by setting a __newindex metamethod on the global environment. The problem being is __newindex doesn't run if a global already exists. It simply overwrites the previous value. This means if you try to run the chunk that registers a function for UNIT_SPELLCAST_START and a global with that name already exists, you'll end up overwriting that global. Best case scenario, Scorpio will think AuctionFrameTab_OnClick is an event to register if the AuctionUI hasn't loaded already. Worst case, your addon throws an error and causes problems to whatever code already was using that global by corrupting their variable. Why do I do this? People tend to blindly accept code without even taking a critical look at it for vulnerabilities and other problems. Even many addon authors fall into this trap. It's nothing to be ashamed of and I hope this becomes a learning experience to help raise awareness to the risks of doing so. The WoW UI environment isn't just pure Lua, there are lots of caveats to it that doesn't exist in a normal Lua environment. |
老实说我一点都不了解你的帖子和看法
我觉得有语言障碍的问题啦~请问你是台湾还是大陆人吗? |
Quote:
|
Quote:
|
All times are GMT -6. The time now is 03:57 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI