Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - DLPB

Pages: 1 2 [3] 4 5 ... 361
youll have to wait for reunion r06. it can't be added easily without my dll. it's a mandatory fux there along with many others.

Time to put this battle mode nonsense to bed.

Because this game is probably the most cobbled together thing I've ever seen, this Field Battle Mode flag (not to be confused with the Battle Type or the Battle Formation flag, set in Scene) stuff is a total nonsense when you look at what's going on.  The game actually only uses 16 bits for the Field Battle Mode - despite the fact there is a "Field Battle Mode (2)" which appears to allow 32 bits.  The engine simply does not support it.  Instead, the flags are converted to a 2 byte value. Regardless of the flag set in Field Battle Mode (1), the same counterpart will be set with Field Battle Mode (2).  Example:

Flag 1 in Field Battle Mode (1) is "Do not show Battle Rewards". This will set the exact same bit in FF7 memory as Flag 1 in Field Battle Mode (2).  The value in memory is 0x80 at CC0DC6.

Field Battle Mode (1) is actually only Flags 0-7 + Flag 16.  Why 16?  because that is the Disable Game Over flag, which gets its own byte to itself (CC0DC5).  In actual fact, this is a shoddy - and I do mean SHODDY - shoehorned fix. Clearly, the 16 bits (instead of 8) is there in Field Battle Mode (1) purely so the Disable Game Over byte can be set.  Flags 8-15 simply cannot be used in Field Battle Mode (1) - though I assume any of those being set to 1 will result in Disable Game Over, since CC0DC5 will then be non zero.

So, what about Field Battle Mode (2)?  Well, this is a jumble too.  The engine makes sure that the flags set here will set the same 2 byte value at CC0DC6 (+ Disable Game Over bit at CC0DC5). Flag 0-7 of Field Battle Mode (2) is the same as Flag 0-7 of Field Battle Mode (1). But Flag 24 becomes the Disable Game Over (it's Flag 16 in Field Battle Mode (1) ).  Flag 16 in Field Battle Mode (2) is Disable Victory Celebration Music, which is actually given the value 0x100 at CC0DC6. It's the only flag that can't be set with Field Battle Mode (1). 

Rather than think of this in terms of field flags, it's much easier to think of it as a memory value.  The value the engine actually makes use of.

The memory values at at CC0DC6/9A88A6 are:

Field Battle Mode (2). Current Makou flags in square brackets.
0x01: Unused [Flag 8]
0x02: Enable countdown timer [Flag 7]
0x04: Preemptive Strike [Flag 6]
0x08: Cannot escape from battle [Flag 5]
0x10: Unused [Flag 4]
0x20: Do not play victory fanfare music [Flag 3]
0x40: Activate Battle Arena [Flag 2]
0x80: Disable Rewards [Flag 1]
0x100: Disable Victory Celebration [Flag 16]
0x200: Unused [Flag 15]
0x400: Unused [Flag 14]
0x800: Unused [Flag 13]
0x1000: Unused [Flag 12]
0x2000: Unused [Flag 11]
0x4000: Unused [Flag 10]
0x8000: Unused [Flag 9]

And Disable Game Over is set as Value 0x01 at  CC0DC5 [Flag 24].  It must be noted that although 24 bits can be reflected from CC0DC5 using Field Battle Mode (2), only the 16 bits at CC0DC6 will be copied to battle memory (9A88A6) making them effective.  Game Over flag is not copied.  The engine checks for it at CC0DC5 - not at 9A88A5 when the battle ends.

Basically, as I noted on the github, Makou Reactor should do away with Field Battle Mode (1) and only allow the "32 bit version"  - although it should simply show to the user flag 1-17, with flag 17 being "Disable Game Over".   In other words, the non usable flags should be hidden and effective ones translated by Makou Reactor.

Yeah, it will fix the issue of them not saving.   8-)

I've also added the "if escape, still add kills"  to battle exit.
Code: [Select]
Procedure AddKillsOnEscape; stdcall;

