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)

Wow.exe version 4.0.0.12911 (my installation) (...) I tried a lot of time searching where this 12911 could come from but ... Any idea ???

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.

I don't know if this has changed with addition of mmaps, but copying over the 'buildings' folder was not needed before.

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).

[*]Mining does not work correctly. I have a mining skill of 21, copper ore is orange to me, but I only had one skill increase after mining three times

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

Just trolled around on wowhead with quest http://old.wowhead.com/quest=12517

The current requirements for this quest are that you're level 10. You don't need to be a scribe to do the quest.

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).

So you can confirm that at retail mob can't go behind if run from front and no free place in from target?

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

Ppl don't care if those features are implemented in hack way or workaround...

Yes we do!! So speak for yourself please

I guess many of us are just bored to see only Schomoozed and Xfurry, Stfx and sometimes SilverIce to work on something...

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:

src/game/GridNotifiers.h: In constructor 'MaNGOS::NearestGameObjectEntryInPosRangeCheck::NearestGameObjectEntryInPosRangeCheck(const WorldObject&, uint32, float, float, float, float)':

src/game/GridNotifiers.h:642: warning: 'MaNGOS::NearestGameObjectEntryInPosRangeCheck::i_z' will be initialized after

src/game/GridNotifiers.h:641: warning: 'uint32 MaNGOS::NearestGameObjectEntryInPosRangeCheck::i_entry'

src/game/GridNotifiers.h:620: warning: when initialized here

src/game/GridNotifiers.h: In constructor 'MaNGOS::GameObjectEntryInPosRangeCheck::GameObjectEntryInPosRangeCheck(const WorldObject&, uint32, float, float, float, float)':

src/game/GridNotifiers.h:671: warning: 'MaNGOS::GameObjectEntryInPosRangeCheck::i_z' will be initialized after

src/game/GridNotifiers.h:670: warning: 'uint32 MaNGOS::GameObjectEntryInPosRangeCheck::i_entry'

src/game/GridNotifiers.h:653: warning: when initialized here

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

PS: thats no windows problem

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:

Exception code: C0000005 ACCESS_VIOLATION

...

Call stack:

Address Frame Function SourceFile

00427D6F 00000000 std::_Tree<std::_Tset_traits<unsigned int,std::less<unsigned int>,std::allocator<unsigned int>,0> >::_Eqrange+F

004188C2 00000000 std::_Tree<std::_Tset_traits<unsigned int,std::less<unsigned int>,std::allocator<unsigned int>,0> >::erase+22

00797714 00000000 BattleGround::~BattleGround+154

00850568 00000000 BattleGroundRL::~BattleGroundRL+18

0069454F 00000000 BattleGroundRL::`scalar deleting destructor'+F

0069207C 00000000 BattleGroundMgr::DeleteAllBattleGrounds+AC

0046381D 00000000 WorldRunnable::run+FD

00930219 00000000 ACE_Based::Thread::ThreadTask+19

01022E34 00000000 ?invoke@ACE_OS_Thread_Adapter@@UAEKXZ+74

78543433 00000000 _endthreadex+44

785434C7 00000000 _endthreadex+D8

7C57B388 00000000 lstrcmpiW+B7

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!

I also did not find any example of a map yell as each instance has only one zone (atleast in TBC and I think in WotLK as well)

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