Are all addon "open source"?
Is there any "compiled" file or the addon is the code we have in .lua filess basically?
Thanks. |
They're open source. The lua is what is used by Blizzard to run the add-on.
|
Open source ~= Visible Code. Not every addon is open source.
|
Quote:
to list a few.... Finally, take note that although an addon may be viewable it may have a licensing agreement attached to it. This may or may not prevent someone from using code or altering code without the authors permission. A lot of the WOW addons don't have licensing attached to it and are freely available to grab code from or modify in any shape or form. There are a few whom have GNU open licenses which allow you to use code and or alter it but also require you to mention the Author when you credit your work. My advice is just to review the code and check for licensing material. In practice I always credit any author regardless if they do or don't have a licensing agreement attached to their addon. But that's just me :) |
Do note that if an addon doesn't have a specific license attached, due to the Berne Convention, that addon's license is "by default" All Rights Reserved.
What that actually means for addons isn't exactly easy to nail down, due to the interaction of Blizzard's guidelines and RR licensing. Here's another thread where some people discuss it: http://www.wowinterface.com/forums/s...ad.php?t=48570 You can be sure that it means, at least, that you cannot literally copy the addon in its entirety or any of its parts and paste them into yours. That is actually and clearly illegal. Most authors, as several expressed in that thread, are okay with you reading through their code and learning from it -- even copying the spirit of novel techniques they may have used to solve various problems. |
Quote:
1. I check their license, contact author if need be 2. Include credits and their license |
Quote:
Also, as others have said, open source does not mean the same thing as source viewable. WoW addons can not be obfuscated or compiled. |
Quote:
On a different topic, I wonder what the Statute of limitations(or do you call it prescription??) are for AddOns, since there's different law enforcements(I assume EU, USA and Asian regions all have different timespans). I hope there's never going to be any occasion that will play a role. Lucky Blizzard brings us content every half year or so, so chances are small :rolleyes: |
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
I know you're trying to be helpful, but as in some other recent thread, the information you're giving is simply wrong.
The only possible advantage a smaller file could have would be in reducing the amount of time it takes to read the file from your hard disk, and there's simply no way that any functioning modern hard drive is going to take 2-3 additional seconds to read a few hundred KB worth of files. (Basing that size on the size of a BigWigs zone module; I can't imagine DBM modules are all that much bigger.) The size of each file is not really what matters. The quantity of files will have a much more noticable effect. If you are really hyper-obsessed with minimizing the time it takes to load your addon, you'll see a much bigger difference by combining all of your code into one file, than you will by reducing all of your variable names to single letters and removing all the whitepsace from each file. Also, most of the time it takes to load an addon has nothing to do with either the size or the quantity of files in the addon -- it's in your code being compiled and executed, and the Lua interpreter doesn't give a rat's behind whether your variable name is 1 or 1000 letters long. Minifcation is useful in, say, the JavaScript code for a website -- but it doesn't make the code itself load or run any faster, it only makes it faster to transfer the file from the server to your computer. No files are being transferred across a network in the WoW addon environment, so that isn't a concern. The only reason to minify, obfuscate, or do any similar thing to the code of a WoW addon is to make your code harder for other people to read because you're paranoid that someone is going to copy you. This is why Bejeweled and Peggle got permission to obfuscate their code -- because those are addons based on established proprietary games that are sold for profit, and it wouldn't make sense for their creators to suddenly start giving away the code for free, and Blizzard loses nothing by letting them run their game inside of WoW. In fact, Blizzard benefits from it, in that people are less likely to get bored and quit if they have something fun to do in between real activities like dungeons and raids. TLDR version: Minifying or obfuscating your WoW addon code has no benefits for normal addon authors. |
Be aware that Blizzard has some size limitations on a single loaded file. I ran into this when I tried combining eleven files into one that was approaching 5MB in size. I know most will never encounter this, but it exists.
|
The Lua compiler translates programs written in the Lua programming language into binary files that can be loaded and executed with lua_dofile in C or with dofile in Lua.
The main advantages of precompiling chunks are: faster loading, protecting source code from user changes, and off-line syntax error detection. Pre-compiling does not imply faster execution because in Lua chunks are always compiled into bytecodes before being executed. The compiler simply allows those bytecodes to be saved in a file for later execution. Longer variable names would never have an impact on runtime performance in a compiled language. But in a just-in-time compiled language, it could slowdown program startup and program performance. For dynamic languages such as Lua or Python or Ruby, the length of a variable name could very well affect runtime performance depending on how variable name lookups are performed. If variable names are hashed and then the hash is used to index a table of values to get the value of the variable, then natrually the more data the hash function has to process, the longer it will take. When you compile this: Lua Code:
The compiled file will be this: Lua Code:
And if you complie this: Lua Code:
You will get this: Lua Code:
- Used lua 5.1. Since the variable name is more then 8 charaters the compiler can't transalte that variable name into 1 bytecode, so it will take up more space, and since the code is longer the execution is going to take more time. You are right about it's might be irrelevant for 100-200 kB codes or i7 12 core processors, but it still a performance improvement, bit faster execution, less memory fragmentation. |
Quote:
|
Quote:
Edit: @Nimhfree: If there is a limit on the size of a single file WoW will load, it's certainly larger than 5 MB, as saved variables files for damage meters don't start failing to load until they're in the 30+ MB range. Edit #2: I just tested loading a 30 MB file in an addon, and had no trouble at all. I didn't bother testing anything larger, as there's pretty much no way the combined size of any addon is more than 30 MB. |
I must be mistaken about the error loading my 5MB being related to size. I will dredge up that version and post whatever the error was. I am guessing it is related to the number of "ifs" if it is not size related, but will know for sure later.
Edited to add: It turns out the actual error I am getting is: 1x Grail-059\Grail-QuestNames.lua:142112: control structure too long near "<eof>" Basically the file structure looks like: if locale == "enUS" or locale == "enGB" then elseif locale == "deDE" then elseif locale == "esES" then -- all the rest of the locales until else print("Unsupported locale", locale) end Each of the "language sections" has over 12,000 lines in it looking like: G[32647]='工作令:金蓮會I' G[32648]='工作令:金蓮會II' However, within each section there are if blocks with various line count in them like: if release >= 17345 then G[11488]='博學者殿堂' G[11490]='占卜者的占卜' G[11492]='難以殺死' end |
All times are GMT -6. The time now is 04:27 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI