evilatwow

Well, I do check it whenever I need info about the DB tables...which is quite often. But to be honest I often fall back to the WoTLK version soon because the table I want is not documented yet. The differences between TBC and WoTLK aren't massive, so that's usually good enough for me to figure out what I wanted to know. So: yes, there's interest here, but to be honest probably not enough to warrant the effort if I'm like the only one (or even if there's only a few people)

Hmm... the servers went from 3.3.5 straight to 4.0.1 if I remember correctly, so there never was a 4.0.0 on live servers. So I would guess you installed it from the Cata DVD (without patching it afterwards) or even got some PTR/beta build.

Remember that git keeps all info about a repository locally on disk, so now that you've cloned it in ScriptDev2, you can just rename that folder and you should be fine As an alternative, you can edit the CMakeLists.txt file in src/bindings too. You'll see something like add_subdirectory. Change the directory to what you have now and you should be fine too.

And that remains the same - it's not needed to run your server; it's intermediate output for (at least) generating the vmaps

I agree with stfx here - the link works fine even with http (using Opera on Linux).

It's probably a silly question, but the "mining three times" was on different deposits right? Because it used to be that you had to mine several times to get all ore etc from a single deposit, which only once gave a skill up if appropriate. These days on offi (since WoTLK I believe, but I'm not sure), you mine once and get everything a deposit contains at once.

No, the buildings folder is an intermediate folder created by the extractor, and used as input for the assembler. Once you have your vmaps, you can delete it again

Fortunately I can The issue was fixed for master in this commit and for One in this commit

Is this true? I can't comment on the level requirement, but I'm sure that you don't need inscription to use that deck to summon the npc and hand in the quest. I did it with an 85 character (but note that we have 4.3 now on live of course).

That seems to be what happens, yes, although I realize a few tests aren't real proof. For what it's worth then: I did a few tests in the Cathedral of Darkness (Icecrown zone), because there are many mobs in there that respawn fast. Even when pulling lots of zealots from both sides, they run to me and stay in front of me, despite the fact there isn't really room for all of them to spread out (sometimes I pulled more than 25 zealots at once). They all spread around as nicely as possible (even if the results looks 'very crowded') in a 180 degrees cone (half a circle). I got the same behavior in Stockades and Zul'Farrak when pulling like half the instance at once; though in Zul'Farrak casters stayed at a distance of course, while melee filled half the circle in front of me But like I said: it's not a proof, but a good indication

The pooling mentioned is a system in the server core to be able to say "<this> can spawn in one of several locations", but in the end it's up to your database to make use of it (or not). I don't know about your database, but I think the herbs aren't pooled yet in UDB (not in TBC-DB, their 2.4.3 version, anyway). In that case, there's probably not much you can do yet except delete a few herbs spawns in your database

Yes we do!! So speak for yourself please So, what's keeping you to get started then? 'We must do something' is the unanimous refrain. 'You begin' is the deadening refrain.

There is not much point for well written code. The only point I can see for them is a 'stupidity check' for people that use their own members in initializer lists. Like this: struct A { A() : j(0), i (j) {} int i, j; }; You'd be surprised how many bugs I've discovered in my professional life using that warning. But that aside... my point is this warning is apparently on by default for MaNGOS and a handful of headers are causing so many warnings - because they are included everywhere - that we don't see the real warnings any more. Since a fix for them is trivial, I didn't see why I wouldn't fix them. In a perfect world, all code compiles warning free with -Wall

Check the wiki page and search for 'GAMEOBJECT_TYPE_BUTTON' to see what data should be in those data fields

Patch made against ManGOS One s1434, but the same issue is still present in Master. What bug does this patch fix? I noticed that moving items around in a guild bank tab causes these moves to be appended to the tab's log. That shouldn't be the case. It also fixes a 'typo': splited => split Who wrote the patch? I did (github user evil-at-wow). Additional notes Just for clarity, the following is the intended behavior. Logged: putting items in the guild bank (character inventory to guild bank) retrieving items from the guild bank (guild bank to character inventory) moving items from one tab of the guild bank to a different tab, even when splitting or merging stacks Not logged: moving items from a slot to a different slot on the same tab of a guild bank splitting a stack of items within the same tab of a guild bank merging stacks of items within the same tab of a guild bank Or in summary: anything that does not change the content of a guild bank tab (the total amount and kind of items) should not be logged. Patch: http://paste2.org/p/1818770

And it's even easier to pipe the build output to /dev/null, so I don't see any other warnings either! But that's not the point. It's trivial to fix those warnings, so why wouldn't we just fix them?

Patch made against ManGOS One s1434. I took the liberty to get rid of a few hundred GCC compiler warnings when building MaNGOS. I just changed a handful of initializer lists where members were not in the order mentioned in the class definition. This fixes compiler warnings like this: I also removed the <iostream> include in GridNotifiers.h, because I don't see why it is needed. Patch: http://paste2.org/p/1799751

Yeah, I figured that there was an important difference between the bracket IDs in Zero/One and Master. Good to see that confirmed; so I agree with your fix No, it's not, it's a problem in general But for whatever reason, this crash was only showing on my Windows box and not on the Linux machine. Must have been lucky there

