The Wanderer

If you're talking about the UDB Forum thread I think you're talking about, these may be the queries you're referring to. If not, please excuse the intrusion. update pool_template pt join (select pgo.pool_entry, count(1) zone_total from pool_gameobject pgo join pool_template pt on pgo.pool_entry=pt.entry where pt.description like "MASTER%" or pt.description like "%MASTER" group by pool_entry) tpgo on pt.entry = tpgo.pool_entry set pt.max_limit=ceil(tpgo.zone_total/3); update pool_template pt join (select pp.mother_pool, count(1) pool_total from pool_pool pp join pool_template pt on pp.mother_pool=pt.entry where pt.description like "MASTER%" or pt.description like "%MASTER" group by mother_pool) tpp on pt.entry = tpp.mother_pool set pt.max_limit=ceil(tpp.pool_total/3); These set the number of "active" spawns of each category in each zone to 1/3 of the total number of available spawns for that category in that zone, rounding up. This fraction was chosen arbitrarily, and it isn't thoroughly tested, but may be an improvement; YMMV. If you can come up with a better way of deciding what fraction of spawns to activate, please share. To preview the changes these updates will make, use these queries: select pt.description, pt.max_limit, ceil(tpgo.zone_total/3) new_limit from pool_template pt join (select pgo.pool_entry, count(1) zone_total from pool_gameobject pgo join pool_template pt on pgo.pool_entry=pt.entry where pt.description like "MASTER%" or pt.description like "%MASTER" group by pool_entry) tpgo on pt.entry = tpgo.pool_entry order by description; select pt.description, pt.max_limit, ceil(tpp.pool_total/3) new_limit from pool_template pt join (select pp.mother_pool, count(1) pool_total from pool_pool pp join pool_template pt on pp.mother_pool=pt.entry where pt.description like "MASTER%" or pt.description like "%MASTER" group by mother_pool) tpp on pt.entry = tpp.mother_pool order by description;

If you're talking about the 'Rate.Mining' values in mangosd.conf, unless I'm very much mistaken those only have to do with how many times you can mine from any given ore node; they don't affect how many nodes will spawn. To affect that, you need to modify the database. Specifically, you need to modify pool_template, to raise the max_limit values in appropriate ways. The trouble lies in determining what constitutes "appropriate", and there's some disagreement on that point at the moment. I've posted some fairly simple SQL over in the UDB forums which should raise the limits in most cases, for ore and herbs alike. I wouldn't necessarily recommend using what I posted as-is, but it might be suitable, and at the least it should point you in the right direction.

I don't use external ACE myself, but at a guess, I think you've got the syntax wrong. I think you need to do something like either cmake -DACE_USE_EXTERNAL=1 -DACE_ROOT=/home/include or ACE_ROOT=/home/include cmake -DACE_USE_EXTERNAL=1

Mangos Version: r10892 Custom Patches: None, now that underlying changes broke the "Blink fix" patch I'd been maintaining. SD2 Version: r1913 Database Name and Version: 'UDB 0.12.1 (395) for MaNGOS 10892 with SD2 SQL for rev. 1913', plus ACID 3.0.7 and a few local tweaks to item-drop and herb-spawn rates. How it SHOULD work: After taking the talent Enduring Winter, casting Frostbolt should trigger the Replenishment effect (spell 57669). How it DOES work: With max-rank Enduring Winter, casting Frostbolt does not trigger the Replenishment effect. Additional information: Sometime in 2010, this worked, with the same rank of the same talent. I did not immediately notice when it stopped working, and I haven't been able to identify either the relevant change (in the commit logs) or the actual relevant code. However, the revisions I have been running at during that time are: r9310 r9311 r9671 r6729 r9795 r10000 r10269 r10549 r10720 r10892 so presumably it was functional at one of those points, with the corresponding then-newest versions of USB, SD2, and ACID. In the config file for this instance of mangosd, Rate.Talent is set to 4. The character on which this is being observed has taken very nearly all of the Mage talents, which was not the case when the effect was observed to be working; it is possible that some interaction between talents is affecting this, but I don't know how likely that is, or which ones it might be if so. I do notice that there is provision for spell ID 57669 in the SPELLFAMILY_PRIEST, SPELLFAMILY_HUNTER and SPELLFAMILY_PALADIN cases of Unit::HandleDummyAuraProc, but not in the SPELLFAMILY_MAGE or SPELLFAMILY_WARLOCK cases; I tested a couple of (the listed) revisions ago, and as expected, Warlocks also didn't see their Replenishment effect, but the other three listed classes did see their own versions. I tried to check the history to see if there might once have been such an entry, but didn't get very far, because that file is new enough to not have much history; I also tried adding a SPELLFAMILY_MAGE case modeled after one or another of the existing PRIEST, HUNTER and PALADIN ones, but did not manage to get it to produce any visible effect.

