EQEmulator Forums - Lua Scripting+Content Databasing system

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)

- - Lua Scripting+Content Databasing system (https://www.eqemulator.org/forums/showthread.php?t=36380)

Quote:

Originally Posted by Harakiri23 (Post 218914)

You want to simplify things but still dont want to use a wrapper ?

Simplify things for people who write scripts, not so much people who write the script system. There's a big difference. Using a wrapper is pretty much the opposite from what I've seen -- makes things easy for the system writer, but no real help to casual script writers.

Quote:

Originally Posted by Harakiri23 (Post 218914)

You still need at least one or two who understand lower level lua api

I understand it, and I'm the one writing all the functions, so that's fine with me.

For the two or three who might care, currently have a work-in-progress repo here; trying to keep the repo wiki up-to-date with all the EVENTs and object functions and eventually some script examples, as well as how-to's on module writing and adding new object types etc.

Another positive to the Lua system, the more we move into it the more we can 'live update' while the system is running. not sure how much of an advantage it is, but hey there you go.

Added scriptability for the SoF+ respawn window by way of an EVENT_RESPAWN_WINDOW. This allows respawn options to be customized: options can be added or removed based on the Client's level, the current zone, qglobals; options to respawn in guild hall, server hub zone, options to return to a questgiver if you were in the middle of a quest event, etc.

Full description and some example usage can be found at https://github.com/Zaela/LuaEQEmu/wi...respawn_window

Someone may want to make a Perl version of this if nothing else. I think it's a pretty neat thing.

Also, there is a bug with the respawn window and aggro; when the Client is hovering for respawn, they will continually aggro whatever killed them (aggro, lose aggro because the client is not a valid attack target, then aggro again, rinse and repeat) and mess up the Client's x-targets. This can spam trigger EVENT_AGGRO and possibly EVENT_COMBAT. To fix, replace this in aggro.cpp:

Code:

bool Mob::CheckWillAggro(Mob *mob) {

        if(!mob)

                return false;

        _ZP(Mob_CheckWillAggro);



        //sometimes if a client has some lag while zoning into a dangerous place while either invis or a GM

        //they will aggro mobs even though it's supposed to be impossible, to lets make sure we've finished connecting

        if(mob->IsClient() && !mob->CastToClient()->ClientFinishedLoading())

                return false;

with this:

Code:

bool Mob::CheckWillAggro(Mob *mob) {

        if(!mob)

                return false;

        _ZP(Mob_CheckWillAggro);



        //sometimes if a client has some lag while zoning into a dangerous place while either invis or a GM

        //they will aggro mobs even though it's supposed to be impossible, to lets make sure we've finished connecting

        if (mob->IsClient()) { 

                if (!mob->CastToClient()->ClientFinishedLoading())

                        return false;

                //clients will continually re-aggro whatever killed them if respawn hover is enabled,

                //repeatedly triggering EVENT_COMBAT/AGGRO and messing up x-targets; this fixes that

                if (mob->CastToClient()->IsHoveringForRespawn())

                        return false;

        }

Quote:

Originally Posted by addingice (Post 218517)

Pros of Lua vs Perl:

Smaller footprint, memory and cpu wise.
Can be distributed with the code base.
Removes an outside dependency.
Popular among game enthusiasts.
If it's used to replace Perl & MySQL then we also have the option of creating 'eq server in a box' linux distribution with a great deal less headache since it's only the server to deal with and not the server and sql issues.
Item look up side can become far more dynamic for the custom users. Easy set bonuses, for example.
Lua to c interface is far simpler and cleaner. Means that whole interfacing point could become much cleaner for scripter's. Examples where shown in the thread. Could lead to a standard library for EQ Lua scripts since it's far simpler to reuse.
Some tools might be easier to write since we can reuse much of the lua script code directly into the tools themselves. This is difficult to do with Perl as it stands.

Cons of Lua vs Perl:

Switching systems means we have people who need to learn Lua who all ready know Perl.
Perl has a huge number of packages all ready made (may not be relevant considering our current uses).
need to rewrite many of the current quests to use Lua.
Some will not switch since they have a large number of custom scripts.
Under some conditions the Lua GC can become finicky. (rare but can happen, usually just a set gc level change at the global scope)

Pro's of Lua vs MySQL:

Imperative as well as Declarative for those who want more dynamic content behavior or are used to imperative but not declarative systems.
A chance to clean up the item table and other components since it's getting a little....crazy? yeah. crazy. :grin:
Lua embedding is just as supported as SQL in almost all cases.
Easy starting out for modders / content creators. All that is required is a text editor.

Con's of Lua vs MySQL:

SQL is a very common language. Many developers know it. Lua? not as much.
Thousands of SQL tools out there.
very very very easy to do global modifications in SQL, may not (but doesn't have to be) easy to do this in Lua, depends on implementation.

What else am I missing? I'll edit as I people add.

Very nice, i was gonna ask this. Now I Know, my brain farted when he said switch from a DB to LUA i was like how will that work?

Awesome, great to hear that Lua is of interest in the community and among the devs. Out of all the languages I know, I use lua for my personal projects 90% of the time and for work whenever I can get away with it.

However, I would highly recommend using LuaJIT over basic Lua. As noted in the pros/cons list, Lua GC does have some iffy scenarios that LuaJIT fixes. LuaJIT also makes the c/c++ binding far easier once you grasp the ffi library. It's also very hard for other scripting languages to beat it's performance.

We're not exactly ready to talk much about it but atm we're working on a Lua parser for EQEmu.

Though we're not requiring LuaJIT just Lua 5.1 and people can use LuaJIT if they choose (I do).

ok so like ive been mia for a while.. this isnt really a thread necro since last post was a month ago.

question:
I noticed in the changelog the following disturbing note:
Now generally the perl system is now considered deprecated (in favor of lua in the long term) I felt this was too big a change to pass up adding when I got it working.

is this official then? Do i need to learn lua? I liked perl+mysql because I could have offline tools to interact with the db server, and I don't wanna learn new tricks.

Deprecated doesn't mean you can't use it if that's what works for you. It's not being removed it's just not going to get the same kind of attention Lua does.

This is an unrelated lua project. MySQL is still used, and will be for sometime (I just think it would be cool if we had support for multiple DBs, but I don't think anyone is working on that for now)

Since Oracles takeover of Sun, they now owns MySQL which probably will end up being proprietary to some degree. Some of sun developers had left and branch out MySQL into MariaDB.

Perhaps we can take a look at including MariaDB as another database to use with EQEmu.

https://mariadb.org/

MariaDB should theoretically just work. There is a lot of reorganization and cleaning up that would be needed to be done to make multiple DBs work nicely.