Fix in Progress Build 4.1 Side quest - Vogel

[Pieter Boelen]

Following changes made:
- Smuggling questbook entry disabled
- Crewmember walks up to the player, then starts the dialog (so he won't be standing at the door, allowing the player to walk right past and miss him)
- Called Group_SetTaskNone("Skipper1"); to keep the target ship in place

Additionally, I confirmed that it is 'bQuestDisableMapEnter' that is responsible for disabling the Sail-To menu.

As far as I can tell, this should take care of all the real issues. However, it is still not entirely smooth.

SHOULD 'bQuestDisableMapEnter' affect Sail-To at all?
Is it even necessary here or should we get rid of that line?

If we keep everything as-is, is it necessary to add a Questbook entry as reminder for the player on where to actually find the target ship'?

 

[Grey Roger]

Disabling map entry is probably necessary as the Vogelstruijs might not be there if you leave the island and then return. (I had a similar problem with my "Hornblower" extension. Wolfe's ship is near Martinique, but you don't know that yet. If you direct-sail from Barbados to Guadeloupe or Nevis, you'll almost certainly pass through Martinique's waters, and when you leave, Wolfe's ship disappears. So the dialogs with both Teresa Moreno and Major Hogan put Wolfe's ship back again.)

 

[Pieter Boelen]

Disabling map entry is probably necessary as the Vogelstruijs might not be there if you leave the island and then return.

That's probably true. Though it shouldn't be. I remember it from Governor Ship Hunting Quests and the Smuggling Coastguard though.
Sometimes those quest-added ships are persistent and we have to manually remove them. Except when we WANT them to be persistent and then they vanish without apparent reason.

Remaining questions then:
- SHOULD 'bQuestDisableMapEnter' affect Sail-To?
- Is it necessary to add a Questbook entry as reminder for the player on where to actually find the target ship?

 

[Grey Roger]

Remaining questions then:
- SHOULD 'bQuestDisableMapEnter' affect Sail-To?
- Is it necessary to add a Questbook entry as reminder for the player on where to actually find the target ship?

I'd say 'bQuestDisableMapEnter' should not affect Sail-To, the reason being, when I was programming the convoy battle for "Ardent", I pretty much copied the battle code for the Oiseau from "Tales of a Sea Hawk". This includes the line 'Island_SetReloadEnableGlobal(PChar.location, false);'. (And a corresponding 'Island_SetReloadEnableGlobal(PChar.location, true);' later.) I ran into a problem in that the convoy battle completes when all convoy commanders are dead, which happens when you kill the last one in his cabin, so 'Island_SetReloadEnableGlobal(PChar.location, true);' didn't work and Sail-To was permanently disabled at Jamaica. This was confirmed by putting 'Island_SetReloadEnableGlobal(PChar.location, true);' into "console.c" and using it when I was back on the sea near Jamaica. I've sorted out Ardent's problem.

But what it means is that 'Island_SetReloadEnableGlobal(PChar.location, false);' is the way to disable Sail-To. So 'bQuestDisableMapEnter' should not need to do it as well. Something calling itself "DisableMapEnter" should disable map enter and that's all.

Adding the questbook entry to remind the player where to find the Vogelstruijs makes sense if Sail-To is made to work. It doesn't help to know that the ship is at Boca de Hubon unless you can Sail-To Boca de Hubon or you happen to have a map of Hispaniola and can find out where Boca de Hubon is. Mind you, if Sail-To works, you don't need to Sail-To Boca de Hubon because you can probably Sail-To the Vogelstruijs.

 

[Pieter Boelen]

To clarify, I meant here Sail To also to ships. 'Island_SetReloadEnableGlobal' should do it only for the shore locations.
But apparently 'bQuestDisableMapEnter' affects both for some reason.

when I was programming the convoy battle for "Ardent", I pretty much copied the battle code for the Oiseau from "Tales of a Sea Hawk". This includes the line 'Island_SetReloadEnableGlobal(PChar.location, false);'. (And a corresponding 'Island_SetReloadEnableGlobal(PChar.location, true);' later.) I ran into a problem in that the convoy battle completes when all convoy commanders are dead, which happens when you kill the last one in his cabin, so 'Island_SetReloadEnableGlobal(PChar.location, true);' didn't work and Sail-To was permanently disabled at Jamaica. This was confirmed by putting 'Island_SetReloadEnableGlobal(PChar.location, true);' into "console.c" and using it when I was back on the sea near Jamaica. I've sorted out Ardent's problem.

Ah, yes; when you're in a cabin, then PChar.location is that cabin and not the island you're at.

So 'bQuestDisableMapEnter' should not need to do it as well. Something calling itself "DisableMapEnter" should disable map enter and that's all.

That's what I was thinking too, so I was quite surprised to find out that it did more than just that.
Just wanted to check if anyone could think of an important reason for that. Nothing springs to mind here.
So I'm inclined to search for whatever code is responsible for that and to get rid of it.

Adding the questbook entry to remind the player where to find the Vogelstruijs makes sense if Sail-To is made to work. It doesn't help to know that the ship is at Boca de Hubon unless you can Sail-To Boca de Hubon or you happen to have a map of Hispaniola and can find out where Boca de Hubon is. Mind you, if Sail-To works, you don't need to Sail-To Boca de Hubon because you can probably Sail-To the Vogelstruijs.

Actually, I was thinking of the reverse. If you have a map of Hispaniola, then you can find out where Boca de Hubon is even if Sail-To doesn't work.
If it does work, then you can just use it to instantly go to the quest ship (or randomly try them all) and the Questbook entry may be a bit superfluous.
Doesn't do any harm being in place though. But it's more effort to add it than to not add it.

 

[Levis]

so what should still be done on this bug?

 

[Pieter Boelen]

At the very least, 'bQuestDisableMapEnter' itself should be changed so that it does NOT affect the availability of the Sail-To menu.

 

[Grey Roger]

Have a look at this. I think it might solve the problem, but it will be some time before I can test it.

     case "birdhunt3":
//       bQuestDisableMapEnter = true;
       UpdateRelations();
       Group_CreateGroup("Skipper1");
       Group_AddCharacter("Skipper1", "Skipper1");
       Group_SetGroupCommander("Skipper1", "Skipper1");
       Group_SetTaskRunAway("Attack");
       Group_LockTask("Skipper1");
       Group_SetAddress("Skipper1", "Hispaniola", "Quest_ships", "quest_ship_6");
       Sea_LoginGroupNow("Skipper1");
       characters[GetCharacterIndex("Skipper")].nosurrender = 2;
       SetCharacterRelationBoth(GetCharacterIndex("Skipper1"),GetMainCharacterIndex(),RELATION_ENEMY);
     //   if(GetRMRelation(PChar, HOLLAND) > REL_WAR) SetRMRelation(PChar, HOLLAND, REL_WAR);
       Character_SetAbordageEnable(characterFromID("Skipper1"), false);

       Pchar.quest.birdboarding.win_condition.l1 = "Ship_HP";
       Pchar.quest.birdboarding.win_condition.l1.character = "Skipper1";
       Pchar.quest.birdboarding.win_condition.l1.quantity = 3500;
       Pchar.quest.birdboarding.win_condition.l1.operation = "<";
       Pchar.quest.birdboarding.win_condition = "birdboarding";
       PChar.QuestsCheck = true; // PB: Enable checking quest status every minute at sea

       Pchar.quest.birdhunt_escape_to_sea.win_condition.l1 = "MapEnter";
       Pchar.quest.birdhunt_escape_to_sea.win_condition = "birdhunt3_reset";
     break;

     case "birdhunt3_reset":
       DeleteQuestAttribute("birdhunt3");
       pchar.quest.birdhunt3.win_condition.l1 = "location";
       pchar.quest.birdhunt3.win_condition.l1.location = "Hispaniola";
       pchar.quest.birdhunt3.win_condition = "birdhunt3";
     break;

The 'bQuestDisableMapEnter = true;' line (and corresponding line to set it back to false) are commented out. This means you can leave Hispaniola. If you do, Vogelstruijs might not be there when you return. To counter that, entering the map triggers case "birdhunt3_reset", which clears out any trace that "birdhunt3" was ever called, then sets it to trigger again when you next visit Hispaniola.

Does condition "MapEnter" also trigger if you direct-sail to another island? I think so, because "Hornblower" uses it to detect when you've cleared Jamaica and trigger the capture of Le Reve.

It may be necessary to also set up similar checks for arrival at the various ports and beaches around Hispaniola, just in case the Vogelstruijs also disappears if you land and then return to sea.

Though of course, if 'bQuestDisableMapEnter' is reprogrammed to not disable Sail-To, that would solve the problem more neatly.

 

[Pieter Boelen]

Very nice, @Grey Roger!

Does condition "MapEnter" also trigger if you direct-sail to another island?

It does indeed.

Though of course, if 'bQuestDisableMapEnter' is reprogrammed to not disable Sail-To, that would solve the problem more neatly.

I do think that would make sense as I was quite surprised it even did that at all.
Just need to find what code is responsible for that though.

 

[Grey Roger]

Don't you just love Windows Search? Of course you do.

A search for "if (bQuestDisableMapEnter" turns up "AIShip.c", but all that does is:

if (bQuestDisableMapEnter) { bDisableMapEnter = true; }

Alright, search for "if(bDisableMapEnter" instead. That finds "NK.c" and "BattleInterface.c". And in "BattleInterface.c":

if(bDisableMapEnter)   bMapEnter = false; // PB: Moved up so Sail-To gets disabled correctly
bEnableIslandSailTo = bMapEnter;

 

[Pieter Boelen]

Hmm.... that looks very confusing. Maybe try commenting out that line marked "PB" and see what that does.
I probably had a good reason for doing that, but I can't even remotely remember why.

If that does indeed turn out to be the cause, I should probably try to find when it was changed and hopefully that will lead us to figure out why.

Don't you just love Windows Search? Of course you do.

I love it very much! Can't do it when I'm not near my game files though.