Question regarding support for multiple Client Versions

dhmann · 3. Mai 2017, 16:36

Greetings ascemu-community,

I have a few questions regarding your plans to support several game versions with one branch, maybe this could be used as a thread for advantages and disadvantages of the different approaches how one could tackle this problem.

It seems like your goal is to have one codebase which works for Classic, TBC, Wotlk, and Cata depending on which flags you use to compile the sources.

Doesn't this overcomplicate a lot of things instead of making it easier to work with the code? Maybe I got the wrong idea but it seems like you want to do the following tasks:

-Split up the handling of the different DBCs
-Split up stat calculation, spells, scripts etc.

I have questions regarding how you seem to handle this:

Sometimes this projects uses giant #ifndef clauses to split up code, doesn't this just make the code way bigger and convoluted than it needs to be? Other times different systems seem to use just two different source files depending on which wow version is used. What is your final goal? Split them up in different files or have them all in one?

Another question I have regarding this is, how do you want to handle spells and scripts for instances/raids in this system?

Depending on which client versions the differences can be rather big. Whole raids changed, spells where completly changed. Does it really make sense to put them into one system instead of one system for every game version?

Eg: One Cataclysm Spellsystem, one for wotlk...

Not here to critizice, I just want to understand your design decisions and understand the bigger picture you want to achieve

What's the reasoning behind not just using different branches like every other emulator out there?

Best regards,
dhmann

Evairfairy · 3. Mai 2017, 18:03

Hi dhmann, thanks for your questions

It seems like your goal is to have one codebase which works for Classic, TBC, Wotlk, and Cata depending on which flags you use to compile the sources.

This is correct

Doesn't this overcomplicate a lot of things instead of making it easier to work with the code? Maybe I got the wrong idea but it seems like you want to do the following tasks:

-Split up the handling of the different DBCs
-Split up stat calculation, spells, scripts etc.

On the contrary, it makes it much simpler by forcing us to separate the core systems from the content. Right now you'll see things like stat calculations and spell effects inlined because it's easier to implement that way at the time, and then later on nobody ever goes back and fixes it. Forcing the separation of core logic and content ultimately will result in code that is easier to read and maintain, as it won't be possible to have "magic values" - operations such as stat calculations would have to be accessed through some kind of interface.

Sometimes this projects uses giant #ifndef clauses to split up code, doesn't this just make the code way bigger and convoluted than it needs to be? Other times different systems seem to use just two different source files depending on which wow version is used. What is your final goal? Split them up in different files or have them all in one?

This was caused by my own poor explanations and inactivity at the time we began the move to multiversion. Code for different versions will be split into separate .cpp files, always. The large ifdef statements you see are mostly from me not conveying the need to split code up. As for headers, it's a bit more complex.

It's not entirely decided yet, but for the most part all versions will share the same interface. Methods that will never be available on certain versions (such as achievements on classic and bc) are the tricky part - I'm not yet sure whether to wrap them in an ifdef (thus preventing them from ever being called in older builds) or just to nullsub them. The advantage of the former is that it prevents developers from accidentally implementing code that won't work on all versions. The advantage of the latter is that it makes code easier to read - going with the achievement example again, it'd mean the difference between something like:

C-Quellcode

void a_creature_death()
{
player->giveItem(1111);
player->giveAchievement(2222);
}

and:

C-Quellcode

void a_creature_death()
{
player->giveItem(1111);
#ifdef GAME_WOTLK
player->giveAchievement(2222);
#endif
}

I haven't put too much thought into it so there's probably a much better solution that I'm not thinking of, but as it stands we don't know yet.

Another question I have regarding this is, how do you want to handle spells and scripts for instances/raids in this system?

Most spell data is taken directly from DBC files, so there's no issue there. As for the spells that need their own scripts with complex logic that change across versions (I can't think of any off the top of my head but I'm sure they exist), it's easiest to just duplicate the spell script. There are few enough cases that we'd still benefit overall.

Instance and Raid scripts will be redone in Lua. As I see it, forcing people to write C++ "scripts" only serves to slow down development, over-complicate things and introduce additional points of failure. The only real advantage would be speed, and there are plenty of ways to script content in Lua that will result in it running just as fast (algorithms aside) as C++ code.

