• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Included in Build False Flags: Modify Memory Functionality

If you want to look at some relevant code, it is all in PROGRAM\Screwface_functions.c .
Specifically this spot:
Code:
         chr.PlayerNation = iNation;
         Trace("FLAGS: The " + GetMyShipNameShow(chr) + " has spotted us at " + ship_range + " and will remember us as " + GetNationDescByType(iNation) + " with visibility=" + visibility_range);
That is where an NPC starts to remember what nation you belong to (specifically what flag you were flying when you were spotted).

And this function that gets called when your false flag is recognized:
Code:
void SetGroupHostile(ref chr, bool bBetrayed)
{
   int i, num, otherChar;
   string sGroupID = GetGroupIDFromCharacter(chr);
   if (sGroupID == "") // For forts and other ships that may not be in any group
   {
     chr.recognized = 1;
     if (bBetrayed) chr.betrayed = 1;
   }
   else
   {
     ref rGroup = Group_GetGroupByID(sGroupID);
     num = Group_GetCharactersNumR(rGroup);
     for (i = 0; i < num; i++)
     {
       otherChar = Group_GetCharacterIndexR(rGroup, i);
       characters[otherChar].recognized = 1;
       if (bBetrayed) characters[otherChar].betrayed = 1;
     }
     Group_SetTaskAttack(sGroupID, PLAYER_GROUP, false); // False to skip call to SetCharacterRelationBoth!
   }
}

The spots where .PlayerNation and .recognized are set to 1 is where the timer has to be started for that specific character.

Then when the timer expires, this function from PROGRAM\NATIONS\nations.c should be called for that specific character:
Code:
void ResetCharacterMemory(ref chr)
{
   DeleteAttribute(chr,"recognized");
   DeleteAttribute(chr,"betrayed");
   DeleteAttribute(chr,"PlayerNation");
   DeleteAttribute(chr,"relation_to_pirates");
}

So we know where to start it and we know where it should lead. We also know mostly how to get there.

First have a quest case which detects that you're on the worldmap, triggered like this:
Code:
Pchar.quest.start_countdown.win_condition.l1 = "MapEnter";
Pchar.quest.start_countdown.win_condition = "start_countdown";
Then quest case "start_countdown" is your one with the expiry date.
The main thing I am wondering about is how to make that work for a whole bunch of NPCs individually.

It can't be "Pchar.quest.start_countdown", but has to be "NPchar.quest.start_countdown".
And then the next quest case that gets called needs to be called for that same NPC.
So the character ID that it applies to needs to be maintained through several quest cases.

Should be possible. I just haven't thought of exactly how yet.

