dufernst

Seems to be working here.

This would only check the requirements when the actual entrance of the instance is used.

If "The key requirements were not included on instances, instead heroic mode is available to all players at 80." can be read as, "You need to be level 80 to enter the instance using the normal entrance. For other means of entering the instance only the normal level requirements apply.", then this would be correct.

If this is not the case, then additional checks in the CanEnter function might be required (or checks have to be moved to CanEnter).

I haven't been able to find clear sources on this matter, some players from blizzard assumed the check would apply for all means of entering the instance.

No with 2.4.3 you only needed the key.

http://www.wowwiki.com/Hellfire_Ramparts

http://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-exploits/96259-guide-get-into-heroic-instances-without-attunement.html#post628499

Btw can anyone confirm that wotlk heroics (on blizzard servers) can be entered when you are not level 80 (by being summoned with a warlock summon stone) but do meet the minimum requirement for normal?

This could indeed fix a mistake with target selection. Another spell that is bugged right now because of this wrong selection is 69674.

But are you sure this patch is correct for all cases?

You would also need a column for the guid.

So then you would have the following columns:

1. guid (unique key)

- Datatype : int

- Len : 11

2. time_current

- Datatype : bigint

- Len : 40

- Default : 0

- Not NULL: checked

- Unsigned : checked

Then you could use the following statement to insert the time for a specific guid.

CharacterDatabase.PExecuteLog("REPLACE INTO Character_current_time (`guid`, `time_current`) VALUES

(%u, %u)", pPlayer->GetGUID(), currenttime);

On a side note: GetGUID isn't used/available any more, you could use GetObjectGuid with GetRawValue (don't know exact funtion name) to get the guid.

With the current implementation

-    data << uint8(skillReqLevel ? skillReqLevel : tSpell->reqLevel); 
+   data << uint8(tSpell->reqLevel);

would work best.

Because even when a skillReqLevel is provided, learning the spell would fail on

   // check level requirement 
   if (!prof || GetSession()->GetSecurity() < AccountTypes(sWorld.getConfig(CONFIG_UINT32_TRADE_SKILL_GMIGNORE_LEVEL))) 
       if (getLevel() < trainer_spell->reqLevel) 
           return TRAINER_SPELL_RED;

That's why the druid spells only show up green when another spell is learned (client side list update based on the required level?).

And it's the reason that it's not possible to learn those druid spells regardless of having those spells set to a lower required level in the packet.

Seems to work fine with this, but only checked it for druid trainers.

Our fork also seems to have this problem, so maybe You can share the solution?

What Schmoozerd said: http://paste2.org/p/1780732

Though I just noticed that in master we still have the cap to 40%, not sure if this should not be decreased to 25%..

Probably yes, current tests indicate a 24-27% glancing blow chance, still seems a bit to high.

Already resolved, appeared to be a problem related to our fork.

This puts a smile to my face

Awesome

Probably has something to do with

https://github.com/mangos/mangos/commit/a4e08e8f6d846947401a1925e34a31ea7ee4a716

The use of ObjectGuid and GetObjectGuid is now mandatory.