xeross155

Well for now you could write a script that gets triggered by your server wrapper script that queries the database for its current version and updates it as needed, and after that you launch the server.

C:\\Development\\one\\sql\\updates>updates.py

File "C:\\Development\\one\\sql\\updates\\updates.py", line 42

print 'ERROR! Could not finish updates!'

^

SyntaxError: invalid syntax

C:\\Development\\one\\sql\\updates>

Using this: http://lillecarl.ath.cx/paste/index.php/view/44130236 And Python 3

Don't use python 3

@Dark_Oppressor

1. You can indeed just compile the AHBot version directly, or merge it into a clean version of MaNGOS (Even make a patch), just take a look at the GIT tutorials in some subforum don't recall which one (I think it's called "Source code mastery")

2. Yes it takes a while for them to appear, how long I don't really know

3. Yes it uses this GUID to not require an actual character to exist for the auctions, it just takes the highest possible value for that variable type and if it the client asks the server for the name the server will check if it matches that and returns the configured name for the AHBot.

~Xeross

What I also wanted to do was make an easy way to disable mods during runtime, so they can be disabled with an in-game command, and then the ModMgr will check if a mod is enabled before firing its hooks or before calling its timer for example.

that should also be pretty easy to do with cipherCOMs eventsystem. just drop the hook from an event (-> remove it from the unordered_set) and you're done. creating a command for doing that shouldn't be too hard.

I know it isn't that hard, just stating it, but thanks for the reply anyway.

Xeross when you say "disabling a mod" you just mean stop it from running anymore right? i mean that could be made with just one public variable that you change with a gm command, but if you wanna make each script in its own "application extention" (.so, .dll) etc... and unload it from ram and such for later loading again, you should look at Xenos Scripts for tc2

For now it will simply be a toggle in the mod yes m_enabled (It's already implemented just not with commands), and once we move to .so/.dll based stuff I indeed want to look into actual reloading of the .so/.dll.

What I also wanted to do was make an easy way to disable mods during runtime, so they can be disabled with an in-game command, and then the ModMgr will check if a mod is enabled before firing its hooks or before calling its timer for example.

As far as I can tell DasBlub's event system works pretty much like a hooking system, you hook into events and the manager triggers the hooks.

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

It works but it doesn't work with CMake yet I think, just requires you to modify a few files.

No just temporarily stopped. I might pick it up again if I find the time

Well Cyber hasn't ticked it off in the main post yet

The reason it's not in the core yet is because it doesn't match the MaNGOS coding standard, once that's finished it should be accepted.

Aren't these just warnings

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.

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.

MaNGOS indeed has a lot of WoW related code, the only thing I use the MaNGOS source for when working on my own attempts at engines is to borrow ideas from it. For example the Log class and various other things such as the abstraction for Unit->Creature/Player, etc. more as inspiration than base.

That his is still on the first page after all that time.

Anyway, from what I've found the best approach for me to keep my work not-broken and easily manageable is to rebase it every time, thought this might not be desirable for public projects that people pull from, unless you only supply them with patches that is.

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

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.

Yes that's what I would want to eventually achieve

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

Disregard that, think I found it reupping.

Edit: enjoy http://www.mediafire.com/?ksu36nitt5c7naf

push the source on a git ...u will never lose it

I normally push it to GIT, think I did this project before actively using git for everything.

I'm currently writing some multi-mod thing that will have the broadcaster implemented, yet I can't promise anything for release dates, and the old one should still work fine if you manually apply a patch

Bots, ahbot, etc. Can all be done in core, though in some occasions that isn't the best choice.

Yet with AHBot you could run it in core (Or possibly make it use XML-RPC or SOAP or whatever ?), including advanced behaviour, etc.

Just a quick question, why is this still a sticky, from what I can tell it is quite outdated.