I don't know where or how you'd check if the player's ship is the stored one, but the basic logic would be something like this:
Code:
if (<player's ship> == <stored ship>) return true;
for (n=1; n<4; n++)
{if (companion ship(n) == <stored ship>) return true;}
return false;
I'm not sure off-hand how to get <player's ship> or <companion ship(n)>, but presumably there is a function to find what type of ship is used by the player or in any given companion slot. <stored ship> will have been copied from <player's ship> at some point where the fort is remembering you.
GetCharacterShipID(ref char) is the safest way of doing that.
 
I'll need some time to look through that in detail if I'm going to do anything sensible to it. But for now...

The main thing I am wondering about is how to make that work for a whole bunch of NPCs individually.

It can't be "Pchar.quest.start_countdown", but has to be "NPchar.quest.start_countdown".
And then the next quest case that gets called needs to be called for that same NPC.
So the character ID that it applies to needs to be maintained through several quest cases.

Fair enough, but they still need to check that you have left the island. Since the character being checked is no longer the character which owns the quest, I believe it needs an extra line:
Code:
NPchar.quest.start_countdown.win_condition.l1 = "MapEnter";
NPChar.quest.start_countdown.win_condition.l1.character = Pchar.id; // <--  This one
NPchar.quest.start_countdown.win_condition = "start_countdown";[code]
 
Indeed it needs to be the Player entering the map for the timer on the NPC to be started.

From my side, the main query I have is how to run separate quest timers for all relevant characters and have it still apply specifically to that character?

If I know that part, sorting out the rest should be relatively simple.
I just don't know if that had ever been done before and if it works.

I think the Church Help sidequest stores some quest attributes on Father Bernard (?).
But that still relates to the player, if I recall, which is what we don't want here.

If you do end up trying to understand the code I posted before, feel free to ask any questions you might have.
I wrote it so at least there is someone around who knows what it does and why. :doff
 
I had a quick look into this one and it seems that I was right to not know how to do what I have in mind; it is NOT easy!

Quest checks basically are only being done on quest attributes assigned to the player character.
So you can ASSIGN them to another character, but that has no effect.

A second problem is that when a quest case executes, the ONLY information you have available is the name of that quest case.
All the other quest attributes are, by that time, already gone.
So you can execute the "Forgetting" case, but you won't know who it is that should do the forgetting.

This is the quest case I was trying to make work:
Code:
     case "Forgetting_Test":
       NPChar = GetCharacter(sti(objQuestScene.list.(sQuestName).chrIdx));
       LogIt("Quest executed on " + GetMySimpleName(NPChar) );
     break;
With this in console:
Code:
   ch = CharacterFromID("Dou_soldier_1");

   DeleteAttribute(pchar, "quest.Forgetting_Test");
  
   pchar.quest.Forgetting_Test.win_condition.l1 = "Location";
   pchar.quest.Forgetting_Test.win_condition.l1.character = ch.id;
   pchar.quest.Forgetting_Test.win_condition.l1.location = pchar.location;
   pchar.quest.Forgetting_Test.win_condition = "Forgetting_Test";
   QuestsCheck();
   ExecuteQuestCheck(QuestNameForChr(ch));
  
//   DumpAttributes(ch);
  
//   DumpAttributes(objQuestScene);

That makes this decidedly complicated and maybe even impossible. At least through "quest cases".
I have been trying some quite fancy tricks, but none seem to work.
A different solution seems to be required.....


New option would be to handle it in a similar way to the "last speak date" for item traders.
That means storing not just the "playerNation"/"recognized" attribute, but storing also the date at which it happened.
Then some time later, you can check how much time has passed since that was stored and, if it exceeds the delay, erase the memory.

With that logic, it can probably be kept within the CheckInitialFlagRelations function itself.
That function gets called every time RefreshBattleInterface(bool CheckRelations) gets called with CheckRelations = true .
When I did my rewrite, for performance reasons I tried to limit the amount of times that happens.
So now that gets called if:
- Player hoists another flag
- Any ship or fort recognized your false flag
- You close the "Transfer" interface (because you may have just completed boarding)
- Some other interface code that I think shouldn't be very relevant
- Companion turns hostile
- You fire on a non-hostile ship (to turn the other ship hostile)
- When a ship surrenders
- When you close the Nation Relations interface

In other words: Basically whenever you could expect relations to have changed for some reason.

Alternatively, it could be a single "forget me" check while the 3D scene is loaded.
 
Actually, I think it might be OK if NPC ships don't forget. Ever.
Because brand new ships get generated after a while and the new ones don't remember. So no problem there.

That means it is mainly just forts, because those are persistent.
Those weren't part of the False Flags Checking mod before, because Screwface couldn't make them work.
But after my rewrite, now they DO work. Which is great from a functional point of view.
Not quite ideal for gameplay yet though....
 
On the contrary, I'd have thought that false flag checking is exactly where the fort ought to have its chance to get you. It's just spotted a ship coming in under a friendly flag. Unless that ship does something naughty, e.g. fires at the fort or attacks another friendly ship, the fort has no reason to suspect it. Unless, that is, someone with a high power spyglass has recognised my face - and that's the false flag check.

Meanwhile, I did a bit of experimenting and confirmed it. In a previous version of Beta 4, I can pirate the payroll ship, get attacked by Santiago fort, sail off to Isla Mona, return, and the fort does not attack me again. In the current version I do exactly the same and the fort attacks. So something has changed. Though it may have changed in the 27th March version because I didn't get round to installing that before the 2nd April official release made it redundant, so the version in which I wasn't attacked is the 17th March version.
 
On the contrary, I'd have thought that false flag checking is exactly where the fort ought to have its chance to get you. It's just spotted a ship coming in under a friendly flag. Unless that ship does something naughty, e.g. fires at the fort or attacks another friendly ship, the fort has no reason to suspect it. Unless, that is, someone with a high power spyglass has recognised my face - and that's the false flag check.
I'm not sure what you're saying there.
All I was saying is that until Beta 3.4, forts never ever did false flag detection. Now they do, in exactly the same way that applies to ships.

Ships don't need to forget (because they're generated brand new soon enough anyway), but forts are persistent.
Therefore having them also not forget means that once they've seen you as hostile, it'll remain that way for the rest of the game.
That is an (unintentional) side-efect of the system actually working.

