Jump to content

Regarding Script Engines


Unkle Nuke

Recommended Posts

MaNGOS still uses forks of ScriptDev2 for EventAI scripting, which has come to a nearly complete stop.

Lets face it, using a systems programming language like C++ for scripting is just plain nuts. I've heard all the arguments from the "SD2 fanbois" a dozen times over. None of them hold any compelling reason or even technical justification for choosing to restrict script development only to those who can write OS-level code. Well, there actually were plenty of reasons... all of them political and backed by certain interests to ensure SD2 remained the defacto choice.

Meanwhile, there have been many attempts at creating a Lua-based scripting engine, with the promise of opening up a world of possibilities and making scripting accessible to the masses. Unfortunately, all but one of those projects flamed out after a short life.

However, it does beg the question - What will MaNGOS do now?

Already, the idea has been put out there to adopt Trinity Core's scripting engine. I see this as a negative for two reasons:

1. It makes us reliant upon yet another outside group for producing a vital part of our server. We've all seen how well that worked out in our partnerships with UDB, ScriptDev2, Project Silvermoon, and Eluna. Considering that Trinity was formed after a very nasty split with MaNGOS in 2008, it doesn't exactly inspire confidence in the longevity of a collaboration.

2. Besides all that, scripting with Trinity's SmartAI isn't much easier than using ScriptDev2. We'd be right back to using C++ as a scripting language. At best, that's only moving sideways. Aren't we supposed to move forward? Isn't the idea to have a scripting language even casual coders can pick up without burning out brain cells? To at last open things up so it has the potential of having hundreds of people working on scripts?

The way I see it, if we're going to borrow another project's code, we're better off forking Eluna or porting Ascent's Lua engine. Adapting Eluna to our needs would be easier, since it's already designed for a fork of MaNGOS. On the other hand, Ascent has a huge community of script writers and a massive library of scripts. But, porting their stuff and cleaning up/fixing scripts would be a big job.

Forking another project isn't as ideal as it sounds. If we end up having to fork and maintain their code ourselves, wouldn't that energy be better spent on our own work? If they change the headers or use other tricks to make life harder for our us, we've wasted a lot of effort undoing that mess so it won't break our code. Having in-house development of our own tools and code guarantees it will work as it should, builds our own sense of accomplishment, and bolsters pride in the MaNGOS name.

I believe we're better off developing our own script engine. Who says we have to use Lua? Python is a good choice. There's certainly far more Python experts and usable libraries out there for us to take advantage of in developing a Python engine.

That said, I tend to favor the idea of Lua because it's what Blizzard uses. It might be a lot of work to research and implement the Lua flavor used for WoW, but it means our scripts would have the same functionality as their retail counterparts.

Sooner or later, we have to get off the fence and make a choice. More importantly, we need people to get off their asses and commit to actively taking part in developing the engine and scripts we'll need, among many other things. MaNGOS is only as good as what you are willing to put into it!

Let's hear your thoughts.

Edit:

In light of Foereaper's remarks below and our recent conversation on Skype, I withdraw my assertion that Eluna abandoned our project to support Cmangos. The story is a bit complicated, but suffice to say that the Eluna team was mislead, and so were we, by individuals who were not dealing honestly with either project. My apologies to Foereaper and his team.

Link to comment
Share on other sites

Eluna is an odd one... And one where i can see the views of the project leader (Rochet) and Salja coming into difficulties.

Salja refused to use Mangos after the new build system was introduced and instead used the cmangos core instead.

Rochet's goal is to have a scripting system that is basically emu core independant, he would be happy to support us as well.

- Once Rel19 has finally left the build, the idea I had was that we get some input from Rochet on how to implement it into Mangos.

The way the Eluna library would be set up is as a subproject of mangos, that way - Whenever an update is pushed or required, we only need to update the subproject and hey presto it works.