(I'd also like to try and move spell scripting to Lua, but one step at a time).

Depending on which client versions the differences can be rather big. Whole raids changed, spells where completly changed. Does it really make sense to put them into one system instead of one system for every game version?

Given the above answer, we'll be able to develop a model that will allow for version-specific script modifications. For instances that are completely different (e.g. deadmines in cata), we'll just have entirely separate scripts. We won't try to mash them together into a single unit.

Eg: One Cataclysm Spellsystem, one for wotlk...

The spell system will mostly stay the same

one of the main reasons for moving to multiversion is that there actually aren't that many differences between the fundamental logic of how mechanics are handled in each version. The numbers and calculations change, but an effect that "restores power" is going to do the same thing across all versions - give the target power back of a specific type. Even when mechanics are entirely different (such as normalised CC timers in PvP), it's so self contained that it's easy to add a check for it.

I hope that answers your questions. Let me know if I haven't.

Thanks!

dhmann · 3. Mai 2017, 20:21

Evairfairy schrieb:

This was caused by my own poor explanations and inactivity at the time we began the move to multiversion. Code for different versions will be split into separate .cpp files, always. The large ifdef statements you see are mostly from me not conveying the need to split code up. As for headers, it's a bit more complex.

That's fair. I was just very confused when I found this part in the source

Evairfairy schrieb:

's not entirely decided yet, but for the most part all versions will share the same interface. Methods that will never be available on certain versions (such as achievements on classic and bc) are the tricky part - I'm not yet sure whether to wrap them in an ifdef (thus preventing them from ever being called in older builds) or just to nullsub them. The advantage of the former is that it prevents developers from accidentally implementing code that won't work on all versions. The advantage of the latter is that it makes code easier to read - going with the achievement example again, it'd mean the difference between something like:

This is where I think it might get tricky. I never heard of #ifdef being good practice to use, but rather to only use it where it's really needed. In my opinion I think not using seperate files could result in even bigger spaghetti code than we have now, but I never needed to solve a problem like this, so I could be completely wrong here.

Evairfairy schrieb:

Instance and Raid scripts will be redone in Lua. As I see it, forcing people to write C++ "scripts" only serves to slow down development, over-complicate things and introduce additional points of failure. The only real advantage would be speed, and there are plenty of ways to script content in Lua that will result in it running just as fast (algorithms aside) as C++ code.

(I'd also like to try and move spell scripting to Lua, but one step at a time).

Woah... Wait... Are you sure about that? Is this final?

I already wanted to point out several things in the thread about Luabridge vs. LuaEngine.

I didn't look into whether you improved and fixed the LuaEngine from ArcEmu back in the day so I will assume its exactly the same System. Even when you patched a few things, I don't think it's salvageable, here's why:

The old LuaEngine has many problems:
-It's not properly threaded.
-Variables are always global. Want to run the same instance with two groups at the same time? The Boss will share their timers, phases etc. There are ways to circumvent this, but it's just a bunch of hackfixes that try to fix something that was broken from the beginning.
-It leaks memory all over the place when you make simple mistakes in your Lua scripts.
-While true that Lua CAN be executed at nearly the same speed as C++ Code, this Luaengine certainly does not... I can't seem to find the old discussions over at arcemu.org but they tested it, it's slow.

Reworking LuaEngine is WAY to much work. You could script everything up to legion in C++ in the time that you would probably need to fix up LuaEngine to a somewhat stable state.

I didn't really understand how you could drop support for Luabridge so quickly just because of a forum poll. Does no one remember why Luabridge was written?

It was made to eliminate the problems that arose with LuaEngine:
-Properly threaded scripts.
-Variables are not global.
-No more memory leaks! (In theory, I think it was never fully finished)
-WAY faster!

LuaBridge has one big problem though. It's a little bit harder to work with. There is not as much documentation around as for LuaEngine (could be written), some functions have different names(change the names), some are missing (easy to reimplement though).

Because people would not adapt to these few simple changes ArcEmu needed to still support LuaEngine and could never fully drop support, this slowed them down immensly at the end.

It was their own fault though, they didn't provide much documentation, so when they released LuaBridge no Lua-Developer had any idea what to do with it, no one realized how much better it is.

This project could make it different, but please think a bit more about it.
Lua is awesome for all sorts of custom content or to quickly try out some things, Lua scripting for other games and then WoW is what got me into programming 10 years ago in the first place.
But I don't think this project should use Lua as it's main scripting language. You would need to work around so many problems... Implementing custom Lua Functions which are only used for one Bossfight (Gunship Battle has few mechanics which are never used otherwise), fixing LuaEngine in the first place. I think in the end using Lua would make things even more complex and not simplify it, because you would constantly need to switch between C++ and Lua to implement new functions

Evairfairy schrieb:

The spell system will mostly stay the same one of the main reasons for moving to multiversion is that there actually aren't that many differences between the fundamental logic of how mechanics are handled in each version. The numbers and calculations change, but an effect that "restores power" is going to do the same thing across all versions - give the target power back of a specific type. Even when mechanics are entirely different (such as normalised CC timers in PvP), it's so self contained that it's easy to add a check for it.

Silly me, I meant talents

Cata was where they completly reworked talents, right? Stopped playing retail there

They where completly different if I remember right.

Thank you for taking time to answer to my questions, I appreciate it .

Evairfairy · 3. Mai 2017, 21:59

dhmann schrieb:

Woah... Wait... Are you sure about that? Is this final?

No.

Ultimately, the goal is to try and make things better for content developers. If this turns out to go against that goal, then we won't bother - so feel free to share any criticisms

I have nothing to do with LuaBridge/LuaEngine, I haven't had time to even begin looking into them, let alone make decisions about whether they should be scrapped.

Additionally, the idea I'm currently pursuing is to determine whether "scripting by configuration" (I don't know a real term for it, I made that up) is possible. What I mean by this is being able to dictate what an intelligent object should do and when it should do it, and having the core actually build and perform the logic for that. An obvious example is creatures - [cast a spell on the nearest player when health drops to 40%].

As far as I see it, the benefits would be:
- Not having to evaluate Lua in realtime immediately gets rid of a lot of the complexity involved in trying to scale dynamic scripting for an mmo server
- By forcing developers to rely on pre-existing implementations of things like targeting features, we can avoid a lot of the "private server" bugs that tend to crop up (like NPCs suddenly beginning to run away while casting)
- Elimination of speed concerns
- If done right, should make it much easier to determine what a given module does
- Effortless reloading at runtime (as the lua state does not need to be preserved)
- Eliminates many multiversion considerations with regards to achievements etc
- Can be extended to handle things that have to handled fast, like spell logic
- Can be extended to handle things like dialog in a more elegant way

The negatives I've come up with so far are:
- I haven't found any existing examples of this being done at scale (ai_agents is the closest thing I can think of)
- Initial complexity in creating the system
- Allowing for complex configuration of creature logic could lead to scripts being incredibly unwieldy if done poorly
- Edge cases would mean having to implement entirely separate target types etc
- May be difficult for others to figure it out - ultimately, there can't be content without content developers

dhmann schrieb:

I didn't look into whether you improved and fixed the LuaEngine from ArcEmu back in the day so I will assume its exactly the same System.

We have not touched the LuaEngine as far as I am aware.

dhmann schrieb:

Even when you patched a few things, I don't think it's salvageable, here's why:

The old LuaEngine has many problems:
-It's not properly threaded.
-Variables are always global. Want to run the same instance with two groups at the same time? The Boss will share their timers, phases etc. There are ways to circumvent this, but it's just a bunch of hackfixes that try to fix something that was broken from the beginning.
-It leaks memory all over the place when you make simple mistakes in your Lua scripts.
-While true that Lua CAN be executed at nearly the same speed as C++ Code, this Luaengine certainly does not... I can't seem to find the old discussions over at arcemu.org but they tested it, it's slow.

Reworking LuaEngine is WAY to much work. You could script everything up to legion in C++ in the time that you would probably need to fix up LuaEngine to a somewhat stable state.

I didn't really understand how you could drop support for Luabridge so quickly just because of a forum poll. Does no one remember why Luabridge was written?

It was made to eliminate the problems that arose with LuaEngine:
-Properly threaded scripts.
-Variables are not global.
-No more memory leaks! (In theory, I think it was never fully finished)
-WAY faster!

Thanks, I didn't know this. I haven't looked into the Lua system yet

dhmann schrieb:

This project could make it different, but please think a bit more about it.

We have literally dozens of major things to think about. Almost everything is open to change, especially right now. If you have any better ideas then by all means voice them.

dhmann schrieb:

I think in the end using Lua would make things even more complex and not simplify it, because you would constantly need to switch between C++ and Lua to implement new functions

We don't expect most developers to deep dive into the C++ code. We want to make it as easy as possible for people to develop content without having to dive into the C++ code.

As for the developers that do write C++, we want to provide as much abstraction as possible so that lesser skilled developers will find it as easy to work with the software as possible.

dhmann schrieb:

Silly me, I meant talents Cata was where they completly reworked talents, right? Stopped playing retail there They where completly different if I remember right.

Talents from Vanilla through Wrath were the same, and then the system changed enough that it'd probably be worth just having multiple separate classes for handling talents, and treat them as version-specific features.

Finally,

dhmann schrieb:

LuaBridge has one big problem though. It's a little bit harder to work with. There is not as much documentation around as for LuaEngine (could be written), some functions have different names(change the names), some are missing (easy to reimplement though).

Because people would not adapt to these few simple changes ArcEmu needed to still support LuaEngine and could never fully drop support, this slowed them down immensly at the end.

Separating the content scripting from the C++ code entirely is (in my opinion) a good way to ensure that we provide an appropriate Lua interface along with the necessary documentation to go with it.

We're not afraid to break things, so it really is just a case of ensuring we provide a viable alternative to the existing systems.

Hope that helps

dhmann · 4. Mai 2017, 10:16

Evairfairy schrieb:

Additionally, the idea I'm currently pursuing is to determine whether "scripting by configuration" (I don't know a real term for it, I made that up) is possible. What I mean by this is being able to dictate what an intelligent object should do and when it should do it, and having the core actually build and perform the logic for that. An obvious example is creatures - [cast a spell on the nearest player when health drops to 40%].