Meanwhile, I did a bit of experimenting and confirmed it. In a previous version of Beta 4, I can pirate the payroll ship, get attacked by Santiago fort, sail off to Isla Mona, return, and the fort does not attack me again. In the current version I do exactly the same and the fort attacks. So something has changed. Though it may have changed in the 27th March version because I didn't get round to installing that before the 2nd April official release made it redundant, so the version in which I wasn't attacked is the 17th March version.
If you want to be sure, compare the Screwface_functions.c file between the Beta 4 public release version and the one where the behaviour seemed different.
You should see that there is only one single change that affects anything, but that is just a fix and doesn't affect false flag detection.

Unless the previous version you checked is REALLY old. But the relevant code hasn't really been touched since the modpack was called Beta 3.5 WIP.
That seems extremely unlikely though.

Also note that you CANNOT determine any difference based on just one single observation due to the random element.
You may be recognized and you may not be. That makes all the difference in the world and there is just no guarantee of it always playing out the same way.

Double-check your compile.log, because that will tell you if you were recognized or not.
If you happened to be recognized in one modpack version, but not in the other, then naturally the behaviour afterwards would be different.
It could also depend on how close you got to the fort. So a simple comparison without checking the circumstances means nothing.

Do you remember how I insisted for a long, long time to maintain a 100% false flag detection chance for testing purposes?
This example tells you why.
 
@Grey Roger: I still don't think I understood your last message. :unsure

If you want to do reproducible tests with false flag detection, I recommend removing the // from the last line shown here in PROGRAM\Screwface_functions.c:
Code:
      chance = 0.5 + chance; // 0.5 will be decreased if you are too easily recognized
       chance = chance * GetChanceDetectFalseFlag();
     //   chance = 1.0;
Then if your flag CAN be detected, it WILL be detected. At least you know what you get then, without leaving it to chance.


Other than that, what is going to be done here? I've got ideas aplenty, but none that are good quick-fixes.
Not better than the four workarounds I already mentioned anyway.

So if it is up to me, I do intend to eventually tackle this. But I have no clue when that might be.
If it is within the next two months, that would be early.
 
Sorry, I've been busy with other things.

But I can say with near certainty that it's nothing to do with false flag detection because the results are consistent and repeatable. I start with a savegame well away from Cuba, sail to Cuba on worldmap, then switch to 3D sailing and Sail-To Santiago, so the range from the fort is consistent. If I do this with the 2nd April version, the fort always fires. If I do it with the 17th March version, the fort never fires. No other fort causes any trouble, not surprisingly since I'm currently "Unrecognised" so they have very little chance of detecting the false flag.

It is safe to assume that the version in which the fort does not remember me and does not fire is not that ancient. Partly because this is the "Ardent" storyline, which didn't exist until the beginning of this year. And partly because the game main screen tells you which version it is, which is how I know it's the 17th March one. :D

It occurs to me that it's entirely reasonable within the quest for Santiago fort to remember that the last time it saw that SP_CastelF, I'd just pirated it. So I'm considering adding a questbook entry saying that the ship is hot and you need to get rid of it soon, especially if you plan to go to Santiago - which you will for other quest purposes.

Does 'ResetFort' take effect immediately? If so, it becomes easy to handle this for quest purposes. Have one quest case right after capturing the ship which activates on "mapenter", whose only job is to set up another one which activates when you enter Cuba waters. That one is to check if your ship or any of your companions is a SP_CastelF, and if not, call ResetFort. Provided that stops Santiago fort from firing at you even if you exited worldmap right in Santiago harbour, that ought to sort out the quest. But things become a lot more complex if 'ResetFort' only works if it's called before the fort has seen you again.
 