- One question which I have never got to the bottom of (and don't have the time / expertise to investigate atm) is this: Salja always insisted that SD2 was vital for Eluna to work, where as theLuda was adamant it wasn't.

If anyone has any insight into that, I would be extremely grateful.

Link to comment
Share on other sites

Salja always insisted that SD2 was vital for Eluna to work, where as theLuda was adamant it wasn't.

I guess it depends on how you define vital. Just get it to work without concern about performance and scalability or get it to work as a real alternative to the current c++ scripts.

Interessting topic so far, im curious how the outcome will be...

Link to comment
Share on other sites

Salja always insisted that SD2 was vital for Eluna to work, where as theLuda was adamant it wasn't.

The only thing you need for Lua to work, is the required libraries. Luda was right, when Salja didn't know what he was talking about. SD2 is a crap library anyways.

Link to comment
Share on other sites

I figured I should chime in on a couple things that are brought up. Specifically the part about Eluna dropping any sort of support for any sort of core. Eluna was initially built on cmangos, so it has never really been built specifically for mangos alone. This was a decision made by Luda and Salja, as the cmangos core at the time was further down the development path than the mangos branch. Whenever we were done with initial Implementation, Luda was to implement and release Eluna with the core, which unfortunately never happened, leaving us hanging with no idea what was really going on. It has always been our goal to be officially released with Mangos, but the entire ordeal has pretty much hit a stand still with little to no communication with the Mangos team.

SD2 in and of itself is not needed what so ever for Eluna to be implemented, my personal preference would be for Eluna to phase it out, however this is not something that would be up to the Eluna team.

Also figured I'd chime in on the entire project leader part, both Rochet, Tommy and I are equally in charge of the project so if anyone want any information what so ever, all three of us are capable of answering and taking executive decisions :)

Edit :

To the original poster, mangos having its own script engine would be a terrible idea, Eluna already has the basics and necessities done, creating a new engine for scratch would be a huge waste of time, effort and resources, instead of contributing and working together on a unified engine that works across cores.

And for the love of god, stay away from arcs and ascents lua engine! They have some very nasty fundamentally flawed systems, I'm not saying Eluna is perfect either but it's definitely much better than the above.

Link to comment
Share on other sites

Hehe, you're fine, it's not that big of a deal to me at least, just figured for fairness sake that it should be mentioned :) And yes, I would like to have a proper discussion with all involved in getting the engine implemented, so we could get this show on the road.

Edit:

Figured I should bump this thread with some more information. Rochet and I had a chat with Antz and MadMax yesterday, and we all agreed on implementing Eluna into Rel19.

Edit:

Base implementation is now complete on Zero, Rel19 branch. Tested and working.

Edit:

I would still like some more opinions and such on the matter :) After all, it's you guys who will be using this!

Link to comment
Share on other sites

After having a very long chat with Antz, researching Eluna's work and community, and an equally enlightening chat with Foereaper, my concerns have been eased.

As for getting to know more about Eluna and their team, Foereaper has started a Q&A thread in the Dev Team sub-forum for discussion of more technical matters. All of our Dev Team members are encouraged to take advantage of this opportunity to get straight answers from one of Eluna's own admins.

So lets' see what you guys can do with Eluna, Foe. I mean... really impress! ;)

As for the purpose of this thread, has anyone else got anything to offer? Keep in mind that offering comments could result in your being drafted into service for starting a project to implement those ideas.

Footnote:

Before there is an uproar, I want to make it clear having Eluna on board is in no way to be taken as discouraging anyone from working upon other scripting methods. If you can do it better, then please do! But, we should also extend Eluna that same courtesy.

This is "Open Source, Open Learning, and Open Community" in action. May we always live by that philosophy.

Link to comment
Share on other sites

  • 5 months later...
  • 4 months later...
  • 11 months later...

The problem is not C++. The problem is that they use an API. And this API is nowhere documented. Even the fields in the database is nowhere exactly documented as well. So it is very hard to correct mistakes. For example it is almost impossible to understand how exactly the movement of the creatures work. The movement is horrible and I corrected already mistakes but it still go on my nervs how the creatures run into me. At least I reached that they stop trying to cuddle with me while fighting.

There are so many mistakes. Almost every quest has a mistake that must be correct. This is an incredible work. Without documentation it is even harder. The mechanics are very false and so on. Even if I could program very well in C++. It does not matter because I don't know the API. I had to read the whole source code and find out all by my own. That is a life time work.