As far as I see it, the benefits would be:
- Not having to evaluate Lua in realtime immediately gets rid of a lot of the complexity involved in trying to scale dynamic scripting for an mmo server
- By forcing developers to rely on pre-existing implementations of things like targeting features, we can avoid a lot of the "private server" bugs that tend to crop up (like NPCs suddenly beginning to run away while casting)
- Elimination of speed concerns
- If done right, should make it much easier to determine what a given module does
- Effortless reloading at runtime (as the lua state does not need to be preserved)
- Eliminates many multiversion considerations with regards to achievements etc
- Can be extended to handle things that have to handled fast, like spell logic
- Can be extended to handle things like dialog in a more elegant way

Isn't this basically the System Trinitycore uses with the name SmartAI?

They save all the things they need like spells, equipment, class in a database, and the Core interpretes the logic and let's the Units act accordingly.

This System is used for every simple NPC, even for small Bosses which do not have extensive logic like phases, I think Deadmines is like 90% scripted in their Database.

The advantages are:
-Once the scripts are loaded from DB they are very memory friendly, as they are only a few data values and the core does the rest. No need to write logic for every single simple Spellcasting NPC.

In my eyes something like this is the right approach for simple scripts, C++ for advanced scripts and Lua as a temporary solution or for custom content.

Evairfairy schrieb:

