rumpa

Hehe... embarassing... after obviously well needed more catching up will I now instead use Mangos One for client 2.4.3 and not Mangos zero. In short, yes, I was trying to extract 1.12 client maps from a 2.4.3 client. // R

Rumpa = Butt, just to go offtopic a lil. And you must use DBC extractor from mangos repo with correct wow version, AND that y our client isnt broken Thanks for the reply... and yes, ad.exe is from the last retrieved repo. Client is also working as its fine with the current old MaNGOS installation from last year that I got.

Hello! Many thanks for the tutorial! I'm trying to get back into MaNGOS and get my old server from last year back up, and more or less giving it a fresh start as much seem to have happened! Gotten all the way to the actual map extraction part... and end up with: Map & DBC Extractor =================== Opening S:\\World of Warcraft/Data/patch.MPQ Opening S:\\World of Warcraft/Data/patch-2.MPQ Extracting dbc files... Extracted 0 DBC files Extracting maps... Read Map.dbc file... Fatal error: Invalid Map.dbc file format! ...we are still on the 2.4.3 client right...? The old \\News file showing requested client seem to be gone. There is a readme file mentioning "World of Warcraft Client Patch 1.12", but the mangoszero test site mention 2.4.3, so I'm confused (more then usual). Surely am I not to revert back to client 1.12?!?

Had the same issue. Thanks chrisgp, your solution worked like a charm. No idea if removing the two objects mess something else up, but here is the query needed for easy copy and paste for others: DELETE FROM mangos.gameobject WHERE guid IN (42508, 42509);

Yepp! My attempt on update pool_gameobject was based on the column name and its description in the wiki: "Chance the gameobject will be spawned in the pool. " I misinterpreted the description I guess.

Thank you The Wanderer! That did the trick! Much more reasonable amount of spawned minerals!!! JohnGreiner, hope it helps you too. Lynx3d, thanks. Shows that I shouldn't make assumptions on table columns based on their names.

Yes, I know. A happy coincidence when I registered made me register with that ID!

Hello again! Schmoozerd, thanks. I tried that, but am still seeing very few minerals. Is it OK to mention specific game areas in here...? In this case is the checking area G@rrison Armory. Very few even after the query. Also tried another approach, and it did increase a little, but not much there either: UPDATE pool_gameobject SET chance = chance + 50 WHERE description LIKE 'Mineral%'; Current MAX chance was 40, so above is easy to revert. Don't know if the chance field is % though and my coding skill is way to low to go into digging C++, so your assistance and suggestions are appreciated!

Thank you for the reply and explanation (I've never been on retail)! I better read up on features, been off from MaNGOS for way too long. *hangs head in shame*

Hello! Revision 1994 DB patched up to 11773, based on complete UDB + UDB patches up to 401 + additional mangos patches Hopefully can some helpful soul shed some light on a rather obscure issue! Quite a lot of gameobjects are simply missing in the game after startup. MaNGOS starts without problems, and reports for gameobjects: >> Loaded 101586 gameobjects There are LOTS of items in the game, but one item that is missing almost overall is gameobject with id = 1731, that is based on gameobject_template entry = 1731. Minerals overall are sorely lacking... Tried in-game adding an object with id 1731 (.gobject add 1731) and it appears without problem, respawns also. So just to test... in the db, I deleted all gameobjects with id = 1731 and then re-inserted all rows without specifying guid, having the db create new guid for all rows. So as an example for one row: delete from gameobject where id = 1731; insert into `gameobject` (`id`, `map`, `spawnMask`, `phaseMask`, `position_x`, `position_y`, `position_z`, `orientation`, `rotation0`, `rotation1`, `rotation2`, `rotation3`, `spawntimesecs`, `animprogress`, `state`) values('1731','0','1','1','-392','-1775','113.071','5.827','0','0','0','0','60','255','1'); All inserts are based on the original id = 1731 rows, given guids > 200000 (default I guess). Now every object with id 1731 appear as wanted after startup! But not a good solution of course this will mess upp guids and table dependencies, not to mention future patching will be a mess. Any ideas or thoughts???