Posts from Help with fixing the enchanted arrow.

Basically.
I don't like that the enchanted ballista (fixed) depletes the hero's ATB, turning it from a great ability into useless junk.

It needs to be fixed.
The version being used is NCF normal (i.e., the original with 2 changes, which are completely irrelevant in this context).

Link to the fix description - ыыы
It's written for stripped executables, but there's simply no other information.

The file needs to be changed in 7 places. I started checking everything manually.
The original expected data matches for 6 occurrences.

The original expected data does not match here ыыы
99 zeros are expected, but I have:
52 35 0e 37 59 37 88 37 98 37 28 38 78 38 98 38 cb 38 e4 38 3a 39 8e 39 d3 39 ea 39 ef 39 0f 3a 14 3a 61 3a 78 3a 7d 3a 9d 3a a2 3a ec 3a 14 3b 38 3b 80 3b f0 3b 02 3c 2b 3c 53 3c 77 3c c5 3e ce 3e d3 3e e2 3f 00 00 00 40 00 00 a8 00 00 00 3b 30 40 30 bd 30 c2 30 33 31 8f 31 e6 32 39 33 71 33 76

Guessing is not an option; 99 zeros occur 939 times, and I won't find the right one.
How can I make it work correctly?
Maybe someone knows or simply has a link to the correct changes?

I want to fix the Imbue balista exhausting Hero ATB bug. I have a normal NCF exe (Original, that was not modified except the creature's count bytes).
I have only the information "for stripped exe".
The input byte values match 6 offsets. But the 7th offset has other bytes than 99 zeros (above).

How to do this properly? Is there a correct description for the Original?

@dredknight?

And how do I properly tag him on the forum so he sees it?

@vasik, in my opinion, the word "stripped" here should be understood as "trimmed" or even "bare," meaning that it refers to a version reduced to the bare essentials – in other words, the original version without any modifications.
P.S.
I compared the Ubi version (I have a disc version + patch) with the Nival/Buka version – they are identical... because in all 6 instances, everything matches, and in these 6 modifications, there is no redirection to address 00BD90E0
Therefore, we need to clarify with the esteemed comrade dredknight what kind of version they were tinkering with!
Although something tells me that this was specifically related to MMH55... in general, in the .exe RC14_B6 at this address, there are no zeros, and not even
8B 54 24 1C 8D 4C 31 04 56 51 50 89 CE 8B 86 E8
FE FF FF 8B 48 08 8D 8C 31 E8 FE FF FF 2B 49 FC
83 E9 68 8B 41 90 A3 24 61 13 01 8B 40 1C A3 28
61 13 01 58 59 5E C3 90 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 56 8B 35 24 61 13 01 A1 28 61 13 01 89 46 1C
5E 58 C3
but this -
8b 54 24 1c 8d 4c 31 04 51 56 50 2b 49 fc 89 ce
8b 86 ec fe ff ff 8b 48 08 8d 8c 31 ec fe ff ff
2b 49 fc 83 e9 68 90 90 90 8b 41 94 90 90 90 89
c1 a3 24 61 14 01 8b 40 1c a3 28 61 14 01 58 5e
59 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 56 8b 35 24 61 14 01 a1 28 61 14 01 89 46 1c
5e 58 c3

the thing is, the 7th patch is necessary. I made the 6th patch, and now, if a hero has the Enchanted Ballista skill, the game will crash when attempting to fire. It says the error is here: 0x00d360ea. This number is slightly larger than the size of the heroes. Apparently, the 7th patch fixes some kind of link, and it's essential. Technically, I don't know the meaning of these patches, so we just need to find the correct number.

The thing is, patch #7 is necessary.

I made patch #6, and now, if the hero has the Enchanted Ballista skill, the game will crash when attempting to fire.
It says the error is here: 0x00d360ea
This number is slightly larger than the size of the heroes.
Apparently, patch #7 modifies some kind of reference, and it's impossible without it.

Technically, I don't know the meaning of these patches, so you just need to find the correct number.

So, it's better to use the larger number because when the .exe file is launched, it is re-addressed with an offset in RAM of 00 40 0c 00, and thus the game actually crashes at address 00 93 54 ea (this is the address in the .exe).

There is no explicit indication of an address with a bunch of zeros in the additions; there is only indirect addressing, but what it refers to is another question!
00D360C4                 loc_D360C4:                             ; CODE XREF: 00D35FD9
00D360C4                 mov     edi, [ebp-0Ch]
00D360C7                 cmp     dword ptr [edi+484h], 0
00D360CE                 jz      short loc_D3610B
00D360D0                 mov     eax, [esi+1Ch]
00D360D3                 add     eax, 36h
00D360D6                 mov     edx, eax
00D360D8                 shl     edx, 4
00D360DB                 sub     edx, eax
00D360DD                 mov     eax, [ebp-18h]
00D360E0                 add     edx, ebx
00D360E2                 mov     ecx, [eax+edx*4]
00D360E5                 mov     edx, [ebp-50h]
00D360E8                 push    ecx
00D360E9                 mov     ecx, [ebp-64h]
00D360EC                 push    edx
00D360ED                 mov     edx, [ebp-24h]
00D360F0                 push    ecx
00D360F1                 mov     ecx, [ebp-14h]
00D360F4                 push    edx
00D360F5                 mov     edx, [esi]
00D360F7                 push    ecx
00D360F8                 mov     ecx, [ebp-10h]
00D360FB                 push    edx
00D360FC                 push    edi
00D360FD                 push    ecx
00D360FE                 lea     edx, [eax+0B34h]
00D36104                 mov     ecx, ebx
00D36106                 call    sub_D1C780

The game crashes at var_64 – some variable in the game; it is very likely that the address of the Enchanted Ballista mechanic procedure is stored there!

Try making patch #7 with the address 00 b8 e8 fc (there are a lot of zeros here) or with 00 b9 04 fc (and here the zeros alternate with ff)

There are many instances of empty values with 99 zeros; you can't just guess.
Even if you follow some logic, it doesn't help – you still get the same result.

There are many instances of 99 consecutive zeros, so you can't just guess.
Even if you follow some logic, it doesn't help – you still get the same result.

Not by guessing, but by shifting relative to the variable var_64.

didn't help :(

Hey @Vasik,

Stripped means this is the normal EXE without the debug data.
So if you want to use the patch on ToE exe you need to strip the debug data first and then apply the patch it.

I dont sure that is the best solution - It will change exe a lot and I might have the issues if I want to update something else / play online etc.

If I get know the proper 7th description for normal non-stripped ToE I will replace the bytes manually, I just need a proper information for it.

We began using stripped space because there was not enough space within the exe to add new assembly code. It is impossible to implement 7th change without free space.
basically what is done is we tell the code to reroute reading from EXE to the free space below (that is with changes before the 7th).
Then it goes to 7th change location and that code executes the new commands and then go back to the ToE EXE code again.

If all players use the same modification of the EXE multiplayer will work without any problem.