Thanks, I didn't know this. I haven't looked into the Lua system yet

I may have overreacted a bit there

It's just, I have seen many ArcEmu forks try out the all Lua scripting approach over the years, and every time the same result came to light. It's way too limiting for advanced scripts, and making it viable is a tremendous task. In my eyes trying to make LuaEngine viable for the X time is wasted time and better invested in rewriting other systems that badly need a change.

Evairfairy schrieb:

Separating the content scripting from the C++ code entirely is (in my opinion) a good way to ensure that we provide an appropriate Lua interface along with the necessary documentation to go with it.

We're not afraid to break things, so it really is just a case of ensuring we provide a viable alternative to the existing systems.

Hope that helps

Evairfairy schrieb:

We don't expect most developers to deep dive into the C++ code. We want to make it as easy as possible for people to develop content without having to dive into the C++ code.

As for the developers that do write C++, we want to provide as much abstraction as possible so that lesser skilled developers will find it as easy to work with the software as possible.

I think this always works up to a certain degree. Simple and most old Bosses for example are fairly easy to script 100% Blizzlike. But some of the newer Bosses and Eventscripts need a deep unterstanding of the game mechanics and how the emulator works, at the latest content creators will need C++ skills there

I hope I didn't seem to negative in my posts

I am just honestly interested in what direction you want to go with this project and I wanted to point out the problems LuaEngine has.

Best regards,
dhmann

Evairfairy · 4. Mai 2017, 11:25

dhmann schrieb:

Isn't this basically the System Trinitycore uses with the name SmartAI?

To an extent, yes, except you can't see at a glance what any one creature is doing or how it may interact with others, the syntax is inherently limited and it's difficult to add new additional features to it.

dhmann schrieb:

I think this always works up to a certain degree. Simple and most old Bosses for example are fairly easy to script 100% Blizzlike. But some of the newer Bosses and Eventscripts need a deep unterstanding of the game mechanics and how the emulator works, at the latest content creators will need C++ skills there

