LUA vs DLL

[Andrew]

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

I personally think that the .NET approach is the wrong way of going for this project.
1) Mono isn't mature and stable yet, so it'd definitely be broken on my Ubuntu machine which doesn't even allow me to run Mono yet.
2) Is it a bug in our code or Mono? The Mono project is going to be like the Samba project. It's always going to be playing catch up. i.e. You'll implement a function in .NET not yet available in Mono.
3) A scripting language such as Python is mature and stable with examples of how to implement it in your C++ code.
4) I don't believe that .NET is any faster then Python and it wouldn't make a difference if .NET is faster because all the important quest functions would most probably be written in C++ with the ability to use them in your Python script anyway. Not only this but quests aren't time critical.
5) We need normal people who may only know how to edit a text file to be able to enter quest data. Asking these people to test their quest by recompiling them in a compiler is raising the bar of technical knowledge required to help contribute.
5.1) Not all people editing scripts will be programmers, they might just be making something as simple as a spelling correction with no idea what the surrounding code means.
I worry about this because:
1 - I think it will have a dramatic effect on contributions we receive on quest data.
2 - I will no longer be able to run the server on my Ubuntu machine given what I have said above.
I am not saying that .NET is no good, just that I don't think it would be the best solution.

[daeken]

1) Mono isn't mature and stable yet, so it'd definitely be broken on my Ubuntu machine which doesn't even allow me to run Mono yet.

With the exception of the .NET framework 3, Mono is actually fairly mature. The shortcomings are (typically) well documented and easy to work around. In addition, I don't see why you wouldn't be able to use Mono on Ubuntu -- it's available in apt and I've not heard anything about it having issues from any developers on other projects of mine.

2) Is it a bug in our code or Mono? The Mono project is going to be like the Samba project. It's always going to be playing catch up. i.e. You'll implement a function in .NET not yet available in Mono.

I disagree fairly strongly. There will always be subtle differences, but the Mono project has shown that they've been able to keep up by focusing on building out one .NET framework version at a time. In addition, this is a server emulation project -- we're going to be playing catch-up faaaaaar more than the Mono project ever has to; they have to deal with incremental updates every year or two, we have to deal with it every patch.

3) A scripting language such as Python is mature and stable with examples of how to implement it in your C++ code.

I agree that Python is mature, but like Lua you have to build an explicit bridge everywhere you want to do cross-language calls. This adds up very quickly. I love Python, but I don't think that it's the right tool for the job here.

4) I don't believe that .NET is any faster then Python and it wouldn't make a difference if .NET is faster because all the important quest functions would most probably be written in C++ with the ability to use them in your Python script anyway. Not only this but quests aren't time critical.

Well, .NET is far faster than Python -- IronPython (Python hosted on .NET) alone is twice as fast, and it's significantly slower than something like C#. Also, the system I was proposing could go far beyond simple quest scripting and allow for building any modules in .NET. That said, I tend to agree that speed is a non-issue for most cases.

5) We need normal people who may only know how to edit a text file to be able to enter quest data. Asking these people to test their quest by recompiling them in a compiler is raising the bar of technical knowledge required to help contribute.

No need to ask them to touch a compiler -- the .NET framework exposes the compiler entirely at runtime. That way, people can just edit 'scripts' in C#/IronPython/VB/Boo/whatever, and the emulator can compile them at loadtime.

5.1) Not all people editing scripts will be programmers, they might just be making something as simple as a spelling correction with no idea what the surrounding code means.

This isn't an argument for any particular approach, really. If you feel Python is the proper language for this, then that's an argument for IronPython as much as CPython. Language and framework aren't inherently connected.

I worry about this because:
1 - I think it will have a dramatic effect on contributions we receive on quest data.
2 - I will no longer be able to run the server on my Ubuntu machine given what I have said above.

I think that there are ways to manage this such that it affects neither code contribution nor cross-platform capability in a negative way.
- Daeken

[skandragon]

Why must it be one or the other? Why can it not be both? Perhaps a scripting language for development purposes, and a .dll / shared library for production use?
That is, scripting hooks are always nice, even if I don't know what LUA is, and I could see reasons to write scripts in Perl, Python, Ruby, etc. Perhaps taking a page from the web developers, Asterisk PBX, etc. and doing some sort of small protocol between the server and a script, via a TCP or Unix domain socket?

[CrabClaw]

True that
My preferences would be Ruby(I am doing this now for my own projects), then Python and then Lua or Perl. I can do either though equally. But it is early in the game, so we can be open for experimentation to see what works the best.

[Diamente]

I get deja-vu reading this read. I think everyone has said all the same things at least twice now.

[wolfgurr252]

Lua would suck as main script allow it to be enabled for custom content but other wize use .dll's and python sucks for new age mmo's emu's its to slow.
only good thing about lua vs gm and other worthless set ups is 64bit support

[Andrew]

