Decision on mod-eluna’s future: Alignment with Eluna or Rebrand

[iThorgrim]

Hello everyone,

Following discussions with Foe (Eluna developer) and internal reflections, I would like to open a discussion about the future direction of mod-eluna. The main point of concern is the divergence between mod-eluna and Eluna:

• Eluna’s philosophy: provide a unified API across all emulators (TC, Mangos, AC) so that scripts are portable and consistent. Some features specific to a core may need to be adjusted or removed to achieve this.

• mod-eluna’s origin: AC needed hooks and methods that were not accepted in Eluna, creating divergence. Continuing independently may further increase differences, even though both share the Eluna name and branding.

There are two main options to consider:
Option 1 — Align with Eluna (main)

• Advantages:
  • Cross-core script compatibility.
  • Easier maintenance thanks to upstream Eluna development.
  • Stable and consistent API for users.
  • Leverage contributions from the centralized Eluna team.
• Considerations:
  • Some AC-specific features may need to be modified or removed.
  • Less flexibility to implement rapid AC-specific changes.
  • Requires adapting existing AC scripts to the unified API.
  • Dependence on the direction of the parent Eluna project.

Option 2 — Rebrand mod-eluna and remain independent

• Advantages:
  • Full freedom to implement AC-specific hooks and methods.
  • Faster evolution according to AC-specific needs.
  • Control over branding and project roadmap.
  • Ability to define AC-specific priorities and design choices.
• Considerations:
  • Scripts will be AC-specific and may need adaptation to run on other cores.
  • Maintenance effort may be higher to manage differences between cores.
  • Coordination with upstream Eluna changes will be optional, requiring independent updates.

---

Question to contributors:
Which direction should we take for mod-eluna ? (Make yourself understood in the comments or by using the following two reactions)

🚀 - Align mod-eluna with Eluna.
❤️ - Rebrand mod-eluna and maintain full independence.

The goal is to ensure clarity for developers and users while balancing cross-core compatibility and feature flexibility. Feedback will be summarized and next steps proposed after contributions are collected.

[Doodihealz]

Personally I am down for aligning. It's extremely frustrating to get a user who says my scripts are throwing out error after error, only to find out they're using a different Eluna. I used to rebuild it a second time with the other Eluna but gave up on that.

[FrancescoBorzi]

My 2 cents: the ideal scenario would be aligning with Eluna, if we could somehow find a way to prevent this:

Some AC-specific features may need to be modified or removed.

Eluna could just throw an error for functionality that is AC-only because the other emus don't support it, something like "This feature is not available in your emu", hoping that the other emus will support more and more of those, and we reach full feature equality.

But I do see the difficulty of achieving this, which is why I'm not casting my vote for any option.

[Foereaper]

My 2 cents: the ideal scenario would be aligning with Eluna, if we could somehow find a way to prevent this:

Some AC-specific features may need to be modified or removed.

Eluna could just throw an error for functionality that is AC-only because the other emus don't support it, something like "This feature is not available in your emu", hoping that the other emus will support more and more of those, and we reach full feature equality.

But I do see the difficulty of achieving this, which is why I'm not casting my vote for any option.

Support for this already exists for methods, but the caveat still exists that a feature should be implementable on other cores. This will require some review, and if a feature is found to not align with the overall direction of the project, then the feature will not be implemented.

A good example of this is the http methods, they would never be accepted on the other emulators, there are frankly better ways to support this instead of adding core and engine support for a niche feature. Same with the Halaa specific methods.

In the end, if we allow for just anything, then we end back up with a divergence that shouldn't exist to begin with. Sure, you'd get a message saying that x feature isn't implemented, but for the end user the result is the same; they'd have to port their scripts between emulators, and that breaks with the whole idea of Eluna.

Final note: Eluna does support a custom methods header file that users can drop in. AC specific features could possibly be implemented here, but this is primarily meant for end users to add features they specifically need for their own projects. I don't want this to become a crutch for implementing core specific things which leads back to divergence.

[FrancescoBorzi]

Given the above, what I'd do is then:

• Have an Eluna's fork for AC but try to keep it as aligned as possible with Eluna upstream
• Keep the additions minimal and only for those cases where they are strictly required
• Provide a small AC-Eluna documentation underlying the differences and addition, refer to the official Eluna's documentation for the rest

[FrancescoBorzi]

(and ideally AC contributors should always send PRs directly to the main Eluna repo, not to the AC's fork. The fork should just have minimal changes...)

[Foereaper]

Given the above, what I'd do is then:

• Have an Eluna's fork for AC but try to keep it as aligned as possible with Eluna upstream
• Keep the additions minimal and only for those cases where they are strictly required
• Provide a small AC-Eluna documentation underlying the differences and addition, refer to the official Eluna's documentation for the rest

In that specific case I'd much rather you fork and rebrand if I'm being completely honest, because that is pretty much where we are today. The overhead on support and API divergence isn't solved, and end users take the hit on their scripts not being portable across emulators.

[heyitsbench]

Is it possible to use an additional module to expand Lua functionality to have this repo be aligned and have any AC specific features be relegated to that module? I suspect not, but I figure I should ask.

[Foereaper]

Is it possible to use an additional module to expand Lua functionality to have this repo be aligned and have any AC specific features be relegated to that module? I suspect not, but I figure I should ask.

Eluna supports both C modules and like mentioned the CustomMethods header file to expand functionality, but this is primarily for end users to expand their own functionality and make it less likely for them to have merge conflicts. I obviously can't stop (and don't necessarily want to stop) anyone from releasing their own custom methods, modules and header, but honestly this is just skirting the issue, no?