push ebx

mov dx,[$9AB0C2]
and edx,$C // if escape (04 or 08)
test edx,edx
je @End

xor edx,edx
xor ebx,ebx


mov eax,ebx
inc ebx

cmp eax,2
ja @End

xor edx,edx
mov dl,[eax+$DC0230] // retrieve ID in slot 0-2
cmp dl,$FF
je @Start

imul eax,eax,$34
mov al,[eax+$9A8DBF]
and eax,$000000FF

imul edx,edx,$84
add edx,$DBFD8C + $24  //Character kills.

xor ecx,ecx
mov cx,word ptr [edx]
add ecx,eax
  cmp ecx,$FFFF
  jna @Label1
    mov ecx,$FFFF

mov word ptr [edx],cx

jmp @Start


pop ebx

Ordinary escape is given value of 04.  Seems Smoke Bomb (and possibly other materia/item escapes) are given 08.  I am going to check what value is given when the "no reward screen" field opcode is operating.

Edit.  It uses 0x20...  so normal victory flag when the "no reward" is in use.  I'm going to need to disable the normal victory kill update as well and always force it on exit.

For some reason, the enemy skills learned address (9A8DDC for Member 0) requires that byte to be $80.  If it isn't, the address isn't changed.  Perhaps there is a check for it somewhere.  If it's 00, then I assume the game ignores writing to 9A8DDC.  [Edit.  005DB061 is where the check is made.  The originally game sets the byte to 0x80, but any non zero should work. If 00 then Enemy Skill is not equipped, you see.  There is a further check after that, which I am unsure of.]

It also seems to me that the mask check (xor) can be ignored?  All it will do then is ALWAYS update on battle victory when E Skill is in a slot, rather than what it does now- check if any change from e skill at battle start.

I've also disabled the victory E Skill update and put the update in battle exit (so that the E skill change will always be reflected).

I'm not really sure if I need to preserve edi,ebx,esi here.  Didn't check.

Still this nifty replacement I've made for the Enemy Skill mask ensures that, from now on, the enemy skills MISSING from the total are what count, not the ones that are PRESENT.  See, originally, if one of your characters had a full enemy skill set, it would then stop all other enemy skills from learning all abilities. And if one of the materias had, say, Frog Song, then none of the others without it would gain it either.

Code: [Select]
Procedure CreateEnemySkillMask5CFB93; stdcall;

push ebx
push esi
push edi

xor edi,edi
mov esi,$00FFFFFF

mov ecx,[esp+$10] //Starting address of character materia

xor ebx,ebx


cmp ebx,8
je @Label5

test edi,edi
jne @Label3
  mov eax,[ecx+ebx*4+$40] // Retrieve Materia ID and AP in Weapon slot.
  jmp @Label4
  mov eax,[ecx+ebx*4+$60] // Retrieve Materia ID and AP in Armour slot.

cmp al,$FF //If no materia in slot, then jump to next slot.
je @Label2

xor edx,edx
mov dl,al
imul edx,edx,$14
mov dl,[edx+$DBDF6D] //retrieve formula ID for materia
and dl,$F
cmp dl,7  //materia is Enemy Skill
jne @Label2

shr eax,8
and esi,eax
or esi,$80000000

inc ebx

jmp @Label1

  test edi,edi
  jne @End
    inc edi
    jmp @START


mov eax,esi

pop edi
pop esi
pop ebx


Not rigorously tested yet, but seems to work.

Enemy skills can now be learned when a materia already has the skill.  It's not really a bug that it originally doesn't - but a design choice. A bit lazy of them not to add the ability in too.  For now, the "Enemy Skill learned" text will always be seen when it is used on member, but I am thinking I can add in a check to stop it.

NFITC1 also noted the area where they are all added, so I've moved the code to battle end, instead of "menu at battle end" - meaning learned skills are always learned.  Not just at victories. This one was a big oversight.

