assembly learning day 3

Using cheat engine to find Monster Crystal adjusted drop rate:

Details and static drop rates for most monster crystals found in alba_data\btscene\pack\wdb\_x000.bin\bt_chsp_x000_8.wdb (after unpacking x000.bin). Look for s10DropItem2 and u14DropProb2 for Monster Crystal dropped and probability rate.

For Pulsework Soldier (k063 or mcr_k063), searched mcr_k063 in memory while in 003 AF and picked the third of 3 options. Went there in memory and checked what accessed that spot. Two instructions accessed that spot in memory, both of them very close to each other.

For now until the program crashes, mov [edi+10], ax moves the value of the drop rate of Pulsework Soldier to be analyzed. It gets 1500 already to be analyzed. This is currently at ffxiii2img.exe+55D0CB.

...I mistyped it. It's probably +55D0C7, not CB. It writes the probability of the drop to 0x054FF0F0, but that can be either monster crystal or item, it appears. However, when I do a breakpoint write, the game stalls because the memory is constantly writing to that address. This approach will not work.

Since I'm checking for the formula anyway, I want to see how the synch rate affects this. Will see what I can do about that.

When you start synchro, the memory at 0x0B6E7654 is accessed. However, that's not terribly helpful.

Was able to find the address where the synchro number is stored. It is stored as a 5 digit set of 2 bytes. Always starts at 10000. The last digit is not shown in-game, but is usually rounded. Used pointer maps and pointer scan to get the value saved.

Testing with ONLY the monster attacking, with Serah and Noel not attacking. Reason is that sometimes the monster HP depletes before Synch attack even starts.

Looks like when you don't finish an enemy with synch ability, there is one instruction that isn't called. Whether you have a successful catch or not, that instruction is called. ALSO, when the enemy runs out of HP before you can get the synch ability off, that instruction is not called. I'm guessing that means that the monster must be the one that finishes the enemy off, but I'm not 100% sure. The value must be different when the instruction is called, so I need to check.

After further testing, the enemy health must be depleted by the synch ability. If it is depleted beforehand by Noel or Serah or poison, it will not go towards the instruction and possibly the calculation that I have yet to figure out.

40419
35953 - Spiceacilian

Set breakpoint at sole instruction, and when enemy is defeated by monster synch ability, that breakpoint is triggered. It takes the value of the synch and puts it in EAX and subtracts 10000 from it (for example of above, 35953 - 10000 = 25953) and puts it back in EAX. An instruction then converts EAX into a scalar single precision floating-point value and stores it in XMM1. XMM1 is multiplied by ffxiii2img.exe+95C60C (which looked like 0 but it was more like 0.0001, but then it rounded to the nearest tenth?). Anyway, the result is 2.60 in this example. A comparison is done between that and what appears to be 0.00 (all the hex values are 00 for a while at that address). jna (jump not above) is then done, which it's not, so it doesn't jump. I'm assuming all of this is done to check if a synch ability actually had any button presses to increase the % value in-battle. If it didn't, it jumps and moves on. Otherwise, it does next.

For reference, mcr_k665, Spiceacilian's monster crystal, has a 20% chance of dropping.

