Fixed Kill Ferro Cerezo - not in tavern

[Ketchup]

Ferro Cerezo isn't in the tavern on Sao Jorge after I speak to the padre and get told to sink his ship. I spent a few nights in the tavern and he still isn't there.

 

[Pieter Boelen]

Does he need to be? If you have to sink his ship, then you have to find his ship at sea, no?

I did change some of the code there to deliberately remove him after you leave the location.
See here: Fixed - quest find Danielle: killing ferro cerezo | PiratesAhoy!
Maybe I misunderstood how that quest is supposed to work though. If I did, please let me know what should happen instead.

Perhaps @Grey Roger is more familiar with this than me?

 

[Ketchup]

He should always be in the tavern so you can speak to him, as his ship only spawns at the port if you speak to him first, as it updates your quest book. So yes, he has to be in the tavern.

 

[Grey Roger]

Agreed - Ferro Cerezo must be in the tavern because you need to talk to him first. Case "prepare_ferro_to_Sea" is triggered by his dialog.

@Pieter Boelen: the snag with your fix is that it triggers when you leave the tavern main hall, which means it will probably trigger if you rent a room. It also means he's not there if for any reason you go into the tavern, go away again e.g. to visit the shipyard or store, and then return to the tavern. I'd be inclined to remove case "ferro_leaves" and cancel his immortality at case "prepare_ferro_to_Sea". Or have "ferro_leaves" conditional upon you going to sea, not on leaving the tavern. (I can't see where Ferro Cerezo is removed from the tavern in the older version of the code, but it must happen somehow.)

 

[Pieter Boelen]

Indeed then "ferro_leaves" must be triggered at the same time that questbook entry gets triggered. Then it should be OK.

When I made my changes to this, it was from a save that was made after that fact, so I could not test it properly.
If someone has a compile.log from a full playthrough of that whole scene, that would help as then I can see which quest cases are meant to trigger in sequence.
I have to admit I couldn't quite figure that out last week.

 

[Pieter Boelen]

@Grey Roger: Do you reckon you could find a better spot to put the "set immortal OFF" line?

 

[Grey Roger]

I'd be inclined to remove case "ferro_leaves" and cancel his immortality at case "prepare_ferro_to_Sea".

@Grey Roger: Do you reckon you could find a better spot to put the "set immortal OFF" line?

I'm still part way through playing "Tales of a Sea Hawk" and have not yet reached this point. When I do, if you haven't already corrected the code then I'll have a look at moving the lines to cancel Ferro Cerezo's immortality and remove him from the tavern.

 

[Pieter Boelen]

When I do, if you haven't already corrected the code then I'll have a look at moving the lines to cancel Ferro Cerezo's immortality and remove him from the tavern.

Point is that you are more familiar with that quest than I am since I probably haven't played it in 10 years.
Plus the savegame I had for testing missed out on the beginning that I really needed to check it properly.
So I can try to fix it once more, but chances are I won't get it right again. Which is a perfect waste of my time and efforts.
While you can probably point to the correct quest case right now and save me the trouble.

 

[Grey Roger]

Point is that you are more familiar with that quest than I am since I probably haven't played it in 10 years.
Plus the savegame I had for testing missed out on the beginning that I really needed to check it properly.
So I can try to fix it once more, but chances are I won't get it right again. Which is a perfect waste of my time and efforts.
While you can probably point to the correct quest case right now and save me the trouble.

I did. Case "prepare_ferro_to_Sea".

Although I've played the story several times (as there wasn't any other storyline when I was playing the stock game and Build 13 ) I haven't looked at the code in as much detail as, for example, "Hornblower" and "Assassin". But although it's hard to trace through the code as the code is a mess, it was by searching for mention of "Ferro Cerezo" that I found this quest case. So, when I get to that point in the story, I'll try moving the lines for cancelling immortality and removing from tavern to that case, then test it to see that it works properly. Until then, I'm still working on the Royal Navy fleet repaint and my own storyline...

 

[Pieter Boelen]

Ferro Cerezo isn't in the tavern on Sao Jorge after I speak to the padre and get told to sink his ship. I spent a few nights in the tavern and he still isn't there.

Is that a savegame where he is already missing? Do you also have a savegame from a bit earlier?

 

[Ketchup]

The previous is after, this is before I speak to the padre :

 

[Pieter Boelen]

Save attached to PROGRAM\Storyline\standard\quests; that should hopefully prevent it in the future.

On an existing savegame execute this through console:

