Planned Feature Encourage Play for Evil Characters

[Hylie Pistof]

1) I don't want to pull this thread off track.

2) It's been a while since I started a new game so it might have changed and I don't remember, but combat used to be pretty tuff for a while and then it got easier. I'm now at level 38 or so and am switching between swords to see which one looks best riding on my characters hip. Many swords look like they are floating in air and that is why I'm using the Spanish Rapier. It is touching my hip. Combat? Whatever..........

 

[Pieter Boelen]

And that's how I've used it. Take a look at this, but it's currently completely untested, so use at your own risk! But you can WinMerge it with your own one to find out what I've done and see if there are any blatant errors.

For the sake of figuring out this logic properly, I attempted a complete rewrite that hopefully leads to something that makes more sense:

  if(first)
   {
     rel = RelationToRMRelation(GetFlagRMRelation(mNation));                       // relation based on flag
     if(GetFlagRMRelation(mNation) == RELATION_ENEMY)                         // your flag IS hostile to the merchant
     {
       // nothing: you are claiming to be hostile, so that is how you will be treated
     }
     else                                               // your flag is NOT hostile to the merchant
     {
       switch(GetNationRelation(PERSONAL_NATION, mNation))
       {
         case RELATION_FRIEND:                                   // you are FRIENDLY yourself
           rel = GetRMRelation(GetMainCharacter(), mNation);                   // use your actual relations
           DeleteAttribute(merch, "FalseFlagDetect");                       // forget if he ever doubted you
         break;
         case RELATION_NEUTRAL:                                   // you are NEUTRAL, but not hostile
           if (frnd() < GetChanceDetectFalseFlag() || CheckAttribute(merch,"FalseFlagDetect"))   // checks if the merchant will believe you
           {
             merch.FalseFlagDetect = true;                           // you have been caught and the merchant won't be so trusting next time
             rel = GetRMRelation(GetMainCharacter(), mNation);                 // use your actual relations instead
           }
         break;
         case RELATION_ENEMY:                                   // you are actually an enemy
           if (frnd() < GetChanceDetectFalseFlag() || CheckAttribute(merch,"FalseFlagDetect"))   // checks if the merchant will believe you
           {
             merch.FalseFlagDetect = true;                           // you have been caught and the merchant won't be so trusting next time
             rel = GetRMRelation(GetMainCharacter(), mNation);                 // use your actual relations instead
           }
         break;
       }
     }
     merch.traderelation = rel;                                     // store the determine relation for later use
   }
   else
   {
     rel = sti(merch.traderelation);                                   // use the SAME relation for the WHOLE dialog
   }

At the moment the RELATION_NEUTRAL and RELATION_ENEMY sections are identical, so you would need to think of how those should be different.

Maybe some sort of "forget after a day" thing for RELATION_NEUTRAL or "reset after leaving the island"?

Or should the value from GetChanceDetectFalseFlag() in some way be scaled by a factor that depends on your level of negative relations?
So if you're "almost friendly", then it is almost always OK, but if you are really very hostile, then you are much more easily caught?

If so, maybe there could be some use for a function like this one?

float GetDetectionChance(int iNation)
{
   float chance = GetRMRelation(GetMainCharacter(), iNation)/REL_MIN;
   if (chance < 0.0) chance = 0.0;
   return chance;
}

That would return a chance of "1.0" if you are MAXIMUM HOSTILE and "0.0" if you are completely Friendly.
Not sure yet where that would fit into all of this....

In theory, that could be a complete replacement for the current GetChanceDetectFalseFlag() because that is more of a "fame-based recognition check".

 

[Pieter Boelen]

I don't want to pull this thread off track.

There is a lot of good stuff being discussed here at the same time. I wouldn't want to put a stop to that!
Once some separate things start becoming clear, we can start individual discussions for those.
So go right ahead and provide whatever feedback you might have.

It's been a while since I started a new game so it might have changed and I don't remember, but combat used to be pretty tuff for a while and then it got easier.

In theory, I don't actually mind if that is indeed the case.
At least then the "NPCs that level together with the player" don't end up defeating the purpose of levelling up.
But you do need to be able to gain your own fencing experience to keep up with your enemies, I suppose.
Hmm....

