Chucksta

[quote=Goullio]I have looked in the quest_template file but there doesn't seem to be such a tag. I suppose its a game mechanic which decides when the quest becomes a too ''low'' level.[/quote] Yeah, probably server core side. I'll track it down at some point.

Thanks, gambit2312 :) Yes, it would make sense to concentrate on the other cores, but I think if I did that, this could easily end up being like a job Saying that though, my focus is primarily on Zero, and applying fixes to the other cores that I have achieved for Zero that are also relevant to them. MaNGOS Four is a nice challenge that I think I will enjoy wrestling with :) Plus plenty to learn from it. I don't know what happened to get the MaNGOS Four server to run earlier, but I just did a fresh install and the damn thing is complaining about the version of the game data (maps, vmaps, etc.) Which is the issue I had the last time I tried this. At some point last time I tried this, I obviously managed to extract the correct version of the files, but I can't find any mention of it in my notes!!!! Anyway, I'll write it down here this time! Of course, I now have to figure out how to get those correct data files again, :confused: lol and damn! :mad: :o :)

YEY, I just successfully got the server to run and not crash :D The thing is the installation was from my previous attempt, so not sure what happened to make it work now! :confused: What I'll do is install another one from scratch... and pray. ----------------------------------------------------------------------------------------- Server failed to run after the fresh installation: [B][COLOR="#FF0000"]Correct *.map files not found in ../data/maps[/COLOR][/B] Checking the [B]component.wow-enUS.txt[/B] file in the dbc folder, it reports the client build to be 18273. MaNGOS Four needs 18414. I applied a means to trick it (thanks, Antz) by altering the code in the [B]system.cpp[/B] file but it still failed, coming up with the same error. code added at 3 points in the [B]system.cpp[/B] if (build == 18273) { build = 18414; } Although whilst extracting the data it said the build was 18414, it still showed as 18273 in the [B]component.wow-enUS.txt[/B] file. I'll have to revisit this at another time :( EDIT: Thinking about it, I don't know how that hack would make it work, unless the server is only looking for some sort of label/mark in the files that says what version the build is. If there are checks on the size of files, this would obviously fail! Hmm, I must have gotten the proper build from somewhere! Damn gremlins must've half inched it!!!

Okay, I'll check to see how this is decided in the core. Hmm, I could check in retail too, if the quests still work that way. I'll do that, then check to see how this is decided for MaNGOS. Yey, bring on a new toon! The start area is my favourite :) ---------------------------------------------------------------------------------------- On retail now and monitoring the exclamation mark of a quest at the same level as the Wine Shop Advert one. With a toon at level 3 (Mungo the Monk), the exclamation mark is still yellow. Let's level up some more :) Ding, level 4 :) and the exclamation mark is still yellow. Level 5 and still yellow. Level 6 and still yellow. I don't know how good a comparison this is though. It could be they have changed the way it works. I'm going to head to SW and see if that Wine Shop Advert quest still exists :) The quest still exists and it is yellow for my level 6 monk. Gonna do something else now for a bit, and come back to this later.

Checked in-game: at level 3 the exclamation mark is there, then when I .levelup to 4, the exclamation mark vanishes. I have no idea if this is how it should work, so someone else with better knowledge of the game needs to contribute to this. :) Is this how it should work ?

[B][SIZE=3][COLOR="#008000"]ONE POSSIBLE FIX:[/COLOR][/SIZE][/B] The Elunafication of the Event (actually it processes both salute and wave, so 2 events): local NPC_General_Marcus_Jonathan = { EMOTE_RECEIVE_WAVE = 101, EMOTE_RECEIVE_SALUTE = 78, EMOTE_SEND_SALUTE = 66, NPC_ID = 466 } function NPC_General_Marcus_Jonathan.OnReceiveEmote(event, creature, player, emoteid) if (emoteid == NPC_General_Marcus_Jonathan.EMOTE_RECEIVE_WAVE) then creature:SendUnitSay("Greetings, citizen!",7); elseif (emoteid == NPC_General_Marcus_Jonathan.EMOTE_RECEIVE_SALUTE) then creature:Emote(NPC_General_Marcus_Jonathan.EMOTE_SEND_SALUTE); end end RegisterCreatureEvent(NPC_General_Marcus_Jonathan.NPC_ID, 8, NPC_General_Marcus_Jonathan.OnReceiveEmote) This has been tested in-game, and works. Code by Foereeper Butchery of code by Chucksta :P ----------------------------------------------------- [B]NOTE TO SELF[/B]: Implement this in SD2 as well, via the [B][COLOR="#800080"]ScriptName [/COLOR][/B]field of the [B]creature_template [/B]table.

