Olion
Members-
Posts
537 -
Joined
-
Last visited
-
Days Won
30 -
Donations
0.00 GBP
Content Type
Profiles
Bug Tracker
Wiki
Release Notes
Forums
Downloads
Blogs
Events
Everything posted by Olion
-
The good-style core support was [URL="https://github.com/mangoszero/server/commit/2a71b6a08901f927f2699436f415df33bd7e3fc5"]done[/URL] by @H0zen. [URL="https://github.com/mangoszero/database/pull/46"]Introducing[/URL] the DB change mentioned above. Missing lightning animation is related iirc to the spawn delay of the trigger being targeted by the spell.
-
Journeyman Riding reduces to 75/75 on relog
Olion commented on madmax's bug in Archived Reports (Zero)(Resolved issues)
It looks like the bug was introduced by [URL="https://github.com/mangoszero/server/commit/e16313c5b2617b364224b1fb82e5399cb32c0af1#diff-455b2dabe05641574822077561cec24e"]this commit[/URL] and empowered by [URL="https://github.com/mangoszero/server/commit/8261268c69c598b189d866310f35cb967ee41f64"]this one[/URL]. The new overriding spell is set correctly and client is informed about it, but then [FONT=Courier New]Player::addSpell([/FONT] for an unclear reason terminates prematurely [URL="https://github.com/mangoszero/server/blob/develop21/src/game/Object/Player.cpp#L2972"]here[/URL] signaling that the spell cannot be learned. In between, the skill is set/corrected in the method [URL="https://github.com/mangoszero/server/blob/develop21/src/game/Object/Player.cpp#L3011"]below that return[/URL]. I see the following options: 1) make use of EFFECT_0 of the learned riding spell (which is dummy effect) in a simple spellscript setting the skill value. It looks like there are 8 of such spells; 2) correct the added code in order to soften the condition for premature termination of [FONT=Courier New]Player::addSpell([/FONT]. btw the code does not look good having large replicated parts. I would prefer the 2nd option, but for that we better ask [URL="https://www.getmangos.eu/members/h0zen/"]the patch author[/URL]. -
Spell duration incorrect...
Olion commented on Xenithar's bug in Archived Reports (Zero)(Resolved issues)
Was merged [URL="https://github.com/mangoszero/server/commit/504a7c3b88d943a03ed80701059aaab93f84cb1d"]here[/URL]. -
Instance entry level not correct...
Olion commented on Xenithar's bug in Archived Reports (Zero)(Resolved issues)
Fixed [URL="https://github.com/mangoszero/server/commit/2aa0003d4278b92bb21916dd96830b8fb1a0f426"]here[/URL], finally. -
Group Loot Zoning Crash
Olion commented on Aparadox's bug in Archived Reports (Zero)(Resolved issues)
After a cleanup, [URL="https://github.com/mangoszero/server/pull/82"]PRed[/URL]. -
Instance entry level not correct...
Olion commented on Xenithar's bug in Archived Reports (Zero)(Resolved issues)
You did miss a point in the algorithm above. [quote=Olion]3) go away from the instance entrance;[/quote] Anyway, these both are due to a single implementation bug, namely a jammed delayed teleport. @H0zen has fixed it [URL="https://github.com/mangoszero/server/pulls"]here[/URL]. -
Instance entry level not correct...
Olion commented on Xenithar's bug in Archived Reports (Zero)(Resolved issues)
However, this mechanic does not explain a weird implementation bug with double call to Player::TeleportTo() due to delayed teleporting. For this particular instance, several entry ATs are defined. The 1st call returns OK for level 29, but the 2nd call finds an unpredictable AT from the fourth ones, depending on the DB entries order. The bug has the most beatiful look in such case: 1) as a non-GM 29 lvl character, try to enter the enabled - left for 29 lvl - teleport; 2) get "Required level 35" error; 3) go away from the instance entrance; 4) .gm on will now teleport you into the instance. -
Instance entry level not correct...
Olion commented on Xenithar's bug in Archived Reports (Zero)(Resolved issues)
SELECT id,`name`,required_level FROM areatrigger_teleport WHERE target_map=189; 45,Scarlet Monastery - Graveyard (Entrance),29 610,Scarlet Monastery - Cathedral (Entrance),35 612,Scarlet Monastery - Armory (Entrance),33 614,Scarlet Monastery - Library (Entrance),31 Well, some idea is seen here, but I cannot say, is it wrong. -
[quote=MrFreak]This is unique because it is calculated as id + delay which gives you a composite key between them. Delay field is responsible for the sequential execution of them.[/quote] Not that exactly. The world table structure is more or less reasonable and elaborated. If you do not see the key composed of the two fields, then it's not a key. Nothing prevents us to define several script commands with the same delay, i.e. executed at the same moment of time. The execution order remains undefined though. The dbscript_on_* tables should be moved as a whole to the same trash bin as EventAI engine, being substituted by something like TC's SmartAI. However, even TC's SmartAI has yet no full support for this (for instance, spell events not related to gameobjects, so the SmartAI cannot substitute dbscripts_on_event).
-
Thank you. I was too glad for the SPELL_ATTR_HEARTBEAT_RESIST_CHECK spell attribute found recently by the TC team, and switched off involved unit type checks. It turns to be an error. Since I introduced this bug, [URL="https://github.com/mangoszero/server/pull/35"]here[/URL] is the correcting PR. P.S. However, the PvE heartbeat resist is a topic requiring research. AFAIK there exists some.
-
Two other issues are difficult. The q:9759 Ending Their World should be scripted (luckily, TC 3.3.5 has the [FONT=Courier New]npc_demolitionist_legoso[/FONT] script which can be adopted). The q:9740 The Sun Gate needs server-side definition of the spell 38096, and for this mechanic Two core is not ready yet; so, for now, it also must be scripted.
-
The simplest case is q:9579 Galaen's Fate. The quest item drops from the [URL="http://www.wowhead.com/npc=17606/sunhawk-reclaimer#drops:mode=:50-18+1"]mobs[/URL] with 4% chance. Wowhead indicates 5%, but there is no way to say does it pertain to the WotLK (also the wowhead data for quest item drop are wrong oftenly because the statistics was taken for players with and without the quest). For these values, to have the amulet with 80% chance you must kill 40 and 31 mobs, correspondingly. But, only 26 mobs are spawned once. More reasonable values look like 10-20% (15 to 8 mobs for 80%). To change the drop chance, for example, to 10%, execute the following on your `world` database: UPDATE `creature_loot_template` SET `ChanceOrQuestChance`=-10 WHERE `entry`=17606 AND `item`=23873;
-
Release 20 - Loot problem
Olion commented on kstrain's bug in Archived Reports (One)(Resolved issues)
So try to push, because I will not. -
Release 20 - Loot problem
Olion commented on kstrain's bug in Archived Reports (One)(Resolved issues)
Yes. The patch below fixes this bug. -
[Bug] Anger Management not working properly and Muck Frenzy walking on ground
Olion commented on easylife's bug in Mangos One
You are correct. [URL="https://github.com/mangosone/server/blob/develop21/src/game/WorldHandlers/SpellAuras.cpp#L6431"]This "ModifyPower"[/URL] should be put under the check if(target->IsInCombat()). -
Group Loot Zoning Crash
Olion commented on Aparadox's bug in Archived Reports (Zero)(Resolved issues)
The developers use the latest available version, which is one from the repo branch develop21 now. I switched to the older release20 branch, applied the patch and (after re-creating VS project files with cmake, what is my usual procedure) got the sources compiled cleanly. It means that you failed to apply the patch somehow. Reset your sources with "git checkout -f" and try again "git apply" ensuring there was no error on each step. Note that the patch does not require any change of the VS project, so if you use pre-built slns, they are ok still. I realize that it would be much more comfortable to get changes from the repo with "git pull", but the PRs [URL="https://github.com/mangoszero/server/pulls"]are not being merged for months[/URL], and we can do nothing about it. -
Group Loot Zoning Crash
Olion commented on Aparadox's bug in Archived Reports (Zero)(Resolved issues)
Use the patch provided. It accounts for a possibility of missing characters rolling for an item, on the instance map with the mob corpse. These characters will not get the rolled loot, though a roll is done for them and the group is informed about it. If such behaviour looks undesirable, the roll for such characters may be suppressed resulting in just a minor code complication. -
Group Loot Zoning Crash
Olion commented on Aparadox's bug in Archived Reports (Zero)(Resolved issues)
More specifically, a player opens a group loot and roll begins; he votes for rolled item (either need or greed); no others votes for the item (cannot say is this required); he leaves the instance (by heartstone so on) appearing on another map; when the roll expired, the core crashes. See Group.cpp:1120-1121. The cause is evident. -
Unfortunately, this copypaste from TC will not compile in Zero due to missing SpellInfo class. The problem of the casting mode for such spells, either player->player or questender->player, looks permanent :) The correct solution seems to use both modes depending on conditions. The above patch provides an incomplete list of the conditions. In general, the questender->player mode seems to be the reasonable one, except the spells which cannot be casted in this mode. Most of later spells have TARGET_SELF=1 (we don't need usually the questender to cast the reward spell on itself, do we?). After a brief look on the spells actually used for RewSpell, we've to add the spells either with TARGET_NONE=0 (the core interprets it as TARGET_SELF) or with SPELL_EFFECT_LEARN_SPELL=36, SPELL_EFFECT_TRADE_SKILL=47. The difference between these two solutions on the actual DB arises just for dummy auras 23356,23357. Checking if the core allows .cast back the auras from mob to player will solve the dilemma: if yes, then 2nd way (check spell effects); else 1st way (check TARGET_NONE=0 for non-empty spell effects). Again, due to missing SpellInfo class, a special method has to be created to check the mentioned conditions correctly basing on SpellEntry entity.
-
Now in Zero warden, the main problem is that the (client) signatures are present for 5875 version, and some of these will fail for 6005 version. At least, it is the 634 check. Until multi-client support implemented, the check is better to be removed. The question is, should we do it globally in develop21 branch; I suggest no.
-
[url]https://github.com/mangoszero/server/pull/10[/url] Nothing unpredictable; some TODOs are such that better be done :) CreatureAI::Reset() is called now right after AI construction also (in addition to default evade and respawn). Also, a minor correction introduced to the AT 522 "at_twiggy_flathead" script.
-
Hm, I did not imagine that it will raise so fast. I suspect this is due to a detail I intended to fix sometime later :) Trying right now instead...
Contact Us
You can also email us at [email protected]
Privacy Policy | Terms & Conditions
This website is in no way associated with or endorsed by Blizzard Entertainment®