But I can say with near certainty that it's nothing to do with false flag detection because the results are consistent and repeatable. I start with a savegame well away from Cuba, sail to Cuba on worldmap, then switch to 3D sailing and Sail-To Santiago, so the range from the fort is consistent. If I do this with the 2nd April version, the fort always fires. If I do it with the 17th March version, the fort never fires. No other fort causes any trouble, not surprisingly since I'm currently "Unrecognised" so they have very little chance of detecting the false flag.
What does compile.log say? There should be some lines in there to say what is going on with that fort.

It is safe to assume that the version in which the fort does not remember me and does not fire is not that ancient. Partly because this is the "Ardent" storyline, which didn't exist until the beginning of this year. And partly because the game main screen tells you which version it is, which is how I know it's the 17th March one. :D
Can you post Screwface_functions.c from the version that seems different to you?

It occurs to me that it's entirely reasonable within the quest for Santiago fort to remember that the last time it saw that SP_CastelF, I'd just pirated it. So I'm considering adding a questbook entry saying that the ship is hot and you need to get rid of it soon, especially if you plan to go to Santiago - which you will for other quest purposes.
But whatever IS going on, it is NOT ship-related. Because no such feature currently exists.

Does 'ResetFort' take effect immediately? If so, it becomes easy to handle this for quest purposes. Have one quest case right after capturing the ship which activates on "mapenter", whose only job is to set up another one which activates when you enter Cuba waters. That one is to check if your ship or any of your companions is a SP_CastelF, and if not, call ResetFort. Provided that stops Santiago fort from firing at you even if you exited worldmap right in Santiago harbour, that ought to sort out the quest. But things become a lot more complex if 'ResetFort' only works if it's called before the fort has seen you again.
'ResetFort' doesn't exist; it is 'ResetFortS' if you want to call it on all forts of a certain nation.
Otherwise, you can call this function on the fort commander:
Code:
void ResetCharacterMemory(ref chr)
{
   DeleteAttribute(chr,"recognized");
   DeleteAttribute(chr,"betrayed");
   DeleteAttribute(chr,"PlayerNation");
   DeleteAttribute(chr,"relation_to_pirates");
}
That immediately removes the "memory" attributes. Of course if you do that while still in sight, the fort may get a new memory again straight away.
Calling it on the worldmap would definitely work, because next time you enter 3D sailing mode, the "loss of memory" takes effect on the actual relations.
 
At last, here's a "compile.log" from after I'd loaded a savegame, sailed to Cuba, Sailed-To Santiago and been shot at by the fort. As expected, there's nothing about recognition. Havana remembers me as Spanish - last time it saw me, I was sailing away in a war tartane which, being handed to the character by a "GiveShip2Character", wasn't known by the game to have been pirated, so the fort had no reason to be suspicious. Santiago remembers me as pirate because it saw me capture the payroll ship.

Which is fine. Partly because it makes sense and partly because I've finally remembered that there's another way into Santiago anyway - land at Bahia de Moa and walk to the exit at the port. So for now I've simply added a bit to the closing questbook entry for the "Payroll Ship" quest which advises that the ship is known to be pirated so if you want to visit Santiago, do it via Bahia de Moa.

I'll want to use that 'ResetCharacterMemory' for the "Kidnap" quest because if you go for the ransom, the deal is done at Playa de Sierra Maestra, which is in sight of the fort (that's why it sees you pirating the payroll ship). Part of the deal is that the fort won't fire at you. But once you're away and safe after the deal, I want Santiago to be particularly dangerous because now the governor really hates you, so is there a way to make a fort remember you as a pirate? Or to store the fort's memories somewhere so they can be restored after the ransom deal is complete?

Incidentally, something other than "Screwface_functions.c" must be responsible. I tried copying it from the 17th March install, reloaded a savegame from before I had taken the payroll ship, replayed the attack, sailed away from Cuba (made sure the island icon on worldmap had vanished), sailed back to Cuba, Sailed-To Santiago, and still got attacked. (And also copied the current version of "Screwface_functions.c" so I could put it back again after the experiment.) For good measure, I tried the same thing with "SEA_AI\AiFort.c", with the same result.
 