Tested this in game: [B][COLOR="#008000"]/salute resulted in a returned salute by General Marcus[/COLOR][/B] :) [B][COLOR="#FF0000"]/wave got no response[/COLOR][/B] hmm, maybe a kick in the noodles? I'll check the database in a mo... coffee needed!!! ----------------------------------------------------------------------------------------------------------------------- The scripts related to this issue are in the [B]creature_ai_scripts[/B] table. The event used for received emote is 22: EVENT_T_RECEIVE_EMOTE = 22, // EmoteId, Condition, CondValue1, CondValue2 code from the [B]CreatureEventAI.h[/B] file I'll sort this out later. Need to get an endorphine hit ! ------------------------------------------------------------------------------------------------------------------------- Strange, everything looks okay script/database-wise: [B]creature_template[/B] ([B][COLOR="#800080"]Entry[/COLOR][/B] 466) -> ([B][COLOR="#800080"]creature_id[/COLOR][/B] 466)[B]creature_ai_scripts[/B]([B][COLOR="#800080"]action1_param[/COLOR][/B] -552) -> ([B][COLOR="#800080"]entry[/COLOR][/B] -552)[B]creature_ai_text[/B] - this has the text "Greetings citizen." Hmm, maybe I'm blind and missed it. Checking in-game again! Nope, little git is definitely ignoring me! Perhaps a setting is wrong in the [B]creature_ai_text[/B] table's record. -------------------------------------------------------------------------------------------------------------------------- The salute emote is coming up on the server terminal: [B][COLOR="#0000FF"]CreatureEventAI: ReceiveEmote CreatureEventAI: Condition ok, processing[/COLOR][/B] It is not coming up when waving, so there must be a setting wrong! Gonna compare the record with similar ones... --------------------------------------------------------------------------------------------------------------------------- One or more of the other scripts is interfering with the /wave one. I had to delete all of the others before the /wave one would work. Now I need to put them all back till I find the offending record! fun fun fun, NOT, lol --------------------------------------------------------------------------------------------------------------------------- Hmm, it seems that the wave emote does not like any other emote events to exist. Confuzzled to the max!!!

[B][SIZE=3][COLOR="#008000"]Pull Request has now been made with this fix:[/COLOR][/SIZE][/B] [url]https://github.com/mangoszero/server/pull/269[/url]

Thanks, Xenithar. I'll have a play with that those emotes :) ----------------------------------------------------------------------------------------------------------------- [B][COLOR="#008000"]THE FIX[/COLOR][/B] [B][COLOR="#0000FF"]UPDATE db_script_string SET `type`='2' where content_default like "%\%s%" and type = 0;[/COLOR][/B] [B][SIZE=3][COLOR="#008000"]Pull Request has now been made with the fix:[/COLOR][/SIZE][/B] [url]https://github.com/mangoszero/database/pull/181[/url]