I honestly don't believe this is the case, for a few reasons.

Firstly, the only time C++ is really necessary is when low level performance optimisations are required. Everything else can be logically represented in either C++ code or in Lua; if it can't, it's due to not exposing enough of the core through the Lua APIs.

Secondly, even if there are several custom mechanics that can only realistically be handled in C++ code, I believe we'd be better off just accomodating for that on a case-by-case basis and making the rest of it as generic as possible.

If you can think of anything you don't believe can be handled by Lua configurations then please let me know.

dhmann schrieb:

I hope I didn't seem to negative in my posts I am just honestly interested in what direction you want to go with this project and I wanted to point out the problems LuaEngine has.

I don't treat criticism as negativity, and I don't treat negativity as a bad thing.

If someone is being overly critical of something, it forces you to evaluate whether it really is the best course of action to take.

If someone is being overly negative of something, it forces you to think about whether the unhappiness caused by your change is sufficiently offset by the benefits of it.

dhmann · 4. Mai 2017, 12:34

Evairfairy schrieb:

I honestly don't believe this is the case, for a few reasons.

Firstly, the only time C++ is really necessary is when low level performance optimisations are required. Everything else can be logically represented in either C++ code or in Lua; if it can't, it's due to not exposing enough of the core through the Lua APIs.

This is what I meant. Doesn't this make things more prone to errors in the long run?

Instead of just having just a simple core script system you would need to put Lua on top of it, then if one of those systems is bugged for whatever reason you would need to backtrack if it's a fault with the LuaEngine or the Scriptsystem in general.

I think pursuing good C++ scripts first, and then maybe port everything over when then core systems work is a more feasible approach. Getting Lua to work as a fully usable script engine might take months, in the same time you could add basic C++ Scripts for every single instance and raid.

The reason why I am asking all this is because in the last few weeks I had the same idea of continuing to work on arcemu as a sideproject just for fun, then I found this project and thought it makes more sense to contribute to a project where already a few people are working on

I still got a few questscripts, raidfixes etc. lying around from back in the day somewhere, I wanted to clean them up and port them over.

But I see no reason in beginning to clean them up if this project doesn't want to use C++ scripts and rather wants to fix up Lua first. I for myself would see Lua as the lowest priority possible at the moment, as nearly everything else needs some work beforehand. But I thought getting a few more Quests to work for a few minutes of work might still be worth it because I already got most stuff done

I got a fully working script for the Quest "The Affray" for example. This Quest is reported as bugged in the issue tracker, I have a fix for it, should I withhold it because Lua needs to work properly beforehand?

I think I will try to fix a few additional open issues in the tracker in the meantime.

Point off all my ramblings are: I COULD fix up a few quests and stuff, but I won't be able to do so if I need to get Lua to work first

Evairfairy · 4. Mai 2017, 12:50

dhmann schrieb:

This is what I meant. Doesn't this make things more prone to errors in the long run?

Instead of just having just a simple core script system you would need to put Lua on top of it, then if one of those systems is bugged for whatever reason you would need to backtrack if it's a fault with the LuaEngine or the Scriptsystem in general.

I don't think this is an issue just due to how simple the Lua runtime actually is. If scripts were being interpreted as they were needed then yes, however any issues should be fairly easily picked up when loading the scripts.

Introducing additional points of failure is something to be mindful of, however I think the benefits outweigh the detriments.

dhmann schrieb:

I think pursuing good C++ scripts first, and then maybe port everything over when then core systems work is a more feasible approach. Getting Lua to work as a fully usable script engine might take months, in the same time you could add basic C++ Scripts for every single instance and raid.

I'm not sure if this is what you're referring to or not, but I think a good approach would be to pursue the scripting-by-configuration model but have that be done from C++ scripts instead of from Lua. I don't think it would take anywhere near "months" to get Lua to a usable state though, that seems like an extreme overestimate (inactivity not withstanding).

dhmann schrieb:

The reason why I am asking all this is because in the last few weeks I had the same idea of continuing to work on arcemu as a sideproject just for fun, then I found this project and thought it makes more sense to contribute to a project where already a few people are working on

I still got a few questscripts, raidfixes etc. lying around from back in the day somewhere, I wanted to clean them up and port them over. But I see no reason in beginning to clean them up if this project doesn't want to use C++ scripts and rather wants to fix up Lua first. I for myself would see Lua as the lowest priority possible at the moment, as nearly everything else needs some work beforehand. But I thought getting a few more Quests to work for a few minutes of work might still be worth it because I already got most stuff done

