Jump to content

subhuman_bob

Members
  • Posts

    102
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Posts posted by subhuman_bob

  1. a path takes about 5ms to generate

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

  2. And atm i think all DB devs are pretty angry

    ..only when people try to tell us how we feel. :)

    Why you dont work together with other dev groups (Database wise) instead of developing against them.

    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.

    (Just an example: Damage) It always worked using atkspd instead of the multiplier

    Only if you assume 0 damage reduction. Anything else, and it does not work right.

    But people test all files and report all bugs they see... Hell yeah there are tons of little bugs which dont need to be fixed right now, but there are some serious bugs for more than 2 years already which hasn´t been fixed at all.

    Reporting a bug is not the same as fixing it.

    There are still tons of 3.0.x quests left and ofc 3.1.3 quests. (UDB for example) but they cannot continue their work because each release of mangos devs bug the DB again.

    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.

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

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

  5. Just few mofications of the core needed and no crash return on our test server (running for 1 month now). What we did :

    When a group or raid is made, all the members of the group/raid takes the faction of their leader.

    If group is disband or a member is removed, members take back their faction. Easy as 1-2-3.

    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.

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

  7. lvl5 isn't 11111, that would be lvl31

    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

  8. uint32 race_data = target->getRace();

    if(race_data == RACE_HUMAN)

    *data << uint32(1);

    else if(race_data == RACE_ORC)

    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.

    Have not noticed. Running AMD dual core with 1g mem only on Ubuntu Linux with a 7megabit connection. Of course we never have more than 20-30 people on at once. Your more than welcome to come see it working on my server if you'd like, might save you compile time if you don't like the way it works.

    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.

  9. + if(target->getRace() == RACE_HUMAN)

    + *data << uint32(1);

    + else if(target->getRace() == RACE_ORC)

    + *data << uint32(2);

    + else if(target->getRace() == RACE_DWARF)

    + *data << uint32(3);

    + else if(target->getRace() == RACE_NIGHTELF)

    + *data << uint32(4);

    + else if(target->getRace() == RACE_UNDEAD_PLAYER)

    + *data << uint32(5);

    + else if(target->getRace() == RACE_TAUREN)

    + *data << uint32(6);

    + else if(target->getRace() == RACE_GNOME)

    + *data << uint32(115);

    + else if(target->getRace() == RACE_TROLL)

    + *data << uint32(116);

    + else if(target->getRace() == RACE_BLOODELF)

    + *data << uint32(1610);

    + else if(target->getRace() == RACE_DRAENEI)

    + *data << uint32(1629);

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

  10. I don't think this is a good idea. pool-system has a totally different purpose. Mixing it with this link-system would be much more confusing than a new table or field

    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)

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use