Another plugin language - beacos LUA is hard for some ppl

[NiLSPACE]

3. Beacos i want low memory usage, almost any scripting language wont be that good.

You'd be surprised how low the memory usage is. WorldEdit (one of the biggest plugins we have) uses around 1.6 MB in memory.

[fhntv24]

Hmm ... My minigame plugin right now ( in java ) is 4 mb. I will make test version of my minigames written in LUA and say what results are. If it would be ok - i will be happy =).

Also, will you implement new MC's nbt tags , such as noAI ? ( question is offtopic, but ... )

[NiLSPACE]

Also, will you implement new MC's nbt tags , such as noAI ? ( question is offtopic, but ... )

That's currently not possible. We're planning for a while now that you can give entities their own AI, pathfinding and more but it would require a big rewrite.

[fhntv24]

Also, will you implement new MC's nbt tags , such as noAI ? ( question is offtopic, but ... )

That's currently not possible. We're planning for a while now that you can give entities their own AI, pathfinding and more but it would require a big rewrite.

can i at least send it to clients ? You can disable AI in world config.

[xoft]

1. It doesnt have "right" OOP with protected and private variables.

It emulates enough of OOP for us to be usable. No-one really needs protected and private variables, and even that can be done in Lua, if you really want to.
We've written several plugins that have OOP principles used in it, and all of them use basic Lua.

2. LUA is fast, but i saw page with performance comparisons and lua wasnt best in speed.

Lua is considered one of the fastest scripting languages. And frankly, we haven't really seen a single instance of when Lua was too slow for us.
Note that it is a scripting language. It is designed to invoke functions of the host program. If there is something calculation-heavy that Lua is too slow for (such as comparing an entire chunk worth of data to another piece of data), we simply write the code in C++ and export it as an API.

3. Beacos i want low memory usage, almost any scripting language wont be that good.

Lua actually runs on microcontrollers that have only kilobytes of RAM. It is extremely efficient in memory management, unlike other scripting languages.

[LogicParrot]

No-one really needs protected and private variables

...In simple stuff like plugins, not universally.

[Shadowraix]

Why not lua:
1. It doesnt have "right" OOP with protected and private variables. You can only make local variable, or named protected variable. Isnt problem for plugins , its more for API with other plugins ( if there would be something like that ? )
2. LUA is fast, but i saw page with performance comparisons and lua wasnt best in speed.
3. Beacos i want low memory usage, almost any scripting language wont be that good.

Its really isnt that big problems, but for me they are. Even not first problem ( i can learn new languages, that isnt a problem ) - but 2 second ones are. Again , not big problem for some one - but its big for me. If you dont wont implement C++ plugins - i can implement by myself beacos MCServer is open source

I never found the lack of classes to be the biggest issue. I've been using Lua for about a year or two and I've found it extremely simple to use. Compared to something like C++, Lua is a much easier language to grasp with its simple concepts and syntax. If you want OOP then you can use metatables. The Lua website has documentation on how to do that.

Just because Lua isn't the fastest language in the world doesn't mean we shouldn't use it. I mean, Lua is one of the most widely used languages. Garry's Mod, Just Cause 2, and even World of Warcraft all use Lua as a scripting language. (Although it is arguably the fastest scripting language.)

I would suspect that memory usage would be lower. Java is a resource hog. I would think that C++ would manage memory a lot better depending on how the developers coded it. The Lua plugins is more on a plugin to plugin basis. Lua has a garbage collector which helps. Although, Lua has a small memory footprint as it is anyway.

Overall, I see Lua (Not LUA) as a great solution. It provides an excellent balance of performance, flexibility, and simplicity. I think getting all of the core server features implemented into MCServer and finishing up the API to deal with that should be a priority. Maybe alternatives can be considered like AngelScript or even MoonScript afterwards.

[DiamondToaster]

If performance and memory are that large of a concern then you could hack together MCServerJIT like I did. It compiles each plugin into native code. I'm not really sure how Lua is that hard though, it's an extremely flexible dynamically typed syntax. One could also use setmetatable() for "classes". I picked Lua up in about 2 days and ever sice, I've learned to prototype plugins in only a couple of hours. A C++ interface seems kind of overkill as no current Lua plugin has even come close to hitting the limits of the interpreter in terms of speed, much less LuaJIT.

[xoft]

Actually, one plugin of mine did hit a limit in the performance. When I was adding the web preview support for the Gallery plugin ( https://forum.cuberite.org/showthread.ph...4#pid19734 ) I first did the check for non-air blocks in Lua code. It processed a 16 * 16 * 256 area in several seconds on my laptop, which was really, really slow. That's why I ended up writing the cBlockArea:GetNonAirCropRelCoords() API function, which does this in a fraction of the time.

Which exactly illustrates the principle - if something is too slow for Lua, we implement it in C++ and add it to the API.

[NiLSPACE]

Do you still have the Lua code for that? We could compare it with LuaJit.