ChangeCharacterAddressGroup(characterFromID("ferro cerezo"), "Conceicao_tavern", "sit", "sit5");

 

[Ketchup]

It works, I expected nothing less
However, the padre claims that his ship is a sloop, and it is a pinnace, so just a small confusion between what is said and what actually happens.

 

[Pieter Boelen]

It works, I expected nothing less

I assume you mean that the console command works?

I'd quite like to know if the actual fix works too.
But the only way to find out is to play through the story again from a point before Ferro "ran off".

However, the padre claims that his ship is a sloop, and it is a pinnace, so just a small confusion between what is said and what actually happens.

This line?

"I managed to find out that he has his own ship. It's a sloop, if I am not mistaken. And he is often seen at #sConceicao# - he's probably involved in smuggling.",

I don't remember that ever being changed, suggesting it's been wrong since the original game.
Anyway, that's easily rectified in PROGRAM\DIALOGS\English\padre Domingues_dialog.h

 

[Grey Roger]

I've tested it and found that Ferro Cerezo still doesn't work properly.

Case "prepare_ferro_to_Sea" is not in fact a useful place for anything. It's triggered by dialog with Ferro Cerezo, so putting the line to make him immortal there means you can still kill him in the tavern if you do it without talking to him first. And the line to cancel his immortality has not been put back, so when you go to sea to attack his ship, the ship is invulnerable.

The attached version of "quests_reaction.c" has the immortality line moved back to case "prepare_for_meet_ferro", which is triggered by the dialog with Padre Domingues and is where Ferro Cerezo is first placed in Sao Jorge tavern. The line to cancel his immortality is added to case "to_sea_for_capture_cerezo", which is when you've just put to sea. There's still no line to remove Ferro Cerezo from the tavern; he's removed anyway if you kill him at sea, but not if you buy the documents from him, and I imagine that's always been the case. If we do want to remove him from the tavern then case "kicked_to_mine_complete" seems to be a good place - it already has lines to cancel cases "kill_ferro_cerezo" and "abording_ferro_cerezo". (It's where you've just left Bridgetown to go to the mine and have met the thugs who want to enslave you.)

But there's one other snag which I don't know how to fix. The last line of case "to_sea_for_capture_cerezo" is:

SetCharacterRelation(GetCharacterIndex("Conceicao Commander"),GetCharacterIndex("Ferro Cerezo"),RELATION_FRIEND);

Here's what "Conceicao Commander", alias Basil Vespucci, thinks of that:


I didn't have to do a thing. One of my companion ships, Mefisto, fired a broadside into Ferro Cerezo's ship, but a single salvo of 12lb cannonballs isn't going to do much to a pinnace; all the real work was done by the fort.

 

[Pieter Boelen]

Case "prepare_ferro_to_Sea" is not in fact a useful place for anything. It's triggered by dialog with Ferro Cerezo, so putting the line to make him immortal there means you can still kill him in the tavern if you do it without talking to him first. And the line to cancel his immortality has not been put back, so when you go to sea to attack his ship, the ship is invulnerable.

Did I not set Immortal to 'true' first and then set it to 'false' afterwards?
Or did I by accident only move the 'true' one to later?

The attached version of "quests_reaction.c" has the immortality line moved back to case "prepare_for_meet_ferro", which is triggered by the dialog with Padre Domingues and is where Ferro Cerezo is first placed in Sao Jorge tavern. The line to cancel his immortality is added to case "to_sea_for_capture_cerezo", which is when you've just put to sea. There's still no line to remove Ferro Cerezo from the tavern; he's removed anyway if you kill him at sea, but not if you buy the documents from him, and I imagine that's always been the case. If we do want to remove him from the tavern then case "kicked_to_mine_complete" seems to be a good place - it already has lines to cancel cases "kill_ferro_cerezo" and "abording_ferro_cerezo". (It's where you've just left Bridgetown to go to the mine and have met the thugs who want to enslave you.)

I'm not too fussed about him not leaving. Maybe he could be "cleaned up" at a later stage as you suggest,
just in case so he doesn't needlessly and permanently occupy a seat that could be used for other purposes.

But there's one other snag which I don't know how to fix. The last line of case "to_sea_for_capture_cerezo" is:

SetCharacterRelation(GetCharacterIndex("Conceicao Commander"),GetCharacterIndex("Ferro Cerezo"),RELATION_FRIEND);

Here's what "Conceicao Commander", alias Basil Vespucci, thinks of that:

