Medium Priority Freed/Ransomed Prisoners Remain in Cargo Hold

[Jason]

Ahoy Pieter,

The game is playing extremely well and seems very stable. A great job! Thanks for all your efforts. The only glitch I have noticed playing the July 18th update is when you ransom your captives in the hold the accept, pay you but then they just stand in the hold. I think they are gone in the game sense because you can't interact with them, but the character is still standing there.

 

[Pieter Boelen]

The only glitch I have noticed playing the July 18th update is when you ransom your captives in the hold the accept, pay you but then they just stand in the hold. I think they are gone in the game sense because you can't interact with them, but the character is still standing there.

Really? That's the first time I hear of that one!
@ANSEL or @Grey Roger, would you be able to confirm that?

 

[Pieter Boelen]

On second thought, it DOES ring a bell. I think somebody might have reported that before, but we never heard back on it.

When you ransom a captive, they usually run off, don't they?
The only theory I had is that perhaps if you (the player) leaves before the enemy captain does, that captain never does actually leave.
Does that sound like it may be what is happening to you?

 

[Grey Roger]

Yes, I've seen that happen a few times. One reason is that the captive can't get out, typically because some of your officers are in the hold as well and are blocking both the door and the stairs. There have been more than one occasion when I've had a few prisoners, talked to one and he just stood there, then I physically pushed into the officer near the stairs and kept pushing to move the officer to the side, then I talked to the next prisoner and he duly ran up the stairs. This is nothing new, though. And the prisoner who didn't run up the stairs is usually gone next time I visit the hold, possibly because his position in the hold is now taken by a new prisoner which reminded the game to get rid of the reluctant escaper.

 

[Pieter Boelen]

In that case, is anyone familiar with a command that makes characters try to "nicely" exit the location and, if that fails, disappear anyway?
Maybe @Grey Roger or @Jack Rackham would know?

Alternate solutions:
- Prevent player from leaving before the prisoner does (this sounds annoying)
- Set a PostEvent/LocationExit quest to remove the prisoner
- Detect that an attribute ("prisoned") has been removed (or better, that an attribute "freed" has replaced it) and use that instead?

 

[Grey Roger]

I've no idea what command is already in use, or which file to search and where in that file to look. But the LocationExit quest to remove the prisoner sounds like the best solution to both problems. You can stay and watch the prisoner run away if you like; if the prisoner can't run away for any reason, or you can't be bothered to wait, he'll just be quietly removed when you're not there.

Preventing the player from leaving before the prisoner does is a bad idea. It means if the prisoner can't leave for any reason, neither can you!

 

[Pieter Boelen]

Preventing the player from leaving before the prisoner does is a bad idea. It means if the prisoner can't leave for any reason, neither can you!

That's what I figured. As I said: annoying indeed.

But the LocationExit quest to remove the prisoner sounds like the best solution to both problems. You can stay and watch the prisoner run away if you like; if the prisoner can't run away for any reason, or you can't be bothered to wait, he'll just be quietly removed when you're not there.

The main issue with that one is what happens when you have TWO prisoners and set them BOTH free?
I can store the character ID being removed in a player attribute, but I can only do that for one character.

So.... allow only one to be freed at the same time? And only allow another to be freed after the first one has left the area?
Again beginning to sound annoying....

 

[Grey Roger]

OK, thinking about this:

How would I go about making someone run somewhere and then disappear? Well, I've used 'LAi_ActorGoToLocation' to make someone walk to a location and disappear, maybe there's a 'LAi_ActorRunToLocation' as well? As it turns out, there is - like the "GoTo" version, it's defined in "LAi_Actor.c":

void LAi_ActorRunToLocation(aref chr, string groupExit, string locatorExit, string locID, string groupEnter, string locatorEnter, string quest, float timeout)

So, Windows Search for 'LAi_ActorRunToLocation', disregard any references to "quests_reaction.c" and "both_reaction.c" as they'll be storylines, and find that it's also in "quests_common.c". Look through that, and what I find is:

    case "Surrendered_Captain_Run":
       if(CheckAttribute(PChar,"prisonerIDX"))
       {
         NPChar = GetCharacter(sti(PChar.prisonerIDX));
         LAi_ActorRunToLocation(NPChar, "reload", LAi_FindRandomLocator("reload"), "None", "reload", "", "", -1);
         RemovePassenger(PChar,NPChar);
         DeleteAttribute(NPChar,"prisoned");
         DeleteAttribute(PChar,"prisonerIDX");
       }
     break;

Now, when I used 'LAi_ActorGoToLocation', it was with a positive timeout. I'm guessing that if the character hasn't made it to the destination point by then, he disappears anyway. I've no idea what putting "-1" for the timeout does, maybe it means the function never times out which means if the character can't get to the location then he stays where he is - which is exactly what is happening here.

Perhaps replace that "-1" with "10". If he can't get to an exit in 10 seconds then he probably can't get there at all, in which case hopefully he'll disappear from where he's standing now. This may or may not be an improvement.

