Unconfirmed Bug Mutiny problem

[Grey Roger]

Mutineers steal some of your gold. Looting dead mutineers just means you get back what you already had before the mutiny.

These ones are rich because I used cheatmode to give myself lots of free money to encourage mutinies.

 

[DavyJack]

Mutineers steal some of your gold. Looting dead mutineers just means you get back what you already had before the mutiny.

These ones are rich because I used cheatmode to give myself lots of free money to encourage mutinies.

I see. Lol. So, the bug only happens when a certain quest is triggered then-- in the Woodes Rogers Storyline?

 

[Grey Roger]

Cracked it!

The problem is with officers. The mutiny code checks all your passengers; any whose reputation is better than "Swindler" may join in the fight on your side. If there aren't enough loyalists from there, some loyal crew are spawned as fantoms. Any officer whose reputation is "Swindler" or lower may join in as a mutineer, in which case he is killed and replaced by a clone fantom; again, if there are not enough mutineers, some crew are spawned as fantoms.

It is that replacement of the rotten officer with a clone that is causing the trouble, which is why my savegame has no problem - none of my officers are evil enough. If I use cheatmode to turn one of them into "Horror of the High Seas", the bug strikes.

This is the line which creates the clone fantom:

chr = LAi_CreateFantomCharacterEx(true, 0, true, true, 0.25, model, ani, chLocType, chLocLoc + pos);

As far as I can tell from looking at old files, 'LAi_CreateFantomCharacterEx' used to take "ani" as an argument. It was changed to not take "ani" round about the time we switched from Beta 4 to Beta 4.1, early in 2016. Almost all 'LAi_CreateFantomCharacterEx' calls were changed to remove the "ani" argument, but for some reason this one was missed. I don't know why it doesn't trigger a game-breaking error; syntax errors usually do. Instead, 'LAi_CreateFantomCharacterEx' gets confused and uses the "ani" argument for the model, which is why this shows up in "system.log":

resource\models\characters\man.gm: can't open geometry file
Character model 'characters\man' not loaded

"man" is an animation, not a character model.

The solution: get rid of "ani" in that line. The result:


By the way, the reason I have a visible sword is that I copied "RESOURCE\MODELS\Ammo\OtherItemsJRH\bladeA4.gm" into "RESOURCE\MODELS\Ammo".

Attached is "PROGRAM\Loc_ai\LAi_mutiny.c" with the offending line corrected.

@Jack Rackham: location "mutiny_deck" is indeed a "Woodes Rogers" quest location, but it's also a standard location defined in "PROGRAM\Locations\init\boarding.c":

    // ID
   Locations[n].id = "MUTINY_Deck";
   Locations[n].id.label = "Boarding deck";
   n = n + 1;

This one has no attributes because function 'MutinyDeck_Start()' in "LAi_mutiny.c" copies it from whichever quarterdeck is appropriate to your ship. I don't know whether having two locations with the same ID will cause trouble. Certainly if you ever use your own version again after the start of the storyline, and if there's been a mutiny, it won't look the same and may not work properly. You may want to rename your quest version to avoid any conflict.

 

[Jack Rackham]

Very good. I'll rename my "mutiny_deck" wherever that id shows up.

 

[Jack Rackham]

Done! Here are the six changed WR files. (to "mutiny_deckWR")

Also the texture file en3.tga. There's a wrong version of en3.tga in the game (again). I've tried to replace it earlier too.

The effect of the wrong en3.tga is that some (imported) weapons and tools get a strange shiny metal look.
(in gm-viewer they look very much darker than normal)

 

[Pieter Boelen]

This is the line which creates the clone fantom:

chr = LAi_CreateFantomCharacterEx(true, 0, true, true, 0.25, model, ani, chLocType, chLocLoc + pos);

As far as I can tell from looking at old files, 'LAi_CreateFantomCharacterEx' used to take "ani" as an argument. It was changed to not take "ani" round about the time we switched from Beta 4 to Beta 4.1, early in 2016. Almost all 'LAi_CreateFantomCharacterEx' calls were changed to remove the "ani" argument, but for some reason this one was missed. I don't know why it doesn't trigger a game-breaking error; syntax errors usually do. Instead, 'LAi_CreateFantomCharacterEx' gets confused and uses the "ani" argument for the model

Wow; that's some serious digging on your part!

Does the wrong function call have the same number use the same number of input arguments as the correct one?
In Matlab/Python, sometimes functions can accept a varying number of input arguments.
But it does still sound weird. Especially if you provide more than it should expect.

@Jack Rackham: location "mutiny_deck" is indeed a "Woodes Rogers" quest location, but it's also a standard location defined in "PROGRAM\Locations\init\boarding.c":