I got a fully working script for the Quest "The Affray" for example. This Quest is reported as bugged in the issue tracker, I have a fix for it, should I withhold it because Lua needs to work properly beforehand?

I think I will try to fix a few additional open issues in the tracker in the meantime.

Point off all my ramblings are: I COULD fix up a few quests and stuff, but I won't be able to do so if I need to get Lua to work first

Most of the time spent on fixing content is on research, it's not actually on development. Having working C++ scripts, even temporarily, is still going to be a massive benefit to the project. So don't be afraid of contributing if your concern is that it's wasted time, it's not

One thing I will say is to be mindful of the fact that all new contributions to the project are done under the MIT license, not the GPL or AGPL. This means you can't use existing code if that code is GPL licensed (unless you wrote it yourself, in which case you have the right to redistribute it under any license you like).

dhmann · 4. Mai 2017, 13:04

I don't know how skilled you are as a developer exactly, I only know every single developer back in the day at arcemu.org bit out their teeth while working on the LuaEngine, and there were some skilled people there. When only a few people over here can fix this up, that would be insanely good. I would totally Love this if its possible in the long run.

Do you plan to let the user decide if he wants to use the C++ or Lua library of scripts later on? This seems like a great idea instead of completely removing them at some point

I never used scripts I found somewhere on the internet, everything is self written or modified code thats already there.

What happens if I need to edit a source file that is from the time before you switched licenses? For example add a new function to an existing class?

Those function could be licensed under MIT but is in a GPL File... How ist something like this handled?

On my phone right now, formating this is hard. Sorry for that.

Evairfairy · 4. Mai 2017, 13:35

dhmann schrieb:

I don't know how skilled you are as a developer exactly, I only know every single developer back in the day at arcemu.org bit out their teeth while working on the LuaEngine, and there were some skilled people there.

I still have a lot to learn, but currently I'm probably the most skilled developer on the team. I've been doing this for a while now, and I'm currently employed as a software developer (albeit for .NET stuff) at a UK company. I'm perfectly comfortable writing and reading C++ code as well as making high-level design decisions about the project - though admittedly, that's probably one of my weaker areas

dhmann schrieb:

Do you plan to let the user decide if he wants to use the C++ or Lua library of scripts later on? This seems like a great idea instead of completely removing them at some point

We're not going to go out of our way to support it unless there's a good reason to, but we're also not going to just rip it out because we're not using it anymore. I don't think I can really answer that question at this point

dhmann schrieb:

I never used scripts I found somewhere on the internet, everything is self written or modified code thats already there.

Great, in that case you just need to familiarise yourself with the MIT License and make sure you're happy to distribute your code under that.

dhmann schrieb:

What happens if I need to edit a source file that is from the time before you switched licenses? For example add a new function to an existing class?

Generally, we seek to avoid editing old files. Where it's unavoidable, just wrap it in comments saying something like "MIT Start" and "MIT End".

We're not really worried about getting sued for GPL violations, it's more out of respect for the people that committed code under the GPL, as I suspect many of them aren't okay with the idea of releasing source code without restriction.

The MIT license is fully compatible with the AGPL, so it's perfectly fine for the code there to be used in a GPL context.

dhmann · 4. Mai 2017, 15:20

Evairfairy schrieb:

We're not going to go out of our way to support it unless there's a good reason to, but we're also not going to just rip it out because we're not using it anymore. I don't think I can really answer that question at this point

That's fair enough

Evairfairy schrieb:

Great, in that case you just need to familiarise yourself with the MIT License and make sure you're happy to distribute your code under that.

Haha yes I rather use MIT than aGPL, I am familiar with both.

Evairfairy schrieb:

Generally, we seek to avoid editing old files.

But what's the point in using the ArcEmu base then? If you plan to rewrite nearly every system why don't you just use MaNGOS instead?

What's the purpose of rewriting code just for the sake of it?

Evairfairy · 4. Mai 2017, 16:07

dhmann schrieb:

But what's the point in using the ArcEmu base then? If you plan to rewrite nearly every system why don't you just use MaNGOS instead?

What's the purpose of rewriting code just for the sake of it?

ArcEmu has a much better codebase to work from than MaNGOS, and we did not always plan to rewrite it. From a technical perspective, many of ArcEmu's core systems are very well written even to this day.

We also hope to continue the Ascent mentality of maintaining a high quality codebase, rather than rushing to implement features as quickly as possible and having code suffer as a result

C-Quellcode

C-Quellcode

Teilen