I'm not sure that explains everything, though. If I'm understanding correctly, that would mean that the problem is entirely with gameobjects, and that in turn would mean that I would expect to get the crash by interacting with the gameobject itself. However, I don't get a crash from the interaction with the gameobject; I can bring up its loot window just fine. I only see the crash when I try to interact with the item contained in the gameobject - when I try to loot it into my inventory. That would lead me to expect that the problem would be with the actual item. Unless - it might be possible that it *is* looting the item successfully, and the crash comes when it tries to trigger despawning of the gameobject? That might fit both with your assessment and my observations...

I'm not sure I entirely understand how to do that, in that I don't really understand the "pool" tables (ha!), although a look at the 390 updatepack file has already answered at least a couple of questions. More to the point, however, wouldn't that also stop them from working correctly for Noblegarden purposes? I specifically want to have the event working correctly, and just papering over the problem in a "well, if it hurts, don't do that" way wouldn't really solve the problem. FWIW, it occurred to me that I might have still had the custom temporary fixes proposed on the UDB forum in my database, and that they might have been causing the issue; however, after I deleted the mangos database and recreated from scratch, the issue does still manifest. (Incidentally, is there any practical way to rename the thread, since half of the title isn't accurate after all? As I just discovered, apparently editing the title of the initial post doesn't do it.)

Okay, I spoke too soon; on retrying, the assertion failure does recur when running in GDB, so I now have that log (per the GDB-debugging HOWTO thread). Not sure why it didn't happen last time I tested, but it seems to now. Am I correct that that log should be posted over in the "crash dumps" sticky thread, rather than under this thread?

Mangos Version: r9765 Custom Patches: a fix for the Blink spell, forward-ported from a r6xxx version SD2 Version: r1671 Database Name and Version : UDB 0.12.0, updatepack 390 This is kind of a weird one. Yesterday, I updated MaNGOS and UDB to incorporate 390's fix for Noblegarden, and tweaked the database to let Noblegarden still be active (duration 40312 instead of 10078). Thereafter, when I loot a Brightly Colored Egg gameobject (specifically, when I try to take the Brightly Colored Egg item into my inventory), mangos-worldd crashes. Well, not crashes precisely; it dies on a failed assertion. Specifically, in src/game/Framework/TypeContainer.h line 78, it dies on "Assertion 'i->second && "Object with certain key already in but objects are different!"' failed." Because this is a failed assertion, not a crash per se, I do not have a crash dump, and I don't think this scenario lets me create one. I do have a GDB log of reproducing this on a copy without debug info. However, I have not been able to get one from a copy which does include debug info. The reason is that, although the --with-debug-info copy does exhibit the problem when run directly, when it is run under GDB the problem does not seem to happen; the loot succeeds, and everything appears to work normally. Running the non-debugging copy under GDB does show the problem, however. What information can I provide to help track down this issue, and how should I provide it?

I think that's still wrong. According to the WoWWiki description, you have a 100% chance up through 75, yes - but then you have on average a 50% chance up through 150. According to my math, using the above formula you have 100% chance up through 75, then *more* than 100% up through 99, 100% at 100, and less after that - for an average of 163.3785% during 76 through 150. According to the thread you linked initially, after skill 375, the chance of skill-up increases. That's why I did three cases; I don't see any way to avoid it and still have the correct chance in all three skill ranges. Yeah, I found that before, but couldn't find it when I was writing my previous post. <snip> I'm not an expert on this codebase, but at a glance that looks good to me. Which place would be correct - Developer's Corner -> Database, or the UDB forums themselves? I'm not yet entirely up on the etiquette around here.