Making a note here so that I can revisit this tomorrow... The issue of spawning of the object up in the sky may be due to the the rounding of the value passed in the Z variable (Foereeper's idea) - a good idea! Tracing back the code has taken me to the Create( ) function of the GameObject.cpp file. I will revisit this again tomorrow and run some tests on the contents of the variables.

Here are the scripts it runs in sequence, once the quest is considered completed: 1) [B]Cast spell[/B]: 4153 - "Imbues target's spirit with bestial guile." - taken from the [B][COLOR="#0000FF"]Spell.dbc[/COLOR][/B] file 2) [B]Talk[/B]: What is this power that flows through me? Is this the power of shamanism that Tor'gan spoke of...? 3) [B]Talk[/B]: %s watches as his blood begins to stir, and the guile of the raptor slips through him. 4) [B]Emote[/B]: 15 ????? 5) [B]Talk[/B]: Amazing! I feel... renewed. My strength returns! It looks like (3) should not actually be spoken by the NPC. I'll have a look at the [B]dbscripts_on_quest_end [/B]wiki entry to see if we can make it appear not as spoken text, but as the other thingy whats'it ... brain fail!!! I have no idea what emote 15 is. I'll see if I can find out. ---------------------------------------------------------- The form of the text output is specified in the [B]db_script_string[/B] table, [B][COLOR="#800080"]type[/COLOR][/B] field. [B]dbscripts_on_quest_end[/B] ([B][COLOR="#800080"]dataint[/COLOR][/B]) -> [B]db_script_sctring[/B] ([B][COLOR="#800080"]Entry[/COLOR][/B]) with a choice of: [COLOR="#0000FF"]0 CHAT_TYPE_SAY ‘white’ text 1 CHAT_TYPE_YELL ‘red’ text 2 CHAT_TYPE_TEXT_EMOTE ‘brown’ small emote-text 3 CHAT_TYPE_BOSS_EMOTE ‘big yellow’ emote-text displayed in the center of the screen 4 CHAT_TYPE_WHISPER whisper, needs a target 5 CHAT_TYPE_BOSS_WHISPER whipser, needs a target 6 CHAT_TYPE_ZONE_YELL ‘red’ text, displayed to everyone in the zone[/COLOR] I'm going to try 2, CHAT_TYPE_TEXT_EMOTE ------------------------------------------------------------------------ [B][SIZE=3][COLOR="#008000"]D'oh, silly me!!!! That is the answer!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![/COLOR][/SIZE][/B] confuzzled by terminolgy!!!!!!!! The text will now be emoted!!!!!!!!!! [B][SIZE=4][COLOR="#008000"]FIX[/COLOR][/SIZE][/B] [B][COLOR="#0000FF"]UPDATE db_script_string SET `type`='2' WHERE `entry`='2000000115';[/COLOR][/B] -------------------------------------------------------------------------- [COLOR="#FF0000"]Looking at the [B]db_script_string[/B] table, I can see other text entries that should be emoted are actually set to be spoken by the NPC. I'll extend this fix to include all of the offending records.[/COLOR] I'm a tad busy at the mo, so will have at this later :)

The [B][COLOR="#800080"]CompleteScript [/COLOR][/B]field of the [B]quest_template [/B]table contains: 702, so definitely could be a scripting issue. This points to 5 entries in the [B]dbscripts_on_quest_end [/B]table, each with a delay that results in the scripts being executed is sequence. I'll look at this properly tomorrow... chill time :D

[CENTER][B][SIZE=4][COLOR="#008000"]FIX[/COLOR][/SIZE][/B] [B][SIZE=3][COLOR="#008000"]For Real!!!![/COLOR][/SIZE][/B][/CENTER] Okay, this will result in the correct health and mana for the creatures, but does not fix the failing function. I could not interpret the meaning of the code (or be bothered to try?). What this fix does is only run the first part of the IF ELSE statement if the rank of the creature is 0. If the creature is of any other rank it will run the second part of the IF ELSE statement: [B][SIZE=3][COLOR="#008000"]How to:[/COLOR][/SIZE][/B] [B]Replace this code: [/B] file: Creature.cpp line: 1193 [B][COLOR="#FF0000"]if (cinfo->ArmorMultiplier > 0 && cCLS)[/COLOR][/B] [B]with this code:[/B] [B][COLOR="#008000"]if (cinfo->Rank == 0 & cinfo->ArmorMultiplier > 0 && cCLS)[/COLOR][/B] [B][SIZE=3]CODE AS IT WILL APPEAR AFTER THE FIX IS ADDED (excluding a couple of comments)[/SIZE][/B] CreatureClassLvlStats const* cCLS = sObjectMgr.GetCreatureClassLvlStats(level, cinfo->UnitClass); if (cinfo->Rank == 0 & cinfo->ArmorMultiplier > 0 && cCLS) // this code only works on rank 0 creatures { // Use Creature Stats to calculate stat values // health health = cCLS->BaseHealth * cinfo->HealthMultiplier; // mana mana = cCLS->BaseMana * cinfo->PowerMultiplier; } else // this code works on all ranks { // Use old style to calculate stat values float rellevel = maxlevel == minlevel ? 0 : (float(level - minlevel)) / (maxlevel - minlevel); // health uint32 minhealth = std::min(cinfo->MaxLevelHealth, cinfo->MinLevelHealth); uint32 maxhealth = std::max(cinfo->MaxLevelHealth, cinfo->MinLevelHealth); health = uint32(minhealth + uint32(rellevel * (maxhealth - minhealth))); // mana uint32 minmana = std::min(cinfo->MaxLevelMana, cinfo->MinLevelMana); uint32 maxmana = std::max(cinfo->MaxLevelMana, cinfo->MinLevelMana); mana = minmana + uint32(rellevel * (maxmana - minmana)); } I'm not sure that they would allow this fix to be PR'd, as ideally the function that is at fault should be fixed and not to just have a simple work-a-round like this.