Anyway, for now I don't envision any changes that will break getting the Toff quest.
If ever we reconsider, we might increase the reputation requirement for it. But not now.

I'm now at level 38 or so and am switching between swords to see which one looks best riding on my characters hip. Many swords look like they are floating in air and that is why I'm using the Spanish Rapier. It is touching my hip. Combat? Whatever..........

If some swords aren't in line with the character models, would any locators need to be changed to move them closer together?

Anyway, I have to admit I always chose my swords based on looks more than stats as well.

 

[Hylie Pistof]

The sword location doesn't seem to be tied to the model but to the animation. Bigger models have the sword inside their bodies while smaller characters have it hanging in air beside them. But I have never looked at the models so I could be wrong.

 

[Pieter Boelen]

The sword location doesn't seem to be tied to the model but to the animation. Bigger models have the sword inside their bodies while smaller characters have it hanging in air beside them. But I have never looked at the models so I could be wrong.

Character models do have some potentially relevant locators:

 

[Hylie Pistof]

Indeed. I discovered that a little while ago and have been moving the saber_belt locator in closer to the body but it breaks the animation. The sword ends up laying across the character's legs. So it is something that possibly someone who has done animations might understand.

 

[Grey Roger]

For the sake of figuring out this logic properly, I attempted a complete rewrite that hopefully leads to something that makes more sense:

Why didn't you do that in the first place? It would have saved me the effort of the now redundant rewrite, as well as some time testing the other version, and you'd have spent the same time anyway.

At the moment the RELATION_NEUTRAL and RELATION_ENEMY sections are identical, so you would need to think of how those should be different.

RELATION_NEUTRAL should be the same as RELATION_FRIEND, not RELATION_ENEMY. The merchant doesn't care if your nation is allied or just at peace with his, what's important is that you're not at war, so he has no objection to trading with you. Anyway, those are the relations between nations: 0 = friend, 1 = neutral, 2 = enemy. Shouldn't you be checking relation of your character to the merchant's nation, as in the original code, so you can distinguish between Hostile ("REL_WAR"), Wary ("REL_AFTERATTACK"), Neutral ("REL_AMNESTY") and Friendly ("REL_NEUTRAL")? ("REL_NEUTRAL" is 0, which is friendly and the maximum you'll get without a LoM.)

What I don't see in that quoted code is what effect reputation has, and as that's what started this whole thing in the first place, that's the important bit. Can an evil character now trade in a friendly or neutral port? Can he trade in a Wary port if under a false Friendly flag?

Or should the value from GetChanceDetectFalseFlag() in some way be scaled by a factor that depends on your level of negative relations?
So if you're "almost friendly", then it is almost always OK, but if you are really very hostile, then you are much more easily caught?

Why? Either you're recognised or you're not. If you're recognised, you're treated for what you are; if you're not recognised, you're treated for what you claim to be. Maybe allow a factor if your character relation to the nation is "REL_MIN" or less, i.e. they really hate you - this goes beyond the normal result of your nation being at war with them, this means you've been doing some serious harm to them yourself. On the other hand, either you did it legally under a LoM, probably got a promotion or two for it, so your Fame has gone up and will already be affecting your detection chance; or you did it illegally and by now have probably turned Pirate.

Otherwise leave it alone - don't fix what isn't broken.

 

[Grey Roger]

Meanwhile, on the other front, the version of "Enc_Walker.c" which I posted earlier does not work. Partly because of a few typos and partly because I'd used "PChar.reputation" directly, which didn't seem to produce a useful result. So after fixing the typos, I did a bit more digging and found function 'GetCharacterReputation'. So the version attached here is tested and works. Well, sort of.

I'd added a few 'logit' lines to monitor my reputation versus the defined values for "Matey" and "Dashing". And I found that although those seem to be defined in "characters.h" as 65 (REPUTATION_GOOD) and 75 (REPUTATION_VERYGOOD), they actually seem to be defined somewhere else because I became "Matey" when I hit reputation 60. So you'll still get the +1 increases for a while after you've become "Matey" and the +2 increase for giving money to a failed pickpocket for a while after you've become "Dashing", but when you reach reputation 65 and 75 respectively the increases do stop.

