[WIP] xMods - Making mods easier

[xeross155]

I've been working on this idea for a while now, I've got some code that I will share in the near future (Need to smooth it out a bit), okay now onto what this actually is.

I've been developing mods for some time now, and the problem I kept running into when updating them was that you would get merge conflicts everywhere when something in the modified files updates.

Now I've been thinking and why not make some kind of base system that only requires for a minimal amount of code on various locations.

So far I've implemented timed mods, and per-mod config files. I've managed to port both my External Mail patch to this system, and my announcer patch.

So the only things that are added to the source files of MaNGOS as of now are:

- The initialization of the ModManager (Well it only loads em for now but ok)

- A call in the World Update for the timers to work.

So it basically boils down to creating hooks for various things (PvP Kill, Bank Deposit, whatever you can think of), this way everything would pretty much keep functioning if something changes, the only thing that has to be updated is the mod manager and the actual hook calls.

Also currently the mods that are loaded in have to be statically included in a specific .cpp file, perhaps something for the future is that they are actually contained in DLL's.

So tell me what you think, comment on it, etc.

I have to be honest that it might all sound kinda vague, but perhaps it'll become clearer when I release the source.

ZOMG There is code \\o/

Well I decided to push what I have so far, it's really just an abstraction of timers and some per-mod config files.

Unfortunately one of the test mods got lost but my ExtMail and Broadcaster have been included and use the basic functionality that is available.

This is using the rsa modified mangos core because that's what I used (Unfortunately used) to run on my test server. just diffing it to the main rsa and then patching vanilla mangos should yield a working patch.

https://github.com/xeross/mangos/commits/xmods

Comments, random blabber and other bullshit related to this appreciated.

~Xeross

[Unkle Nuke]

If I understand your meaning, the proposed idea is that xMods would act as an API of sorts, operating as a layer between the MaNGOS core and a mod. Mod coders need not worry about core changes breaking their code. The mods would work as plug-ins for xMods.

Is that close to the mark?

[xeross155]

Yes that's what I would want to eventually achieve

[darkstalker]

this resembles me the idea of trinity's spell scripts

[shauren]

this resembles me the idea of trinity's spell scripts

not just spell scripts, entire script system

[Wortex]

Either way, this is much needed for developers whom wish to experiment and/or do stuff otherwise impossible due to merges.

If Xeross will succeed, the modifications of MaNGOS will become much more easier, therefore much more popular.

[Patman128]

It's not a bad idea, it would be nice to have mods separated.

[lecails]

So, Modmanager has its own function and mod use this function for work ? And Modmanager udapted his code when mangos updated but the function of Modmanager is always called whith the same way so mod working at all the time.Great idea,you can make a library so as ScriptDev2 For more mobilty.

So your project is a centralization of work on xMods update instead of update each feature.But I think its very complex, because each feature is pretty different so its great for small feature whith small code .

[Unkle Nuke]

I think that is the intent, lecails, making small or modular patches easier to write by only having to consider the xMods API. This allows the mod developers to concentrate on adding new features or improving their code, rather than spending half their time tracking down core changes and fixing the broken mod code.

I have difficulty seeing how a mod as large and complex as Playerbot would fit into xMods, and core mods that are intended to integrate directly with the core will continue to develop as they always have.

That said, would xMods work better as a scripting engine? This could simplify mod creation by having xScript commands that can be used without wondering about all the plumbing and how it plugs into the core. You might use a command like modValue to set or alter an integer or string of a known value, such as character HP or a mount's flying speed.

[mrelfire]

As as 'Customer', why not integrating 'quicker' 'mods', with options to switch on /off the mod

i.e autionhousebot more nearly 5 months in review mod and not integration or news

[DasBlub]

this remembers me at cipherCOM's eventsystem, which was a very good idea. i prefer his approach over yours as it's more general and it can also be used for SD2, ACID and even the core itself.

maybe someone (*looks at ciperCOM*) can pick the development up again and continue that idea?

[xeross155]

this remembers me at cipherCOM's eventsystem, which was a very good idea. i prefer his approach over yours as it's more general and it can also be used for SD2, ACID and even the core itself.

maybe someone (*looks at ciperCOM*) can pick the development up again and continue that idea?

From what I understand this is basically a huge collection of hooks that mods can hook into?

---

And with this thing, so far I've not really created an API and I really doubt whether this will become something of widespread use, but the concept is the interesting part.

I'll see if I can push out what I have so far, but it still lacks in-game commands, etc. (Although mod disabling/enabling is technically working). Currently also working on other projects though.

[xnxx10]