[B][SIZE=3][COLOR="#0000FF"]New Post - Looking at the Code[/COLOR][/SIZE][/B] [B]The ranks of the creatures:[/B] SharedDefines.h, lines 1772 to 1780 enum CreatureEliteType { CREATURE_ELITE_NORMAL = 0, CREATURE_ELITE_ELITE = 1, CREATURE_ELITE_RAREELITE = 2, CREATURE_ELITE_WORLDBOSS = 3, CREATURE_ELITE_RARE = 4, CREATURE_UNKNOWN = 5 // found in 2.2.3 for 2 mobs }; The code that sets the health and mana for the creatures is: Creature.cpp, line 1192 onwards if (cinfo->ArmorMultiplier > 0 && cCLS) { // Use Creature Stats to calculate stat values // health health = cCLS->BaseHealth * cinfo->HealthMultiplier; // mana mana = cCLS->BaseMana * cinfo->PowerMultiplier; } I forced the health and mana of the creatures to be 100 by including the following code, thus proving that this code does set the elite's health and mana if (cinfo->ArmorMultiplier > 0 && cCLS) { // Use Creature Stats to calculate stat values // health health = cCLS->BaseHealth * cinfo->HealthMultiplier; health = 100; // mana mana = cCLS->BaseMana * cinfo->PowerMultiplier; mana = 100; } NEXT: figure out what is actually happening there, and if it is in this code that is causing the fault. ------------------------------------------------------ [B][COLOR="#008000"][SIZE=3]FIXED[/SIZE]![/COLOR][/B] [IMG]http://s18.postimg.org/uzez3mu3d/Load_Kazzak_Well_Ard.jpg[/IMG] [B][SIZE=3][COLOR="#0000FF"]LOL, FOOLED YOU :P[/COLOR][/SIZE][/B] I cheated... The above code that deals with setting the health and mana of the creature actually has another part to it: // TODO: Remove cinfo->ArmorMultiplier test workaround to disable classlevelstats when DB is ready CreatureClassLvlStats const* cCLS = sObjectMgr.GetCreatureClassLvlStats(level, cinfo->UnitClass); if (cinfo->ArmorMultiplier > 0 && cCLS) { // Use Creature Stats to calculate stat values // health health = cCLS->BaseHealth * cinfo->HealthMultiplier; // mana mana = cCLS->BaseMana * cinfo->PowerMultiplier; } else { // Use old style to calculate stat values float rellevel = maxlevel == minlevel ? 0 : (float(level - minlevel)) / (maxlevel - minlevel); // health uint32 minhealth = std::min(cinfo->MaxLevelHealth, cinfo->MinLevelHealth); uint32 maxhealth = std::max(cinfo->MaxLevelHealth, cinfo->MinLevelHealth); health = uint32(minhealth + uint32(rellevel * (maxhealth - minhealth))); // mana uint32 minmana = std::min(cinfo->MaxLevelMana, cinfo->MinLevelMana); uint32 maxmana = std::max(cinfo->MaxLevelMana, cinfo->MinLevelMana); mana = minmana + uint32(rellevel * (maxmana - minmana)); } The second part, after [B][COLOR="#0000FF"]else[/COLOR][/B], is apparently the old way of working out the health and mana. I commented out the first part, thus making the system run the old code. This, as you can see, results in the correct health and mana for the creatures. Obviously there must be a reason why the new way to work out these values was implemented, but for some reason it only works for normal mobs (rank 0). The fault is occurring here: CreatureClassLvlStats const* cCLS = sObjectMgr.GetCreatureClassLvlStats(level, cinfo->UnitClass); Well, presumably the way the GetCreatureClassLvlStats( ) function is working out the values is wrong; at least for non rank 0 mobs.

Gonna check this one out now. Apply my obsessive personality to it and see what happens!!! :confused: :p :mad: :o ;) ------------------------------------------------------- [B]Lord Kazzak[/B] Entry: 12397 [url]http://db.vanillagaming.org/?npc=12397[/url] HP: 347,581 This HP value is both on the above page and in the database ([B]creature_template [/B]table, [B][COLOR="#800080"]MinLevelHealth [/COLOR][/B]and [B][COLOR="#800080"]MaxLevelHealth[/COLOR][/B]) And the [B][COLOR="#800080"]curhealth[/COLOR][/B] field in the [B]creature[/B] table. [B]SciptName[/B]: boss_kazzak I'll now check in-game. [B][COLOR="#FF0000"]PROOF OF THE ISSUE:[/COLOR][/B] [IMG]http://s23.postimg.org/hoe49btbv/Weedy_Lord_Kazzak.jpg[/IMG] [B][SIZE=3]One weedy Lord Kazzak![/SIZE][/B] The Dreadlord NPCs in the area are also showing a similar value for their HP, when it should be about 46k/47k ------------------------------- Now boys and girls, 'ow be dis 'appening?!?!?! ------------------------------- I just checked the normal mobs in the Blasted Lands and their HP was correct, but on checking a Rare that I can across (Magronos the Unyielding), I found his HP to be 2784, when it should be 8536 Rank: 4 (Rare) [IMG]http://s24.postimg.org/k0oevg339/Magronos_The_Unyielding.jpg[/IMG] I'll now check other areas/maps to see what the stats of the elites/rares are there. ------------------------------- Badlands The normal mobs' HP is as it should be, but HP of the elites is again way too low: [B]Scorched Guardian[/B] Rank: 1 (Elite) HP should be: 5195 - 5881 Is in-game: 1716 [IMG]http://s4.postimg.org/tb3in97cd/Scorched_Guardian.jpg[/IMG] --------------------------------- Hmm, I'll check the code in the core...

