Included in Build Hornblower updates

[Pieter Boelen]

Nor is this the only time when someone gets killed in a fight and resurrected later, but usually they get renamed, which is why you'll find code renaming Matthews (during the Antigua land battle) and Haggman (during the extension) back to their original names.

If I recall, there is code to avoid renaming characters upon resurrection.
ch.questch = true; might do it. I'd have to check. Using that, you then wouldn't need to rename them back again.

 

[Pieter Boelen]

As promised, here are my LOG-files from yesterday's tests.

As for the "random names on death", this is the applicable code from CharactersUtilite.c:

void SetRandomNameToCharacter(ref rCharacter)
{
   if (CheckAttribute(rCharacter, "questchar")) {
     if (CheckAttribute(rCharacter, "old.name")) rCharacter.name = rCharacter.old.name;
     if (CheckAttribute(rCharacter, "old.middlename")) rCharacter.middlename = rCharacter.old.middlename; // KK
     if (CheckAttribute(rCharacter, "old.nickname")) rCharacter.nickname = rCharacter.old.nickname; // KK
     if (CheckAttribute(rCharacter, "old.lastname")) rCharacter.lastname = rCharacter.old.lastname;
     return;
   }

So just adding the "questchar" attribute should put an end to it.
Might be a simpler solution than renaming the characters back.

 

[Pieter Boelen]

Would it make sense to add DeleteAttribute(PChar, "isnotcaptain"); lines to all C.S. Forester dialog cases where you're given command of the Hotspur?
On the off-chance that it does, I've just done that in my own game version. So I just need to know if should be kept.

 

[Pieter Boelen]

"isnotcaptain" has the following effects:
- Cannot hire officers
- Cannot take any crewmembers with you ashore
- No paying of salary
- Player shown as "Navigator" instead of a Captain
- Never get morale issues from having too much money
- It is removed when you leave the service of a country in whichever way
- At the moment it is used exclusively for Hornblower.

Does this make sense to you? Especially if you're removing it for part of the storyline before adding it again later?
Or do you have any change requests for it?

Addition to the above list:
Since you cannot select any officer in your Passengers list either, you cannot add or remove any of them from your shore party.
But that also means you can only change the officer type of those already IN your "shore party" as any others cannot be selected.
That should not be a problem when those are pre-assigned in the character init files though.

Additionally, you CAN still take prize ships even if you're not the captain.
But you can NOT get any officers to actually assign. Which means you're pretty much forced to assign your quest ones.
Which is exactly not meant to happen as that really does have the potential of breaking things.

Probably a better solution to BOTH issue is to use a line like this one for all characters that need to be with you for quest purposes:

SetCharacterRemovable(characterFromID("Lt. William Bush"), false);

In theory we could then remove the whole "cannot select passengers list if not the captain" behaviour from the Passengers Interface altogether.
Might not make sense for a Midshipman (the player) to assign the Captain as "Gunner", though.

Maybe even if this is done everywhere needed, we can lose a LOT of the "isnotcaptain" limitations.
After all, players can pretend that whatever captain-like actions they take, they were ordered to do by the real captain.

 

[Grey Roger]

As promised, here are my LOG-files from yesterday's tests.

Thanks!

From "compile.log":

Quest name interrogation_wolfe_start FOUND in QuestComplete
SETTING MUSIC: music_dungeon
SETTING MUSIC: music_dungeon
Quest name interrogate_wolfe1 FOUND in QuestComplete
Template <goto> -> failure for chr.id = Location fantom character <13>

That looks like a soldier, or possibly a random prisoner, is having problems - I don't think "fantom character <13>" is any of the quest characters. May be worth checking in case it shows up during anyone else's visit to Bridgetown prison.

Actor error: character <Thomas Wolfe> now is do template <goto>, his not is free for new task
Quest name wolfe_out_of_jail FOUND in QuestComplete

Case "wolfe_out_of_jail" is where he's supposed to be moved to "officers/reload27_2". What does that error message mean? That is where he's appearing at the port gate instead of where he should be. It seems to come from "LAi_actor.c":

bool LAi_type_actor_Error(aref chr, bool lockTest)
{
   if(CheckAttribute(chr,"chr_ai.type") && chr.chr_ai.type != LAI_TYPE_ACTOR)
   {
     Trace("Actor error: character <" + chr.id + "> now is not actor, his have type <" + chr.chr_ai.type + ">");
     return true;
   }
   if(lockTest)
   {
     if(CheckAttribute(chr,"chr_ai.type.lock") && sti(chr.chr_ai.type.lock) != 0)
     {
       Trace("Actor error: character <" + chr.id + "> now is do template <" + chr.chr_ai.tmpl + ">, his not is free for new task");
       return true;
     }
   }
   return false;
}

As for his non-appearance at Boca de Yuman, it always worked for me, but if the automatic move is unreliable then I'll force the issue. At case "Hispaniola_shore_for_Quelp", where everyone else is being moved, add this:

ChangeCharacterAddressGroup(characterFromID("Thomas Wolfe"), "Hispaniola_shore_01", "officers", "reload1_1");

That should put him on the same spot as Sharpe, but Sharpe will move soon anyway as he's a companion. Having multiple characters spawn to the same spot doesn't prevent anyone's appearance, they all appear on top of each other until they move. There are several places in "Hornblower" where multiple riflemen start off on the same spot, but another good place to see this is any time you have companion officers and you've just spent a night in a tavern - when you leave the room, you're all very intimate.

 

[Grey Roger]

Addition to the above list:
Since you cannot select any officer in your Passengers list either, you cannot add or remove any of them from your shore party.
But that also means you can only change the officer type of those already IN your "shore party" as any others cannot be selected.
That should not be a problem when those are pre-assigned in the character init files though.

Additionally, you CAN still take prize ships even if you're not the captain.
But you can NOT get any officers to actually assign. Which means you're pretty much forced to assign your quest ones.
Which is exactly not meant to happen as that really does have the potential of breaking things.

Probably a better solution to BOTH issue is to use a line like this one for all characters that need to be with you for quest purposes:

SetCharacterRemovable(characterFromID("Lt. William Bush"), false);

I'd already come to a similar conclusion, though for pretty much the opposite case, i.e. when "isnotcaptain" has been deleted (instead of being set false). At that point all restrictions are off - you can hire officers and you can assign or remove companions. So not only can you assign officers to prize ships, you can also remove them from your active companions list, precisely the problem which banning the hiring of officers or altering the companions list was supposed to solve. So I'll need to make sure all quest officers are protected by 'SetCharacterRemovable' when they're critical to quest progression. There's no harm in assigning Bush as commander of a prize ship if he's not critical to the next quest progression, and in fact that's exactly what I did which then triggered the "Captain Bush" problem. I may leave the Able Seamen permanently protected, though - they're not officers and should not be allowed command of prize ships! Ditto for Sharpe and his men, who are army, not navy, and aren't even supposed to command a rowing boat.

In theory we could then remove the whole "cannot select passengers list if not the captain" behaviour from the Passengers Interface altogether.
Might not make sense for a Midshipman (the player) to assign the Captain as "Gunner", though.

You aren't prevented from accessing the passengers list anyway. You just can't assign officers to or from the companion slots.

Meanwhile, some other maintenance is going to be needed. I want to check that all 'vcskip' lines are cancelled when the area they're protecting is no longer needed for the quest chapter; add (and cancel) some more 'DisableFastTravel' lines to prevent teleport to the ship; give everyone a suitable default role with 'ch.quest.officertype' (which may also solve the "Captain Bush" problem).

And then there's a little something I'm working on - nothing major, just an event which should have been added ages ago and might now actually happen...

 

[Pieter Boelen]

Case "wolfe_out_of_jail" is where he's supposed to be moved to "officers/reload27_2". What does that error message mean?

I'm not at all sure, really. Anyway, before making a fix, I'd like to try again some time. Maybe I can find the opportunity somewhere this weekend.
Moving him to the next location would work ONLY if you don't visit ANY other places first.
Or are you proposing doing that and also removing the LAi_ActorFollowEverywhere behaviour?

There's no harm in assigning Bush as commander of a prize ship if he's not critical to the next quest progression, and in fact that's exactly what I did which then triggered the "Captain Bush" problem.

Does he not become relevant again later? Once he is assigned as a companion, it may be difficult to get him ashore again.
Though I know that IS possible. Danielle in the Standard storyline can be a companion AND a shore party character at the same time.

I may leave the Able Seamen permanently protected, though - they're not officers and should not be allowed command of prize ships! Ditto for Sharpe and his men, who are army, not navy, and aren't even supposed to command a rowing boat.

Just setting their Leadership or Sailing skills to 0 does already prevent them from both levelling up in that skill AND commanding ships, if I recall.
At least.... that used to be the case. Maybe @Levis can confirm if asigned skills of 0 for quest characters indeed still do not increase as originally intended.

It was quite funny when I noticed they were shown as part of the "Officer" group in the F2>Character Interface.
Of course that does make sense, because there IS no other group. Though there used to be a "Passengers" one; I'd have to check how they can fall under that instead.

@Levis: Do you reckon it would make sense to have a "Sailor" officer type? We could use those for merchant boarding crews, player shore crew and also these quest characters.

You aren't prevented from accessing the passengers list anyway. You just can't assign officers to or from the companion slots.

Are you really sure about that? Because yesterday I definitely could NOT select any character in the Passengers list.
And when I couldn't remember why, I looked up the code. That's when I remembered I did deliberately put that in place.
I'd rather get rid of that limitation if I can, but right now it should still be in place.

Meanwhile, some other maintenance is going to be needed. I want to check that all 'vcskip' lines are cancelled when the area they're protecting is no longer needed for the quest chapter; add (and cancel) some more 'DisableFastTravel' lines to prevent teleport to the ship; give everyone a suitable default role with 'ch.quest.officertype' (which may also solve the "Captain Bush" problem).

All sound like some very good ideas to me.

And then there's a little something I'm working on - nothing major, just an event which should have been added ages ago and might now actually happen...

Consider my curiosity peaked....

 

[Levis]

I've made a sailor type officertype already. it will be in the update I hope to upload tonight

 

[Pieter Boelen]

I've made a sailor type officertype already. it will be in the update I hope to upload tonight

Cool!
Then I just need some confirmation on the below too:

Just setting their Leadership or Sailing skills to 0 does already prevent them from both levelling up in that skill AND commanding ships, if I recall.
At least.... that used to be the case. Maybe @Levis can confirm if asigned skills of 0 for quest characters indeed still do not increase as originally intended.

Basically, any "questchar" character with a skill of "0" should never increase that skill. Sailors should have Leadership = 0 so that they can never command ships.
Other passengers can be given Sailing = 0 for the same effect. That should make sense for Riflemen, no?

 

[Levis]

Cool!
Then I just need some confirmation on the below too:

Basically, any "questchar" character with a skill of "0" should never increase that skill. Sailors should have Leadership = 0 so that they can never command ships.
Other passengers can be given Sailing = 0 for the same effect. That should make sense for Riflemen, no?

at the moment this isn't the case but I should be able to make it so this works this way. should be a simple change (I hope).

 

[Levis]

But I must say I don't like having characters with a skill of 0 in something so they will be set to 1. And I think even then they can be assigned to a ship ... the error will appear they aren't fit for it but you can ignore this error right?
So @Pieter Boelen is the only reason to have them at 0 for some skills to prevent them from commanding a ship? I've seen the 0 skill multiple times already....

 

[Pieter Boelen]

And I think even then they can be assigned to a ship ... the error will appear they aren't fit for it but you can ignore this error right?

You're thinking of the "minimum sailing/leadership skills to be able to command a ship" feature. But that applies only in Realistic Game mode.
In Arcade Game Mode, the only limitation is that leadership and sailing must be greater than 0.

I think at the moment that isn't deliberately used for quest purposes, but should be quite a convenient way of handling it.
Basically if you want a quest character who shouldn't be able to command a ship, you can set Sailing or Leadership to 0 and then it stays that way and they can't be assigned.
Giving them 1 instead wouldn't work, since then you CAN assign them.

If I recall, some stock game quest characters were set up with certain skills at 0 too, but I don't know the reasoning behind that.
It wasn't the same reason, that for sure. Probably also the reason why there is an "allow skill increase if zero" option in InternalSettings.h somewhere.

We should get rid of that option so that you can NOT do that, but also make sure that it is set with 0 only when it is deliberately meant like that for specific quest purposes.

 

[Grey Roger]

I'm not at all sure, really. Anyway, before making a fix, I'd like to try again some time. Maybe I can find the opportunity somewhere this weekend.
Moving him to the next location would work ONLY if you don't visit ANY other places first.

On this occasion, visiting any other place is going to be a good trick, unless you do it by console command in which case it's your own fault. There's only one way out of Bridgetown prison and when you use it, you're standing in front of the prison. That's when Wolfe is supposed to teleport to "officers/reload27_2", which is also just outside the prison.

Does he not become relevant again later? Once he is assigned as a companion, it may be difficult to get him ashore again.
Though I know that IS possible. Danielle in the Standard storyline can be a companion AND a shore party character at the same time.

So does Lt. Uriah Quelp at case "a_new_dawn_a_new_ship" - he becomes a companion officer and a companion ship at about the same time. I suspect that there's nothing preventing a companion captain from being put on land as well, other than the quest writer being careful not to have the same character in two places at once. It's not even logically inconsistent - you're both captain of a ship and walking around on land, why can't your officers do likewise?

Just setting their Leadership or Sailing skills to 0 does already prevent them from both levelling up in that skill AND commanding ships, if I recall.
At least.... that used to be the case. Maybe @Levis can confirm if asigned skills of 0 for quest characters indeed still do not increase as originally intended.

It won't matter if Matthews, Styles etc. are all under the protection of 'SetCharacterRemovable'. Besides, at the moment Matthews, for example, has Sailing 6, which is fair enough as he is a sailor. So making him Navigator and getting the benefit of that skill should be alright. He just shouldn't be able to command anything, which he won't if he's not removable and can't be put onto another ship. As for Leadership, Matthew has - OK, that's getting changed right now, nobody should have Leadership 13!

Are you really sure about that? Because yesterday I definitely could NOT select any character in the Passengers list.
And when I couldn't remember why, I looked up the code. That's when I remembered I did deliberately put that in place.
I'd rather get rid of that limitation if I can, but right now it should still be in place.

I'm fairly sure I was able to assign Pellew to different roles when I was fighting Temeraire. But you can check that one quickly enough because one of C. S. Forester's jumps leads to that battle.

 

[Grey Roger]

Just in case you hadn't seen, I intend to make a new Installer EXE by Sunday evening which will of course include your latest work on Hornblower.
If you have anything extra that you'd like me to add, you'd be very welcome to post it before that time.

Nothing new yet. Once I've done my maintenance work, I'm going to want to check that it hasn't messed things up before I put it out for release.

I think it is perfectly fine. Except when that character is killed while ashore, the ship probably disappears with him.
So if you DO intend to allow that, I might suggest making such characters immortal until they have outlived their quest purpose.

That is a different problem, and one which can potentially affect any quest-critical officer. The problem with making them all immortal is that some of them, e.g. Bush, don't outlive their quest purposes until the end of the game, so making them all permanently immortal potentially gives you an invincible team of companions. They're often immortal or not at risk while they're doing their quest stuff, and if they get killed while they're not on quest duty then they'll just get resurrected when the quest calls for them again, as indeed has already happened to Matthews and Haggman in my current game.

I did wonder why those sailors are even assigned as officers at all.
Could they not be "LAi_ActorFollowEverywhere" instead? So they're with you, but you can't assign them to anything?
That is done with Pintel for Jack Sparrow too, if I recall.

If you can't assign the sailors to command prize ships because they're unremovable then there is no problem. I'll have to check exactly when they enter your "Passengers" list and can be assigned jobs, but I see no reason not to be able to use their skills if they're part of your crew. (In fact, if they're getting the "ch.questchar = true" attribute which means they get exactly what is shown in "Story.c" rather than randomly assigned skills for their level, I'll probably change their skills, make each sailor have something different, and give him a suitable "ch.quest.officertype" to match.)

I haven't done anything with the surrendering yet. I'm still also tinking about how to make it best.

What is wrong with surrendered captains as they are now? Is there a point to making them useless unless you find some item or other?

 

[Pieter Boelen]

That is a different problem, and one which can potentially affect any quest-critical officer. The problem with making them all immortal is that some of them, e.g. Bush, don't outlive their quest purposes until the end of the game, so making them all permanently immortal potentially gives you an invincible team of companions. They're often immortal or not at risk while they're doing their quest stuff, and if they get killed while they're not on quest duty then they'll just get resurrected when the quest calls for them again, as indeed has already happened to Matthews and Haggman in my current game.

If they get resurrected, that is of course fine. But I don't think resurrecting works for companion ships.
You could try, just to be sure, I suppose.

If you can't assign the sailors to command prize ships because they're unremovable then there is no problem. I'll have to check exactly when they enter your "Passengers" list and can be assigned jobs, but I see no reason not to be able to use their skills if they're part of your crew. (In fact, if they're getting the "ch.questchar = true" attribute which means they get exactly what is shown in "Story.c" rather than randomly assigned skills for their level, I'll probably change their skills, make each sailor have something different, and give him a suitable "ch.quest.officertype" to match.)

Sounds good to me.

What is wrong with surrendered captains as they are now? Is there a point to making them useless unless you find some item or other?

If I understand correctly, that came from this bug I reported yesterday: Confirmed Bug - Levelling: Skills of Zero Trigger Errors | PiratesAhoy!
That may have happened because the enemy captain had leadership 1, which was reduced to 0 by surrendering and then caused errors.

But please have a look at this post I just made on the subject: WIP - Skill modifiers for characters | PiratesAhoy!
There I propose simply removing that feature, rather than adapting the Levelling system to support that one example.

 

[Grey Roger]

If they get resurrected, that is of course fine. But I don't think resurrecting works for companion ships.
You could try, just to be sure, I suppose.

If the quest itself is going to put the officer into a dangerous situation then he can be made immortal for that part of the quest. If that part of the quest is safe but you go off looking for trouble and get the officer killed then you face the consequences. (If you do that while you're supposed to be bringing Quelp and Bracegirdle from Bridgetown to Charlestown, the quest recognises that you got them killed and kicks you out of the navy.) "Hornblower" has always been a bit vulnerable to players going off and doing their own thing, though it is rather more tolerant now, e.g. you can make friends with Fred Bob without displacing a quest officer. But basically, if you are determined to go off-quest and play free-play instead, I'm not going to stop you.

 

[Pieter Boelen]

Looking at your quest code again, I've got a clue on why Wolfe was acting strangely:

    case "take_wolfe":
       ChangeCharacterAddressGroup(characterFromID("Thomas Wolfe"), "Greenford_prison", "goto", "goto23");
       LAi_ActorGotoLocator(characterFromID("Thomas Wolfe"),"officers", "reload1_2", "", 30.0);
       SetOfficersIndex(Pchar, 1, getCharacterIndex("Richard Sharpe"));
       Pchar.quest.wolfe_out_of_jail.win_condition.l1 = "location";
       PChar.quest.wolfe_out_of_jail.win_condition.l1.character = Pchar.id;
       Pchar.quest.wolfe_out_of_jail.win_condition.l1.location = "Greenford_town";
       Pchar.quest.wolfe_out_of_jail.win_condition = "wolfe_out_of_jail";
     break;

Possibly LAi_ActorGotoLocator gave him the task to go to a certain locator, but he never got the chance to finish that.
So instead he showed up in the NEXT location on that locator, which then overrode the LAi_ActorFollowEverywhere that was executed later.
Not sure that IS what happened, but it might explain it.

 

[Pieter Boelen]

This now included for testing in here: Mod Release - Build 14 Beta 4 Internal WIP For Testing | Page 8 | PiratesAhoy!

 

[Grey Roger]

Looking at your quest code again, I've got a clue on why Wolfe was acting strangely:

    case "take_wolfe":
       ChangeCharacterAddressGroup(characterFromID("Thomas Wolfe"), "Greenford_prison", "goto", "goto23");
       LAi_ActorGotoLocator(characterFromID("Thomas Wolfe"),"officers", "reload1_2", "", 30.0);
       SetOfficersIndex(Pchar, 1, getCharacterIndex("Richard Sharpe"));
       Pchar.quest.wolfe_out_of_jail.win_condition.l1 = "location";
       PChar.quest.wolfe_out_of_jail.win_condition.l1.character = Pchar.id;
       Pchar.quest.wolfe_out_of_jail.win_condition.l1.location = "Greenford_town";
       Pchar.quest.wolfe_out_of_jail.win_condition = "wolfe_out_of_jail";
     break;

Possibly LAi_ActorGotoLocator gave him the task to go to a certain locator, but he never got the chance to finish that.
So instead he showed up in the NEXT location on that locator, which then overrode the LAi_ActorFollowEverywhere that was executed later.
Not sure that IS what happened, but it might explain it.

I hadn't thought of that, but trials over the weekend disprove it anyway. Being in a hurry, I didn't wait for Wolfe to get to the prison door before I went out. As usual in my game, he did appear where he was meant to, outside the prison and on my right. Anyway, Sharpe also doesn't finish his move to the door out of the tunnel to Charlestown Naval Academy if you rush through the door too quickly, which doesn't cause any such trouble. (At least, not now I've changed the move line so that it it no longer the trigger for the next quest case!)

Besides, what's fouling up here isn't the 'LAi_ActorFollowEverywhere' line, it's the 'ChangeCharacterAddressGroup' a couple of lines above it which is supposed to put him outside the prison. Anyway, there's a quick way to check it - when you've finished the dialog with the prison commandant, press "R" a few times and wait for Wolfe to get to the door, then see if that makes any difference.

 

[Grey Roger]

You are invited to attend the wedding of:

Commander Horatio Hornblower, R.N.
and
Maria Mason

in Bridgetown Parish Church


Attendance will require the installation of the attached "wedding.zip". Those of you still running the 5th November version of Beta 4 get an express coach to take you to there.