Also, not related to good vs. evil but definitely related to "Enc_Walker.c", this from the section where the walker has volunteered to be an officer and you've accepted, so now it needs to decide what sort of officer you're getting:

    case "enlist_me":
       NPChar.Dialog.Filename = "Enc_Officer_dialog.c";
       d.Text = DLG_TEXT[292];
       Link.l1 = DLG_TEXT[293];
       Link.l1.go = "exit_change_dlg";
       NPChar.offgen = true;
       NPChar.officer = true;
// MAXIMUS interface MOD -->
       /*switch(Rand(7))
       {
         case 0: NPChar.quest.officertype = OFFIC_TYPE_BOATSWAIN; break;
         case 1: NPChar.quest.officertype = OFFIC_TYPE_CANNONEER; break;
         case 2: NPChar.quest.officertype = OFFIC_TYPE_QMASTER; break;
         case 3: NPChar.quest.officertype = OFFIC_TYPE_NAVIGATOR; break;
         case 4: NPChar.quest.officertype = OFFIC_TYPE_FIRSTMATE; break;
// MAXIMUS officers -->
         case 5: NPChar.quest.officertype = OFFIC_TYPE_CARPENTER; break;
         case 6: NPChar.quest.officertype = OFFIC_TYPE_DOCTOR; break;
         case 7: NPChar.quest.officertype = OFFIC_TYPE_ABORDAGE; break;
// MAXIMUS officers <--
       }*/
       //Levis let's use the unique types you can get from the enc_walker.
       //NPChar.quest.officertype = GetRandomOfficerType(); //Levis let's use a global function so we can easily add types later.
       LAi_Create_Officer(rand(8), &NPChar); //so that these officers are better than tavern ones.
       PChar.newofficerid = NPChar.id;//MAXIMUS
// MAXIMUS interface MOD <--
     break;

You'll see that the original code to choose officer type has been commented out in favour of the call to 'GetRandomOfficerType()'. That was a total disaster and was commented out, but the original code was never uncommented. My guess is this is why, if you try to hire a walker, it's liable to crash the game. In my own version I've removed the '/*' and '*/' around the original code and have been able to hire walker officers of various types. Perhaps do likewise for the official version?

 

[Pieter Boelen]

Why didn't you do that in the first place? It would have saved me the effort of the now redundant rewrite, as well as some time testing the other version, and you'd have spent the same time anyway.

Because I had no intention of touching any of this before Beta 4 was already released?
Because I was at work and both had no access to the game files AND was very busy with my job?
Seem like some rather valid reasons to me....

RELATION_NEUTRAL should be the same as RELATION_FRIEND, not RELATION_ENEMY. The merchant doesn't care if your nation is allied or just at peace with his, what's important is that you're not at war, so he has no objection to trading with you. Anyway, those are the relations between nations: 0 = friend, 1 = neutral, 2 = enemy.

RELATION_NEUTRAL happens for anything between "almost hostile" to "almost best buddies". "Wary" falls somewhere squarely in the middle.
Making RELATION_NEUTRAL and RELATION_FRIEND identical means that "Wary" means nothing again.

I do agree that it shouldn't be identical to RELATION_ENEMY either. Probably all three sections need to be different, which is why there are three sections.
But I didn't have much inspiration to think of how RELATION_NEUTRAL should be different from those other two.