Next, it moves a value to xmm3 that's stored at ffxiii2img.exe+1EDD0C4 (1.00). The next instruction stores ffxiii2img.exe+211E94C (3.00) at xmm2. Following instructions are completed:
	movaps xmm0, xmm1 (moves 2.60 to xmm0, so now xmm0 equals 2.60)
	addss xmm0, xmm3 (adds 1.00 to 2.60. xmm0 now equals 3.60, so I guess the -10000 from earlier has now equaled itself out?)
	comiss xmm0, xmm2 (compares 3.60 to 3.00. next instruction is a jump not above, which will not jump since it is above. I'm guessing it's for handling most cases where synch rate goes below or equal to 300%? I may want to do a separate test for that)
	jna (won't jump because explained above)
	subss xmm2, xmm3 (may be for handling cases above 300%, as explained above. This subtracts 1 from 3 and stores 2.0 in xmm2).
	movss [esp+28],xmm2 (stores 2.0 in a spot in memory close to the text where mcr_k665 is. I wonder what the relevance is.)
	jmp to skip a line, but the line skipped is interesting. It's the same as previous, but it stores xmm1 instead of xmm2. So instead of 2.0, we'd get 2.6 stored in the spot near mcr_k665. I wonder if there's a general case for numbers above 300%?
[Skipping a few lines, as it's zero-ing out registers and memory spots.]

I had completely forgotten about this, but it looks like the next check is to see whether the monster crystal fragment skill is active or not. It checks for whether privilege11 is turned on or not. It then writes out privilege11 into memory and eventually will check that.

At some point that I didn't notice, 0x7D0 was stored in both EDI and EBP. This is important because that equals 2000, which is the drop rate for Spiceacilian's monster crystal. Oops. But I also don't know if this applies to the 1.2 rate for privilege11. I picked a bad case for the monster.

Anyway, the privilege is disabled, so I'll have to tackle that another day. Looks like I'm back to the instructions for calculating. It's putting values back into the float registers after they were cleared at some point.
	movss xmm0,[esp+28] (moves 2.0 back to float register 0.)
	cvtsi2ss xmm1,edi (converts 2000 or the crystal drop rate into a float and puts it into register 1.)
	mulss xmm1,xmm0 (multiplies the floats (2.0 * 2000.0 = 4000.0) and stores it in register 1.)
	cvttss2si ecx,xmm1 (converts 4000.0 into 4 bytes and stores it in ECX.)
	add edi,ecx (adds 2000 to 4000??? why????? anyway, stored in edi)
	cmp edi,ebx (compares 6000 to 0. 6000 is greater than 0)
	jg [function]
	cmp edi,0x2710 (compares 6000 to 10000. 6000 is less than 10000, so it will not trigger the next jump, which is a not less)
So I guess it checks if the value is between 0 and 10000? Still not sure what that means yet. But if it did go greater than 10000, it would go to ffxiii2img.exe+54ABE, which is a mov [esp+30],00000001.
Interesting value it pulled just now, a 2850. Not sure what that is. Maybe it'll be used for comparison in a bit.
	push ffxiii2img.exe+95de2c has comment ("[battle] crystalized check %d/%d(%d)")

Confirmed with another monster (Tabasco Toad) that EDI and EBP are indeed storing the crystal drop rate.

Set breakpoint at ffxiii2img.exe+54ABA:

Synchronized % - 28304
Capture Rate of Tabasco Toad - 1500
ECX - 2745 (1.83 (which is [28304 - 10000]*0.0001) * 1500)
EDX - 25550
ESI - 957 - random value, possibly?
EDI - 4245 (1500 + 2745. Still not sure what this does)
EBP - 1500
This was ...i forgot check if it was successful or not, but I believe it wasn't? Maybe it was? Oops.

Synchronized % - 47287
Capture rate of Tabasco Toad - 1500
ECX - 3000 (2.00 * 1500)
EDX - 25550
ESI - 5308
EDI - 4500
EBP - 1500
Unsuccessful. EDX doesn't seem to play a role, so will exclude. Looks like indeed that anything above 300% is rounded down to 300%. Neat.

Synchronized % - 43829
ECX - 3000
ESI - 2910
EDI - 4500
This was successful. EDI > ESI = success, maybe? Need to confirm if it's ECX > ESI or EDI > ESI, but I believe it's the latter.

Synchronized % - 41818
ECX - 3000
ESI - 1022
EDI - 4500
Successful is my guess. Successful is correct.

ESI - 6677. My guess is no. It is indeed no.
ESI - 3141. This case, ECX < ESI < EDI. This was successful, so as long as EDI > ESI, or as long as the random number generated is lower than what the formula outputs (the higher the number the formula outputs, the greater the odds), then you'll get the monster crystal.

My best guess is that ESI is a random number between 0 and 9999, based on the values I've seen from the testing done. I saw as high as 9685, and if it went higher than 9999 then the 100% monster crystal drops would not be dropped.

I put two breakpoints in, one at where I started (the sole instruction mentioned above) and one where I got my register values mentioned recently here at ffxiii2img.exe+54ABA. The random value does not change between the two breakpoints, meaning the ESI value was set before this for checking for the monster crystal.

I could finish here, but I want to figure out how privilege11 or the fragment skill for monster crystals plays into it, whether it's additive or multiplicative.

Testing with Spiceacilian on a file where I already have a Spiceacilian. May fix this in a moment.
Spicacilian monster crystal drop rate: 20%, or 2000.

Okay, that was quick. It does not check if I already have the monster crystal. Time to infuse.

Took care of that.
Synch rate - 30844
ESI - 9916, so not getting this monster. Let's see the other values.
ECX - 6000 (Interesting. This has 2000 points more than normal. (2000 catch rate * 2.00) + 2000
EDI - 8000 (wasn't getting the monster, but I was pretty close.)
EBP - 2000

Second test with lower synch rate.
Synch rate - 17491
ESI - 4108
ECX - 3498 (uhh (0.75ish * 2000) + 2000 = 3498 this feels odd)
EDI - 5498

Something I haven't noticed that I need to check: if you use a synchro ability but don't get above 200%, is it worse than not using a synchro ability at all?

Synch rate - 22920
ESI - 5606
ECX - 4583 (1.29 * 2000) + 2000
EDI - 6583

It seems like it is. I'm not sure how to confirm this regularly yet, but it seems like if you use a synchro ability and get less than 200% on a finishing move, it lowers the chances of getting the monster crystal drop than if you just never tried the finishing move at all.

Synch rate - 10000
ESI - 3143

...my premise is flawed. The reason is that the EDI is the result of adding back in the missing 100% of the base drop rate. Okay, I think we're good. The formula is thus:

```
synchroRate = value between 1.0000 and 3.0000
// Note that synchroRate cannot exceed 3.0000. All values above that get rounded down to 3.0000.
privilege11/fragmentSkillActive = 2000
baseRate = (depends on monster, but usually a value between 300 and 10000)

dropRate = ([baseRate*synchroRate]+privilege11)/10000
```

I am satisfied with this.