Tools / Re: [N/A] Text and Hex Editors - Hext Tools 3.0
« on: 2018-02-04 17:16:54 »
The log will likely tell you more than just that.  Those Tifa addresses are memory addresses - not file. They don't exist in the file.

But this thread is not for anything other than bug reports or issues that are caused by Hext programs.

I don't support 7th Heaven.  It's completely separate and outside of my input.  And it tries to support the older menu changes - which I no longer support.

Other Mods / Re: need standalone 60fps mod
« on: 2018-02-02 22:54:34 »
One reason I pull download links is because people refuse to read threads.  Lazy people.  And then I am forced to repeat that the download is not supported anymore.Anxious Heart and 60fps is part of The Reunion as an optional mod.  It's been improved,  All I can tell you is to wait.

The old 60fps had serious bugs.  That's the main reason it was pulled.

It will break your game.

So, donation or no donation, it's not going back up.  I don't have the old installation anymore. IT was a game breaker.

I mean use the English 1.02 exe and convert the text in it to French using touphscript.  But you'd need to rename the french program files to their english equivalents. This will be easier when my dll is released.

Nope. :P  Ochu is English only. But I think a better idea is to just convert the exe text of english version into french and then a whole lot more mods and tools will likely work for you. 

Yes :) See tools.

I've added the ability to change slots already in Ochu.  It's pretty easy to find the addresses and the Savemap is online too :)

However, changing characters in battle is not as trivial.

Nope.  It doesn't work like that. Different cpu language - different memory addresses. The math is almost same, but you have to find the new code locations or addresses.

Actions will no longer perform on enemies that have been killed (but animation etc not yet visible to the player).  This stops reviving enemy bug and also stops accidental use of action on enemy that is already dead (the action skips to another enemy originally, which I always found annoying anyway).

Nope... that way will fail for multi targets and for confuse.  I'll sort this using miss flag. 


Darkness is now part of the physical accuracy check.  This means that enemies are now able to be affected by it.  On other hand, Sadness and Fury will no longer affect enemies.

I said that phrase earlier today too.  ;D  I am trying to get it out as fast as possible with as many bug fixes as I can.  It is taking an awful lot of time.

NFITC1 has done the rest, so gave him a little head start with this one.  It's more or less complete aside from a few unknown flags and their function.

Hopefully, that will prove useful to you, NFITC1 :)  Have at you.

The Sleep, Confusion, Manip flags are there to remove the status if hit.  Those 3 are removed on physical attack.  Not sure why it's ecx+0000023C and not ecx+00000228.  Evidently, the former is checked to see what needs removing.

And thanks for the donation. To you and all who contributed.  It was  a very generous amount. :)

Meanwhile I need to finalize the database for you, so you can update.

Other Mods / Re: need standalone 60fps mod
« on: 2018-01-25 02:05:55 »
If you had been following the threads, you would know that R06 allows all parts to be standalone. It also comes with a complete optional replacement of the audio module, as well as a totally new way to mod the game for developers. That's the main reason why R06 is taking time. And since I've done what you asked, perhaps pay me.  It wouldn't go amiss to get something back instead of demands.

The reason why it hasn't been standalone up until now is because coding in asm is time consuming and annoying.  Giving options for everyone is time consuming and annoying.  My new dll system allows me to do this easier.

Tools / Re: [FF7PC] Trainer - Ochu (3.4)
« on: 2018-01-24 23:05:48 »
there is a help file.

Tools / Re: [FF7] Yet Another Multi-Patcher - YAMP
« on: 2018-01-23 16:04:55 »
I don’t know assembly. Could I just make something like “if damage = X, then print X” or something ?

That sounds easy...   But it isn't.  It's a lot of work to do that in assembly.  We do not have the source code.

Cheers, dude!

Meanwhile, I need some of your knowledge regarding battle formula in order to fix some of these bugs.  Pretty sure I am doing it right, but need to run some things by you on Discord or Qhimm irc.

Pages: 1 2 [3] 4 5 ... 361