Shouldn't you be checking relation of your character to the merchant's nation, as in the original code, so you can distinguish between Hostile ("REL_WAR"), Wary ("REL_AFTERATTACK"), Neutral ("REL_AMNESTY") and Friendly ("REL_NEUTRAL")? ("REL_NEUTRAL" is 0, which is friendly and the maximum you'll get without a LoM.)

Absolutely! That is what this line is for when you are recognized:

rel = GetRMRelation(GetMainCharacter(), mNation)

My reasoning this time was that if the merchant doesn't recognize you, he uses the relations based on flag. If he does recognize you, he'll use your actual relations.
But if your flag is hostile, he doesn't care about recognizing you because you are already claiming to be an enemy.

Maybe allow a factor if your character relation to the nation is "REL_MIN" or less, i.e. they really hate you

Just so you know, less than REL_MIN doesn't exist. -119 is really the rock bottom.

Why? Either you're recognised or you're not.

I figured that if you're MASSIVELY hostile (between -119 and -60), then you are probably "wanted" and people may be more on the lookout for you.
While if only your nation is hostile (-60), but you personally did nothing to offend them, the game could be more considerate.

Refer to the GetDetectionChance function I proposed above. I am admittedly not sure if, how and where something like that should be used; for now it is just a random idea.

A few ideas:
- Have that function return a value > 0.0 only IF you are actually hostile; between Hostile and Friendly, only your Fame counts (as per regular false flag detection chance)
- Determine the detection value based on the average between GetChanceDetectFalseFlag and GetDetectionChance
- Add GetDetectionChance on top of GetChanceDetectFalseFlag only IF you are actually hostile

That last one there doesn't sound half-bad to me.
You'd have a harder time in the early game when your detection chance is low to trade with MASSIVELY hostile nations than with only slightly hostile ones.
This would affect mainly Rebels who start out with REL_MIN to one specific nation.

Something worth considering, I reckon....

 

[Pieter Boelen]

I'd added a few 'logit' lines to monitor my reputation versus the defined values for "Matey" and "Dashing". And I found that although those seem to be defined in "characters.h" as 65 (REPUTATION_GOOD) and 75 (REPUTATION_VERYGOOD), they actually seem to be defined somewhere else because I became "Matey" when I hit reputation 60. So you'll still get the +1 increases for a while after you've become "Matey" and the +2 increase for giving money to a failed pickpocket for a while after you've become "Dashing", but when you reach reputation 65 and 75 respectively the increases do stop.

Maybe there is a mismatch between the function that determines the "display reputation name" and the actual reputation definitions.
That doesn't help. Could you please make a Bug Tracker entry for that? Then I'll see if I can figure out why that happens.

You'll see that the original code to choose officer type has been commented out in favour of the call to 'GetRandomOfficerType()'. That was a total disaster and was commented out, but the original code was never uncommented. My guess is this is why, if you try to hire a walker, it's liable to crash the game. In my own version I've removed the '/*' and '*/' around the original code and have been able to hire walker officers of various types. Perhaps do likewise for the official version?

Does that crash still happen? I know that was reported before, but as far as I understood, it was fixed.
If it is still a real bug, it needs a Bug Tracker entry! Otherwise nobody capable of fixing it will know that it still needs fixing.

At the moment BOTH those sections of code are sort-of intentionally commented out.
All characters in the game are given an "officer type" now, so they all already have the attribute set.
However, random characters don't get assigned most of the normal random officer types.
That is why the "Enc_Walkers" you can hire can be Sailors and Pirate Sailors and stuff like that.

Levis wants it that way so you can get such "odd" officer types, but I've got to admit I am not quite sold on it myself.
I'd much rather have hireable officers have only normal, REAL offier types.

Eventually I'd like to see "Enc_Walker" thoroughly modified so that characters' officer types are defined FIRST and then based on the defined type, different dialog options would be available.
This would mean that if you never talked to a character and start the dialog, the response won't be 100% random but will always be appropriate for that type of character.
The intention was to do that after Beta 4 has been released though, because it does risk breaking stuff for a while that currently isn't broken.
There is also the complexity of having character models and officer types somehow linked here as well, because it seems wrong for a towngirl to be a hireable officer type.

Anyway, that is just stuff for the future. In the meantime, if indeed the CTD still happens, make a Bug Tracker entry, ideally with a savegame.

 

[Pieter Boelen]

A new idea occurred to me on the TradeCheck function: Why don't we determine the 'rep' variable at the same time as the 'rel' one?
If your false flag is believed, then 'rep = NEUTRAL'; if you are "caught", then your 'rep = real rep'.
That makes things even easier for low reputation characters. As long as their flags ARE believed, that is.

To offset the effect of making things potentially too easy, I propose adding GetDetectionChance on top of GetChanceDetectFalseFlag IF you are hostile.
That would make it harder to do business in more hostile towns, which does make sense to me.
GetDetectionChance does then need to be changed to ensure they work together properly and the combined value doesn't exceed 1.0 too soon.
Still have to think that through... later.

 

[Grey Roger]

RELATION_NEUTRAL happens for anything between "almost hostile" to "almost best buddies". "Wary" falls somewhere squarely in the middle.
Making RELATION_NEUTRAL and RELATION_FRIEND identical means that "Wary" means nothing again.

That's the problem with using 'GetNationRelation(PERSONAL_NATION, mNation)' as the check rather than 'GetRMRelation(GetMainCharacter(), mNation)'. The former is for nations and determines whether their ships shoot at each other (hostile), whether one will hate you if you attack the other (allied) or whether they just leave each other alone (neutral). The latter deals in detail with how they view you. So if you want to distinguish between "Wary" and "Hostile", that's the one to use.

I do agree that it shouldn't be identical to RELATION_ENEMY either. Probably all three sections need to be different, which is why there are three sections.
But I didn't have much inspiration to think of how RELATION_NEUTRAL should be different from those other two.

When does PERSONAL_NATION become RELATION_FRIEND to another nation?

Absolutely! That is what this line is for when you are recognized:

rel = GetRMRelation(GetMainCharacter(), mNation)

My reasoning this time was that if the merchant doesn't recognize you, he uses the relations based on flag. If he does recognize you, he'll use your actual relations.
But if your flag is hostile, he doesn't care about recognizing you because you are already claiming to be an enemy.

I had the same idea, and was going to post a slightly modified version of the one I posted earlier, replacing 'rel = REL_NEUTRAL;' with 'rel = GetNationRelation(pNation, mNation);'.

Just so you know, less than REL_MIN doesn't exist. -119 is really the rock bottom.

I figured that if you're MASSIVELY hostile (between -119 and -60), then you are probably "wanted" and people may be more on the lookout for you.
While if only your nation is hostile (-60), but you personally did nothing to offend them, the game could be more considerate.

-60 is borderline and is the default hostile setting if your nation is at war with theirs, even if you personally haven't done anything. You're not massively hostile at -61. Perhaps define a new value at, say, -90.

A few ideas:
- Have that function return a value > 0.0 only IF you are actually hostile; between Hostile and Friendly, only your Fame counts (as per regular false flag detection chance)
- Determine the detection value based on the average between GetChanceDetectFalseFlag and GetDetectionChance
- Add GetDetectionChance on top of GetChanceDetectFalseFlag only IF you are actually hostile

That last one there doesn't sound half-bad to me.
You'd have a harder time in the early game when your detection chance is low to trade with MASSIVELY hostile nations than with only slightly hostile ones.
This would affect mainly Rebels who start out with REL_MIN to one specific nation.

Something worth considering, I reckon....

The only realistic use for 'GetDetectionChance' is for enemy ships and forts. If your relation is MASSIVELY hostile, i.e. less than -90, then they're actively looking for you. But then, as I said, you're either a Pirate or you've been attacking their ships legally under a LoM, earning fame, and becoming more visible for the normal 'GetChanceDetectFalseFlag' anyway. Meanwhile, traders aren't actively looking for you, it's not their job, and they can't see your flag anyway from inside their shops. So they only need to check against fame, i.e. 'GetChanceDetectFalseFlag'.

 

[Pieter Boelen]

That's the problem with using 'GetNationRelation(PERSONAL_NATION, mNation)' as the check rather than 'GetRMRelation(GetMainCharacter(), mNation)'. The former is for nations and determines whether their ships shoot at each other (hostile), whether one will hate you if you attack the other (allied) or whether they just leave each other alone (neutral). The latter deals in detail with how they view you. So if you want to distinguish between "Wary" and "Hostile", that's the one to use.

Very true. Maybe it would indeed be better to use nested if-statements based on the 'float relation points'.

When does PERSONAL_NATION become RELATION_FRIEND to another nation?

Come to think of it, I'm not sure if it ever does. I'd have to check nations.c to be sure.
If it doesn't, would you reckon it makes sense to change it so that it DOES if you are personally Friendly with that nation (eg. GetRMRelation returns 0.0 or higher)?

I had the same idea, and was going to post a slightly modified version of the one I posted earlier, replacing 'rel = REL_NEUTRAL;' with 'rel = GetNationRelation(pNation, mNation);'.

As you want the 'float points' and not the 'int relation', you would need this:

RelationToRMRelation(GetNationRelation(pNation, mNation))

That is functionally equivalent to:

rel = RelationToRMRelation(GetFlagRMRelation(mNation));

Because 'pNation' is equal to GetCurrentFlag() , I used that second one in my rewrite to make it clearer that it is based on FLAG.

-60 is borderline and is the default hostile setting if your nation is at war with theirs, even if you personally haven't done anything. You're not massively hostile at -61. Perhaps define a new value at, say, -90.
[...]
If your relation is MASSIVELY hostile, i.e. less than -90, then they're actively looking for you.

I wasn't saying that you're "massively hostile at -61".

What I propose is a gradual change: At "60" you are only just barely hostile and -119 is where you are truly massively hostile.
That is why I figure that GetDetectionChance should return 0.0 at "60" and 1.0 at "-119".

This only occurred to me today, so the version I wrote yesterday doesn't actually do that yet.
Should be a relatively simple change though.

The only realistic use for 'GetDetectionChance' is for enemy ships and forts.

I was wondering about that... If we do add that, maybe it should affect only navy ships and not merchant ones?

But then, as I said, you're either a Pirate or you've been attacking their ships legally under a LoM, earning fame, and becoming more visible for the normal 'GetChanceDetectFalseFlag' anyway.

That is true. Though I imagine it would be possible to be famous without being massively hostile or you might be massively hostile without a huge fame.

Meanwhile, traders aren't actively looking for you, it's not their job, and they can't see your flag anyway from inside their shops. So they only need to check against fame, i.e. 'GetChanceDetectFalseFlag'.

I was thinking about "an increased number of (unseen) Wanted posters".

This is along the lines of the simple "dangerous" locations I implemented many years ago for @Bartolomeu o Portugues' storyline.
He added REAL "Wanted" posters there with Bartolomeu's portrait on them and there may be instant hostility in those areas because people are on the lookout for you.
What I would somehow like to do is to implement that as a more general gameplay element that isn't linked to just one storyline.

I figure that being more hostile could function as some sort of "negative fame"/notoriety.
So even if you're not famous for positive reasons (eg. your money or your actions as indicated by Fame), stories about your hostile actions do still go round.
Moreso if you are more hostile.

Implementing such logic here and there would also help to make a difference between "-60" and "-119" because right now that doesn't mean anything.
Hostile = hostile, which doesn't sound entirely right to me....

 

[Grey Roger]

Maybe there is a mismatch between the function that determines the "display reputation name" and the actual reputation definitions.
That doesn't help. Could you please make a Bug Tracker entry for that? Then I'll see if I can figure out why that happens.

No need. I think I have it. As you're working on "CharacterUtilite.c", you'll need to make the relevant change because if I do it, you'll end up with my version of "tradecheck" again.
Here's the problem:

string GetReputationName(int reputation)
{
// KK -->
   int delta = roundup(makefloat(REPUTATION_MAX - REPUTATION_MIN + 1) / makefloat(REPUTATION_TABLE_SIZE));
   int rep = makeint(makefloat(reputation) / makefloat(delta));
   return ReputationTable[rep];
// <-- KK
}

REPUTATION_MAX, REPUTATION_MIN and REPUTATION_TABLE_SIZE are all defined in "characters.h" as 89, 1 and 9 respectively, which means delta is going to end up as 10. So if your reputation is 60, rep = 60/10 = 6, so your reputation is ReputationTable[6], which is "Matey". Change the calculation for rep:

int rep = makeint(makefloat(reputation) / makefloat(delta) - 0.5);
if (rep < 0) rep = 0;          // Needed because reputation < 5 will give rep < 0

Either that or just knock 5 off all the reputation value definitions in "characters.h" so that "Matey" is 60, for example.

Does that crash still happen? I know that was reported before, but as far as I understood, it was fixed.
If it is still a real bug, it needs a Bug Tracker entry! Otherwise nobody capable of fixing it will know that it still needs fixing.

It's a real bug, alright. Just go into "Enc_Walkers.c", find the line 'switch(chance)', and right above it add 'chance = 10';. For good measure, down at case 10, replace 'if (11 < Rand(19))' with 'if (-1 < Rand(19))'. Then every walker you meet will want to become an officer, which should see you bitten by the bug pretty soon.

At the moment BOTH those sections of code are sort-of intentionally commented out.
However, random characters don't get assigned most of the normal random officer types.
That is why the "Enc_Walkers" you can hire can be Sailors and Pirate Sailors and stuff like that.

No they can't, as both the options to assign them a type are commented out. There does seem to be some default behaviour because sometimes it doesn't crash and then you get a "Fighter" type.

Levis wants it that way so you can get such "odd" officer types, but I've got to admit I am not quite sold on it myself.
I'd much rather have hireable officers have only normal, REAL offier types.

I don't much care either way, but what is important is to have a system which works. The system to give odd officer types didn't.

Eventually I'd like to see "Enc_Walker" thoroughly modified so that characters' officer types are defined FIRST and then based on the defined type, different dialog options would be available.
This would mean that if you never talked to a character and start the dialog, the response won't be 100% random but will always be appropriate for that type of character.
The intention was to do that after Beta 4 has been released though, because it does risk breaking stuff for a while that currently isn't broken.
There is also the complexity of having character models and officer types somehow linked here as well, because it seems wrong for a towngirl to be a hireable officer type.

Anyway, that is just stuff for the future. In the meantime, if indeed the CTD still happens, make a Bug Tracker entry, ideally with a savegame.

A savegame won't do any good. If it's before you've talked to the walker, his type has yet to be determined - talker, beggar, item trader, sneaky trader, recruit, etc. If it's after you've talked to the walker, either he wasn't an officer, the game crashed, or you got lucky and hired a Fighter. Nor do log files give any clue.

Or you use this version of "Enc_Walker.c", which has the original system uncommented, in which case you can hire non-fighter officers. And then put it in "Build Testing List", not "Bug Tracker".

 

[Pieter Boelen]

No need. I think I have it. As you're working on "CharacterUtilite.c", you'll need to make the relevant change because if I do it, you'll end up with my version of "tradecheck" again.
Here's the problem:

string GetReputationName(int reputation)
{
// KK -->
int delta = roundup(makefloat(REPUTATION_MAX - REPUTATION_MIN + 1) / makefloat(REPUTATION_TABLE_SIZE));
int rep = makeint(makefloat(reputation) / makefloat(delta));
return ReputationTable[rep];
// <-- KK
}

REPUTATION_MAX, REPUTATION_MIN and REPUTATION_TABLE_SIZE are all defined in "characters.h" as 89, 1 and 9 respectively, which means delta is going to end up as 10. So if your reputation is 60, rep = 60/10 = 6, so your reputation is ReputationTable[6], which is "Matey". Change the calculation for rep:

int rep = makeint(makefloat(reputation) / makefloat(delta) - 0.5);
if (rep < 0) rep = 0; // Needed because reputation < 5 will give rep < 0

Either that or just knock 5 off all the reputation value definitions in "characters.h" so that "Matey" is 60, for example.

You can do it and post the file; I'll use WinMerge to copy the relevant differences anyway.

The TradeCheck function I wrote yesterday isn't exactly definitive either; that was more of an experiment.
So change and post away!

A savegame won't do any good. If it's before you've talked to the walker, his type has yet to be determined - talker, beggar, item trader, sneaky trader, recruit, etc. If it's after you've talked to the walker, either he wasn't an officer, the game crashed, or you got lucky and hired a Fighter. Nor do log files give any clue.

Cheers!

I moved the rest of my post here instead: Confirmed Bug - Crash After Looking at Walker Skills | PiratesAhoy!

 

[Grey Roger]

Very true. Maybe it would indeed be better to use nested if-statements based on the 'float relation points'.

Yes, that ought to do it.

Come to think of it, I'm not sure if it ever does. I'd have to check nations.c to be sure.
If it doesn't, would you reckon it makes sense to change it so that it DOES if you are personally Friendly with that nation (eg. GetRMRelation returns 0.0 or higher)?

It doesn't really matter if you're going to use nested if-statements based on character relation for "tradecheck". Elsewhere, ships only need to know one thing - are you hostile? If so, they'll fire; if not, they won't.

I wasn't saying that you're "massively hostile at -61".

I figured that if you're MASSIVELY hostile (between -119 and -60), then you are probably "wanted" and people may be more on the lookout for you.

-61 is between -119 and -60.

What I propose is a gradual change: At "60" you are only just barely hostile and -119 is where you are truly massively hostile.
That is why I figure that GetDetectionChance should return 0.0 at "60" and 1.0 at "-119".

And why I suggested starting at -90, which is where you've done enough damage that they now regard you as a major threat and are actively looking for you, as opposed to just checking any ship which might be flying a false flag.

I was wondering about that... If we do add that, maybe it should affect only navy ships and not merchant ones?

Makes sense. They're the ones whose captains may have been given specific orders to find you.

I was thinking about "an increased number of (unseen) Wanted posters".

This is along the lines of the simple "dangerous" locations I implemented many years ago for @Bartolomeu o Portugues' storyline.
He added REAL "Wanted" posters there with Bartolomeu's portrait on them and there may be instant hostility in those areas because people are on the lookout for you.
What I would somehow like to do is to implement that as a more general gameplay element that isn't linked to just one storyline.

It won't be linked to just one storyline for much longer. I already knew about that one, having played "Bartolomeu" and found out why I was attacked by random civilians who wouldn't normally be thugs, and duly pirated it, which is why you're going to see this in "quests_reaction.c" for "Ardent" when I get the next bit in a state to be uploaded:

       Locations[FindLocation("Santiago_Town_01")].dangerous = true;
       Locations[FindLocation("Santiago_port")].dangerous = true;

I figure that being more hostile could function as some sort of "negative fame"/notoriety.
So even if you're not famous for positive reasons (eg. your money or your actions as indicated by Fame), stories about your hostile actions do still go round.
Moreso if you are more hostile.

Of course, if you ever get round to having number of ships sunk/captured factor into fame for privateers and naval officers...

 

[Pieter Boelen]

-61 is between -119 and -60.

I meant sort-of halfway between. Anyway, I'll admit my wording was ambiguous. Hopefully you understand my meaning better after my explanation.

And why I suggested starting at -90, which is where you've done enough damage that they now regard you as a major threat and are actively looking for you, as opposed to just checking any ship which might be flying a false flag.

Definitely a possibility. But would that be better or worse than the gradual approach that I suggested?
I like the idea that "one more point" does actually make a small difference. Otherwise it is very black/white.

It won't be linked to just one storyline for much longer. I already knew about that one, having played "Bartolomeu" and found out why I was attacked by random civilians who wouldn't normally be thugs, and duly pirated it, which is why you're going to see this in "quests_reaction.c" for "Ardent" when I get the next bit in a state to be uploaded:

Locations[FindLocation("Santiago_Town_01")].dangerous = true;
Locations[FindLocation("Santiago_port")].dangerous = true;

Then you're familiar with the reasoning behind it.
That particular code is VERY old though. Maybe 5 years or more.

Of course, if you ever get round to having number of ships sunk/captured factor into fame for privateers and naval officers...

Might even be quite easy to do that. But I'm not sure if we should want that, because "Fame" is a general number and "ships sunk" only goes UP.
If we include my proposed gradual approach where appropriate, then we would have an alternate version that sort-of covers the same logic BUT is nation-dependent and can go down as well as up.

 

[Grey Roger]

You can do it and post the file; I'll use WinMerge to copy the relevant differences anyway.

The TradeCheck function I wrote yesterday isn't exactly definitive either; that was more of an experiment.
So change and post away!

Done.

 

[Pieter Boelen]

Done.

Thanks!

 

[Grey Roger]

Definitely a possibility. But would that be better or worse than the gradual approach that I suggested?
I like the idea that "one more point" does actually make a small difference. Otherwise it is very black/white.

Black/white is perhaps more realistic. The French Admiralty wouldn't say "Captain Nelson sunk one of our ships today. Instruct all our captains to look a little bit harder for him." But they might one day say "This Captain Nelson has sunk a lot of our ships. Instruct all our captains that hunting him down is a major priority as of today."

Might even be quite easy to do that. But I'm not sure if we should want that, because "Fame" is a general number and "ships sunk" only goes UP.
If we include my proposed gradual approach where appropriate, then we would have an alternate version that sort-of covers the same logic BUT is nation-dependent and can go down as well as up.

And we're back to historical figures who made a name for themselves by sinking a lot of ships and are still famous today. Fame of that sort should stick. It doesn't need to be nation-dependent. What is nation-dependent is what the nations do based on that fame. Friendly nations love you, enemy nations hate you, neutral nations probably don't care about the military implications but have still heard of you. So friendly nations might do something nice e.g. access to governors' nieces, hostile nations do something nasty e.g. being more likely to recognise you, and neutral nations don't do anything so it doesn't matter.