All 'SetCharacterRelation' are absolutely meaningless after my complete rewrite of the Nation and Sea Relations code.
Now all relations are based directly on the flag flown and nation relations.
Pirate and Portugal are hostile to each other, therefore a Portuguese fort will try to sink a Pirate ship.
By far the simplest solution to prevent that is to make Ferro Cerezo Portuguese with NPChar.nation = PORTUGAL; .

Before I did my rewrite, all of it was insanely complicated, messy and was very capable of not doing what you'd expect or want.
So to prevent myself going crazy, I did not try to replicate all the original functionality,
but I substantially simplified it all so that at least it would consistently do what we want.

In this process, we did lose the ability to set relations between specific characters.
If at all possible, I'd like to avoid bringing that back and instead make sure that character nationalities and nation relations make sense in context.
Actually having this working properly should be possible in theory, but would probably require some substantial development.

 

[Grey Roger]

Did I not set Immortal to 'true' first and then set it to 'false' afterwards?
Or did I by accident only move the 'true' one to later?

The latter. But it was I who suggested using case "prepare_ferro_to_Sea", so I'll accept part of the blame.

I'm not too fussed about him not leaving. Maybe he could be "cleaned up" at a later stage as you suggest,
just in case so he doesn't needlessly and permanently occupy a seat that could be used for other purposes.

The main snag with using that seat for other purposes, e.g. some new side quest, is what happens when someone tries to do that side quest when this part of the main quest is active and Ferro Cerezo is supposed to be there? Likewise, anyone wanting to have new side quest action in Kralendijk tavern should avoid the seats used by Raoul Rheims and Toff Oremans.

All 'SetCharacterRelation' are absolutely meaningless after my complete rewrite of the Nation and Sea Relations code.
Now all relations are based directly on the flag flown and nation relations.
Pirate and Portugal are hostile to each other, therefore a Portuguese fort will try to sink a Pirate ship.
By far the simplest solution to prevent that is to make Ferro Cerezo Portuguese with NPChar.nation = PORTUGAL; .

What's going to happen when you attack him? If I understand the relations system correctly, either you'll need to raise a flag hostile to Portugal, which means the fort will attack you; or you attack him while under a flag friendly to Portugal, which is very naughty and will cost you lots of reputation.

That does explain why my early attempts to turn the English convoy in "Convoy Strike" in "Ardent" didn't work. They disregarded the command to turn them hostile because they were still under an English flag and you were still under an English or allied flag (you wouldn't have got out of Curacao without being attacked by the fort otherwise). In the end I settled for temporarily setting Spain at war with England and having you auto-hoist a Spanish flag, then make Spain allied to England again when the battle was over. Perhaps do something similar here - temporarily make Portugal neutral to Pirates (not allied, we still don't want Portugal to object to you attacking Ferro Cerezo), then set Portugal back to being hostile to Pirates when the battle ends. Perhaps also set Ferro Cerezo to use a less obviously piratey Pirate flag, e.g. one of the Moorish style flags with crescents rather than skull and crossbones, so it doesn't look so silly when the fort fails to fire at a blatant pirate.

In this process, we did lose the ability to set relations between specific characters.
If at all possible, I'd like to avoid bringing that back and instead make sure that character nationalities and nation relations make sense in context.

The fundamental problem remains - if you make an enemy character friendly to a fort then you need to turn hostile to the fort to attack him, and if you make him hostile to the fort then the fort attacks him. In some periods it may be less of a problem because of the way international relations are set, but in "Colonial Powers" you basically have two power blocs: Britain + Holland + Portugal against France + Spain. (And, of course, Pirates hostile to everyone as usual.) So without some temporary messing about, everyone is either allied to the fort or hostile to the fort.

 

[Pieter Boelen]

The latter. But it was I who suggested using case "prepare_ferro_to_Sea", so I'll accept part of the blame.

As long as we get it right in the end. Thanks for catching!

The main snag with using that seat for other purposes, e.g. some new side quest, is what happens when someone tries to do that side quest when this part of the main quest is active and Ferro Cerezo is supposed to be there? Likewise, anyone wanting to have new side quest action in Kralendijk tavern should avoid the seats used by Raoul Rheims and Toff Oremans.

All I'm saying is that a permanently occupied seat that isn't used for anything relevant is superfluous.

What's going to happen when you attack him? If I understand the relations system correctly, either you'll need to raise a flag hostile to Portugal, which means the fort will attack you; or you attack him while under a flag friendly to Portugal, which is very naughty and will cost you lots of reputation.

You can add the "recognized" attribute to make him hostile regardless of flag flown.
And you can add the "skipRM" attribute to avoid any potential penalties from attacking him.
That does mean you also don't gain any points for it,
but there are plenty more ships out there as targets for your promotions if you really need them.
So that shouldn't be all that much of a problem.

That does explain why my early attempts to turn the English convoy in "Convoy Strike" in "Ardent" didn't work. They disregarded the command to turn them hostile because they were still under an English flag and you were still under an English or allied flag (you wouldn't have got out of Curacao without being attacked by the fort otherwise). In the end I settled for temporarily setting Spain at war with England and having you auto-hoist a Spanish flag, then make Spain allied to England again when the battle was over.

