Well here we will do a poll that decides about the future of Eq2emu and thus mankind ^^
Decide Wisely.
Our 2 options for implementing questing and customisation would be a scripting language ( like lua) or a .dll based hook system.
LUA:
+ easily learned
+ programs are human readable ( absolutely no complex code )
+ Implementing it is easy .
- slow as hell . LUA is interpreted ( JIT is yet unstable) . Also LUA was designed for customisation not for actual code.
Tis is the main disadvantage.
For a singeplayer game , we can take out additional 10 ms for scripts every frame ( or more ) . But in a big MMO server, thousands of scripts are called every second , and playing with large and complex scripts s enabled is impossible on affordable hardware.
- LUA is limited. We have to implement everything but a few basic features.
- LUA is juts 1 language. People who dislike it cannot customize LUA
Whereas I propose a .dll based system ( read the sticky about quests , and my thread on scripting hook for an overview).
The points are:
+ extremely fast . The scripts are real 'programs' and thus have the same performance behaviour as any other program.
.dlls can easily achieve 100 times the performance of LUA.
+extremely customisable. With .dlls we can interfere directly and flawlessly between the core and the custom plugins. Thus we do not have to maintain and write an extremely large scripting 'gateway'.
+many programming languages. .dll files can be made with almost any language , ranging from assembler code through C, C++ and C# to exremely user friendly languages like Visual Basic, Blitz Basic and Delphi.
+People can write "wrappers" for LUA and other scripting languages as .DLL
+Making .dlls intergrates into a normal Developer Workspace. It is just like making a regular program !
+.DLL files can be more easily scanned for virusses.
- .DLL files propose a security risk on systems without antivirus. They are also programs of their own . But developers will have to include source codes for the .dll if we choose so ...
- Code generation is a bit trickier. One has to select to which events one has to listen. For making quests this is extremely easy, for other things it can be a bit harder ( but still . 10 minutes more programming or one percent of the speed while running? )
- .DLL files are programs of their own. They could do something that could seriously impair the server.
We can avoid that by catching all Exceptions from the .dll file in the server , and if necessary unload the plugin
- .DLL files need to be unloaded and loaded by the server and not by some code. However I can easily do this.
-.DLL files can create memory leaks on really old windowses( but these would not run LUA scripts very fast ... )
- .DLL files are a Windows concept . But we can use shared libraries on UNIX. However still we may experience problems should we want to port it to another system ( like AmigaOS - but who wants to run EQ2EMU on an Amiga)
Note that the term .dll means both .dlls under windows and shared libraries under *NIX .
Please discuss
I propse .dlls , because LUAs would kill our machine ( as other script libraries do)
All official( as in non - emu) MMO servers I know of use machine code ( like .dlls ) like the Meridian 59 BlackSton server ( it was leaked ... ) and the Dark Age Of Camelot ( highly probable , becaus eof the way the server works and has to be maintained by the GMs - they said some things about procedures ) server.
LUA vs DLL
Moderator: Team Members
-
masterfreek64
- Posts: 36
- Joined: Fri Aug 03, 2007 6:02 am
-
CaptainBeast
- Posts: 14
- Joined: Thu Nov 08, 2007 10:54 am
- Location: Arkansas
I would like to know more about how quests work in EQ2 in general before I would put my vote on any particular methodology for scripting quests; not that I'm in any position to make such a decision mind you, but as a participant in this endeavor and a programmer I believe I have something to contribute.
I know in my own experience playing EQ2, some quests require to to travel across many zones, have certain items your posession when talking to NPCs, have specific faction, know a certain language, kill certain NPCs, zone some more, buy an item or two, harvest certain nodes, craft an item, zone again, etc. - a virtually unlimited number of possible functions and procedures need to be performed just to complete the quest.
Until more is known on how quests operate and how they can be accomplished, I think it's unwise to attempt to define the method for creating and defining a quest. Especially since those wanting to create a quest will necessarily need programming experience and need to know C++ to create a quest under one of the afore mentioned conditions and therefore will need instructions and more than likely an SDK to assist in accomplishing the quest creation. Additionally, we need to know how the data will be stored in the database for those quests (perhaps this has already been decided or being worked on) so that appropriate information can be sent to the "scripting engine" or even what needs to be sent. Quest progress must be stored as well, including the ability to "time" quests so that a particular task must completed in an aloted time and therefore a quest has "completion points" that comprise the entire quest.
I've been a software developer for a long time and I see the benefits (and difficulties) in either implementations. Scripting is always going to be slower than true compiled but it has its benefits as well.
When it comes to software engineering, it's generally a wise practice to understand the problem you are solving before you try figuring the solution.
I know in my own experience playing EQ2, some quests require to to travel across many zones, have certain items your posession when talking to NPCs, have specific faction, know a certain language, kill certain NPCs, zone some more, buy an item or two, harvest certain nodes, craft an item, zone again, etc. - a virtually unlimited number of possible functions and procedures need to be performed just to complete the quest.
Until more is known on how quests operate and how they can be accomplished, I think it's unwise to attempt to define the method for creating and defining a quest. Especially since those wanting to create a quest will necessarily need programming experience and need to know C++ to create a quest under one of the afore mentioned conditions and therefore will need instructions and more than likely an SDK to assist in accomplishing the quest creation. Additionally, we need to know how the data will be stored in the database for those quests (perhaps this has already been decided or being worked on) so that appropriate information can be sent to the "scripting engine" or even what needs to be sent. Quest progress must be stored as well, including the ability to "time" quests so that a particular task must completed in an aloted time and therefore a quest has "completion points" that comprise the entire quest.
I've been a software developer for a long time and I see the benefits (and difficulties) in either implementations. Scripting is always going to be slower than true compiled but it has its benefits as well.
When it comes to software engineering, it's generally a wise practice to understand the problem you are solving before you try figuring the solution.
-
masterfreek64
- Posts: 36
- Joined: Fri Aug 03, 2007 6:02 am
-
Polygon
- Posts: 30
- Joined: Wed Aug 22, 2007 11:28 pm
-
Diamente
- Retired
- Posts: 45
- Joined: Mon Jul 30, 2007 7:49 am
- Location: Oklahoma
If you do the quest system with DLLs you will add all kinds of unnecessary complexity and alienate a large portion of any community you would want to have for writing quests. You would be effectively isolating it to not only developers, but developers who are comfortable enough to write libraries. Sure, with enough tutorials, you could get a community going...but that is an awful lot to ask of an already relatively small set of users.
Besides, the performance difference of dll's(let alone hundreds or thousands loaded at once) versus an interpretted script would be marginal, at best, in a real world scenerio. How many people do you expect to ACTUALLY be connected to an emulated server at one time? Say, for arguments sake, you net 10,000 users at once. Would that be an example of when binaries would be better than scripted if run on crappy hardware? Why yes it would. Now ask yourself this: if you had 10,000 users...is the quest engine REALLY going to be your bottleneck? The point at which you would see a benefit in using binaries on aged hardware is about the same point that you would need new hardware to support the load anyways, which negates the entire issue.
Editting quests in a binary scnerio would also be an extreme pain. I don't want to have to compile the stupid thing every time I change something mundane...let alone compile the library on a "good" machine, then copy it over to the "crappy" machine for use. Theoretical speed is not everything when weighed against the very real drawbacks of complexity.
If modularity is the biggest proponent of the dll idea, you get the same functionality using scripted libraries. Lua and Perl have both been around for long enough that there are literally thousands of libraries available that you can use that add on to the base functionality of the language and can pretty much do anything you want. Give it a week in public, and you'll have a whole slew of libraries for LUA (if we went that route) that interact specificallly with routines and functionality in EQ2Emu.
You mentioned several other MMOs that use binaries for their quest engines. You even mentioned how in one game, only GMs could maintain the system. This is a PERFECT example of the kind of thing I am talking about. I, for one, am not interested in being the only person who could write and/or maintain the quest engine for my entire server...which would literally be the case. At BEST I would write a binary that just called all the scripted components that the quest writers make...which defeats the whole purpose of going binary in the first place...and then I would end up with another piece of the puzzle that could break. Keep it simple. While there may be a large percentage of developers in this group, I guarantee you that your average user/gamer/co-admin/whatever will not be.
All in all, if you want a strong community of people ready from the get-go to help populate the system with quests, do it scripted, and do it in a powerful scripted language people are already probably familiar with. Lua is the de-facto game scripting language right now, and has been for a number of years. Perl was its predecessor and would work just as well. Doing it any other way would be reinventing the wheel and taking a giant step backwards, in my opinion.
There...there's my two cents worth after my many months of silence
Besides, the performance difference of dll's(let alone hundreds or thousands loaded at once) versus an interpretted script would be marginal, at best, in a real world scenerio. How many people do you expect to ACTUALLY be connected to an emulated server at one time? Say, for arguments sake, you net 10,000 users at once. Would that be an example of when binaries would be better than scripted if run on crappy hardware? Why yes it would. Now ask yourself this: if you had 10,000 users...is the quest engine REALLY going to be your bottleneck? The point at which you would see a benefit in using binaries on aged hardware is about the same point that you would need new hardware to support the load anyways, which negates the entire issue.
Editting quests in a binary scnerio would also be an extreme pain. I don't want to have to compile the stupid thing every time I change something mundane...let alone compile the library on a "good" machine, then copy it over to the "crappy" machine for use. Theoretical speed is not everything when weighed against the very real drawbacks of complexity.
If modularity is the biggest proponent of the dll idea, you get the same functionality using scripted libraries. Lua and Perl have both been around for long enough that there are literally thousands of libraries available that you can use that add on to the base functionality of the language and can pretty much do anything you want. Give it a week in public, and you'll have a whole slew of libraries for LUA (if we went that route) that interact specificallly with routines and functionality in EQ2Emu.
You mentioned several other MMOs that use binaries for their quest engines. You even mentioned how in one game, only GMs could maintain the system. This is a PERFECT example of the kind of thing I am talking about. I, for one, am not interested in being the only person who could write and/or maintain the quest engine for my entire server...which would literally be the case. At BEST I would write a binary that just called all the scripted components that the quest writers make...which defeats the whole purpose of going binary in the first place...and then I would end up with another piece of the puzzle that could break. Keep it simple. While there may be a large percentage of developers in this group, I guarantee you that your average user/gamer/co-admin/whatever will not be.
All in all, if you want a strong community of people ready from the get-go to help populate the system with quests, do it scripted, and do it in a powerful scripted language people are already probably familiar with. Lua is the de-facto game scripting language right now, and has been for a number of years. Perl was its predecessor and would work just as well. Doing it any other way would be reinventing the wheel and taking a giant step backwards, in my opinion.
There...there's my two cents worth after my many months of silence
-
Aaden
- Retired
- Posts: 64
- Joined: Mon Aug 27, 2007 12:39 pm
- Location: Connecticut
- Contact:
-
masterfreek64
- Posts: 36
- Joined: Fri Aug 03, 2007 6:02 am
However if you can nearly not run the server we loose hosts , and most likely most quests won't ever be used if they are made with LUA ( too much performance eating)If you do the quest system with DLLs you will add all kinds of unnecessary complexity and alienate a large portion of any community you would want to have for writing quests. You would be effectively isolating it to not only developers, but developers who are comfortable enough to write libraries. Sure, with enough tutorials, you could get a community going...but that is an awful lot to ask of an already relatively small set of users.
No.Besides, the performance difference of dll's(let alone hundreds or thousands loaded at once) versus an interpretted script would be marginal, at best, in a real world scenerio. How many people do you expect to ACTUALLY be connected to an emulated server at one time? Say, for arguments sake, you net 10,000 users at once. Would that be an example of when binaries would be better than scripted if run on crappy hardware? Why yes it would. Now ask yourself this: if you had 10,000 users...is the quest engine REALLY going to be your bottleneck? The point at which you would see a benefit in using binaries on aged hardware is about the same point that you would need new hardware to support the load anyways, which negates the entire issue.
Interpreted vs. machine code. They can by architecture never be in the same performance class. Also if you say we need new hardware anyways, then also consider that you would need even MORE performance for scripting , so interpreted could waste performance that shoudl rather be used to make gamepace faster ( often it is the server software who is lagging , not the line)
Why that?Make a web manager , or use Visual Studio and autodeploy it. Of course, managing Lua scripts is sooo totally easy *wink*Editting quests in a binary scnerio would also be an extreme pain. I don't want to have to compile the stupid thing every time I change something mundane...let alone compile the library on a "good" machine, then copy it over to the "crappy" machine for use. Theoretical speed is not everything when weighed against the very real drawbacks of complexity.
As the quest can be loaded and reloaded on-the-fly it is quite easy to manage them.
Rebuild the binary, perhaps open some sort of remote configuration ( telnet interface, anyone) and send 'reload bin xy'
We could even provide command line support for gcc and compile the stuff, complete with a web editor.
If modularity is the biggest proponent of the dll idea, you get the same functionality using scripted libraries. Lua and Perl have both been around for long enough that there are literally thousands of libraries available that you can use that add on to the base functionality of the language and can pretty much do anything you want. Give it a week in public, and you'll have a whole slew of libraries for LUA (if we went that route) that interact specificallly with routines and functionality in EQ2Emu.
Yes, but it would require additional maintainance and effort. .DLLs are always in connection with the server , got no performance restrictions , etc
no. I said that because of the way the gms manage the server in DAOC , I know they use .dlls ( like a biiiggg lagg when a new quest series is loaded and the engine has to reload modules and initialise stuff - they are not using the newest servers availableYou mentioned several other MMOs that use binaries for their quest engines. You even mentioned how in one game, only GMs could maintain the system. This is a PERFECT example of the kind of thing I am talking about. I, for one, am not interested in being the only person who could write and/or maintain the quest engine for my entire server...which would literally be the case. At BEST I would write a binary that just called all the scripted components that the quest writers make...which defeats the whole purpose of going binary in the first place...and then I would end up with another piece of the puzzle that could break. Keep it simple. While there may be a large percentage of developers in this group, I guarantee you that your average user/gamer/co-admin/whatever will not be.
) Well.All in all, if you want a strong community of people ready from the get-go to help populate the system with quests, do it scripted, and do it in a powerful scripted language people are already probably familiar with. Lua is the de-facto game scripting language right now, and has been for a number of years. Perl was its predecessor and would work just as well. Doing it any other way would be reinventing the wheel and taking a giant step backwards, in my opinion.
You can even make your binaries in Basic. Sorry , but making binaries is not hard.
And people are also familiar with 'real' binary programming language, especially if they can use whatever they want , from Delphi through C to Assembler.
The number of people who know a binary making programming language is far greater than the number of people knowing 'one' scripted language.
-
ZexisStryfe
- Posts: 1026
- Joined: Thu Jul 26, 2007 6:39 am
- EQ2Emu Server: Sytherian Legends
- Location: Connecticut
- Contact:
Personally, while i understand that performance hits will occur from scripting, I would much prefer Lua over DLLs purely due to simplicity. People have to learn to walk before they can run. When it comes to programming, I crawl. 
As to professional MMOs that use DLLs... of course they do! They have staffs of dozens of people that can write them as needed, and thousands of people to beta test. While I have grand plans for my server, I doubt I will ever have more than 2 or 3 people in addition to myself as admins. I am too much of a control freak! And I never expect to have that many players. Not even Winter's Roar/SoD can boast that, and they were by far the most popular EQEmu server.
I would much rather deal with easily editable scripts than compiled binaries anyday.
As to professional MMOs that use DLLs... of course they do! They have staffs of dozens of people that can write them as needed, and thousands of people to beta test. While I have grand plans for my server, I doubt I will ever have more than 2 or 3 people in addition to myself as admins. I am too much of a control freak! And I never expect to have that many players. Not even Winter's Roar/SoD can boast that, and they were by far the most popular EQEmu server.
I would much rather deal with easily editable scripts than compiled binaries anyday.
~ EQ2 Emulator Project Manager
"Zexis, from this day forth, you shall be known as... '3 of 6'" - John Adams
"Zexis, from this day forth, you shall be known as... '3 of 6'" - John Adams
-
Diamente
- Retired
- Posts: 45
- Joined: Mon Jul 30, 2007 7:49 am
- Location: Oklahoma
masterfreek -
You seem to have missed my point. I was not saying that behind the scenes interpretted would beat machine. That is not the issue, duh it would be faster there. My point is that in the real world scenerio, I am not going to split hairs over 0.5789382 seconds worth of speed gain, and I don't believe that this is enough to justify adding the complexity that compiling quests as mini-apps would bring.
The simplicity of the quest writing process has to be addressed also. You say creating binaries is not hard. Well, for developers, it's not. But I know that most of the users who will be utilizing this project will not be professional developers. You HAVE to consider the big picture in terms of your userbase. You are obviously a programmer, or have a decent amount of experience with programming, so compilable languages are an attraction to you and it is easy for you to do it. To the non-professional developer, they are daunting and not something most people will want to mess with. Hell, even some professional developers have never created a custom dll before. Even with a very high-level language like Visual Basic you have to take several extra steps to compile your project to a dll, and that's asking quite a bit considering a non-developer won't be as comfortable performing those steps. I would rather open up a text file in notepad, edit my quest, save it, and get instant results live...as opposed to opening my source in notepad or an IDE, editting my quest, compiling my quest, moving the freshly compiled dll to wherever on the server, unloading the dll, reloading the dll, and then testing my quest live. Just seems like a lot to go through to shave a few clock cycles. Keep it simple. Simplicity is greater than performance in most cases that involve the possibility of end-user customization.
For a server hosting thousands of simulatenous users, going with a compiled solution might be more ideal...but obviously you'd have beefier hardware and such as I explained in my previous post to even support their connections, much less a quest engine. But what will be the average large EQ2Emu server (i.e. eq2emulator.net) population online at the same time? At best I would think 50, MAYBE 100 online all at one time on one server. Maybe I'm wrong there and underestimating the eventual popularity of the system. But even if I am, and the big centralized servers like eq2emulator.net see large populations online at once...wouldn't you think similar projects like the original EQEmu would have gone down the compiled road as well? Perl is slower than Lua even, but you're still talking about fractions of seconds, and it has been good enough for the other MMO emulators. I would not expect to see the average EQ2Emu server hosting more than 5 or 10 people total, not due to performance; but because lets face it...most people will just want to either play solo, or play with a small group of friends. That is just the way these things work. Keeping it simple will cater to everyone's environment.
I would be interested to know what other processes you have going and what hardware you're running on that can be brought to its knees --"killed" as you put it-- by a few simultaneous Lua interpretations. Sounds exaggerated to me. Unless you have some inescapable or needlessly long loop, I just can't see it killing anything or becoming a problem for the kind of use it would get here. And by killed, I don't mean the occasional cpu/ram spike/blip. Even random applications like Notepad can cause that occasionally. What I mean by killed is 100% pegged for prolonged periods and max physical memory and swap usage. That is when you'd start losing connections.
You seem to have missed my point. I was not saying that behind the scenes interpretted would beat machine. That is not the issue, duh it would be faster there. My point is that in the real world scenerio, I am not going to split hairs over 0.5789382 seconds worth of speed gain, and I don't believe that this is enough to justify adding the complexity that compiling quests as mini-apps would bring.
The simplicity of the quest writing process has to be addressed also. You say creating binaries is not hard. Well, for developers, it's not. But I know that most of the users who will be utilizing this project will not be professional developers. You HAVE to consider the big picture in terms of your userbase. You are obviously a programmer, or have a decent amount of experience with programming, so compilable languages are an attraction to you and it is easy for you to do it. To the non-professional developer, they are daunting and not something most people will want to mess with. Hell, even some professional developers have never created a custom dll before. Even with a very high-level language like Visual Basic you have to take several extra steps to compile your project to a dll, and that's asking quite a bit considering a non-developer won't be as comfortable performing those steps. I would rather open up a text file in notepad, edit my quest, save it, and get instant results live...as opposed to opening my source in notepad or an IDE, editting my quest, compiling my quest, moving the freshly compiled dll to wherever on the server, unloading the dll, reloading the dll, and then testing my quest live. Just seems like a lot to go through to shave a few clock cycles. Keep it simple. Simplicity is greater than performance in most cases that involve the possibility of end-user customization.
For a server hosting thousands of simulatenous users, going with a compiled solution might be more ideal...but obviously you'd have beefier hardware and such as I explained in my previous post to even support their connections, much less a quest engine. But what will be the average large EQ2Emu server (i.e. eq2emulator.net) population online at the same time? At best I would think 50, MAYBE 100 online all at one time on one server. Maybe I'm wrong there and underestimating the eventual popularity of the system. But even if I am, and the big centralized servers like eq2emulator.net see large populations online at once...wouldn't you think similar projects like the original EQEmu would have gone down the compiled road as well? Perl is slower than Lua even, but you're still talking about fractions of seconds, and it has been good enough for the other MMO emulators. I would not expect to see the average EQ2Emu server hosting more than 5 or 10 people total, not due to performance; but because lets face it...most people will just want to either play solo, or play with a small group of friends. That is just the way these things work. Keeping it simple will cater to everyone's environment.
I would be interested to know what other processes you have going and what hardware you're running on that can be brought to its knees --"killed" as you put it-- by a few simultaneous Lua interpretations. Sounds exaggerated to me. Unless you have some inescapable or needlessly long loop, I just can't see it killing anything or becoming a problem for the kind of use it would get here. And by killed, I don't mean the occasional cpu/ram spike/blip. Even random applications like Notepad can cause that occasionally. What I mean by killed is 100% pegged for prolonged periods and max physical memory and swap usage. That is when you'd start losing connections.
-
masterfreek64
- Posts: 36
- Joined: Fri Aug 03, 2007 6:02 am
Ok well , I as an old school programmer just hjate pissing away performance.
For my hardware I am running 2 2.8 Ghz Servers , 1 Windows and 1 linux. They are running about 20 server daemons each , and have about 80% load ...
Well ok.
Leave the performance out for now.
Why is making .dlls that hard? I said we could even make an autocompile system with gcc so you just need to place files some ( that IS easy).
Dawn of Light (DAOC emu) , where i am a developer as well, is doing it that way ( however using .NET).
And now if you want to support end-user customisation, you can also make a scripting gateway as a .dll - nearly no performance is lost.
However another major aspect is that the .dll can simply access all classes and functions of the main server - it can just call and handle everything without us having to maintain a complex gating software.
Also , I know of emulated servers with well over 1000 players, and as Everquest mostly failed due to a bad release date , bad european ads and idiot payment methods , we could also reach that.
For my hardware I am running 2 2.8 Ghz Servers , 1 Windows and 1 linux. They are running about 20 server daemons each , and have about 80% load ...
Well ok.
Leave the performance out for now.
Why is making .dlls that hard? I said we could even make an autocompile system with gcc so you just need to place files some ( that IS easy).
Dawn of Light (DAOC emu) , where i am a developer as well, is doing it that way ( however using .NET).
And now if you want to support end-user customisation, you can also make a scripting gateway as a .dll - nearly no performance is lost.
However another major aspect is that the .dll can simply access all classes and functions of the main server - it can just call and handle everything without us having to maintain a complex gating software.
Also , I know of emulated servers with well over 1000 players, and as Everquest mostly failed due to a bad release date , bad european ads and idiot payment methods , we could also reach that.
-
John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
I have been watching this topic evolve. Honestly, I like performance myself. As a software geek, I naturally want my stuff running as efficiently as possible. Now that's what I want. Here's what the community NEEDS;
A minimal learning curve.
DLLs (written in whatever C you want) are not for Joe Admin. There is no way we can expect Joe Admin to sit down with a C/C++ book and learn the language just so they can write quests for their server - be it Live-like quests or custom. I understand the concept of Wrappers. I understand the concept of GMScripts. I know how Ascent and MaNGoS do it. I run DAoC and L2J emulators and still cannot comprehend what they are doing in the quest department.
EQEmulator - that's EQ1... uses Perl. These are plain-text files that can be easily edited, reloaded, and tested with bare minimum effort. Perl is easy, compared to the thought of writing C-code, having to compile it, upload it, test it and if it fails, start again. In this, LUA is "all the rage" out there now. So is Python, from what I read. There is a reason why these non-compiled script languages exist. Simplicity.
IMO, there is no reason to make this harder than we must. In order for this project to take on a life of it's own, we need to provide an engine that ANYONE can utilize. The Core is in place, let the ancillary crap be user friendly. Another major advantage to text-based scripting is the ability to allow your GMs or Admins to edit them remotely. Web pages to tweak quest scripts. What a novel concept.
Considering how much more complex the Quest engine is in EQ2 than EQ, we might all have to bite the bullet and go with something compiled/wrapped/injected. But until that time comes, or we have 20 eager developers jumping in to help, people need to keep simplicity in mind.
And I agree 100% with Diamante's performance risk analysis. It's nominal. This is not the 1980s. Hardware running a public emu should be quality, not crap.
A minimal learning curve.
DLLs (written in whatever C you want) are not for Joe Admin. There is no way we can expect Joe Admin to sit down with a C/C++ book and learn the language just so they can write quests for their server - be it Live-like quests or custom. I understand the concept of Wrappers. I understand the concept of GMScripts. I know how Ascent and MaNGoS do it. I run DAoC and L2J emulators and still cannot comprehend what they are doing in the quest department.
EQEmulator - that's EQ1... uses Perl. These are plain-text files that can be easily edited, reloaded, and tested with bare minimum effort. Perl is easy, compared to the thought of writing C-code, having to compile it, upload it, test it and if it fails, start again. In this, LUA is "all the rage" out there now. So is Python, from what I read. There is a reason why these non-compiled script languages exist. Simplicity.
IMO, there is no reason to make this harder than we must. In order for this project to take on a life of it's own, we need to provide an engine that ANYONE can utilize. The Core is in place, let the ancillary crap be user friendly. Another major advantage to text-based scripting is the ability to allow your GMs or Admins to edit them remotely. Web pages to tweak quest scripts. What a novel concept.
Considering how much more complex the Quest engine is in EQ2 than EQ, we might all have to bite the bullet and go with something compiled/wrapped/injected. But until that time comes, or we have 20 eager developers jumping in to help, people need to keep simplicity in mind.
And I agree 100% with Diamante's performance risk analysis. It's nominal. This is not the 1980s. Hardware running a public emu should be quality, not crap.
-
masterfreek64
- Posts: 36
- Joined: Fri Aug 03, 2007 6:02 am
Uh well ,
if we do an autocompile , autoreload system one can remote edit the binaries. Also we of course could make a little Python system for Joe admin as well - for easier stuff.
Look at Dawn Of Light Server Emulator - they can even do AI and other complex things from a script. Also, because EQ2s quest system is so much more complex , I think we ought to take performance seriously - especially if people would like to do really complex custom quests.
Take a quest that would control an entire dungeon instance for itself , and if the group completes a certain quest step , repositions all mobs to make escaping , or progressing harder ( makiong it look more realistic) .
These quest would require control of many of the games aspects.
With a core-near binary , we just call the corresponding function in the core and it is done.
With a script we are going to have to implement nearly thousands of wrapper functions to give user the customisability a good emu needs
if we do an autocompile , autoreload system one can remote edit the binaries. Also we of course could make a little Python system for Joe admin as well - for easier stuff.
Look at Dawn Of Light Server Emulator - they can even do AI and other complex things from a script. Also, because EQ2s quest system is so much more complex , I think we ought to take performance seriously - especially if people would like to do really complex custom quests.
Take a quest that would control an entire dungeon instance for itself , and if the group completes a certain quest step , repositions all mobs to make escaping , or progressing harder ( makiong it look more realistic) .
These quest would require control of many of the games aspects.
With a core-near binary , we just call the corresponding function in the core and it is done.
With a script we are going to have to implement nearly thousands of wrapper functions to give user the customisability a good emu needs
Who is online
Users browsing this forum: No registered users and 0 guests