Included in Build Random Hireable Officers Get Appropriate Types

[Jason]

Sometimes, so far 1-4, when you encounter a random officer and ask how good he is you get the CTD.

 

[Pieter Boelen]

Sometimes, so far 1-4, when you encounter a random officer and ask how good he is you get the CTD.

In that case, please make a save prior to talking to these random officers. If you get one that crashes, reload your save and see if it crashes again.
If you can consistently replicate it, be sure to post that save on the forum. And even if not, post the compile.log and possible error.log .
You might also want to enable all the DEBUG toggles at the top of PROGRAM\Characters\Leveling.c .

To be clear, are these the characters randomly walking around? Or tavern officers?

 

[Jason]

I did reload a save prior to the encounter and of course since the encounter is random I did not see the officers. To be clear they are not tavern officers. The are walking around outside

 

[Pieter Boelen]

I did reload a save prior to the encounter and of course since the encounter is random I did not see the officers. To be clear they are not tavern officers. The are walking around outside

Any log files then at least?

 

[Grey Roger]

Copy your existing "PROGRAM\DIALOGS\Enc_Walker.c" somewhere safe. Put this in its place. That ought to make testing encounters with random officers in the street a lot easier - if I've done this right, all random walkers should now want to be your officer.

Once you have enough evidence, enough officers, or just want to meet someone else for a change, put back your original "Enc_Walker.c".

 

[Jason]

Any log files then at least?

Yes

 

[Pieter Boelen]

Yes

That is a VERY strange error.log file.
This points to a COMMENT line:

RUNTIME ERROR - file: Loc_ai\LAi_events.c; line: 3376
invalid index -1 [size:1000]
RUNTIME ERROR - file: Loc_ai\LAi_events.c; line: 3376
process event stack error

And that falls outside the actual file:

RUNTIME ERROR - file: battle_interface\BattleInterface.c; line: 720
process event stack error
RUNTIME ERROR - file: battle_interface\BattleInterface.c; line: 720
function 'Event' stack error

Happens sometimes though when there is a clear code error.
Unfortunately the message about that error subsequently isn't clear, which doesn't help.

To be clear, were these log files for the CTD or those French soldiers attacking when they shouldn't?

 

[Grey Roger]

That is a VERY strange error.log file.
This points to a COMMENT line:

RUNTIME ERROR - file: Loc_ai\LAi_events.c; line: 3376
invalid index -1 [size:1000]
RUNTIME ERROR - file: Loc_ai\LAi_events.c; line: 3376
process event stack error

Not in the version of "LAi_events.c" which I can find in the 24th January zip update. Line 3376 is this:

           corpse = CharacterFromId(chr.id);
           LAi_group_MoveCharacter(corpse, LAI_GROUP_CORPSES);
           //MAXIMUS: makes box from corpse with hand-icon in the top-left corner -->
           locNum = 1;
           corpseLoc = &Locations[FindLocation(corpse.location)]; <-- This is line 3376

And that falls outside the actual file:

RUNTIME ERROR - file: battle_interface\BattleInterface.c; line: 720
process event stack error
RUNTIME ERROR - file: battle_interface\BattleInterface.c; line: 720
function 'Event' stack error

Happens sometimes though when there is a clear code error.

Line 720 in the 24th January version is a '}' which marks the end of the definition of 'void RefreshBattleInterface(bool CheckRelations)'.

 

[Pieter Boelen]

So what's the latest news on this one? @Jason, have you had this recently now? How about anyone else?

If we don't get word on this by the end of the week, I'll archive it as "Cannot Confirm".

 

[Pieter Boelen]

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.

Thanks for the confirmation. It was indeed reported before, but I thought it was already fixed again.
Anyway, reopened now.

 

[Pieter Boelen]

Continued from: Planned Feature - Encourage Play for Evil Characters | Page 3 | PiratesAhoy!

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.

Thanks for the confirmation. It was indeed reported before, but I thought it was already fixed again.
Anyway, reopened now.

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.

Assuming that everything works as intended, EVERY single character in the game does get an officer type assigned.
That is what it supposed to be happening anyway.

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.

Very true.

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".

Out of curiosity, did you try uncommenting this line already?

NPChar.quest.officertype = GetRandomOfficerType();

I can think of no reason why that wouldn't work equally well.

But anyway, I'll test it for sure and see what happens. I do believe some changes are in order....

 

[Pieter Boelen]

@Grey Roger: I just looked at the GetRandomOfficerType() function and my first impression is that it should be OK to use here.

But I don't know if character skills are reassigned AFTER that or not.
If those are done before, then you'd get the correct type, but not the corresponding skills.

 

[Grey Roger]