I recently updated to a mangos-one server r1338, and noticed the server crashes every time I shut it down. Though it seems to run fine otherwise, I still find this annoying so I checked it out. The revision isn't important as the latest code still has the problem. And it also happened with the default empty databases, and when just shutting down the server immediately after it's started up (so no need to enter the world first or something). The crash logs gave me a first hint: There's not much info here since it's a release build, but I figured it out nevertheless. The erase call that happens from the BattleGround destructor is actually this code: sBattleGroundMgr.DeleteClientVisibleInstanceId(GetTypeID(), GetBracketId(), GetClientInstanceID()); That code is doing the erase: void DeleteClientVisibleInstanceId(BattleGroundTypeId bgTypeId, BattleGroundBracketId bracket_id, uint32 clientInstanceID) { m_ClientBattleGroundIds[bgTypeId][bracket_id].erase(clientInstanceID); } Upon inspection of some relevant code, I think this is what happens: 1. BattleGround.h includes an enum: enum BattleGroundBracketId { BG_BRACKET_ID_FIRST = 0, BG_BRACKET_ID_LAST = 6, MAX_BATTLEGROUND_BRACKETS = 7 }; 2. The BattleGroundMgr class has the following member: ClientBattleGroundIdSet m_ClientBattleGroundIds[MAX_BATTLEGROUND_TYPE_ID][MAX_BATTLEGROUND_BRACKETS]; 3. Battlegrounds are constructed while starting up the server (or at least 'bg templates' are). 4. The constructor, BattleGround::BattleGround(), sets the m_BracketId member to MAX_BATTLEGROUND_BRACKETS. 5. When shutting down the server, BattleGroundMgr::DeleteAllBattleGrounds() gets called, which will delete the battlegrounds. 6. The BattleGround destructor will call DeleteClientVisibleInstanceId, passing it MAX_BATTLEGROUND_BRACKETS as bracket ID. 7. The DeleteClientVisibleInstanceId tries to call erase on m_ClientBattleGroundIds[<type id>][MAX_BATTLEGROUND_BRACKETS], but that one is outside of the valid range of the array, since in C/C++ array indexes start at 0, so this crashes. As a temporarily workaround I've changed the BattleGroundMgr member as follows: ClientBattleGroundIdSet m_ClientBattleGroundIds[MAX_BATTLEGROUND_TYPE_ID][MAX_BATTLEGROUND_BRACKETS+1]; As can be expected, this fixed my crash. I've seen that the BattleGround constructor mentions "// use as mark bg template" in the comments when setting the m_BracketId member to MAX_BATTLEGROUND_BRACKETS, and I'm not sure what the bg template stuff is all about. So I doubt my fix is a proper one (which is why I used the word workaround). The main branch of MaNGOS seems to set this member to BG_BRACKET_ID_FIRST. This would also fix the problem, but there is no mention of the "bg template" stuff any more, so I'm not sure if that's a good idea or what difference it could make. So I'll leave the real fix to the experts, and hope my findings provide enough info

I always forget about that zone being part of Northrend Well spotted though!

You probably have two machines in your network: 1. The machine running the server, let's call it "server". 2. The machine seen from outside your LAN; typically your router/firewall (might be a little box or another computer). Let's call it "firewall". I'll assume you are running both the realm and world executables on the "server" to make things easier, the realm listening on port 3724 and the world on port 8085 (you can change that in the config files if you want to, but let's keep it at this). 1. Forward port 3724 from "firewall" to "server". I think you've done this already, since you can see the realms from outside. 2. Forward port 8085 from "firewall" to "server". 3. Make sure that the world info in the database, '<realm database>.realmlist' table, is matching the setup AS SEEN FROM OUTSIDE. This means that the 'address' field should be set to your EXTERNAL address, ie the hostname (or IP in theory, see step 4) your friends are seeing (the same they use to connect to your realm I suppose) and that the port is set 8085. This should allow your friends to connect if the world port is forwarded properly (step 2), because the realm daemon will send them this info. 4. Make sure YOU can connect too. Since your client will also get the same info from the realm daemon, this might be a bit tricky since you are on your network after all, so the external IP might not work. I use a hostname in the realmlist database that resolves to my EXTERNAL IP from outside, and make sure that hostname converts to a local IP for machines in my network (by setting it to a fixed IP in /etc/hosts, but I'm on Linux). The trick is to realize that both you, on the LAN, and your friends, outside the LAN, will get the same address info from the realm daemon to connect to the world. Then make sure that translates to the correct machine and port, and you should be fine. Happy gaming!

The northrend fishing contest could be an example I think (map with different zones). You can see the yell in each zone of northrend when the contest is announced.

They are still working on it. Have patience and good things will come

On second thought, I think we don't event want to backport [7125]! I was probably somewhat asleep when I considered giving that merge a go, but then I realized the talent trees were introduced in 3.x while TBC was using the talent point system and pet trainers! So there is no such things as pet talents in One. Now instead of using the (number of) known spells, we could check the number of (free) talent points instead I think. I'll see if I can work out something.

The code in master makes sense: it just avoids unlearning when the pet has no talents, basically meaning it is already/still in the unlearned state. The code in One isn't using talents, so the question is if we can map that talent state to the (number of) spells. I tested a bit more, and even the old check (<= 1) is not working properly: I can keep unlearning although I've just unlearned. So it's not blocking properly even with that condition. Further debugging showed why: my pet, a cat, has 14 spells after unlearning! The reason is they are added after unlearning by Pet::LearnPetPassives, so spells like 17210, 19580, 19581 etc are always known. My conclusion is that even the original condition isn't properly (at least not in all cases), so whether we write <= 1 or just check for size 0 doesn't matter at all. Heck, we might just as well get rid of that condition as it is, since it's not working anyway... Perhaps I should give merging that talent code a go instead