Nevertheless I corrected many mistakes even in the source code and I dont know much C++. I still read a beginner book about basics. And yes I used some of the API too. But this is ridiculous. Even to install a mangoszero with a sourcecoude was very hard. I learned actually nothing about the technology but somehow this gave me an interest in programming. I found out that I have a certain talent for programming.

WoW is a waste of lifetime like every video"game". And to be honest I dont know why the people here put time in this project. Well I have an opinion why they do it. I doubt that they do it because they played the game. By reading some comments in the source code shows that the programmers probably never played WoW.

Okay Blizzard had screw up WoW totally and I wonder how anybody in this world still can play the official WoW of today. But WoW always was a waste of lifetime and always will be a waste of lifetime. It is a way to keep the slaves busy. Panem et circenses.

Link to comment
Share on other sites

Hi Danator, I fully appreciate your frustrations with the project.

When I took it over just over 2 years ago, there was virtually no documentation at all.

Myself and the team have worked tirelessly to get as much as possible documented.

I decided to start with the database and methodically work though and document what we knew and expand on it as we found more out.

- This became its own project in the name of dbdocs. The dbdocs editor was a tool written for users to help contribute updates to the database.

Despite what you might think, they are only about 3 devs currently active on mangos and that is across all the cores.

I work full time and have a family, mangos is my hobby and labour of love. I enjoy working on it and getting it improved.

- I also play wow even now too.

As you can appreciate, the combination of these factors seriously limits my time.

I will also normally attempt to help any windows user who is struggling to get their server set up, set up and working - this sometimes takes up a days development time for me.

- Luckily, I also coordinate the rest of the team and have input into what they are working on.

Another area where we have spent a huge amount of time is Eluna and SD3 scripting engines.

Eluna API calls are documented over at the emudevs site - If a call is not documented and you need some info, you have two port of calls.... either post on the emudevs forum or here (clearing mentioning Eluna) - the eluna team will attempt to answer it as best they can.

SD3 is now a combined library for Mangos Zero, One and Two on Rel21

- We are attempting to start documenting this properly rather than the poor documentation that currently exists, but this takes time. In the meantime, please post any questions on the forum and we will attempt to answer it.

If you don't get an answer, pm me and i'll attempt to get you an answer. I don't visit the forum as such as I should do :(

In recent months I have urged more and more people to post issues on the project tracker, its the only way we can clearly get a feel for what is wrong and attempt to fix it.

I am also trying to make the mangos wiki getMaNGOS WIKI to be the central place for all the information you need.

- Some areas are incomplete due to lack of manpower, again if you come across an area where we are missing information you need - let us know and we'll try and complete it for you.

I'll finish by saying this, MaNGOS is YOUR project as much as it is OURS - You can make a difference, whether it's code, db fixes, bug reports or documentation

- It all helps make mangos better

I hope this helps a little.

Regards

Antz

Link to comment
Share on other sites

The problem is not C++. The problem is that they use an API. And this API is nowhere documented.

This is the only possible strategy for chaotic/incoherent developing inherent to the open-source projects with manpower deficiency. The source code is the ultimate documentation. While most parts are really undocumented, the popular ones like C++ scripting AI have an acceptable description, like comments here, for example.

In between, the issue is rooted in the unknown wow client API. See, Blizz never had presented openly the packet structure and allowed communication patterns. Moreover, they make great efforts to hide the data since Cata client. Uncovering the protocol is the most complicated part of the same developing.

Even the fields in the database is nowhere exactly documented as well.

The best available Mangos-specific description is here for the Zero version. Yeah, it is incomplete, but to a great deal due to missing info about specific structures/fields used in the protocol.

I had to read the whole source code and find out all by my own. That is a life time work.

It is not. We all have the knowledge got exactly that way: 90% for reading the source and 10% for communicating with the colleagues. After ~2 years of that activity, you begin understand something. In particular, you realize that some principles that seemed initially wrong to you, have underlying ideas and natural limitations.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use