It would de-facto be the same situation as it is now, where "additional" functionality is released by the emulator, leading to divergence and lack of portability. I imagine it would be included by default and/or highly encouraged for AC users to use said extra functions, so again, at that point you might as well break away and rebrand entirely.

To make it clear, I think the best thing for the emulation community as a whole is to have a unified scripting experience across emulators, so don't get me wrong and think that I'm pushing for a split. I just have to stick by the ideology of the project, even if that means I have to be a bit of a hardass.

I genuinely don't think the loss of whatever niche functionality the module has compared to the parent repo would be as bad as it might seem, and I'm not saying functionality would never be expanded, I'm just saying that it has to be done in a way that benefits everyone and not just a single emulator.

[heyitsbench]

I'm just saying that it has to be done in a way that benefits everyone and not just a single emulator.

This I fully understand and agree with, and is the main reason I reacted to the post in the direction of aligning the module.

I imagine it would be included by default

I moreso meant an additional module on top of this module, but...

and/or highly encouraged for AC users to use said extra functions

...this I can't argue against.

[mostlynick3]

I think there's a few more considerations to be had in this discussion, namely:

1. AzerothCore is (currently) the largest and most actively maintained emulator that supports Eluna.
2. AzerothCore supports more hooks than any of the other emulators. For better and for worse, many of these extra hooks are actively in use by large parts of the mod-Eluna community.

There is already some minor discrepancies between what Mangos and TC's Eluna versions support, which are clarified in the documentation of the master project. Implementing a piecemeal option where anything extra from AC is PR-ed upstream would expand the preexisting discrepancies, though it would arguably follow suit with the Mangos/TC differences in mind.

However, in my impression, the Mangos/TC differences aren't emphasized much because Mangos has relatively few users. The TC/AC differences are much more noticeable because of the emulators being the most popular in the scene.

If AC is to forego custom implementations simply to adhere to the parent project, the point of forking from TC way back when is lost on Eluna. This is merely the nature of forks; projects and daughter projects diverge to better suit the needs of the maintainers/community. As it stands, many of AC's custom changes are greatly used in the AC community, and removing them would no doubt upset active users.

In a way, the argument then becomes a matter of:
(a) Catering to newcomers to the scene, that may be thrown off by the "different Elunas", and catering to seasoned Eluna users that support for newcomers
(b) Versus catering to the needs and use-cases of active AC Lua developers

As issue (a) could be mitigated by rebranding, and issue (b) could be solved by maintaining a separate fork, I believe rebranding is the most suitable option.

As a concluding note, I would also like to see the fork going one step further and ensuring that the codestyle of the mod aligns with the parent project, so extra features added to the mod can easily be implemented upstream and vice versa. This would then solely be a responsibility of the mod, not the parent project, to ensure at least a high degree of compatibility between the projects, while still keeping the branding, and the corresponding docs, separate.

[Foereaper]

If AC is to forego custom implementations simply to adhere to the parent project, the point of forking from TC way back when is lost on Eluna.

Maybe I'm the cause of this discussion seeming so black or white with my aforementioned stance, but just to be clear, I'm not saying that AC's changes would always be dropped and no development drive from AC would ever make it into the parent repo. What I'm saying is that there needs to be some sort of agreement that not everything should be implemented just because it can be implemented. For existing content that has 3 outcomes:

1. The proposed changes are fine and gets merged with upstream
2. The proposed changes are fine in spirit but not necessarily in implementation, and needs to be amended
3. The proposed changes are not fine and will not be merged with upstream

Which category something lands in obviously depends on what the proposed change is, and the majority of AC's custom changes that lands in 1 or 2 has already been ported.

So no, forks aren't lost on us/me, I completely understand the need and want for developmental freedom, and that's okay. But in that case, we have two different products, and two products sharing a name is bad for everyone.

[iThorgrim]

I have carefully read all the feedback, and I believe that the arguments presented on both "sides" are valid and worth considering.
After some reflection, I have decided to adopt an approach that combines both solutions.

---

1. Renaming and Evolution of the Module

The project mod-eluna will be renamed to avoid any ambiguity and to clearly mark the difference from the official Eluna project.
Some internal adjustments (mainly related to naming) will also be applied.

We will continue to maintain and provide updates for this module, while making it clear that it is not compatible with official Eluna and is designed specifically for AzerothCore.

---

2. An Alternative for Developers

At the same time, for those who would like to use an AzerothCore version that directly integrates Eluna (and is therefore compatible with all Eluna scripts), I spent the last two days working on a complete integration of Eluna into AzerothCore.

You now have two options:

• Use the existing fork:
  https://github.com/ElunaScripts/ElunaAzerothCore/tree/master

  ⚠️ Note: after running

  git submodule update --init

  you will need to manually switch the branch of src/server/game/LuaEngine to ac.
  The full command is:

  git submodule update --init && cd src/server/game/LuaEngine && git switch ac && git pull

• Apply a patch directly:
  For those who do not want to use the fork, I have also generated a .diff file containing all necessary modifications. https://raw.githubusercontent.com/ElunaScripts/ElunaAzerothCore/refs/heads/master/eluna.diff

---

3. Limitations and Clarifications

I want to make it clear that I have only performed minor tests.
It is therefore possible that some errors or oversights may still exist.

The main goal here was not to deliver a perfect, final solution right away, but rather to provide a solid and nearly plug-and-play option for those who want an Eluna integration compatible with the entire Eluna scripts ecosystem.

---

Summary

• The renamed module remains the solution specifically tailored for AzerothCore, with its own development path.
• The Eluna fork/patch offers an alternative for those who want full compatibility with Eluna scripts.

This way, everyone is free to choose the option that best fits their needs.

---

I wish you all a great day and good luck with your projects!