• 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!

Fixed Levelling: Removing Previous Inactive Officers Assigned as Captain

Pieter Boelen

Navigation Officer
Administrator
Storm Modder
Hearts of Oak Donator
@Levis: Grey Roger reported that when selling a companion ship, her commander did not revert back to a non-captain type.
 
No. I'm more interested in tracking down bugs in "Hornblower" and have only been keeping savegames from the beginnings of story chapters.
 
@Levis: I imagine this one should be easy enough to replicate, no?
I think I know the problem. Need to look into it more. I've tested everything from the ship interface and the shipyard interface. but maybe the ship ransack interface uses some other functions so the old offic type isn't set.
 
Quick'n'dirty way to test this: enable cheatmode, start "Hornblower", ask C. S. Forester about "To Cayman". That ought to put you at Cayman port with Lt. William Bush as a companion and about to meet Sharpe. You can then go and capture something, put Bush in charge of it, sell it at the next port, and see if he's "Captain" before, during and after his spell as commander of the prize ship.
 
@Levis: This is totally confirmed.
Worth noting here are the following things:
- Bush did not have ANY officer type assigned to him before me giving him command of the prize ship and was showing as "Inactive"
- As soon as I got onto the boarding deck of my target ship, Bush started a quest dialog with me for some unknown reason:
Code:
Quest name find_the_95th2 FOUND in QuestComplete
- Captured the ship and the second I assigned Bush as captain, he changed to "Captain" type
NOTE: Not(!) "Naval Captain", probably because I was "notcaptain" myself and therefore the game reverted to the default captain type rather than the specific one
- Unassigning him while still interface did not restore him
- Selling the ship later didn't restore him either
 
@Levis: This is totally confirmed.
Worth noting here are the following things:
- Bush did not have ANY officer type assigned to him before me giving him command of the prize ship and was showing as "Inactive"
- As soon as I got onto the boarding deck of my target ship, Bush started a quest dialog with me for some unknown reason:
Code:
Quest name find_the_95th2 FOUND in QuestComplete
- Captured the ship and the second I assigned Bush as captain, he changed to "Captain" type
NOTE: Not(!) "Naval Captain", probably because I was "notcaptain" myself and therefore the game reverted to the default captain type rather than the specific one
- Unassigning him while still interface did not restore him
- Selling the ship later didn't restore him either
it's because he was inactive before.
I will add something to the restore function where if no previous officertype is know the officertype will be removed so it becomes inactive again (or I might set him to the default randchar).

If he isn't set to naval captain I think it's an interface problem because he should be set by this function:
Code:
string GetCaptainType(ref chr)
{
    string CaptainType = OFFIC_TYPE_REGCAP;
    if (IsCompanion(chr))
    {
        if (HasMerchantPassport(GetMainCharacter()))        CaptainType = OFFIC_TYPE_CAPMERCHANT;
        if (IsMainCharacter(chr))
        {
            if (CheckAttribute(chr, "isnotcaptain"))        CaptainType = OFFIC_TYPE_NAVIGATOR;
        }
        if (GetLetterOfMarqueQuantity() > 0)                CaptainType = OFFIC_TYPE_CAPPRIVATEER;
        if (HaveLetterOfMarque(ProfessionalNavyNation()))    CaptainType = OFFIC_TYPE_CAPNAVY;
        if (GetServedNation() == PIRATE)                    CaptainType = OFFIC_TYPE_CAPPIRATE;
    }
    else
    {
        if (CheckAttribute(chr, "FantomType"))
        {
            switch(chr.FantomType)
            {
                case "trade":                                CaptainType = OFFIC_TYPE_CAPMERCHANT;    break;
                case "pirate":                                CaptainType = OFFIC_TYPE_CAPPIRATE;        break;
                case "war":
                    if (sti(chr.nation) == PIRATE)            CaptainType = OFFIC_TYPE_CAPPRIVATEER; // PB: I think this never happens
                    else                                    CaptainType = OFFIC_TYPE_CAPNAVY;
                break;
            }
        }
    }
    return CaptainType;
}

So either there is a logic flaw or something else is going on.
 
I will add something to the restore function where if no previous officertype is know the officertype will be removed so it becomes inactive again (or I might set him to the default randchar).
To be certain, I made a second try, this time with him assigned as Gunner before.
In that case, he did behave himself as expected.

So this is confirmed as being related to "inactive officers without captain type assigned".

If he isn't set to naval captain I think it's an interface problem because he should be set by this function:
On second try, he didn't become "Naval Officer" either, despite me truly being the captain that time.
This actually does make some sense, because this would return FALSE:
Code:
if (HaveLetterOfMarque(ProfessionalNavyNation()))
While it isn't quite visible to the player, Hornblower only gets a LoM after the storyline has completed.
This is to prevent him from gaining promotions through the normal system. So not actually an error there.

Actually, this is why I deliberately set up the logic to work the way it does.
Then at least you can SEE if you've got a naval rank, but aren't shown as "Naval Officer.
Otherwise it would be invisible and, therefore, confusing. Especially for trouble-shooting. :wp
 
So should we change that line to be a check purely for naval assignment?
Also I think the isnotcaptain check should be moved down in the function a bit so it will overwrite the others is neccesary.


So this is confirmed as being related to "inactive officers without captain type assigned".
Yes
 
So should we change that line to be a check purely for naval assignment?
I prefer keeping that as-is. The main reason is so you can SEE if you lose your LoM without losing your navy rank.
Have no clue why that might possibly happen, yet somehow it sometimes did: Fixed - Naval Officer: Letter of Marque does not stick | PiratesAhoy!

If not for this, that would be completely invisible, but it would break promotions quite badly.
So better to keep it for trouble-shooting reasons, which is actually my original reason for adding that in the first place.... :wp

Also I think the isnotcaptain check should be moved down in the function a bit so it will overwrite the others is neccesary.
Again, I prefer to keep it as-is for similar reasons.
If you're playing Hornblower, I want to be able to SEE when that changes to "Naval Captain", because that should NOT be happening.
It is all about making hidden behind-the-scenes game functionality more visible.
Makes it much easier to notice if something goes wrong.

So while I suppose ideally Bush should have become a "Navy Officer" since he isn't the player,
I shouldn't have been able to assign him in the first place because he's an important quest character.

And so what if he's just "Captain"? That isn't technically wrong and makes virtually no difference.
Captains contribute ALL their skills anyway.

This should be an "issue" unique to Hornblower only. And should hardly ever happen because of the "isnotcaptain" limitations.
And does little to no harm at all. And once the storyline completes, you DO get that LoM and you should get to see that you've become a "Naval Captain" in the end.
So I wouldn't worry about it.... :cheeky
 
If the problem is caused by Bush not having a type assigned before, the obvious solution is what I was planning on doing anyway, which is to give him an officer type in the character definition. "First mate" seems appropriate.
 
If the problem is caused by Bush not having a type assigned before, the obvious solution is what I was planning on doing anyway, which is to give him an officer type in the character definition. "First mate" seems appropriate.
That will indeed solve this specific example. :onya

A more general fix by @Levis to avoid it in similar situations in the future would still be a good thing.
At least we found out that this issue exists, which is always a good start to getting it fixed. ;)
 
Back
Top