Attachments

  • compile.log
    5.1 KB · Views: 162
Last edited:
a war tartane which, being handed to the character by a "GiveShip2Character", wasn't known by the game to have been pirated, so the fort had no reason to be suspicious.
Just to prevent any possible confusion, at the moment at least recognition is in no way related with the ship you're sailing.

I'll want to use that 'ResetCharacterMemory' for the "Kidnap" quest because if you go for the ransom, the deal is done at Playa de Sierra Maestra, which is in sight of the fort (that's why it sees you pirating the payroll ship). Part of the deal is that the fort won't fire at you.
There is a character attribute you can add so that a specific character will ALWAYS believe your false flag.
Look up the captain of the Montanez; he has that.
You should be able to add that attribute to the fort commander to ensure he won't be "clever" and recognize you when he shouldn't.
Doing that works similarly to my answer below; just with that other attribute of which I cannot remember the name right now.

But once you're away and safe after the deal, I want Santiago to be particularly dangerous because now the governor really hates you, so is there a way to make a fort remember you as a pirate? Or to store the fort's memories somewhere so they can be restored after the ransom deal is complete?
I think this should do it:
ch = CharacterFromID(*insert ID of fort command*);
ch.PlayerNation = PIRATE;
[/CODE]

Incidentally, something other than "Screwface_functions.c" must be responsible. I tried copying it from the 17th March install, reloaded a savegame from before I had taken the payroll ship, replayed the attack, sailed away from Cuba (made sure the island icon on worldmap had vanished), sailed back to Cuba, Sailed-To Santiago, and still got attacked. (And also copied the current version of "Screwface_functions.c" so I could put it back again after the experiment.) For good measure, I tried the same thing with "SEA_AI\AiFort.c", with the same result.
Other files that may be related:
PROGRAM\NATIONS\nations.c
PROGRAM\SEA_AI\sea.c
PROGRAM\SEA_AI\AIShip.c
PROGRAM\BATTLE_INTERFACE\BattleInterface.c

But I don't think any of those were changed in ways that should affect hostility at all.
And really, all relevant parts are now within just Screwface_Functions.c ; they used to be all over the place, but not anymore.

At least you confirmed one thing: Screwface_Functions.c is OK.
 
Just to prevent any possible confusion, at the moment at least recognition is in no way related with the ship you're sailing.
True. The important bit is that Havana fort remembers me as Spanish because it has no reason to believe otherwise.

There is a character attribute you can add so that a specific character will ALWAYS believe your false flag.
Look up the captain of the Montanez; he has that.
You should be able to add that attribute to the fort commander to ensure he won't be "clever" and recognize you when he shouldn't.
Doing that works similarly to my answer below; just with that other attribute of which I cannot remember the name right now.
But recognition isn't the problem. Memory is the problem. Santiago fort doesn't need to recognise the false flag, it knows I'm a pirate because it saw me pirating, and remembers it. Look at that "compile.log" - nothing about recognition, but two lines about remembering.

Anyway, the attribute appears to be 'ch.skipFalseFlag = true;'. So here's what I should add to make the fort peaceful:
Code:
       ch = characterFromID("Santiago Commander");
       ch.skipFalseFlag = true;
       ResetCharacterMemory(ch);

And to make it hostile again after 'mapenter':
Code:
       ch = characterFromID("Santiago Commander");
       ch.PlayerNation = PIRATE;
       DeleteAttribute(ch,"skipFalseFlag");

I think this should do it:
ch = CharacterFromID(*insert ID of fort command*);
ch.PlayerNation = PIRATE;
[/CODE]
Thanks! I'll try that and see what happens immediately after the ransom (the fort shouldn't fire if I've done 'ResetCharacterMemory') and some time later (that code to make the fort hostile again will be in a quest case triggered by 'mapenter', so once you leave Cuba waters and then return, Santiago fort should start shooting again).

Other files that may be related:
PROGRAM\NATIONS\nations.c
PROGRAM\SEA_AI\sea.c
PROGRAM\SEA_AI\AIShip.c
PROGRAM\BATTLE_INTERFACE\BattleInterface.c

But I don't think any of those were changed in ways that should affect hostility at all.
And really, all relevant parts are now within just Screwface_Functions.c ; they used to be all over the place, but not anymore.

