Tell your ideas, suggestions, anything about Lua
The other topic got fully offtopic about this, so share your stuff here.
-
Should be Lua added to core?
-
Why? Pros/Cons
-
Hooks and such ideas
Here’s a take on it I wrote a while back:
Advantages of using a Lua engine:
[ul][li]Much faster to work with, faster to write, test, evaluate and debug.[/li]
[li]Does not require recompilation.[/li]
[li]Changes can be made without shutting down/restarting the server. Real time development makes it easier to test and experiment with various ideas.[/li]
[li]Developers can test their script on a local server. Does not require any core access at all and can therefore be made on either precompiled binaries or even other emulators.[/li]
[li]Simple syntax makes it a lot faster to write and easier to read. Designed for scripting.[/li]
[li]It offers blazingly fast performance for what it is, can be made even faster by adding [COLOR=rgb(17,85,204)]LuaJIT.[/li]
[li]Very easy to bind methods and hooks to the server.[/li]
[li]Possibility to implement support for [COLOR=rgb(17,85,204)]coroutines.[/li]
[li]Easy format that all content developers can interact with, does not require previous programming knowledge to get started with. [COLOR=rgb(17,85,204)]Fast to learn.[/li]
[li]Could hypothetically make it possible to make changes encounters while they are in progress.[/li][/ul]
[SIZE=18px]Common Concerns and F.A.Q:[/SIZE]
[SIZE=15px]There already is a lot of content scripted in C++ (and work put into it).[/SIZE]
[ul][li]Lua is extremely lightweight, which makes it very easy to port over content to Lua. Porting existing content will not be too tiresome and it’s also important to acknowledge the long-term benefits of having a fast scripting solution for future development. This will speed up future scripts or making adjustments to current scripts a lot. It also allows for more developers to interact with scripting as they don’t have to bother programmers with scripting simple parts of the content they are working on.[/li]
[/ul]
[SIZE=15px]Lua does not perform as fast as native C/C++ code.[/SIZE]
[ul][li]… But that doesn’t make it slow at all, it is extremely fast for what it is and it is certainly adequate for a WoW server. It can be made even faster by using [COLOR=rgb(17,85,204)]LuaJIT which helps achieve native C-performance for some functionalities. It also doesn’t eat up a significant amount of the performance to begin as it’s just a simple scripting engine for content.[/li]
[/ul]
Closing note: with the massive performance overhead gained by using modern hardware the performance costs of having a scripting engine which makes calls from the C++ code is trivial. The improvements in efficiency, ability to evaluate and test out code in real time, giving everyone the power to write powerful scripts not only outweighs the cons but it could also speed up development speed by hundreds of hours, especially with the increased complexity of content in newer expansions and onwards which advances at an almost exponential rate for every expansion.
[SIZE=15px]This will allow for absolutely everyone to write scripts that they can easily test for bugs and interact with on a local work environment, since scripts can be adjusted and reloaded during runtime it also allows for developers to collaborate on larger projects.[/SIZE]
Cons: good luck trying to store WorldObject pointers in the Lua stack and keeping it crash free at same time (unless you are going not to store any pointer at all)
We already have the Eluna Engine project which serves as evidence that this a full-fledged crash-free Lua engine for TrinityCore is possible.
so how do you remove WorldObject pointers from the Lua stack when game project deletes them ?
You should hear with Rochet, he’s an Eluna dev often hanging around in #Trinity, I’m sure he would be glad to share details and ideas about the implementation and also answer their solution to your proposed problem.
I’ll just wait for intra to reply
I can’t give you the answer you are looking for, but either Foeraper or Rochet can. I’ve seen both of them around on the forums and IRC.
I’ll wait for them to reply here then and either confirm or deny that “[COLOR=rgb(40,40,40)]full-fledged crash-free” applies to that Lua engine.
OK. But keep in mind that it’s open-source so you could always look at how they handle things and judge for yourself.
Nice
Thats hard to read…
Like I told you on Skype, I had some inspiration regarding this issue, and I know a way now, but I wonder how they solved it, so I’m waiting as well /emoticons/default_smile.png
best would be to someone take the time, compile it, run it, and write a crashscript in it
Looks like majority wants it.
I think a JIT-compiled scripting language would allow people to iterate on scripts quicker than normal.
In my opinion, the biggest downside of c++ scripting is the need to recompile, and restart, the core.
Using a scripting language, i could start the core => work on the script => try it => correct stuff => try it again …
It just sounds like a lot less lost time when fixing stuff.
Please tell me you aren’t surprised by this.
Btw your signature is quite wrong.
If this project was merely an academic exercise, you wouldn’t have this discussion ( and the wow version one ), and you wouldn’t have people arguing about content and how to make it easier to create content.
So please drop the pretense!
Thank you!
Indeed.
Basically the idea would be to have it as in C++. This means that you should not save a pointer over time unless the object is guaranteed to exist.
The way we have it currently is that when an object is destroyed, it is removed from lua. This means that when you try to use or access a deleted object (pointer) in lua, you will get an error message and it will simply be nil inside lua.
This is implemented by having a pool of objects in the lua state. It is one of the preferred implementation ways as it will keep only one lua userdata for each worldobject (object overall) and it will make them available to GC when deleted.
The bad thing is that each object has in its destructor a function to delete it from the lua pool.
So if you use / create / get a worldobject or any other object in lua, it will be added to the pool as userdata, which all references to the same object then use.
When the object is not used in lua, the userdata is available for garbage collection in lua. If the object is deleted by C++ before it is removed from lua, the object’s destructor invalidates it, making further calls give a warning about bad coding and returning nil, while avoiding crash.
However, this kind of coding style that would cause a crash should be avoided, just as in C++.
Nobody should store a pointer and use it in 10 minutes without knowing if the object exists. Not in C++, not in lua.
Basically what I mean by this is that there is no /need/ to worry about this if you code like in C++
But it will require additional security if you dont want to crash when someone codes wrong and accesses an invalid pointer.
With crashes one of the bad things is enums. A part of these allow you to insert an int and it may crash if you give a nonexistant one.
Many are checked but not all at the moment.
Eluna shouldnt otherwise be able to currently crash in theory
unless there is some problem with the coding… or if you make a bad SQL query, since TC calls abort on that.
As for luajit, someone switched the normal lua source and reported that it gave speed increase.
He did not use the FFI though, as far as I know, which would make it faster.
As stated by someone earlier somewhere, keeping code standards and changing the API can be problematic when the errors are basically only noticable when running the scripts.
ps. I probably said the same thing 3 times or something as I was doing other stuff in between writing.
POW!
Unfortunately that idea doesn’t work as you cannot know when and what will be deleted.
It’s also counterproductive, since it makes things more complicated.
Your pool way also sounds too compicated and also it sounds like your are coupling “WorldObjects” with the Lua Engine, which is a horrible idea. ( We also thought about this with Jackpoz years ago, but didn’t go with it for this reason )
You should probably use smart pointers ( could be too much work to change all pointer to smart pointer, since it’s not just about blindly replacing it ) OR an ownership system like that in Qt.
In Qt pretty much everything is derived from QObject which can have children.
When the object is deleted, it’s children are automatically deleted too.