PS4 enemy/drop frequency

[etony33]

I suppose I could use any emulator and just use the Debug code and Game Genie to make everyone invincible.

[Zucca]

I didn't follow. O.o

Anyway using a script you could potentially see the drop rate for a item that's about to be dropped (in battle).
I'll try to dig deeper into the asm code and pull something from there. It's not easy. PSIV has way much more pointers and other things in the code then other classic PS games. I already planned a make git pull to try out hacking into PSIV more, but for now I'll just settle marking down locations in ROM and RAM and from there, just maybe, I'll find the table of drop rates.

[etony33]

In other words, I could just start a new game on any emulator, make myself invincible so I don't get slaughtered, then I can just use warp codes to go wherever I want.

[Zucca]

Ah got it.
I'm trying to figure out the bits and pieces of the assemly. Can't really say anything yet.

[etony33]

Whatever you can do, I appreciate it. I'm very much a novice when it comes to this sort of thing.

[Zucca]

Well. It seems that the m68k assembly code isn't that complicated. I just don't know exactly what all the operations do. I have the offical m68k programming reference manual open here.

Code: Select all

Battle_CheckItemDrop:
   bsr.w   loc_44CA
   bset   #7, (Battle_Routine_2).l
   bne.w   loc_318E
   clr.w   ($FFFF4190).l ; Clears memory address FFFF4190
   jsr   (loc_27E178).l ; Run subroutine at location 27E178. Something to do with invertory, check if full?
   jsr   (UpdateRNGSeed2).l ; Draw a new random number (runs subroutine at UpdateRNGSeed2)
   andi.b   #$7F, d0 ; Bit-wise AND comparison. A mystery at the moment.
   cmp.b   (Item_Drop_Rate).l, d0 ; Compares Item_Drop_Rate to what's currently stored in d0, I GUESS
   bge.s    loc_318E ; Compares random number to item drop propability number, I GUESS
   addq.w   #1, ($FFFF4190).l
   tst.b   ($FFFFF437).w
   beq.s   loc_318E
   addq.w   #2, ($FFFF4190).l
loc_318E:
   move.w   ($FFFF4190).l, d0
   lea   (loc_319E).l, a0
   trap   #2
   rts

There's the snippet of the code. I've added comments (after the ";") of my progress.
If anyone m68k asm coder is reading this - your help is needed.

[etony33]

I've decided to compile a list of a) missable items (which I'm fairly certain is limited to Laser Sword, Swift Helm, Power Shield, and one of the two Laser Barriers, in addition to some things in Vahal Fort if you don't open it up before getting Elsydeon), and b) items which are not missable, but which are irreplaceable if sold or otherwise removed from your inventory, such as the Impacter, Demi's starting weapon). The second category would apply only to things that are forced into your inventory, so anything that you find in a treasure chest that will be accessible all the way through the end of the game would be in a separate category.

This data would allow me to compile what the "perfect inventory" would look like, given that you only are alotted 40 spots.

[Zucca]

I've made only a little progess.
I've found one static number - 127. If I'm correct then the random number generated needs to be smaller than 127 to get the monster to drop the item.
That means (at least now) the drop rate for each item is the exact same.
Instead of me trying to "decode" the assembly code, rather I'd need to try to make some changes in to the code and compile it. Then run tests. First step would be to set that number much higher. That way I'd add more evidence for my theory if items drops were boosted to 100%.

[etony33]

Hmmm.

Well, it's not 127 out of 256, that's for sure.

[Zucca]

Well, it's not 127 out of 256, that's for sure.

Yeah. That would be 50%. So, yeah, it's not that.
If it was out of FFFF (65535) then it would be 0.19%, isn't that either.

[etony33]

127/4096 (3.1%) might maybe possibly work IF it was for each enemy rather than just in total (in other words, Shadowsaber x3 would be 1-(3969÷4096)^3 or 9%). If that is the case, the game would possibly override it if you were to get more than one drop based on the RNG, giving you one drop instead.

Are there any formations in the game that have more than one enemy that could possibly drop an item?

[etony33]

Actually, that seems about right. It would also explain why it's more difficult to get a Star Dew from Greneris than a Shadowblade from Shadowsaber or Wood Cane from Tech User, since you usually face more than one of the latter enemies in a single formation, while Greneris is always alone.

[Zucca]

Yeah. I think 4095 (FFF) would then make sense...
Here's the subroutine/function to generate the random number

Code: Select all

UpdateRNGSeed2:
   move.w   $8(a5), d0 ; move 16-bits (word) from somewhere to d0
   add.w   (Main_Frame_Count).w, d0 ; add Main_Frame_Count to d0
   sub.w   (RNG_Seed).w, d0 ; substract some random number from d0
   ror   (RNG_Seed).w ; "rotate" random number (to maybe avoid successive similar numbers if used concurrently)
   rts ; return/exit from subroutine

... these, again, are guesses, as I still haven't learnt all the instructions of m68k assembly.

[Zucca]

I happened to be on same irc channel as one guy who I know does know m68k assembly. He happened to answer my question right away and I now got hold on much of the things.
Firstly the random number function creates a 16-bit random number, not 12-bit. But the iten drop ruotine actually only compares last 8 bits. I think I'm close here now...

[Zucca]

I've made only a little progess.
I've found one static number - 127. If I'm correct then the random number generated needs to be smaller than 127 to get the monster to drop the item.
That means (at least now) the drop rate for each item is the exact same.

This is false.

The mystery line "andi.b #$7F, d0" zeroes all the bits after 7th bit. Basically making the random number 7-bit.
7Fhex == 127dec == 1111111bin. Max 127 min 0. But it's still a word so 0000 min and 007F max. These are the limits now for the random number.
(I don't know if anybody reading this still follows, but just in case someone finds something I haven't. )

Then... a comparison is made by subtracting Item_Drop_Rate from the newly created 7-bit random number: cmp.b (Item_Drop_Rate).l, d0
Next line: bge.s loc_318E skip to loc_318E if the random number is positive, meaning we missed the item.

Then again guessing:
addq.w #1, ($FFFF4190).l writes 0001 (in hex) to memory address FFFF4190.

But that's not really important anymore. We already know enough. No need to go further from there. Instead I'll focus on the Item_Drop_Rate, which is a pointer: "Item_Drop_Rate = ramaddr($FFFF41F2)".

So next I'll start searching which other functions/subroutines write to that memory address.
At least now we know that the comparison is made against 7-bit random number.