At least you confirmed one thing: Screwface_Functions.c is OK.
No, I confirmed that something other than "Screwface_Functions.c" is not OK. Slight difference. ;) What might be worth trying is to copy new "Screwface_Functions.c" into the 17th Marc installation and see if the fort then starts remembering me the way it does with the 2nd April installation...
 
Last edited:
But recognition isn't the problem. Memory is the problem. Santiago fort doesn't need to recognise the false flag, it knows I'm a pirate because it saw me pirating, and remembers it. Look at that "compile.log" - nothing about recognition, but two lines about remembering.
You want to force a fort to NOT fire on a technically hostile ship, right?
That requires that fort to not remember, to also skip false flag detection and for the player to be flying a non-hostile flag.
Then the fort will be non-hostile (because of the flag and lack of memory) and it'll stay non-hostile because it isn't doing any false flag checking.

If you just reset the memory, but come in under a hostile flag, the fort WILL fire.
Or if you reset the memory and come in under a friendly flag, you MAY be recognized and the fort will fire anyway.

No, I confirmed that something other than "Screwface_Functions.c" is not OK. Slight difference. ;) What might be worth trying is to copy new "Screwface_Functions.c" into the 17th Marc installation and see if the fort then starts remembering me the way it does with the 2nd April installation...
In other words: "Screwface_Functions.c" is OK. That's what I said, no? :confused:

Your compile.log looks like it details on what happens later. Whatever happened to turn the fort hostile is not mentioned in there.
But that one fort DOES remember you as Pirate, so something happened to turn it hostile and it stays that way because of its memory.
Did you wave a Pirate flag right under its nose? If so, that would be the reason. If not, then apparently it recognized your false flag. Those are the only two possible explanations.

The first time you get within visible range of the fort, it will remember whatever flag you were flying at the time.
If you change flags within view, it will remember that instead. If it is hostile flag, then switching flags to something non-hostile will NOT change the memory again.
Then if you get recognized, it remembers that too.

In other words: The main thing that matters is what happens the first time you get within view of the fort. That event isn't shown in your compile.log, but makes all the difference in the world.

There IS one thing that changed relatively recently that could be affecting this: Us playing around with "visibility distances"!
That is the only thing I can think of that did indeed change and does have something to do with this.
 
You want to force a fort to NOT fire on a technically hostile ship, right?
That requires that fort to not remember, to also skip false flag detection and for the player to be flying a non-hostile flag.
Then the fort will be non-hostile (because of the flag and lack of memory) and it'll stay non-hostile because it isn't doing any false flag checking.

If you just reset the memory, but come in under a hostile flag, the fort WILL fire.
Exactly. You need to approach under a peaceful flag - if you're stupid enough to be flying a pirate flag next to the fort when you don't need to, you deserve what you get. :p Hence the suggested code above, which sets 'skipFalseFlag' to make the fort always believe the false flag and resets the fort's memory; then later it deletes 'skipFalseFlag' and makes the fort remember you as a pirate, so that you get one chance to escape, then when you're clear of Cuba the fort becomes hostile again.

Your compile.log looks like it details on what happens later. Whatever happened to turn the fort hostile is not mentioned in there.
But that one fort DOES remember you as Pirate, so something happened to turn it hostile and it stays that way because of its memory.
Did you wave a Pirate flag right under its nose? If so, that would be the reason.
Yes. During the payroll ship incident. I may have mentioned that. :p

The first time you get within visible range of the fort, it will remember whatever flag you were flying at the time.
If you change flags within view, it will remember that instead. If it is hostile flag, then switching flags to something non-hostile will NOT change the memory again.
Then if you get recognized, it remembers that too.

In other words: The main thing that matters is what happens the first time you get within view of the fort. That event isn't shown in your compile.log, but makes all the difference in the world.
Correct. Originally the fort sees me as Spanish, as that's the flag I use whenever I sail into Santiago port and when I went to Playa de Sierra Maestra to get ready for the payroll ship attack. I still had the Spanish flag up when I sailed from Playa de Sierra Maestra because the only way to succeed is to keep that false flag right until you're alongside and ready to board. That's when I hoisted the pirate flag - pirate I may be, but not evil enough to fire at a Spanish ship while still flying a Spanish flag, and anyway the fort would undoubtedly remember that too.