python sucks for new age mmo's emu's its to slow.

I have to rebuke that, Eve-Online uses Python in both their servers and clients. They have over 10,000 players on their servers at one time.
"When embarking on the creation of EVE Online, a single shared persistent world we realized two things: We could not given constraints of time and commercial reality do this in a compiled language and we needed innovative concurrency control for such a large scale shared state simulation across tens of thousands of CPUs (EVE Clients included). After many experiments with various combination of existing scripting languages and NT fibers we arrived at Stackless Python. Stackless Python offered us the power of Python coupled with a vastly superior concurrency control mechanism over anything we had seen before, first as continuations and later with an innovative channel based API. CCP's commercial success today is built on the single decision of selecting Stackless Python as our foundation." -- Hilmar Veigar Petursson, CEO of CCP Games.
I personally don't care what language it is. Ruby, Python, whatever. As long as it's not something I can't compile such as .NET.
I also think it needs to make sense too. I think it is overkill to have multiple scripting languages and that it would be better to just pick one and run with it, whatever language that might be.
With that in mind it would be awesome to be able to embed Ruby. Python, whatever on the server using the client so that you could have more advanced control at runtime.
If you could type while in the client for example..
/run zoneserver.sendDamagePacket(victim, attacker, damage);
That would be awesome for testing what makes the client tick without having to re-compile or implement /commands. It could also be very powerful for server admins too.

[skandragon]

Using a socket-based communication channel would allow you to write quests or other plug-ins in any language whatsoever. A "null" socket would be used for compiled in stuff -- that is, same API on both ends, just no actual communication path.

[alfa]

Stop me if I'm wrong but easy scripting or not depend on function dev get work, I'm eplain:
If dev made in code or dll all fonctions need for script, like pop a mob at wp, cast spell, reset haine, switch to heal, doing a spell with timer, said,...
It would be easy to made scripts, even if you dont know this lagangue I'm sure a member of community will post a source with comments and example.
Use a function is really esay the most hard is to create/code function.

[wolfgurr252]

also Dev's why not take a look at AngelScript i still think using C++ scripts or something like that best full way to go with server side and custom content but take a look at http://www.angelcode.com/ there not so bad

[masterfreek64]

Well the trick is:
a) use tolua++ - AUTOMATICALLY makes "master code" available in Lua
and
b)
Dlls have a natively linked interface (script and 'official' code is the same )

[masterfreek64]

python sucks for new age mmo's emu's its to slow.

I have to rebuke that, Eve-Online uses Python in both their servers and clients. They have over 10,000 players on their servers at one time.
"When embarking on the creation of EVE Online, a single shared persistent world we realized two things: We could not given constraints of time and commercial reality do this in a compiled language and we needed innovative concurrency control for such a large scale shared state simulation across tens of thousands of CPUs (EVE Clients included). After many experiments with various combination of existing scripting languages and NT fibers we arrived at Stackless Python. Stackless Python offered us the power of Python coupled with a vastly superior concurrency control mechanism over anything we had seen before, first as continuations and later with an innovative channel based API. CCP's commercial success today is built on the single decision of selecting Stackless Python as our foundation." -- Hilmar Veigar Petursson, CEO of CCP Games.
I personally don't care what language it is. Ruby, Python, whatever. As long as it's not something I can't compile such as .NET.
I also think it needs to make sense too. I think it is overkill to have multiple scripting languages and that it would be better to just pick one and run with it, whatever language that might be.
With that in mind it would be awesome to be able to embed Ruby. Python, whatever on the server using the client so that you could have more advanced control at runtime.
If you could type while in the client for example..
/run zoneserver.sendDamagePacket(victim, attacker, damage);
That would be awesome for testing what makes the client tick without having to re-compile or implement /commands. It could also be very powerful for server admins too.

This can be done using C# .... ( and way better that is) and MONO

[John Adams]

Still,
Perl - for simplicity (EQEmu users are already familiar with this scripting style)
LUA - because it's all the rage, and what everyone else is doing(!!1)
World.exe - it just makes sense
These are still my votes.
a) I do not want to compile my scripts between each change
b) I do not want to have to take a college course in C# just to get an NPC to say "Greetings, John"
c) I'd avoid even Perl if it means you still have to load ActivePerl just to make the shit work
d) Scrap the whole thing, go with a database-fed quest engine that is solely executed within the World code (C++) with built-in commands to do everything we need.

[masterfreek64]

a) I do not want to compile my scripts between each change
As i said you can JIT - compile C++ :
The files are dynamically linked. (.dll and .so - when i say either I mean both )
The files are stored as C++ source files in a specified directory of the server.
As soon as the server loads the "last modified dates" of the .dlls (THEY EXIST ON UNIX !)are checked against these of the .cpp files ( the .dlls have to be newer) and if not an integrated GNU compiler ( or another optional toolchain ) is called to compile the scripts...