Le Froid

Confirmed. The low level areas seem to have the lowest amount of resources atm while the higher level areas have too many. In order to properly fix this we're going to need a pooling system.

[quote=gambit2312]I was already in a group[/quote] I just made a commit that will hopefully fix the crash. Please try the Dungeon Finder again after the Covenant server is updated to the latest revision. Sorry for the inconvenience

I'll see if there's a crash log for this so I can get to the root of the issue For the time being, were you in a group before doing the LFG or were you not grouped up?

[quote=gambit2312]why does seal of righteousness work on the ONE server and not in the TWO[/quote] I believe they changed the way it works with the release of WoTLK. I'll see if I can make a temporary fix for it, but there are [i]many[/i] spells that don't work properly atm and that's why I'm working on our spell system as a whole.

Confirmed. Another dev and myself are working on a complete rewrite of the spell system so it should work after that (as well as most other currently broken spells). By the way, have you happened to test the LFG system lately? I attempted to fix the last cause of it crashing the server but cannot test the patch myself.

Odd..I haven't ran into this bug before. I'll look into it.

Well, from looking at Player.cpp in Mangos two, the fields seem to be organized as [quote] uint32 playerBytes = .. (fetch playerBytes1) .. skin = uint8(playerBytes); face = uint8(playerBytes >> 8); hair style = uint8(playerBytes >> 16); hair color = uint8(playerBytes >> 24); uint32 playerBytes2 = .. (fetch playerBytes2) .. facial hair = uint8(playerBytes2 & 0xFF); [/quote] Since mangos handles data in little endian format, we can just split the first player bytes column into four separate ones for skin color, face, hair style and hair color. With the second column I'm not sure whether or not anything other than facial hair is stored there but if so it shouldn't take too long to find out what those bytes are used for. I can take care of this when I have spare time (not sure how long that will be), but if anyone would like to take a stab at this it shouldn't be hard. For instance, one of my characters has the following data in playerBytes(1): 50725129 All we would need to do is convert this into 50, 72, 51 and 29 for the four new fields and then reflect the minor change in the core. Edit: if it's just a matter of figuring out how this data is taken from the client, I should be able to figure that out in the next day or so.

Is this on the master branch or Rel19? IIRC there were quite a few database errors on the master branch from using our DB repo. I was able to fix most of them by applying the latest version of ACID off of their github page

Fixed in 8e091e (and more updates coming soon!)

Fixed in master, although the rune system needs a lot of work done to it!

I'd say it's mostly fixed in the master branch now, I just have to figure out how to give the player 2 extra runic power every 5 seconds.

I fixed this one in the Rel19 branch as well.

I should've fixed this in Rel19 although I'm not sure if the fix was implemented properly (still learning the intricacies of the spell system).

This one kind of works in the Rel19 branch, although I still have to do some work on it before it's completely functional. I'll continue fixing the death knight spells/talents after I finish working on the Dungeon Finder as well as updating the scripts and database for 19. You could probably compile a list of bugs a mile high in the master branch, it's in pretty bad shape atm :(

Yes, it worked fine on my end. I put 3 in for the spawnType in SpawnCreature which makes it a temporary summon and set its despawnTimer to 10 seconds.

The following script should fix that: [code] --[[ -= Script Information =- * Zone: Durotar * QuestId: 808 * Script Type: Quest * Npc: Spirit of Minshina ]]-- local questId = 808 local minshinaId = 3289 local gadrinId = 3188 -- quest giver -- -- Minshina's Skull - Summon Minshina on Completion -- local function Minshina_OnQuestComplete(event, player, creature, quest) if (quest:GetId() == questId) then local minshina = creature:SpawnCreature(minshinaId, -820.111, -4921.800, 19.321, 3.510, 3, 10000) if(minshina) then minshina:Emote(2) -- bowing emote end end end RegisterCreatureEvent(gadrinId, 33, Minshina_OnQuestComplete) [/code]

Glad I could help

If this works then that's great, but if for whatever reason it doesn't I'll share what I did to fix my compile. I copied dep/ACE_wrappers/ace/config-freebsd.h to dep/ACE_wrappers/ace/config.h and added #define ACE_HAS_MEMCPY_LOOP_UNROLL to it, and it worked when i rebuilt everything. By the way there was also a problem with compiling VMaps on FreeBSD for me, it took me a very long time to fix this and I'm not exactly sure which trick I did that actually worked, but I think that it was by editing contrib/vmap_extractor_v3/vmapextract/CMakeLists.txt under "LINK_DIRECTORIES" to put the full directory to libmpq. This would be something like changing to If that fails I would try adding the path to your libmpq binaries in csh (ex: setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/path/to/libmpq}

Yes they do.

Well like you said lillecarl it seems to be fixed in R2. I went through both the MaNGOS One code and R2's and it looks like One does have a (broken) implementation. But if anyone else is looking for the working (perhaps hacky?) code this is what R2 has in their SpellEffects.cpp: This replaces what mangos has under "// Mana Feed" in their SpellEffects.cpp

Yes it does, they implemented mmaps around the same time the main branch did.

I don't recall having this problem on my server. I was just in nagrand killing some ogres in caves with my warlock with no apparent vmap/LoS problems. This is on a MaNGOS One server so my thoughts are that either only the main branch has this bug or your files may be corrupted and you need to re-extract them.