Thanks for the tip :) I'll have a look at Gentoo now.

Ah, that's brilliant :) I'll wait for the feedback from your family and soon to be family ;) I have gone back to running the server on my Linux machine. I find it a LOT faster for development and testing purposes, due to it compiling the server core a hell of a lot faster than on MS windows.

Excellent! Thanks, Xenithar :)

[quote=Xenithar]The way it worked on official was that each worse case had less health, but I believe the rate of loss was the same. The critical soldiers just had little to begin with so you had less time in that essence, but it was not hard to do. I have redone this repeatedly now for testing and it IS possible to save them, but the problem then is that even after being saved, they take a few steps and die. After being saved the decay should stop. Oh, and to save them you have to start bandaging them as they fade in. If you do not start until they are solid, you cannot save them at this point.[/quote] Try with the fixes I recommend, if you can. You'll see that the quest can be done, but still butt clenching! I tried to do it before, but the Critical ones were impossible, even if you were on top of them as they spawned!!! I also experienced the saving of them; they stand and thank you, then die, lol With the code added that gives them 20% health when saved, they no longer die like that :) Try it out. The calculation may need tweaking some more. If okay, then I'll PR it.

[B][COLOR="#FF0000"]TESTING REQUIRED BY OTHERS[/COLOR][/B] Can the proposed fix be tested by someone/others, please. It worked well for me, and still nerve wracking. You'll need to make 2 changes to the code (See [B][COLOR="#008000"]CODE FIXES[/COLOR][/B] for how the code should look): [B]FILE[/B]: npcs_special.cpp [B]LOCATION[/B]: server\src\modules\SD2\scripts\world [B][SIZE=3][COLOR="#800080"]1) add this line:[/COLOR][/SIZE][/B] [B][COLOR="#008000"]m_creature->SetHealth(uint32(m_creature->GetMaxHealth()*0.20));[/COLOR][/B] to the SpellHit( ) function approximately line 335 [B][SIZE=3][COLOR="#800080"]2) change this line[/COLOR][/SIZE][/B] [B][COLOR="#FF0000"]uint32 uiHPLose = uint32(0.05f * uiDiff); [/COLOR][/B] to [B][COLOR="#008000"]uint32 uiHPLose = uint32(0.03f * uiDiff); [/COLOR][/B] in the UpdatyeAI( ) function approximately line 380 --------------------------------------- [B][COLOR="#008000"]CODE FIXES[/COLOR][/B] 1) new code added Player* pPlayer = static_cast(pCaster); if (pPlayer->GetQuestStatus(6624) == QUEST_STATUS_INCOMPLETE || pPlayer->GetQuestStatus(6622) == QUEST_STATUS_INCOMPLETE) { if (Creature* pDoctor = m_creature->GetMap()->GetCreature(m_doctorGuid)) { if (npc_doctorAI* pDocAI = dynamic_cast(pDoctor->AI())) { pDocAI->PatientSaved(m_creature, pPlayer, m_pCoord); } } } // stop patient dying due to an UpdateAI( ) occuring before the healing can kick in m_creature->SetHealth(uint32(m_creature->GetMaxHealth()*0.20)); // THIS SAVES THE PATIENT // make not selectable m_creature->SetFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_NOT_SELECTABLE); // regen health m_creature->RemoveFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_IN_COMBAT); // stand up m_creature->SetStandState(UNIT_STAND_STATE_STAND); 2) existing code changed void UpdateAI(const uint32 uiDiff) override { // lower HP on every world tick makes it a useful counter, not officlone though uint32 uiHPLose = uint32(0.03f * uiDiff);