// ID
Locations[n].id = "MUTINY_Deck";
Locations[n].id.label = "Boarding deck";
n = n + 1;

This one has no attributes because function 'MutinyDeck_Start()' in "LAi_mutiny.c" copies it from whichever quarterdeck is appropriate to your ship. I don't know whether having two locations with the same ID will cause trouble.

If I recall, storyline init overrules default init.
But then at the moment of mutiny, the game will probably copy the settings of your ship deck back over.
So either way, you can't be quite sure what you get; especially if you have a different ship than the storyline expects.

 

[Grey Roger]

Does the wrong function call have the same number use the same number of input arguments as the correct one?
In Matlab/Python, sometimes functions can accept a varying number of input arguments.
But it does still sound weird. Especially if you provide more than it should expect.

The wrong function call has one argument too many, namely "ani". The correct version is exactly the same but with "ani" removed. (One correct line even has a double space where someone deleted "ani," but not the extra space next to it.) If functions are allowed to take varying numbers of input arguments then that explains why it didn't crash the game with a syntax error, which is why the bug has remained undetected for so long - it only strikes if you have a mutiny and have an officer with a really bad reputation.

What worries me now is that the code to scan your passengers for officers with bad reputations skips any who are also companions (in case of officers like Danielle who are both passenger and companion), it skips anyone who doesn't have a "quest.officertype" attribute, but it does not specifically check if the character is removable. The code to scan your passengers for loyal officers to join your side doesn't even check "quest.officertype". So it may be possible for a quest character to get involved in a mutiny on one side or another, and possibly get killed in the fight, even though that character should not normally be able to appear.

The obvious countermeasure is to add lines to skip anyone marked as unremovable - except that this would probably break the very mutiny which started this thread. I'm guessing from the fact that it happens while your crew morale is good that it's somehow related to the "Woodes Rogers" storyline, even though "compile.log" doesn't show any quest cases being triggered. Israel Hands and Ignatius Pell are both storyline characters, they both have evil enough reputation to become mutineers, and they're both unremovable. The only safe solution I can think of is to define another attribute, perhaps call it "can_mutiny", and skip the check for removable if that is set.

 

[Grey Roger]

Also the texture file en3.tga. There's a wrong version of en3.tga in the game (again). I've tried to replace it earlier too.

The effect of the wrong en3.tga is that some (imported) weapons and tools get a strange shiny metal look.
(in gm-viewer they look very much darker than normal)

GM Viewer can't be trusted with weapons. Weapons use different special effects from other models, but GM Viewer treats them all the same. So a lot of swords are either partly or totally invisible in GM Viewer, e.g. "bladeBP".

The version of "en3.tga" which you posted is the old version which is included in the May 2018 installer, so all I need to do to restore that is remove it from the update archive. However, I can't see a problem with it. GM Viewer shows "en3.tga" to be used in "battleax" and "LongRifle_C". Here's "battleax" - old "en3.tga" on the left, new "en3.tga" on the right:

The blade does indeed have a slight metallic finish, which is reasonable as it's supposed to be metal. My guess is that this is how it's supposed to look. When an object which uses it is on screen, and the old version of "en3.tga" is in place, this appears in "system.log":

Can't loading cubemap mip 0 (side: 2), not loading it.
Cube map texture resource\textures\AMMO\EN3.TGA.tx can't loading (size: 64, num mips: 6, format: D3DFMT_A8R8G8B8), not loading it.

That, in fact, is why I created the new version of "en3.tga". No such message appears when the new version is in place. So I reckon that the reason the battleaxe does not have a metallic head with old "en3.tga" is simply that "en3.tga" fails to load at all.

"LongRifle_C" does have a problem, though it's probably nothing to do with "en3.tga". Here are pictures of it lit by sunlight (left) and in shadow (right):

Now look at my character and his shadow. The rifle is lit on the wrong side. I've seen this before on some ship models which I tried to import from GoF. If I remember correctly, when I reported them, the answer was that the only way to fix them was to re-make them in Maya. The same is probably true for this rifle.

The other item which uses "en3.tga" is "OtherItemsJRH\bladeirontool". If you want this to use the old version of "en3.tga", one way would be to hex-edit it to change "en3" to something else, then copy the old "en3.tga.tx" and rename it to match.

 

[Pieter Boelen]

The wrong function call has one argument too many, namely "ani". The correct version is exactly the same but with "ani" removed. (One correct line even has a double space where someone deleted "ani," but not the extra space next to it.) If functions are allowed to take varying numbers of input arguments then that explains why it didn't crash the game with a syntax error, which is why the bug has remained undetected for so long