There IS one thing that changed relatively recently that could be affecting this: Us playing around with "visibility distances"!
That is the only thing I can think of that did indeed change and does have something to do with this.
I doubt it. Playa de Sierra Maestra is close to Santiago fort, which always fired at me when I raised the pirate flag to attack the payroll ship. What it didn't do in the 17th March version was remember me as a pirate and fire at me again when, having left Cuba, I subsequently returned and sailed into Santiago port under a friendly flag.
 
Exactly. You need to approach under a peaceful flag - if you're stupid enough to be flying a pirate flag next to the fort when you don't need to, you deserve what you get. :p Hence the suggested code above, which sets 'skipFalseFlag' to make the fort always believe the false flag and resets the fort's memory; then later it deletes 'skipFalseFlag' and makes the fort remember you as a pirate, so that you get one chance to escape, then when you're clear of Cuba the fort becomes hostile again.
Not fair! You edited my posts after I read it! :razz

But yes, that is indeed what I was trying to suggest. :onya

Yes. During the payroll ship incident. I may have mentioned that. :p
:onya

Correct. Originally the fort sees me as Spanish, as that's the flag I use whenever I sail into Santiago port and when I went to Playa de Sierra Maestra to get ready for the payroll ship attack. I still had the Spanish flag up when I sailed from Playa de Sierra Maestra because the only way to succeed is to keep that false flag right until you're alongside and ready to board. That's when I hoisted the pirate flag - pirate I may be, but not evil enough to fire at a Spanish ship while still flying a Spanish flag, and anyway the fort would undoubtedly remember that too.
Depending on the visibility and distance to the fort, yes they would.

I doubt it. Playa de Sierra Maestra is close to Santiago fort, which always fired at me when I raised the pirate flag to attack the payroll ship. What it didn't do in the 17th March version was remember me as a pirate and fire at me again when, having left Cuba, I subsequently returned and sailed into Santiago port under a friendly flag.
It could be that forts have a "firing range" that exceeds the visibility range. Those two aren't technically linked.

The range values were changed not too long ago. Plus the actual visibility may not have been the same between both play-throughs.

That is why, if you want to fairly compare the two game versions, you need the compile.log files from both times that you were waving a pirate flag in front of the fort's nose.
The entries you get in there should explain exactly what happened, including the distance at which you were seen and the visibility at that time.

Until I see hard proof that I am wrong on this, I am attributing your observed difference between the "17 Mar" and "2 Apr" versions to either "random chance" or the modified range numbers.
Either way, I am inclined to not believe there is anything actually going wrong with this on the 2 Apr version.
What you describe happening does sound like what is supposed to happen.
 
New idea: Have completing a Governor Ship Hunting Quest also "reset all forts for that nation".
That is a much cheaper way; in fact, YOU get paid for it.

Getting enemy towns to become susceptible to your false flags is still not possible then, but hey.... they're hostile for a reason. :wp
 
Before you can complete a governor quest, you need to pay for forgiveness. I don't think he'll offer a job if you're hostile. ;)

For what it's worth: I'm now quite happy for Santiago fort to remember me as a pirate after it saw me taking the payroll ship. It makes more sense than to take it, then sail back into port in the same ship even with a false flag. xD For general use, though, it would be nice if forts' memories reset after a time. (Or, for preference, if you get rid of the ship they remembered, though I can see how detecting that is going to be tricky.) And forts really shouldn't remember your nationality if you're friendly. That would prevent the problem reported by @Hylie Pistof which started this thread, in which he was previously remembered as Portugese when the port was friendly to Portugal, then attacked for being Portuguese when he approached under a different flag after Portugal became hostile to that port.

Maybe disable the fort memory if you have the "Disguise" perk. You're now an expert at concealing your ship's identity so the fort has no idea who you are unless it actively recognises you (false flag check).
 
Before you can complete a governor quest, you need to pay for forgiveness. I don't think he'll offer a job if you're hostile. ;)
Very true. That's why I said "Getting enemy towns to become susceptible to your false flags is still not possible then".

