Fixed Cannot capture enemy captains after surrender

[Tingyun]

@Levis Here is the bugtracker you requested regarding captain generation and surrender

Enemy Captains can, at least most of the time, not be captured any more after they surrender.

At first we thought it might be from the cabinfight dialog file changes, but testing proved this was not the source of the problem.

Perhaps bAllowCapture seems to somehow not be set to true, Pieter quotes the relevant code here: Points, Perks and Leveling UP | Page 2 | PiratesAhoy!

It seems something is going wrong in captain generation, perhaps:

Lack of twin generated for captain

And Pieter suggests a possibilty: "I imagine it might be OK at game start but then as the game has to start cycling through the same Captain IDs, it could start going wrong depending on what happened to the previous Captain with the same ID."

Here is the relevant code from cabinfight that is getting set to false by something happening elsewhere:

bool bAllowCapture = HasSubStr(NPChar.id,"Enc_CabinCaptain") || strcut(NPChar.id,0,1) == "Cr"; // PB: Allow Coast Raiders also
if(!bAllowCapture)
{
bAllowCapture = HasSubStr(NPChar.id,"fantom")&&FindFreeCabinCaptain()!=-1;
}
if(CheckAttribute(NPChar,"cabinfight") && NPChar.cabinfight==true) { bAllowCapture = FindFreeCabinCaptain()!=-1; } /* fantoms allow anything */ //MAXIMUS 10.10.2007

if(CheckAttribute(boarding_enemy,"location.norebirth") && boarding_enemy.location.norebirth==1) { bAllowHireJoin = true; bAllowRelease = false; bAllowCapture = true; } /* special captains must die */
if(CheckAttribute(boarding_enemy,"questchar") && boarding_enemy.questchar==true) { bAllowHireJoin = false; bAllowRelease = false; bAllowCapture = true; }

Possiblly related bugs:

Other Bug 1) Dialog errors that sometimes happen when talking with surrendered captain:
RUNTIME ERROR - file: dialog.c; line: 414
incorrect argument index
COMPILE ERROR - file: dialog.c; line: 414
file not found: dialogs\English\-1.038827h
COMPILE ERROR - file: dialog.c; line: 414
file not found: dialogs\-1.0388279


Other Bug 2) a surrendered captain if hired is regenerated as a new officer with different level

 

[Tingyun]

@Levis @Pieter Boelen

Had a moment to test something, just set bAllowCapture = true here:

bool bAllowCapture  = HasSubStr(NPChar.id,"Enc_CabinCaptain") || strcut(NPChar.id,0,1) == "Cr"; // PB: Allow Coast Raiders also
    if(!bAllowCapture)
    {
        bAllowCapture = HasSubStr(NPChar.id,"fantom")&&FindFreeCabinCaptain()!=-1;
    }
    if(CheckAttribute(NPChar,"cabinfight") && NPChar.cabinfight==true) { bAllowCapture = FindFreeCabinCaptain()!=-1; } /* fantoms allow anything */ //MAXIMUS 10.10.2007

    if(CheckAttribute(boarding_enemy,"location.norebirth") && boarding_enemy.location.norebirth==1) { bAllowHireJoin = true; bAllowRelease = false; bAllowCapture = true; } /* special captains must die */
    if(CheckAttribute(boarding_enemy,"questchar") && boarding_enemy.questchar==true) { bAllowHireJoin = false; bAllowRelease = false; bAllowCapture = true; } /* quest allows capture */ //MAXIMUS: special identifier added into tempquest- and storycharacters init
    bAllowCapture = true

The last line that is. And a captain was previously not capturable, became captuerable, and functioned perfectly as a prisoner in the hold.

So the problem is just that HasSubStr(NPChar.id,"Enc_CabinCaptain") || strcut(NPChar.id,0,1) == "Cr"; OR HasSubStr(NPChar.id,"fantom") is somehow operating wrong now with the new captain generation.

