breakwater
-
Posts
166 -
Joined
-
Last visited
Never -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Posts posted by breakwater
-
-
my opinion:
thats the wrong place, maybe we should cancel all spells on mini pet in Spell:CheckTarget-function
-
new system with pointers
-
Maybe someone can test this patch on a high populated server. Please no direct commit into mangosR2.
-
Spells this will need a check
Spells with are effected by this patch:
SELECT * FROM `dbc-spell` WHERE
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and `dbc-spell`.EffectImplicitTargetA1 != 0) or
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and `dbc-spell`.EffectImplicitTargetA3 != 0) or
(`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and `dbc-spell`.EffectImplicitTargetA2 != 0)
Spells affected in Wotlk: 11728
Spells with are effected by this patch and with an different radius value:
Spells that can make problems because spell target mask is same, but radius value has an other value
SELECT * FROM `dbc-spell` WHERE
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect2 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex2) or
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex3) or
(`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect2 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex2 != `dbc-spell`.EffectRadiusIndex3)SELECT * FROM `dbc-spell` WHERE
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA2 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB2 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect2 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex2) or
(`dbc-spell`.EffectImplicitTargetA1 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB1 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect1 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex1 != `dbc-spell`.EffectRadiusIndex3) or
(`dbc-spell`.EffectImplicitTargetA2 = `dbc-spell`.EffectImplicitTargetA3 and `dbc-spell`.EffectImplicitTargetB2 = `dbc-spell`.EffectImplicitTargetB3 and (`dbc-spell`.Effect2 > 0 and `dbc-spell`.Effect3 > 0) and `dbc-spell`.EffectRadiusIndex2 != `dbc-spell`.EffectRadiusIndex3)
Spells affected in Wotlk: 216
EDIT:
A lot of Wotlk spells are fixed with this patch, because some effects has no radius (Example 72015, 72836)
Spells with makes problems:
often classic spells like:
6266,
3143,
8150,
10253
-
MANGOS_DLL_SPEC uint32 urand(uint32 min, uint32 max); ???
i think the urand(...) funcion should use direct in sd2
like this one
m_uiEyebeam_Timer = 10000 + urand(1000, 5000);
This works realy good, you doesn't need MANGOS_DLL_SPEC
-
We should check some cases in function SetTargetMap(...).
The spells with same target mask must have same radius, chain-length, etc
-
What bug does the patch fix? What features does the patch add?
For preventing an double calculation for effects with same targets
For which repository revision was the patch created?
actual, but i think for all
Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread.
not know
Who has been writing this patch? Please include either forum user names or email addresses.
me
Patch:
new System with pointer
Most target calculation of area spells are unnecessary.
Spells with more then one spell effect with the same target mask and maybe an limitation works now right (limitation in function SetTargetMap(...))
Example Spells:
64218
63342
69674
Sry my english is bad, i hope you understand my idea.
-
take the Database: mangos -> table: creature_template -> column: subname
-
Take a deep and long look into mangos core code. Use the search functions in your favorite IDE(for OS windows ->visual c++). Good words for search are spellscript, achievement...)
Maybe someone other ask the same question, use google for a good search in this forum. The original forum is stupid (30 seconds between searches; stupid solutions).
Maybe you should fix some easier thinks, achievements are complex
-
maybe you can ask a question?
-
Hi
author: me
Revision: i think the actual([11927])
https://github.com/Reamer/mangos/commit/388a3ff5bdc21866fe5d6ad43d6abc4e92eadeb0
Now the heal from NPC's, special from shaman wolfs (last talent-spell in melee talent tree) are show in combat log.
-
IsReachable is already in mmaps.
at the moment i have found this call in bool Unit::SelectHostileTarget()
// check if currently selected target is reachable
// NOTE: path alrteady generated from AttackStart()
if(!GetMotionMaster()->operator->()->IsReachable())
{
-
stacking system need a complete rewrite in mangos
Use the search function and search for: aura stacking
michalpolko should post a rewrite long time ago
-
take a look into this commit, this should help^^
https://github.com/Reamer/mangos/commit/762edc95bc93895c3a10135bc1250e8aae144945
-
why the check target == PLAYER?
I think that's unnecessary.
I think the remove is wrong, because the player with 0 mana should die in explosion. If one player with 0 mana have 15k life, this player is alive after explosion (Basepoints from Explosion BasePoints = 10213 to 11288). But without remove the player dies in next tick .
+ switch (GetId())
+ {
+ case 31447: // Mark of Kaz'rogal
+ {
+ if (target->getPowerType() == POWER_MANA && target->GetPower(POWER_MANA) == 0)
+ {
+ target->CastSpell(target, 31463, true, NULL, this);
+ }
+ break;
+ }
+ }
NOT TESTET
-
my actual code
The original cast is important, because of faction between trollgore and creatures. Trollgore should make damage
I think that's unnecessary:
target->SetDeathState(JUST_DIED);
because creature is dead. Maybe a long time ago, this spell works with fake death creatures
Hope thats help
PS: Code is to old for a good patch-file
-
I think that it's more natural, that adds are despawning after a certain time 2-5 Minutes after Boss FAIL
Despawn after Boss reach home (FAIL) looks unnatural, also after DONE.
-
maybe we can fix TEMPSUMMON_TIMED_DESPAWN_OUT_OF_COMBAT and despawn creature when dies or despawn? I think that is a lot of better
-
* What bug does the patch fix? What features does the patch add?
add a new TemporarySummon Type
* For which repository revision was the patch created?
for a lot of
* Is there a thread in the bug report section or at lighthouse? If yes, please add a link to the thread.
no
* Who has been writing this patch? Please include either forum user names or email addresses.
me
https://github.com/mangosR2/mangos/commit/90b054874e4fcc00beae426d93b76cc7879a0d0c
In my eyes good for manuell summon in scripts.
Example: Boss summon add, this add despawn when corpse vanish or add is a specific time outfight(if bossfight fails)
Best time in my eyes 2-5 minutes
-
No post in under review because me solution is only a hack for some creature_models, which bouding_radius is bigger than 2. The right meaning of bouding_radius is still unknown.
If someone is interested, copy the code where bounding_radius is limit to 2.
-
What is jFusion plugin?
-
After testing on gameserver with this change I can say: I have no monsters with wrong movement.
If I should test special monsters movement, tell me. I post the solution in this thread.
-
I have 4 folders: dbc, vmaps, maps and ->buildings<-
where is your building folder?
Also look for a right path, I think that's the real problem
-
I have make a big mistake, it was late and i have change combatreach, but the meaning of combatreach is clear.
I have change me core to thisone. Boundingradius has a max value of 2. I hope that helps against wrong movement
void Unit::UpdateModelData() { if (CreatureModelInfo const* modelInfo = sObjectMgr.GetCreatureModelInfo(GetDisplayId())) { // we expect values in database to be relative to scale = 1.0 SetFloatValue(UNIT_FIELD_BOUNDINGRADIUS, GetObjectScale() * modelInfo->bounding_radius < 2.0f ? GetObjectScale() * modelInfo->bounding_radius : 2.0f); // never actually update combat_reach for player, it's always the same. Below player case is for initialization if (GetTypeId() == TYPEID_PLAYER) SetFloatValue(UNIT_FIELD_COMBATREACH, 1.5f); else SetFloatValue(UNIT_FIELD_COMBATREACH, GetObjectScale() * modelInfo->combat_reach); } }
Fix battleground exploit
in ... under reviewOld
Posted
maybe you can explain, why you have write this patch with " _player->TeleportToBGEntryPoint();"