[B]uiDiff [/B]receives the value of 100 which results in a perfectly acceptable periodic reduction in the patient's health, as far as I am concerned. [B][COLOR="#FF0000"]However[/COLOR][/B], due to the health being reduced on every tick, or whatever it is called, it results in the patient losing some life for a while even though they have been saved, but... We can save the patient from dying by healing it by say 20% at the point in the code where the system decides the patient has been saved, thus: void SpellHit(Unit* pCaster, const SpellEntry* pSpell) override { if (pCaster->GetTypeId() == TYPEID_PLAYER && m_creature->IsAlive() && pSpell->Id == 20804) { Player* pPlayer = static_cast(pCaster); if (pPlayer->GetQuestStatus(6624) == QUEST_STATUS_INCOMPLETE || pPlayer->GetQuestStatus(6622) == QUEST_STATUS_INCOMPLETE) { if (Creature* pDoctor = m_creature->GetMap()->GetCreature(m_doctorGuid)) { if (npc_doctorAI* pDocAI = dynamic_cast(pDoctor->AI())) { pDocAI->PatientSaved(m_creature, pPlayer, m_pCoord); } } } // stop patient dying due to an UpdateAI( ) occuring before the healing can kick in m_creature->SetHealth(uint32(m_creature->GetMaxHealth()*0.20)); // THIS SAVES THE PATIENT // make not selectable m_creature->SetFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_NOT_SELECTABLE); // regen health m_creature->RemoveFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_IN_COMBAT); // stand up m_creature->SetStandState(UNIT_STAND_STATE_STAND); switch (urand(0, 2)) { case 0: DoScriptText(SAY_DOC1, m_creature); break; case 1: DoScriptText(SAY_DOC2, m_creature); break; case 2: DoScriptText(SAY_DOC3, m_creature); break; } m_creature->SetWalk(false); switch (m_creature->GetEntry()) { case 12923: case 12924: case 12925: m_creature->GetMotionMaster()->MovePoint(0, H_RUNTOX, H_RUNTOY, H_RUNTOZ); break; case 12936: case 12937: case 12938: m_creature->GetMotionMaster()->MovePoint(0, A_RUNTOX, A_RUNTOY, A_RUNTOZ); break; } } } ---------- [B][COLOR="#FFD700"]Injured[/COLOR][/B] / [B][COLOR="#FF8C00"]Badly Injured[/COLOR][/B] / [B][COLOR="#FF0000"]Critically Injured[/COLOR][/B] Each type has an equal chance of being chosen: case DOCTOR_ALLIANCE: patientEntry = AllianceSoldierId[urand(0, 2)]; break; case DOCTOR_HORDE: patientEntry = HordeSoldierId[urand(0, 2)]; break; Should this be changed ? ---------------------------- [B]NEXT[/B]: Critically injured dying too fast. Hmm, they should all be losing health at the same rate, unless that uiDiff is not always 100. TOTALLY FREAKING IMPOSSIBLE TO SAVE THE CRITICALLY INJURED PATIENTS!!! hmm, this needs to be rethought! ------------------------------ Okay, to make it so that the Critically Injured patients can actually be healed, but still requiring plenty of clenching of the buttocks situations whilst praying to your deity of choice, I slowed down the health reduction by a bit. I changed the calculation from [COLOR="#FF0000"]0.05f * uiDiff[/COLOR] to [COLOR="#008000"]0.03f * uiDiff[/COLOR] void UpdateAI(const uint32 uiDiff) override { // lower HP on every world tick makes it a useful counter, not officlone though uint32 uiHPLose = uint32(0.03f * uiDiff); if (m_creature->IsAlive() && m_creature->GetHealth() > 1 + uiHPLose) { m_creature->SetHealth(m_creature->GetHealth() - uiHPLose); }