The easy way to check, as I suggested earlier, is to nobble "Enc_Walker.c" so that all walkers are officers, then see whether the recruits crash the game, are silly officer types (e.g. all fighters), or are a reasonable spread of types. You can find a suitably nobbled version up here, though you'll need to do a bit of WinMerging to get the guaranteed officer code merged with any more recent fixes such as uncommenting one or other of the officer type selection codes, plus my changes to reputation gains from walkers.

 

[Pieter Boelen]

The easy way to check, as I suggested earlier, is to nobble "Enc_Walker.c" so that all walkers are officers, then see whether the recruits crash the game, are silly officer types (e.g. all fighters), or are a reasonable spread of types. You can find a suitably nobbled version up here, though you'll need to do a bit of WinMerging to get the guaranteed officer code merged with any more recent fixes such as uncommenting one or other of the officer type selection codes, plus my changes to reputation gains from walkers.

Just trying to get the most information I can. Hopefully I can actually look at this over the weekend.
Crashes are generally not a good thing.

 

[Pieter Boelen]

After a bit of looking into this, I made the following discoveries:
- The crash does NOT happen for me, regardless of what code is or isn't enable in "Enc_Walker.c"
- Even when assigning different officer types, apparently the skills are initialized FIRST so skills end up not matching
- I am still getting the weird error.log entry I was getting last time I was checking up on officer types

So the actual bug is something that I cannot seem to confirm for some reason.
But the current situation isn't ideal either. Have to see if I can bring a bit more sense into things....

 

[Pieter Boelen]

So I ended up doing quite a bit here, starting with the creation of this function:

string FindRandomModelOfficerType(string model)
{
   string type = OFFIC_TYPE_CIVILIAN; // Define default NPC type

   int num = 0;
   string validTypes = "";

   string curType = "";
   string nexType = FindModelTypeFromModel(model, num);
   
   while (num == 0 || curType != nexType)
   {
     if(UsableOfficerType(nexType, false))   validTypes = StoreString(validTypes, nexType);
     
     num++;
     curType = nexType;
     nexType = FindModelTypeFromModel(model, num);
   }
   if (validTypes != "") {
     type = GetRandSubString(validTypes);
   }

   return type;
}

That one is now used for a lot of different types of characters in the game and should ensure they all get an officer type assigned that matches with their model.
This is a bit backwards, because it would be much more convenient to set the officer type FIRST and then assign the model.
Unfortunately that isn't always possible, so this will have to do.

So officer types should now be set correctly BEFORE any skills are being assigned so that model, officer type and skills all match.
You can now also only HIRE officers with normal officer types.

Ideally the existing officer types should match with the existing character model groups.
But the PotC code is by now in a general Frankenstein state where everything is cobbled together from different parts and nothing quite matches up together.
Getting everything properly in line would be a HUGE undertaking indeed. As much as I would want to have that done, I don't see it happening.

Anyway, I hope this is an improvement of sorts. At least this one should now REALLY be a thing of the past:
Fixed - Levelling: Strange Occupations | PiratesAhoy!
But still.... despite trying many times, I encountered ZERO crashes related to this. So the original report is "Cannot Confirm".

 

[Grey Roger]

Whereas, by editing "Enc_Walker.c" to always have them want to be officers, I had the game crash approximately 1 in 3 times. I tried 20 walkers with the Maximus lines activated and the Levis line still commented out, then I edited the file to comment out the Maximus lines and activate the Levis line, and for good measure also tried rigging my 8th December version to also always have walkers be officers and tried 20 there. Results were about the same. I'd save game just before talking to the walker so that the same walker eventually completed the dialog successfully without crashing the game.

 

[Pieter Boelen]

Whereas, by editing "Enc_Walker.c" to always have them want to be officers, I had the game crash approximately 1 in 3 times.

So even with your quick-fixes, the game still crashes sometimes?
That is SUPER annoying, because I wasn't able to replicate the problem and therefore also cannot do anything to fix it.

I did make some changes that may or may not affect this. Hopefully it is better now...
If not, the only other thing to be done is to enable all the debug toggles at the top of PROGRAM\Characters\Levelling.c and add Trace lines in the dialog file to see how far the game does get before crashing.

 

[Pieter Boelen]

The function I used for this is pretty cool, but also pretty old and I think was never actually put to good use.
So here's a slight improvement from me for it. Goes in PROGRAM\MODELS\models.c:

string FindModelTypeFromModel(string model, int num)
{
 if(GetModelindex(model) == -1)  return ""; // PB: In case this gets called for a model that isn't defined
 ref mdl; makeref(mdl, Models[GetModelindex(model)]);
 if(!CheckAttribute(mdl, "types")) return "";
 aref mdltypes; makearef(mdltypes, mdl.types);
 int numa = GetAttributesNum(mdltypes);
 if(num >= numa) num = numa-1;
 return GetAttributeName(GetAttributeN(mdltypes, num));
}

Should prevent potential error.log entries.