Included in Build False Flags: Modify Memory Functionality

[Grey Roger]

Looks to be a boolean to determine if the battle interface actually needs to be changed.
For example, if:
- You could not board a ship/fort, but now you can (or the other way around)
- You could reload to shore/fort/map before, but now you can't (or the other way around)

If you were a long way out, then Sail-To the port, then you couldn't reload to shore before but now you can. Would that not trigger it?

That still doesn't tell us how to handle it when you "gradually approach" a ship.

First I'll have to see what happens if I gradually approach the fort from outside visible range rather than Sail-To it. Because I suspect the once-per-minute refresh in "LogInterface.c" might take care of that. The sudden transition from outside visible range to inside visible range, on the other hand, is likely not to be caught by the once-per-minute refresh, especially if you dock right after the Sail-To.

 

[Pieter Boelen]

On your first question: Yes, I do believe it would.

In your second: Are you taking about the suggestion I posted earlier today?
Without that, it would work only the first time. With it.... I haven't a clue if it would be good enough or not.

 

[Grey Roger]

After much experimenting and testing, I've come to the following conclusion: stuff it.

I tried changing "BattleInterface.c", replacing the "RefreshBattleInterface(false)" under "if(bYesUpdateCommand)" with "RefreshBattleInterface(true)". This did indeed trigger "CheckInitialFlagRelations" more often and the fort logged me after the Sail-To. Unfortunately it also had the side effect of fouling up the payroll ship incident, in which Santiago fort once again failed to log me as being in the CastelF, so when I went away and returned it reported that it remembered me being in a Shnyava2 which I no longer had. When I returned "BattleInterface.c" to the way it had previously been and re-ran the payroll ship attack, Santiago fort correctly logged me as being in the CastelF.

But the problem about the fort failing to log you if you teleport to port may not actually be a problem. The once-per-minute update does indeed trigger "CheckInitialFlagRelations", which has some very useful implications.