But simply setting it to True still works, so there is no greater underlying issue it seems, and the captains still all function well as prisoners, so Levis just needs to figure out why those checks aren't returning true when they should.

@Levis I hope this helps get things started and lighten your workload, sorry I can't do more, have to get back to work now, thanks for all your bug fixing work.

 

[Tingyun]

Here's a temporary fix for people currently playing to be able to capture captains again. It goes in PROGRAM/DIALOGS

It has all the changes I previously made to Captain dialogue and deathfights still in the file, since those weren't the source of the problem.

All it does is insert a single line of bAllowCapture = true as outlined in the above code. This covers up whatever is going wrong with the captain assignments that causes the previous checks to come back false, but of course it doesn't fix that underlying problem. As long as you don't try to accumulate tons of captains when you don't have enough space (we are skipping the findfreecabincaptain check, and some others), it should allow you to capture them again without a problem. At least in my playtests it worked fine. Please report if it doesn't, it might give a clue to what is going on. Keep a backup of your file, though if you experience a problem capturing any individual captain, just pick a different dialogue option for him, this should work for most captains at least.

Tagging @Jason and @Grey Roger since they reported this bug.

 

[Pieter Boelen]

Ooh.... Hopefully this fix won't be needed for very long. It sounds a bit scary....

 

[Tingyun]

Agreed, this is a temporary measure offered only to experienced players who want to start capturing captains in the meantime, not a real fix.

Happily in playtesting I haven't seen any problems (captured a couple of captains). I think because the checks are coming back false for a silly reason, and actually the captains are fully capturable still. I would imagine it would only cause problems if you tried to capture the sort of captain that you couldn't capture before, ie try to capture someone when you already have the max amount allowed. I know I've specifically tested it on a captain that was not capturable under the bug, then added this line, boarded him again, then he worked fine after capture, everything in the prisoner hold worked great.

 

[Pieter Boelen]

Indeed I imagine this is one of those things that is quite fine. Until it isn't.

 

[Levis]

with my latest files I believe I tackled this bug. But I try it again tonight to know for sure. I know hireing works and it should work by the same principle.

 

[Grey Roger]

As far as I know, this was fixed in the 7th January version, which was basically the 28th July version plus my collection of fixes. Certainly I have not seen any such problem, and I've done a lot of boarding and capturing of enemy captains since then.

 

[Levis]

As far as I know, this was fixed in the 7th January version, which was basically the 28th July version plus my collection of fixes. Certainly I have not seen any such problem, and I've done a lot of boarding and capturing of enemy captains since then.

nope it's not fixed yet. it's the same problem as with the enc_walkers. I hope to provide a zip with files which can be used today

 

[Grey Roger]

The problem reported here is that you can not capture an enemy after he surrenders. That one I have not seen.

There may be a problem with hiring a surrendered captain right after he surrenders - I can't confirm or deny that one because I don't generally hire them at that point.

But I have hired several captains after taking them prisoner and talking to them in the hold, and none of those showed any problems.

 

[Levis]

The problem reported here is that you can not capture an enemy after he surrenders. That one I have not seen.

There may be a problem with hiring a surrendered captain right after he surrenders - I can't confirm or deny that one because I don't generally hire them at that point.

But I have hired several captains after taking them prisoner and talking to them in the hold, and none of those showed any problems.

Both hireing and capturing should add a new dialog file to the character and trigger this. And I believe it went wrong here.
But I will test it again tonight.

RUNTIME ERROR - file: dialog.c; line: 414
incorrect argument index
COMPILE ERROR - file: dialog.c; line: 414
file not found: dialogs\English\-1.038827h
COMPILE ERROR - file: dialog.c; line: 414
file not found: dialogs\-1.0388279

these errors are at least related to the bug I found.

 

[Pieter Boelen]

these errors are at least related to the bug I found.

I've definitely seen those when I was still working with the game code, so that's a real bug that is indeed not fixed.
If you fix it, that'll be very welcome!