Or, leave the code as it is now and see if, when you leave the hold and then return, the prisoner has already disappeared anyway. Especially if you've captured someone else since trying to release this one. Because if that happens then there's not really a problem.

 

[Pieter Boelen]

Good point, @Grey Roger. Maybe this issue can be resolved by just changing that number.

We'd either need to experiment with it OR see if we can find the function definition to see exactly what that number input does.

 

[Jason]

Just to be clear in the case I reported I did not try to leave the hold first.

 

[Pieter Boelen]

If it happens again, do you reckon you could check if this seems to be related to what I suggested above?
I have absolutely no clue if my theory is right, but it is the only explanation I could think of that makes sense to me at the moment.

 

[Grey Roger]

Just to be clear in the case I reported I did not try to leave the hold first.

Were any of your own officers in the hold, and in particular were any standing by the door or stairs?

 

[Pieter Boelen]

@Jason, @Grey Roger and/or @ANSEL: Is anyone of you able to confirm/deny my suspicion?

I may be able to find some time for fixing some stuff this weekend, but only if I know for sure what exactly needs doing.

 

[Pieter Boelen]

So....? Someone....? Anyone....?

 

[Grey Roger]

I finally got the chance to do some serious experimenting with this, having practically stuffed the entire hold with prisoners after a few highly successful battles.

The theory about leaving before the captive is disproven. I managed to hit the "Fast travel" icon quickly enough to teleport to sea before a newly released prisoner had made it to the exit. He did get stuck, but that's because as usual, the exit was blocked by one of my officers - I'd shoved said officer out of the way prior to releasing the prisoner, but the officer was back in place when I returned to the hold, so the prisoner couldn't complete his run. When I again shoved the officer out of the way, the prisoner resumed his run for the exit and disappeared. My guess is if the officer hadn't been there at all, the prisoner would have simply resumed his run when I returned to the hold.

The only way I could get prisoners stuck in the hold is if they couldn't get to the exit at the time they were released. One reason for this is if there are officers blocking both exits. It is also possible to release two prisoners very quickly so that one of them is still running to the exit when you release the second, so the second can't get to the exit. This took some doing - I had to release the one at the far end of the hold first, as he's the one furthest from the exit and therefore the one who will be running for longest, then quickly get to a second prisoner and release him before the runner had left. But I managed it.

 

[Pieter Boelen]

So.... If you leave before the prisoner left and then return, he'll continue running and leave anway?
Assuming he doesn't get stuck, that is...?

 

[Grey Roger]

That is my experience, yes. Better yet, if he's now stuck because the exit is blocked by one of your officers whom you shoved out of the way to let the prisoner start running, the prisoner is still in the middle of the run task and will attempt to complete it when you again shove the officer out of the way.

 

[Pieter Boelen]

So the real problem is that, no matter how hard and how often the prisoner tries, he cannot leave if someone is standing in the way?
Maybe we can convince those officers to be generated somewhere else?

Alternatively, we'd still need to clear all freed prisoners upon leaving the location.
One option would be to add a character attribute upon when the character starts running, for example: NPChar.ClearUponExit = true; .
Then in PROGRAM\Characters\characters_login.c:

// PB -->
void LogoffCharactersFromLocation(ref loc)
{
   int i;
   ref chr;
   string locID = loc.id;
   for(i = 0; i < LAi_numloginedcharacters; i++) //Levis: only use logged in characters
   {
     chr = &Characters[LAi_loginedcharacters[i]]; //Levis: only use logged in characters
   //   if (!CheckAttribute(chr, "location"))   continue; // PB: Then we don't need this anymore, do we?
   //   if (chr.location != locID)         continue; // PB: Same here
     if (HasSubStr(chr.id, "Enc_Officer_"))
     {
       if(bAllies(chr))                   { continue; }
       if(LAi_IsBoardingProcess())
       {
         if (chr.id == boarding_enemy.id)         { continue; }   // PB: Skip the captain of the ship you're currently boarding
         if (IsOfficerOf(boarding_enemy, chr))       { continue; }   // MM: Skip also any officers assigned to this ship
       }
     //   TraceAndLog("LogoffCharactersFromLocation clears " + GetMySimpleName(chr));
       ClearCharacter(chr); // PB: Completely erase the unused character
     }
   if (CheckAttribute(chr, "ClearUponExit")) ClearCharacter(chr); // <-------------------- ADD THIS LINE <--------------------
   }
}

Extract attached to your main game folder to try.

 

[Jason]

Well sorry to have been away for a few days. W/O trying the new fix I can report that in my experience moving the officer away from the stairs prevents the problem.

 

[Pieter Boelen]

Well sorry to have been away for a few days. W/O trying the new fix I can report that in my experience moving the officer away from the stairs prevents the problem.

Thanks for the confirmation!

If you get the chance to try the above fix, I'd much appreciate.
With a bit of luck, that will solve it properly and that'd be one more bug down the drain.