Fixed Odd error while pirate-hunting

[Grey Roger]

After accepting a mission from the governor of Port Royale to attack a pirate ship, I saw this error:



Attached are the log files. This was under Beta 3.3 from 9th November.

By itself, it's fairly insignificant. The quest appeared to go as planned - the pirate ship appeared, I captured it, and was duly rewarded. So originally I put this into the "Minor bugs in Beta 3.3" thread. But the next thing which happened was the bug reported in Promotion ships, so just in case they're related, the report is here too.

 

[Pieter Boelen]

Weirdness:

storyline\Assassin\quests\quests_reaction.c not loaded, loading now!
storyline\Assassin\quests\both_reaction.c not loaded, loading now!
ERROR - Quest name kill_pirate_agree NOT found in ANY function

That case name IS actually defined. In PROGRAM\QUESTS\quests_common.c to be exact.
Which is a file that should always be loaded and therefore this should not be a problem at all.

These error messages were originally added by me because sometimes the game "forgets" that it is supposed to have quests_reaction.c/both_reaction.c loaded.
See PROGRAM\QUESTS\quests.c .

"kill_pirate_agree" is called through AddDialogExitQuest, which indirectly calls CompleteQuestName:

void CompleteQuestName(string sQuestName)
{
   if( CheckAttribute(&objQuestScene,"list."+sQuestName+".chrIdx") )
   {
     Event("qprocTaskEnd","a",GetCharacter(sti(objQuestScene.list.(sQuestName).chrIdx)));
   }
   else
   {
     // PB: Error checking -->
     ref PChar = GetMainCharacter();

     // Common Quests
     CommonQuestComplete(sQuestName);             // <-- Execute the actual quest case
     if(!CheckAttribute(PChar, "questnotfound"))
     {
       trace("Quest name " + sQuestName + " FOUND in CommonQuestComplete");
       return;
     }
     DeleteAttribute(PChar, "questnotfound");

     // Main Quests
     LoadStorylineFile("quests\", "quests_reaction.c");     // PB: To Prevent Errors
     QuestComplete(sQuestName);                 // <-- Execute the actual quest case
     if(!CheckAttribute(PChar, "questnotfound"))
     {
       trace("Quest name " + sQuestName + " FOUND in QuestComplete");
       return;
     }
     DeleteAttribute(PChar, "questnotfound");

     // Both/Side Quests
     LoadStorylineFile("quests\", "both_reaction.c");     // PB: To Prevent Errors
     BothQuestComplete(sQuestName);               // <-- Execute the actual quest case
     if(!CheckAttribute(PChar, "questnotfound"))
     {
       trace("Quest name " + sQuestName + " FOUND in BothQuestComplete");
       return;
     }
     DeleteAttribute(PChar, "questnotfound");

     TraceAndLog("ERROR - Quest name " + sQuestName + " NOT found in ANY function");
     // PB: Error checking <--
   }
}

It should be able to find the quest name there just fine and the error message should not show up.

One thing that might possibly explain it is this new code:

    case "pchar_curare":
       if(CheckAttribute(Pchar, "chr_ai.curare"))
       {
         LAi_ApplyCharacterDamage(Pchar, 1);

         LAi_QuestDelay("pchar_curare", 10.0);
       }
       else return;
     break;

I think that last part "else return;" should be removed to ensure that the function IS allowed to complete.
If it does find the quest, but then stops executing the function, the game will think it didn't find it and give an error message like that.
Even though it DID find it and the game will work just like it should.

@Jack Rackham: Is there any specific reason for that return being there?

 

[Levis]

yes the return part should be removed.
What happens now is that the first file is loaded, everything is set but because of the return statement the game doesn't recognise the case was found and theirefore it loads up the next file in which it isn't found so an error is posted.
removing the return statement should fix this.

 

[Jack Rackham]

I was anxious that the 10 sec loop not was properly stopped when the curare attribute was deleted.
I was obviously wrong.

 

[Pieter Boelen]

We're probably good to remove it then. Thanks for confirming, @Jack Rackham.