At the moment the game system allows basically zero consideration for players wanting to repeatedly fool enemy forts.
It still isn't clear to me though why people would want to do that. Hostile towns should be, by definition, not very safe.

And forts really shouldn't remember your nationality if you're friendly. That would prevent the problem reported by @Hylie Pistof which started this thread, in which he was previously remembered as Portugese when the port was friendly to Portugal, then attacked for being Portuguese when he approached under a different flag after Portugal became hostile to that port.
That should be doable. Just remove the part in PROGRAM\Screwface_Functions.c where "PlayerNation" is set.

I can't quite remember why I added that. Partly as additional cleverness, I suppose. But I suspect the main reason was to help with performance in 3D Sailing Mode.
At the time when I rewrote all this, we still had the "1 second hickup" and I remember being EXTREMELY careful to not have the game code do anything it didn't truly need to.

Of course I now know my changes probably had very little impact on performance one way or another, because the real problem was something else altogether.
I fixed that "something else" now, so maybe not all of my "careful performance code" is quite needed anymore.

For general use, though, it would be nice if forts' memories reset after a time.
It is definitely possible and given enough time and energy, I could manage it for certain.
I've got ideas aplenty, but when I looked into it last week I could see no easy way of accomplishing it.

There are basically two options:

1. Store the date when the last "memory update" was done.
Then next time the memory is checked, either return the values from memory OR reset it if too much time has passed.

2. Create a "secondary quests system" that works also for NPCs and that allows you to figure out for which NPC it is currently running.
I had hoped that was possible with the current quest system, but it is not.

But as mentioned here, it seems there is a good chance I will never actually get to making this happen.
My time, energy and continued enthusiasm are in short supply.
 
That should be doable. Just remove the part in PROGRAM\Screwface_Functions.c where "PlayerNation" is set.
As far as I can tell, this is where "Screwface_functions.c" remembers your flag:
Code:
    if (!CheckAttribute(chr, "PlayerNation") || GetNationRelation(iNation, nNation) == RELATION_ENEMY)
     {
       if (ship_range < visibility_range)
       {
         chr.PlayerNation = iNation;
         Trace("FLAGS: The " + GetMyShipNameShow(chr) + " has spotted us at " + ship_range + " and will remember us as " + GetNationDescByType(iNation) + " with visibility=" + visibility_range);
       }
       else
       {
       //   Trace("FLAGS: The " + GetMyShipNameShow(chr) + " is out of range and is not checking our flag");
       }
     }
     else
     {
       iNation = sti(chr.PlayerNation);
       Trace("FLAGS: The " + GetMyShipNameShow(chr) + " remembers us as " + GetNationDescByType(iNation) );
     }
Simply removing the setting of "PlayerNation" would disable fort memory entirely, wouldn't it? But if the bit from the third line down were changed to this:
Code:
       if (ship_range < visibility_range)
       {
         if (GetNationRelation(iNation, nNation) == RELATION_ENEMY)
         {
           chr.PlayerNation = iNation;
           Trace("FLAGS: The " + GetMyShipNameShow(chr) + " has spotted us at " + ship_range + " and will remember us as " + GetNationDescByType(iNation) + " with visibility=" + visibility_range);
          }
          else Trace("FLAGS: The " + GetMyShipNameShow(chr) + " has spotted us at " + ship_range + "but is not interested as we are not hostile");
       }
Would that not prevent it from remembering you if you're friendly, while still allowing it to remember you if you're hostile?

I wonder if perhaps an additional attribute could be set:
Code:
chr.PlayerShip = GetCharacterShipID(GetMainCharacter());
Then have something like this to check whether you still have that ship:
Code:
bool HasSameShip = false;
ref comp;
int n;
for (n = 0; n<4; n++)
{
  comp = GetCharacter(GetCompanionIndex(GetMainCharacter(), n));
  if (GetCharacterShipID(comp) == chr.PlayerShip) HasSameShip = true;
}
If I read things like 'IsCompanion' in "CharacterUtilite.c" correctly, that ought to cycle through the player and companion ships, and set 'HasSameShip' to true if any of them is the one that 'chr' remembered. If it's false then the memory can be wiped because you no longer have the ship which the fort recognises, so you're safe until it recognises you again.
 
Back
Top