You could have used the "recognized" attribute there too.
That is ship-specific and should do the trick.

The fundamental problem remains - if you make an enemy character friendly to a fort then you need to turn hostile to the fort to attack him, and if you make him hostile to the fort then the fort attacks him. In some periods it may be less of a problem because of the way international relations are set, but in "Colonial Powers" you basically have two power blocs: Britain + Holland + Portugal against France + Spain. (And, of course, Pirates hostile to everyone as usual.) So without some temporary messing about, everyone is either allied to the fort or hostile to the fort.

Please think about those two attributes that already exist.
As far as I understand, it should solve pretty much all of these potential issues.
Admittedly not perfect, but quite simple and already operational.

 

[Grey Roger]

You can add the "recognized" attribute to make him hostile regardless of flag flown.
And you can add the "skipRM" attribute to avoid any potential penalties from attacking him.
That does mean you also don't gain any points for it,
but there are plenty more ships out there as targets for your promotions if you really need them.
So that shouldn't be all that much of a problem.

What exactly does "recognised" do? And, if Ferro Cerezo is Portuguese but "recognized" you and attacks you anyway, what will the fort do when you attack what it thinks is an ally?

You could have used the "recognized" attribute there too.
That is ship-specific and should do the trick.

I'd never heard of "recognized". But I did know about "skipRM", and used it.

The problem with "skipRM" is that it is liable to confuse a player who doesn't know the technical workings of the game, has just got the hang of a relations system which requires you to hoist a hostile flag before attacking a ship, then has to figure out that this time he must not do so and can get away with attacking this ship, but not any other Portuguese ships which happen to be in the area. This is why I didn't use "skipRM" to solve relation issues in "Assassin". But in "Ardent", I made it blatantly clear in both dialog and questbook that there's a very specific story-related reason why you're allowed to attack these English ships but no others. The only way I can think of to make it work here is to change the quest so that you first have a dialog with the governor which similarly makes it clear to the player that he's allowed to attack this Portuguese ship but no other.

 

[Pieter Boelen]

What exactly does "recognised" do?

It forces a ship to be hostile to you regardless of actual nation relations and flags flown.

And, if Ferro Cerezo is Portuguese but "recognized" you and attacks you anyway, what will the fort do when you attack what it thinks is an ally?

The fort will do nothing. They're not in the same group as Ferro Cerezo, so the only link between them would be that they're both Portuguese.
But Portugal won't be offended if you take care of Cerezo; not until you capture/sink him anyway and definitely not if he has "skipRM" set.

The problem with "skipRM" is that it is liable to confuse a player who doesn't know the technical workings of the game, has just got the hang of a relations system which requires you to hoist a hostile flag before attacking a ship, then has to figure out that this time he must not do so and can get away with attacking this ship, but not any other Portuguese ships which happen to be in the area.

Assuming the player is neutral/friendly to Portugal, Ferro Cerezo would be the only hostile Portuguese ship around.
Since he'd have "skipRM", the player would not get the reminder about hoisting a hostile flag, so at least the game won't be actively confusing.
If you do decide to hoist a hostile flag, that is not actually a problem (other than turning all other Portuguese forts/ships hostile); it just isn't necessary.
So if you don't, then you won't be penalized.

For now, this has mainly been applied to any ships that are "Pirate" but not loyal to the actual Pirate Brotherhood.
Examples are the Animists, but also all English quest ships in the Standard Storyline.

I think this is more a problem with the actual stories than with the Nations Relations system though.
Restoring the 'SetCharacterRelation' functionality would not do anything to improve on this as it would be equally confusing.
The best solution is what you said yourself: Ensure there is a valid story-related reason why there is an exception to the rule.
If that reason is clearly communicated to the player, then all the better!