Have to admit, variable number of input arguments is not something I ever encountered on the PotC side before.
So it's still weird...

What worries me now is that the code to scan your passengers for officers with bad reputations skips any who are also companions (in case of officers like Danielle who are both passenger and companion), it skips anyone who doesn't have a "quest.officertype" attribute, but it does not specifically check if the character is removable. The code to scan your passengers for loyal officers to join your side doesn't even check "quest.officertype". So it may be possible for a quest character to get involved in a mutiny on one side or another, and possibly get killed in the fight, even though that character should not normally be able to appear.

I'd say characters showing up should be following the same rules in mutinies as in regular boardings.

The only safe solution I can think of is to define another attribute, perhaps call it "can_mutiny", and skip the check for removable if that is set.

Can the "sit out boardings" attribute be used instead?

The rifle is lit on the wrong side. I've seen this before on some ship models which I tried to import from GoF. If I remember correctly, when I reported them, the answer was that the only way to fix them was to re-make them in Maya. The same is probably true for this rifle.

Swapped lighting direction is often caused by TOOL-saved GMs.
Especially if the geometry is changed.

 

[Grey Roger]

Confirmed: at present, non-removable characters who aren't supposed to appear on deck can appear in a mutiny scene. As a test, I started off as a French corsair (LoM to trigger mutiny if you have millions and don't share, French to start on Martinique). Cheatmode gave me a load of free money and a quick trip to the tavern followed by the store gave me Sabine Matton as a passenger. She didn't join in the fight because she's still in 'LAi_SetStayType' mode, but she's certainly there in the mutiny scene:

Can the "sit out boardings" attribute be used instead?

No, the reason being that there could be an evil quest officer who is allowed to join in regular boardings, but who must not be killed and cloned as a mutineer. (I'm not sure if Nigel Blythe is allowed to join in boardings by default. If so, he's a prime candidate.) Alternatively, you could have a quest officer who must not join in regular boardings but who is allowed to mutiny.

 

[Kara Korsan]

I'm not sure if Nigel Blythe is allowed to join in boardings by default. If so, he's a prime candidate.

I remember having a lot of trouble keeping him out of harm's way. Yeah, he's a definitely a boarder.

 

[Pieter Boelen]

No, the reason being that there could be an evil quest officer who is allowed to join in regular boardings, but who must not be killed and cloned as a mutineer.

Why not? If a quest character must not be killed, does it matter if the killing happens during a boarding or a mutiny?

Or you mean that the killing technically happens BEFORE the mutiny?
And you'd be forced to effectively kill all your evil quest officers...

 

[Grey Roger]

A quest character who is not allowed to be killed during routine operations will probably be immortal. If his clone is immortal as well, you're not going to win the mutiny battle...

The killing happens right at the mutiny start - the mutiny code kills the character before cloning him. You might not need to kill clones of all your evil officers, quest or otherwise, because the code doesn't necessarily put them all on deck. It figures out how many mutineers there should be and starts by looking for officers to use. If it only needs 2 mutineers and you have 3 evil officers, it will take 2 of them. (The code's idea of an officer is a passenger with a "quest.officertype" attribute. The search for not-evil officers to join you doesn't check that, but even if it did, Sabine Matton would still be picked because she has 'ch.quest.officertype = OFFIC_TYPE_SHOPKEEPER;')

 

[Pieter Boelen]

A quest character who is not allowed to be killed during routine operations will probably be immortal. If his clone is immortal as well, you're not going to win the mutiny battle...

Oh crap!

 

[Jack Rackham]

I happened to test sledgehammer from OtherItemsJRH and it had that shiny metal look. So I swithched back the en3 to make it look ok.
Can't say why the battleaxe is ok with the new version.

About GM-viewer: some weapons may look very dark but still ok in the game. (I think pistol13 is an example)
But those that look like shiny metal in the game will certainly look dark too in the GM-viewer.

I have tested bladeirontool with the en3 I uploaded and it's ok in game so I don't have to do anything.

 

[Grey Roger]

I'd prefer to keep the new "en3.tga.tx", partly because the battleaxe looks better, and partly to stop the error messages in "system.log".

A bit of cheating with "console.c" gave me the sledgehammer and iron tool right at the start of "Woodes Rogers", so I could see the problem. After I'd hex-edited both "bladeirontool.gm" and "sledgehammer.gm" to use a non-existent "enX.tga.tx", they look right. There are still errors in "system.log" about the missing file, but at least there are no errors in the wider game resulting from the battleaxe.

Attached: new versions of "bladeirontool.gm" and "sledgehammer.gm". If you find any other tools which look too shiny, I can do the same to them (or you can do it).

 

[Jack Rackham]

That's ok with me.