subhuman_bob

...which is about 2 million CPU cycles (assuming an "average" CPU speed of 2.5 GHz) I don't mean to belittle the work being done here, but want to point out to all the people going "I want this naow!!" that if it was in your server now, it would barely run.

Who knows, maybe that's what one of the "unkxx" fields is for....

...use search, because this question comes up at least once a month....

..only when people try to tell us how we feel. MaNGOS devs in general, and Vladimir in particular, have always been very open to suggestions from us (UDB ) regarding changes that either make our jobs easier, or that otherwise allow us to create a more complete/accurate Database. That having been said, they are still separate projects. MaNGOS devs must focus on doing what's best for MaNGOS- even if it does sometimes make more work for the DB projects or scripting projects. Only if you assume 0 damage reduction. Anything else, and it does not work right. Reporting a bug is not the same as fixing it. The two are completely unrelated. There are two devs working on the damage formulas, and a different dev does almost all of the work on quests. The extra work isn't from new versions of MaNGOS, the extra work is from new patches from the client publisher that add new content or change existing content.

You're using a DB for 7681 with MaNGOS 8078 ...at more than one forum as well.

That would be TheLuda.

MaNGOS is not an emulator

Here's a general rule for you: Doing things the "easy" way is not secure. If you want to make your system secure, you will have to stop doing everything the easy way.

They're undead. Undead creatures do not have active digestive systems, thus they have no need for toilet paper (tp).

It would also increase RAM usage.

MaNGOS doesn't care what language the scripts are written in. Look up the former project called LUAScript if you require proof of this. All this has happened before, and it will happen again. http://mangos-luascript.googlecode.com/svn/trunk

It's not a bug. a ) this (content) should not be discussed here b ) it it were allowed, I'd give you the link to comments on that mob at a popular information site (hint: has "head" in its name) where a search took me all of ten seconds to find the answer.

If you add a new plugin to your web browser, and the plugin does not function properly is it: a ) the fault of the plugin or b) the fault of the browser The browser (MaNGOS) can function on its own, the plugin (SD2) cannot. However it is the responsibility of the plugin to be compatible with the browser, not the other way around.

I didn't say that. However, changing factions while in a group/raid has more effects than just allowing people to work together.

While this may not crash, there will be other complications. There are numerous quest start items that only drop for one faction, as well as many quests inside instance that are only meant for one faction. If you start changing players' factions, you're going to mess this up. If you let players change their faction at will (by joining a group of the opposite faction) pretty soon they're going to figure out they can exploit this to access extra quests. Not to mention strolling through the opposite faction's capital cities unmolested.

Maybe the confusion comes from what is meant by the question "Do VMaps work?" What are VMaps intended to do: They are for determining LOS (Line Of Sight) between two points. Simply put, can mob "a" see player "b" in order to aggro that player? Can player "b" see mob "a" in order to cast a spell at the mob or attack it with a ranged weapon? That's it. As long as a mob does not pick up initial aggro from seeing a player when there is something blocking LOS or a player cannot do a ranged attack against a mob they cannot see* then yes- VMaps work. The initial example about a mob on the ground attacking a flying player has nothing to do with VMaps since there is LOS between the mob and the player. People reporting crashes while using VMaps don't determine if VMaps work, they determine if VMaps are stable- which is a different question. Even then, they aren't determing if the VMaps are the cause of the provblem. The instability may be the result of defective hardware- it's possible that VMaps code is using an instruction that the persons hardware is failing on, or possibly the extra load is producing more heat and causing thermal problems. Anyway, to answer the question "Do VMaps work?" The answer is: yes. Do VMaps control how a mob moves (such as through obstacles) after it has aggro'd a player? No. Because they are not intended to do this. * this is checked by both client and server. Even with VMaps disabled, most ranged attacks will not be allowed by the client if there is no LOS

...however, this has nothing to do with VMaps...

Back to why I said bitmask earlier. One byte for GMLevel 00000001 = can use GMLevel 1 comamnds 00000010 = can use GMLevel 2 commands 00000100 = can use GMLevel 3 commands 00001000 = can use GMLevel 4 commands 00010000 = can use GMLevel 5 commands 00100000 = can use GMLevel 6 commands 01000000 = can use GMLevel 7 commands 10000000 = can use GMLevel 8 commands these of course could be combined 11111111 = can use all GM commands 00110111 = can use GMLevel 6,5,3,2 and 1 commands Now back to DasBlub- yes, 11111 in binary has a value of 31, however value is not the same as meaning. To determine if a player can use a certain command, you logically AND his GMLevel with the required GMLevel of the command. If the result is zero, it cannot be done. If the result is anything but zero, the command can be executed. This is an extremely easy procedure for any CPU. (I can make you a relay-based computer that can do this if you really want) 00110111 <-- GMLevel of player 00001000 <-- GMLevel 4 command ------------- <-- logical AND 00000000 <-- result is zero, cannot be used 00110111 <-- GMLevel of player 00010000 <-- GMLevel 5 command ------------- <-- logical AND 00010000 <-- result not zero, command can be used

That's a good start, and part of what I was thinking of. Yes, only doing getRace() one time is much more efficient. The next logical improvement would be to use a switch. Whether you can notice it or not is immaterial, looking up a player's race up to ten times in a row is inefficient- period. Losing several hundred (or possibly thousands) of clock cycles on a multi-core multi-GHz CPU is not noticeable to a human. Those wasted CPU cycles occur far too quickly for us to notice.

There has to be a more efficient way of doing this. That's a lot of CPU time tied up right there.

I can't say how other DBs may functions, however UDB does not "use ScriptDev2" or depend on it on any way.

Did you verify that your DB has the proper flag set for that item?Edit: I just did so. Both UDB and PSDB show that bit set for item 44458

I think the word you're looking for is "bitmask" It's actually a pretty good idea.

I disagree... 1 ) pools already link mobs to other mobs, this is a logical extension of the current function 2 ) pools are already checked before a mob is respawned, so this is logical 3 ) pool_creature.chance could be altered to be pool_creature.ChanceOrMaster (or something similar) where a negative value indicates the GUID of the mob that must be spawned in order for linked entries to spawn 4 ) no new fields are needed in DB this way (just change an existing field)

I would suggest making use of `pool_creature` table for this instead of adding a new field to `creature` table.