Jackal Tapes Fix (#09. Stealing Boots Glitch)

Treatment of bug where all tapes from second Southern map (Bowa-Seko) would play the same record #09 – “Stealing Boots”

Insanity

Did I ever tell you what the definition of insanity is? Insanity is doing the exact… same f***ing thing… over and over again, expecting… s**t to change. Insanity is when you pick up another Jackal Tape expecting of hearing something further than “Stealing Boots”. No, no, no, no, no, please! This time it’s gonna be different record!

Insanity is when a bug is not fixed for 10 years.

На русском:
https://steamcommunity.com/sharedfiles/filedetails/?id=1563607715

Signs and symptoms

With v1.03 update, a bug was introduced that does not allow to listen and does not mark as taken the tapes from the second Southern map (Bowa-Seko) further than #09 “Stealing Boots”. The first picked up tape on this map is written as #09 “Stealing Boots”, and all subsequent tapes on the same map will simply repeat it, forcing to listen again and again as Jackal tells a sad story about a kid stealing boots from a dead soldier.

Causes

During the game, a list of 17 tapes is kept in memory, in which, among other things, the following information is noted:

Figure 1. Illustration of a list of tapes in memory. The IsTaken field is filled in for example. The FromMap1 field is always filled like this.

The picture above shows 17 tapes. Number 00 is a tape given by Reuben Oluwagembi at the beginning of the game, the rest are scattered around the world. The field IsTaken will be set with “1”, marking tape as picked up. The field FromMap1 is pre-populated when the game (or save) is loaded, marking with the “1” all tapes from the first north map (Leboa-Sako).

When the next voice recorder is picked up, the NewJackalTapeFound subroutine is triggered in the game engine. Tapes from the list are checked one by one for: whether it is marked as taken, and to which map it belongs. Finally, depending on which map you are standing on now, the decision is made: to play the tape and mark it as picked up or look further down the list.

It's simple. Look at this correctly working scheme from the versions of the game from 1.00 to 1.02:

Figure 2. The correct logic of the NewJackalTapeFound subroutine. Green - YES. Red - NO.

Note that if the “Tape Taken” check shows that this tape is marked in the list as picked up, it immediately goes along the green arrow to the next one in the list (Next). According to this logic, tapes from 00 to 08 will be played (and marked) only if you picked up a voice recorder on the first map, and tapes from 09 to 16 - only if on the second.

After update 1.03, the subroutine logic has changed a bit:

Figure 3. Incorrect logic of the NewJackalTapeFound subroutine after update 1.03

Notice where the green arrow goes from “Tape Taken” check. Suppose that we passed into the second act, we are standing on the second map and the situation with the tapes we have as in the table above: three were found on the first map (two plus one from Reuben), and one was found on the second map. Next time, when on the second map we pick up the voice recorder, the first three tapes (00-02) will follow the path:

Tape Taken --> YES --> 1st  Map --> NO --> Tape from 2nd Map --> NO --> Next

Tapes 03-08 will follow the path:

Tape Taken --> NO --> 1st  Map --> NO --> Tape from 2nd Map --> NO --> Next

But tape 09, despite the fact that it has already been marked as taken, will follow the path:

Tape Taken --> YES --> 1st  Map --> NO --> Tape from 2nd Map --> YES --> PLAY

Here is the glitch!

All other changes in the scheme miraculously did not affect the logic. Even if you simply return the green arrow from “Tape Taken” back to “Next”, everything will work as it should.

This error is another confirmation of the statement “If it ain't broken, why fix it”. Perhaps, during some refactoring of the NewJackalTapeFound method, some brackets were put in wrong place of the source code, and the logic changed.

Treatment

To eliminate the error, it is actually enough to change just one byte in the Dunia.DLL file to turn the logic of the subroutine in the right direction.

In order not to change the file physically, I recommend using the utility to start the game with various fixes right in the process memory. Read more:
https://steamcommunity.com/sharedfiles/filedetails/?id=1620638035

Self-medication

If you are confident in what you are doing and are familiar with hex editors, then this is what you need to do.

1. Find where the game is installed - the desired file is located in the BIN subfolder.
   
2. Of course, make a backup copy of the Dunia.DLL file, just in case.
   
3. Then open the file and find the following sequence of bytes:
   

   0A 3B CA 75 0A

4. If found, then, to be completely sure, check that for the Steam-version the file size is equal to 20183176 bytes, and the desired sequence was found at offset 0x0074D865, or for the Retail-version size is 19412104 and offset is 0x00740355.
   
5. Change the first byte of the sequence from 0x0A to 0x14. Now it should look like this:
   

   14 3B CA 75 0A

Visit doctor

Those who do not want to bother with manually editing the file can try an easy-to-use patcher:

https://github.com/FoxAhead/Far-Cry-2-Stealing-Boots-Jackal-Tapes-Patcher/releases/latest

Download and run the file FarCry2StealingBootsJackalTapesPatcher.exe. Use the Browse button to select the Dunia.DLL file. Click Patch!



On the start, the program will try to automatically determine the installation path of the game, so the Browse button should immediately take you to the desired folder, and all that remains is to select the Dunia.DLL file. Before applying the patch, the program checks the file, and if everything is OK, then the Patch! button below will be enabled to click. The backup will be created automatically as soon as you confirm patching. If at any of the stages something goes wrong, the program will report that.

The patcher searches for a suitable pattern of bytes using mask, so theoretically it is able to correct the subroutine even in some exotic Dunia.DLL file (other size, other addresses), provided that there really is an erroneous subroutine.

Prognosis

The final recovery can be considered only if, before applying the patch, you picked up no more than one tape on the second map. Otherwise, all subsequent picked up tapes simply disappeared irretrievably, without appearing in the list. In this case, look for an earlier save. Or ... why not replay the game?

P.S.

Did I ever tell you
what the definition
of insanity is?

[StocKaticUs]

Thank you again!

[Jamie]

imagine doing all this just to play a videogame.

[SmellofNapalm]

Thanks, hopefully the patcher works retroactively, but it's useful to know anyway.

[BEowyn]

ITS ON

[.P 3 i N 3 R]

Dude thank you very much, I dont understant a thing of hex editors but with one I found online directy on the browser I was able to edit the file and made it work. Thank you so much for the help.

[fujikun0331]

thank you!!!!!!

[josh]

Amazing work! And especially thank you for the description for the problem. I was always very curious as why the bug occurred and it's crazy to think just a single byte change was the problem.

[Razzle666]

Thanks for fix,it was easy to use and it take only 30 seconds to do it. It said that pach succeed, I think it should work now. I don´t know why Ubisoft didn´t try fix this 10 years ago. Hope I finally get all tapes, or now I got reason to collect them all instead of that endless repeating insanity. When I play this 10 years ago that stealing boots tape almost make me insane.

[FoxAhead]

I think as long as you don't get money from this hobby, you don't have to pay thousand of $. There are a lot of options to get full version fo free.

[vlastovka]

Nice. I used to hack OS/2 more than 20 years ago when I was young and still rather capable. Its API was way cleaner and better documented than Win32. It is such a shame IBM ditched the OS.

I have one more question :) Was the free IDA enough for your needs or have you bought the full version?