Current status, then:
If you start on worldmap, move close to the port and switch to 3D sailing, you're in visual range of the fort right away and it logs you correctly.
If you start outside visual range and then direct-sail to the port, either by being away from the port when you switch to 3D sailing or by direct-sailing the whole way from another island, the once-per-minute update makes the fort log you.
If you start outside visual range and then teleport (Sail-To) the port, and either you have a hostile flag or the fort detects your false flag, it will attack. Unless you're in something teeny which is blown out of the water in one salvo, the battle will take long enough for the once-per-minute update to get you.
If you start outside visual range and then teleport to the port, and the fort doesn't recognise your false flag, you'll get in safely. But if the fort can't get you on the way in then it will get you on the way out, because when you've finished doing whatever you came here to do and return to sea, you'll do so at short range to the fort, which then gets to log you properly. If it remembers you as hostile then you'll get into port safely but won't get out again - how's that for making hostile ports dangerous? (If you want an in-game explanation, it takes time to search all the paperwork generated by keeping detailed records of every ship to visit the port. If you teleported from beyond visual range right into port and then docked, the fort has no time to search those records. By the time you've finished your business and return to sea, the fort has searched its records and if one of them is about you then the fort now knows who you are.)

So as far as I'm concerned, job done.

 

[Pieter Boelen]

Indeed thinking about it myself, I can't think of a simple way to make the system quite 100% watertight.
But then... we've been discussing here in the first place because 100% watertight is unrealistically good.
So even if we could get it perfect, that perfection isn't actually wanted.

I think that for most instances, the current system with your changes included and also this line should serve its purpose quite alright:

if (abs(ship_range-visibility_range) < 0.1) CheckInitialFlagRelations(chr, visibility_range, ship_range);

And for those cases where the player manages to "slip by" the system, either by using Sail-To or because the one-minute update missed the above condition,
we can apply by far my favourite method of bugfixing: "It's not a bug, it's a FEATURE!"

So as far as I'm concerned, job done.

That's the spirit! Indeed I do believe this is now much better than it was before. Thanks for the support!

 

[Grey Roger]

Indeed thinking about it myself, I can't think of a simple way to make the system quite 100% watertight.
But then... we've been discussing here in the first place because 100% watertight is unrealistically good.
So even if we could get it perfect, that perfection isn't actually wanted.

It depends on the definition of "100% watertight". Making the system remember you 100% of the time is unrealistically good. Making it remember you 100% of the time it's supposed to remember you is just making the system work as intended. But as it stands now, it seems to work well enough to do what is required and doesn't have side effects which foul up anything else unintentionally.
And that means I get to switch my attention back to my storyline.

I think that for most instances, the current system with your changes included and also this line should serve its purpose quite alright:

if (abs(ship_range-visibility_range) < 0.1) CheckInitialFlagRelations(chr, visibility_range, ship_range);

What is that supposed to do? I'm guessing it should go into "CheckAllShips" to replace...

        if (initialize)
       {
         CheckInitialFlagRelations(chr, visibility_range, ship_range);
       }
       else
       {
         if (!CheckAttribute(chr, "PlayerShip") && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range); // <--- ... this line
         Recognized = CheckForMainCharacterfalseflag(chr, visibility_range, ship_range);
       }

Instead of triggering if you're anywhere within visible range regardless of how you got there, it will only trigger when you cross the boundary. So it won't solve the problem of failing to trigger after a Sail-To teleport but may cause additional problems if you never crossed the boundary for any other reason.

 

[Pieter Boelen]

It depends on the definition of "100% watertight". Making the system remember you 100% of the time is unrealistically good. Making it remember you 100% of the time it's supposed to remember you is just making the system work as intended. But as it stands now, it seems to work well enough to do what is required and doesn't have side effects which foul up anything else unintentionally.

Yep, that is pretty much what I meant.

What is that supposed to do? I'm guessing it should go into "CheckAllShips" to replace...

if (initialize)
{
CheckInitialFlagRelations(chr, visibility_range, ship_range);
}
else
{
if (!CheckAttribute(chr, "PlayerShip") && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range); // <--- ... this line
Recognized = CheckForMainCharacterfalseflag(chr, visibility_range, ship_range);
}

Instead of triggering if you're anywhere within visible range regardless of how you got there, it will only trigger when you cross the boundary. So it won't solve the problem of failing to trigger after a Sail-To teleport but may cause additional problems if you never crossed the boundary for any other reason.

The code as it is in your quoted section works perfectly well, but only the first time.
Once "PlayerShip" has been set, it will NOT be updated the next time you gradually approach that fort (or ship).
So if the fort remembers you in a "Shnyava", it is very possible that their memory does not update if you DirectSail past them later with a different ship.

My suggestion is meant to change that so that it ALWAYS updates at the moment you're AT the visible range.
But that isn't a perfectly safe solution either.

 

[Grey Roger]

It ought to update whenever "RefreshBattleInterface(true)" is called. That calls "CheckAllShips("forts", true)". And if "CheckAllShips" is called with "true" then it doesn't get to that piece of code, it goes to the bit above the "else" which unconditionally calls "CheckInitialFlagRelations".

Perhaps remove the '!CheckAttribute(chr, "PlayerShip")' bit and just have it check for 'ship_range < visibility_range'. Then you'll be checked if you're anywhere within visible range. That ought to prevent problems with you never crossing the boundary, e.g. because you teleported or because you started off already in visible range (from a port or from a beach like Playa de Sierra Maestra which is next to the fort).

Or have an additional section:

if (CheckAttribute(chr, "PlayerShip"))
{
    if (chr.PlayerShip != GetCharacterShipModel(GetMainCharacter() && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range);
}

So if the fort has no memory of you, or if the fort does have a memory and it's out of date, then it will redo the check.

 

[Pieter Boelen]

It ought to update whenever "RefreshBattleInterface(true)" is called. That calls "CheckAllShips("forts", true)". And if "CheckAllShips" is called with "true" then it doesn't get to that piece of code, it goes to the bit above the "else" which unconditionally calls "CheckInitialFlagRelations".

Yes, it does.

Perhaps remove the '!CheckAttribute(chr, "PlayerShip")' bit and just have it check for 'ship_range < visibility_range'. Then you'll be checked if you're anywhere within visible range. That ought to prevent problems with you never crossing the boundary, e.g. because you teleported or because you started off already in visible range (from a port or from a beach like Playa de Sierra Maestra which is next to the fort).

Indeed then you'll just call it for all ships every minute.
Might could be a bit "much", but also may not actually do much harm.
You're welcome to try that and see what happens.

Or have an additional section:

if (CheckAttribute(chr, "PlayerShip"))
{
if (chr.PlayerShip != GetCharacterShipModel(GetMainCharacter() && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range);
}

So if the fort has no memory of you, or if the fort does have a memory and it's out of date, then it will redo the check.

If you do that, you have to call your custom function to check all companion ships.
That could work too.

I myself won't do anything until Tuesday/Wednesday for sure (don't have my computer), but by all means please experiment with it!

 

[Grey Roger]

YIf you do that, you have to call your custom function to check all companion ships.

How about this?

if (!HasThisShip(chr.PlayerShip) && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range);

 

[Pieter Boelen]

That might do the trick.
I think you just need to add a check to see if there is already a memory stored.
Otherwise it might error out the first time when the memory isn't set yet.

 

[Grey Roger]

Already in place. I only included the line which was altered from the previous post in an attempt to save space. That hasn't exactly worked out. Here's the whole thing:

       if (initialize)
       {
         CheckInitialFlagRelations(chr, visibility_range, ship_range);
       }
       else
       {
         if (!CheckAttribute(chr, "PlayerShip") && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range);   // GR: If you can be seen and aren't already logged, you are now
         if (CheckAttribute(chr, "PlayerShip"))                           // GR: If you are already logged and the log is out of date, update it
         {
           if (!HasThisShip(chr.PlayerShip) && ship_range < visibility_range) CheckInitialFlagRelations(chr, visibility_range, ship_range);
         }
         Recognized = CheckForMainCharacterfalseflag(chr, visibility_range, ship_range);
       }

So program execution only gets to that line after a check that "PlayerShip" exists.

 

[Grey Roger]

Update: it didn't seem to make any difference. Perhaps "CheckAllShips" is only called once when you arrive at the island, whether out at sea or next to the port, and then isn't called again unless something major happens, e.g. you do something to become hostile, or by the once-per-minute routine. So the bit which wants to update a log if you're within visible range is never called unless you wait a minute or two before teleporting to port.

So "Ardent" is making its own arrangements to ensure that you're remembered in the correct ship after defeating the payroll ship:

       ch = characterFromID("Santiago Commander");
       ch.PlayerNation = GetCurrentFlag();
       ch.PlayerShip = GetCharacterShipModel(PChar);
       Trace("Ardent: The " + GetMyShipNameShow(ch) + " will remember us as " + GetNationDescByType(sti(ch.PlayerNation)) + " in a " + ch.PlayerShip);

This is to happen right after the battle - it's in case "payroll_ship_taken", the same place as you get the cash and XP reward as well as the closing logbook entry.

 

[Pieter Boelen]

Indeed I expected that would be the case.

I think it should be doable to add a player attribute when you do Fast Travel that then forces a relation check.
Big question is how much of a delay there should be. Doing it where I wanted to its still to early.
But leaving it to the one minute update means you can bypass it.

 

[Grey Roger]

As I said in post 103, it doesn't really matter because if the fort can't get you on the way in then it will get you on the way out when you leave port. You only really bypass the system if you start at long range, Sail-To the port, then either Sail-To a distant beach or go straight to worldmap without docking at the port. If anyone really wants to do that, let them.

 

[Pieter Boelen]

Could I ask you to include your final Screwface_functions.c in your next Ardent upload?

The "update when AT range" change I suggested is probably a bit superfluous, it's it not?

 

[Grey Roger]

Could I ask you to include your final Screwface_functions.c in your next Ardent upload?

Why wait? Due to having been distracted by a few other things, e.g. this thread , I haven't been getting much done on "Ardent" lately, so the next upload may be a while. So here's the final version of "Screwface_functions.c".

The "update when AT range" change I suggested is probably a bit superfluous, it's it not?

Indeed. The once-per-minute check will probably deal with crossing the visibility range threshold. But I've left in the attempted check for if the "PlayerShip" attribute is set, the ship in question is not in your fleet and you're within visible range - it may not have done any good during my trials but it might have an effect somewhere and probably won't do any harm.

 

[Pieter Boelen]

Thank you!

 

[Pieter Boelen]

Just for the sake of a bit cleaner code, this is what I am adding to my game:

         if (ship_range < visibility_range)
         {
           bool bCheckInitial = false;
           if (!CheckAttribute(chr, "PlayerShip"))                   bCheckInitial = true;   // GR: If you can be seen and aren't already logged, you are now
           if (CheckAttribute(chr, "PlayerShip") && !HasThisShip(chr.PlayerShip)   bCheckInitial = true;   // GR: If you are already logged and the log is out of date, update it
           if (bCheckInitial) CheckInitialFlagRelations(chr, visibility_range, ship_range);
         }
         Recognized = CheckForMainCharacterfalseflag(chr, visibility_range, ship_range);

We'll see how that goes.