This is scripted in the [B]npc_special.cpp[/B] program file (npc_injured_patient) The periodic loss of health is done in the UpdateAI ( ) function; line 373 onwards. void UpdateAI(const uint32 uiDiff) override { // lower HP on every world tick makes it a useful counter, not officlone though uint32 uiHPLose = uint32(0.05f * uiDiff); if (m_creature->IsAlive() && m_creature->GetHealth() > 1 + uiHPLose) { m_creature->SetHealth(m_creature->GetHealth() - uiHPLose); } if (m_creature->IsAlive() && m_creature->GetHealth() { m_creature->RemoveFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_IN_COMBAT); m_creature->SetFlag(UNIT_FIELD_FLAGS, UNIT_FLAG_NOT_SELECTABLE); m_creature->SetDeathState(JUST_DIED); m_creature->SetFlag(UNIT_DYNAMIC_FLAGS, UNIT_DYNFLAG_DEAD); if (Creature* pDoctor = m_creature->GetMap()->GetCreature(m_doctorGuid)) { if (npc_doctorAI* pDocAI = dynamic_cast(pDoctor->AI())) { pDocAI->PatientDied(m_pCoord); } } } } Presumably the value passed in via the parameter [B]uiDiff [/B]is too high, thus resulting in the speedy loss of health, or could it be that the calculation is not being done correctly? I'll make this my first call tomorrow, if nobody else steps in beforehand :)

Both were added at the same time, if these are to be believed: [url]http://www.wowhead.com/npc=7951/zastysh#comments[/url] [url]http://www.wowhead.com/npc=16076/tharl-stonebleeder#comments[/url] See the Quick Facts section of the page. [B]Added in patch 1.11.1[/B] I'll now look into the other issues now... [B]Big Blizzard Bear[/B] Added in patch 2.4.3 [url]http://www.wowhead.com/item=43599/big-blizzard-bear[/url] [B][COLOR="#B22222"]Removal of the Big Blizzard Bear[/COLOR][/B] No entry found in the creature_template table No entry found in the item_template table Zas'Tysh [B]creature_template [/B][B][COLOR="#800080"]Entry[/COLOR][/B]: 7951 [B][COLOR="#800080"]GossipMenuId[/COLOR][/B]: 6565 [B]gossip_menu_option [/B]table [B][COLOR="#800080"]menu_id [/COLOR][/B]6565 [B][COLOR="#800080"]id[/COLOR][/B] 0 - Murloc pet - [B]item_template [/B][B][COLOR="#800080"]Entry [/COLOR][/B]20371 Blue Murlock Egg - casts spell ID 24696 (resulting in pet Murloc, Murky) : [url]http://www.wowhead.com/spell=24696[/url] [B][COLOR="#800080"]id[/COLOR][/B] 1 - Murloc costume - [B][COLOR="#FF0000"]THIS NEEDS TO BE REMOVED TOO[/COLOR][/B] - patch 2.1.3 - [url]http://www.wowhead.com/item=33079/murloc-costume[/url] [B][COLOR="#800080"]id[/COLOR][/B] 2 - Big Blizzard Bear [B][COLOR="#0000FF"]DELETE FROM gossip_menu_option WHERE `menu_id`='6565' and`id`='1';[/COLOR][/B] [B][COLOR="#0000FF"]DELETE FROM gossip_menu_option WHERE `menu_id`='6565' and`id`='2';[/COLOR][/B] These will remove the Murloc Costume and the Big Blizzard Bear from the items offered by the NPC :) [B]NEXT:[/B] see why entering the code does nothing... I'm not certain, but it looks like a script needs to be associated with each of these via the [B][COLOR="#800080"]action_script_id [/COLOR][/B]field of the [B]gossip_menu_option [/B]table.

Issue found to be due to update not being applied to the mangosdLoadDB.sql file, which changed the structure of the table (added more fields). The adding of the fields was put in place, but the following code that adds the data was not altered to match the change. I'll fix this and PR it. [B][COLOR="#008000"]FIX HAS NOW BEEN PR'd[/COLOR][/B] [url]https://github.com/Chuck5ta/database/commit/0af9bc5ee7af53b255d4b1ad98223d58e6e3431a[/url]