LUA vs DLL

[Weeman0000]

Gota be dll like... lua cant be scriped as much and takes longer to load them, also if you vote lua because you think you can mod the game DONT! other people that know how to script .dll's will make better mods just wait! lol

[Spooler]

I wonder where the idea for this thread came from ...
Haha nice to see people listen to me anyways dll is the way to go it's not hard to learn and there a plenty of prog's out there to make is easy for .dll noobs.
Well cya's in the new year merry xmas an happy new year to all

[Andrew]

I would argue for using Python as it is cross platform (like lua), fast and part of your python code can be re-written in C++ where you need the speed.
I really am against the idea of using DLLs and compiling stuff directly into the server. Everytime you want to make a small change to your server, maybe it's a quest or a spelling mistake in an NPC response you would have to shutdown the server, make your code changes and the recompile parts of the server. When I think about doing that I compare it to recompiling a webserver to edit my web pages. It doesn't really make much sense.
If you implemented support for a language such as python all you'd have to do is edit the script while the server was still running (if you programmed it right) and the change would run next time you ran the script.

[CrabClaw]

I compile my own game code and I agree with Python or Lua type scripting support. I *actually* write quest scripts, and being able to debug them quickly helps getting them done without problems.
When the quest scripts become numerous and up into the thousands the compile/test time will take forever just for one minor change to one script.
Also the ability to do a live update/re-load while not kicking everyone off the server is a big plus too. So scripting is a necessary feature for the content developers to get the job done in a timely manner.

[masterfreek64]

.dlls can be dynamically loaded and unloaded via flags ... they also are thread-safe and portable (ever heard of .so?)

[CrabClaw]

Yes, but you have to recompile them, do you know how long it would take to recompile the thousands of quests into a single dll *every* time you make a minor change?
The scriptDev AI scripts for Mangos has about 1,400+ scripts and is a 10-15 minute re-do each time. With a single script all you have to do is work on a single *.lua text file and re-load. How many quests does EQ2 have?
About ~5400 pre-RoK and ~5900 post.

[John Adams]

Speaking of WoW emulation, not sure what Ascent is calling it this week, but they used to use gmscripting, and switched to LUA. The quest engine we were planning to use in the Earth and Beyond emulator was LUA. There was no such thing as LUA when EQEmu was created, otherwise EQEmu would use LUA I am sure ~wink~
There's a reason so many use LUA, even outside of MMOEmu quest scripting. Back to Ascent, the C++ compiles of their scripts takes < 2 minutes on a decent Windows box. Probably faster on *nix. Compile >time< is not my concern, it's education. People will struggle, both with language and tool comprehension, trying to do squat with compiled code.
If that is not true, then where are the 20 devs helping LE code this beast?

[masterfreek64]

There is a .dll file for each script - or group of scripts ( 50 GM commands in one .dll - compiles in 5 seconds ... )
and the server can just load the new .dll - change the function pointer - wait for all calls to the old one to be finished and unload the old .dll .... - on the fly

[CrabClaw]

Lua is a *lot* less hassle, garbage collection, OO, it's fast and easy to work with, and a hell of a lot less verbose. This means a lot less debugging other peoples wonderful C++ quest code, memory leaks and all, and a lot more work done. Leave C++ work for the core, and let the quest scriptwriter's do their work.
Plus people don't have to have the source code to fix things as well. This is a huge plus. Go to the server/scripts directory and pull up the script just a plain old text editor...bam, done, /reload scrips. No re-compile necessary. Heck, even the AI could be done that way. This would give people a lot more flexibility and depth in making cool things work.
John is right, WoW uses it, NWN used it (I did a lot of quest coding for this). Far Cry used it for AI, Supreme Commander too, a *lot* of games used it for a reason, and WAR will too, why not EQ2Emu?

[LethalEncounter]

Unless I missed a post, all the posts here refer to either dll files OR a scripting language. Why not both? The implementations do not need to be mutually exclusive. We could simply store the dll quests in one directory and the LUA quests in another and the server would load all available quests for a particular zone when it is loaded. That way the server admin will be able to decide which is more important to them: speed/efficiency or flexibility/ease of use.
I believe it would also work nicely because even if you wanted to use all dll quests, new quests could be created in LUA and then ported over to a DLL after you have finished testing it.
I have never used LUA before, but I am leaning towards using it to develop the scripting quest engine.

[CrabClaw]

Excellent idea! This would help a lot.

[daeken]

Unless I missed a post, all the posts here refer to either dll files OR a scripting language. Why not both? The implementations do not need to be mutually exclusive. We could simply store the dll quests in one directory and the LUA quests in another and the server would load all available quests for a particular zone when it is loaded. That way the server admin will be able to decide which is more important to them: speed/efficiency or flexibility/ease of use.
I believe it would also work nicely because even if you wanted to use all dll quests, new quests could be created in LUA and then ported over to a DLL after you have finished testing it.
I have never used LUA before, but I am leaning towards using it to develop the scripting quest engine.

I think that rather than simply building a DLL-based plugin system and then building a LUA layer on that, you may have more luck building a DLL-based plugin system then laying a .NET layer over that, Mono or the official .NET framework. If you do that, you can use C#, LUA, IronPython, IronRuby, etc with a far smaller performance hit than using standard LUA.
I think this will give you the best of all options -- speed, flexibility, ease of use, and scalability.
~ Daeken
Edit: One other benefit that I forgot is that by using .NET for plugins/questing, you can eliminate the security issues you run into when you run straight shared libraries, as you can sandbox the .NET plugins.

[LethalEncounter]

But would the .Net system you suggest be Windows only?

[daeken]

But would the .Net system you suggest be Windows only?

Nope. You'd have to write different code to embed Mono than the standard .NET framework, but that's a slight difference. From there, exposing everything to .NET is generic between the two, and can be done in two ways:
1) Break the emu into logical DLLs. Once you break it into DLLs, you can just import those into your .NET code and call them from IronPython/C#/whatever. A good plugin system would allow the entire emu to be modular, which would be nice since you could write your code in C/C++ or any .NET language.
2) Write specific code exposing the emulator APIs into .NET. This is less flexible and although the initial work required is less (no real refactoring of your existing code), you have to expose APIs explicitly and don't have the ability to change anything that's not exposed.
~ Daeken
Edit: Hmm, I'm having a hard time finding information on embedding the MS .NET implementation. http://www.mono-project.com/Embedding_Mono has information on mono embedding, but I'm unable to find a reference for doing the same with the official implementation. It may be that you'd have to compile the emulator as unmanaged .NET, which would carry next to no performance hit (if there is any at all, which I'm not 100% sure on, tbh) and should work out of the box. If that's the case, though, it makes it damn near completely transparent to use other .NET languages in conjunction with the emulator. Might be the right way to go even if there is an embedding API -- something to think about if nothing else.

[masterfreek64]

Cool i would volunteer to do the .dll part !