Other server system (write in C#) have this, and this was nice idea. Mods work as plugin, and i see even dota patch

[Wortex]

It would be even better if there would be away to simply load the .dll's out of a folder.

Somewhat like a lua, but built in C++ (the dll's I mean).

This might be the start of it, time will tell how dedicated Xeross will be hehe /cheers

[Patman128]

I think the best thing would have it load any DLLs in a folder ("mods" maybe?) and also allow them to be dynamically loaded/unloaded with the server running.

[Unkle Nuke]

I'm not sure what the technical merits are of using compiled DLL plug-ins vs. a scripting API. I favor the scripting method simply because it doesn't require the additional expertise of creating DLL files and would open the door for a lot more people to create mods. Although, I suppose xMods could be coded to compile included scripts as DLL files.

xeross is a gifted programmer, who has done some rather inventive mods and patches in the past, but, like any artist, he works as it suits his mood.

I sincerely do hope your mood is with this idea, xeross. I believe you will create something impressive. As the more youthful members might say of the completed xMods, "Dude! That's some serious code pwnage!"... or something to that effect. You do good work, period.

[Patman128]

I suppose the idea would be that there would be a basic template that most mod creators could copy/paste with all the basic stuff (basic code, project files, etc.) so they wouldn't have to do that, similar to universal (only actually used regularily)

This would be a scripting method, only each mod would be separated. Could you imagine a hundred different versions of ScriptDev2 being worked on by a hundred different people? Adding and removing patches would be hell. It's easier to keep it separated, and it would allow for more advanced things (loading/unloading mods on demand)

I like cipherCOM's system, but it is very complicated, and maybe needlessly. I don't see why using script hooks similar to the AI now wouldn't work with some sort of mod class to manage mods loading/unloading and calling the mod functions.

[Wortex]

Any news on this ? I'm quite excited to see the code/progress.

[xeross155]

Guess I should say hi again, I have unfortunately not worked on this lately, I have other projects that have had higher priority, and let's just say real life isn't exactly going well either.

Once some of my current projects that do not have an infinite running time have been finished I'll take a swing at further developing this.

I do really want the whole dynamic loading of DLLs but I simply do not have the required knowledge to do that, and I would want to have it cross-platform of course.

No progress has been made any more, but I guess I could release the current source to get some feedback/ideas (As I probably took a wrong approach for now).

I'll quickly see if I can dig up the code for it.

Edit: Enjoy

[dpedroia15]

Would it not be modular enough to introduce this concept to SD2 scripts?

I don't know how you're planning to do this, but if you make a basic "core mod" structure which people would implement by overriding certain methods they want to modify, it seems like it could fit nightly into SD2.

[xeross155]

Well each mod would in the end be a set of one or more classes that is isolated from other mods and that would invoke either some MaNGOS singleton or something in xMods itself.

[dpedroia15]

That's sort of what I'm getting at. I'm interested in how you're going to implement it. What I was suggesting was something like this (forgive me, I've been doing a lot of Java lately)

/*
* Basic mod superclass, has functions for each hook we're implementing
*/
abstract class Mod {

   abstract void onMonsterKill(ObjectGuid victimGUID, Player* killer);

   ...

   ...
}

// hooks placed in functions that we'd want to hook...I don't know if this is the best way to do it
// but for example we could have

void Player::KilledMonster( CreatureInfo const* cInfo, ObjectGuid guid )
{
   if(cInfo->Entry)
       KilledMonsterCredit(cInfo->Entry, guid);

   for(int i = 0; i < MAX_KILL_CREDIT; ++i)
       if(cInfo->KillCredit[i])
           KilledMonsterCredit(cInfo->KillCredit[i], guid);

   //hook here
   sModMgr.onMonsterKill(guid, this);
}

//and then the ModMgr would work like script manager and iterate through loaded mod scripts  for onMonsterKill
std::list<Mod*> loadedScripts;
...
void ModMgr::onMonsterKill(ObjectGuid victimGUID, Player* killer)
{
   for(std::list<Mod*>::iterator itr = loadedScripts.begin(); itr != loadedScripts.end(); ++itr)
   {
        Mod* mod = *itr;
        mod->onMonsterKill(victimGUID, killer);
   } 
}

I do not know much about how the whole ScriptMgr system works and whatnot ...nor am I too skilled with C++ but this is just a crude mockup of the idea I had.

[xeross155]

The best way to implement hooks would probably be with a central HookMgr so we can just so something like

sHookMgr->addHook(HOOK_MONSTER_KILL, funPtr);

And then add an sHookMgr->triggerHook(HOOK_MONSTER_KILL, cInfo); into the Player::KilledMonster function, or something similar, but I'll have to brush up on function pointers for this.

[lillecarl]

So if i get this correct, you will make something like "script hooks" that existed in both ascent and tc2 had/has? or what do you mean you want to do?

- LilleCarl

[xeross155]

Well that's the plan when I get to it, yes