PS4 enemy/drop frequency

[etony33]

Awesome, man.

I'm going to do my own little experiment: using walk through walls on the debug menu to bypass the carnivorous trees, then beating DF2, to see what happens to the trees in that case.

On a similar note, would you happen to know how to shut off he ability for the trees to regenerate, thus making them beatable?

[Zucca]

On a similar note, would you happen to know how to shut off he ability for the trees to regenerate, thus making them beatable?

Afaik, if you manage to beat them, you'd get something like 1exp+1mes and the trees would stay there. Basically: If you manage to beat them the result is the same as if you were to run away from them.
I read that from somewhere, but don't just remember where at the moment.

As for the "deciphering" the asm code... I've always ended up in dead end now.
There's nothing about items in enemy statistics. I doubt it's in enemy group data either. The quick look I made didn't reveal anything interesting.
There are two RAM addresses that relate to item drops:

Code: Select all

Item_Drop_Rate = ramaddr($FFFF41F2)
Dropped_Item = ramaddr($FFFF41F3)

... So far there isn't any subroutines (that's human readable* at least) in the code that would write to these locations.
I tried to search for signs from item data too. Hoping there was a optional byte for a enemy id, but I quickly saw that's not how it works, since there's more than one enemy that can drop same item. But I still went to check if there was some array of enemy ids, but no.
If I find the assosciations between enmemies and the items they carry, then I think I can find the drop rate too.

I also found out that the level data for each character is there twice. Other is for the game to adjust character statistics when leveling up and the other is

Code: Select all

; =================================================================
; Copy of the level tables. It seems to be used only when showing the
; EXP, total and the required amount for the next level. If you go to
; the window routine I called Win_StatusEXP, you can see that it loads
; the pointer to these tables; you would only need to tweak the code a bit
; and point to the first tables so that you can free up some space here
; for other data
; =================================================================

So it might be so that there is some other data duplicated where the item drops are specified. At least I'm hoping so.

* There's quite a lot of code that's still on raw hex, so the code we're looking for is propably there.

[lorenzo]

Hi, I'm the author of the disassembly.

Item drops are part of the formation data, so they do not depend on single enemies. Formations are compressed in ROM so it's not possible to edit them directly.

Once formation data is decompressed in RAM, all the info is saved in RAM location from $FFFF41F0 to $FFFF41FF and this section holds number of enemies, enemy groups, item drops, and possibly other stuff.

[Zucca]

Hi, I'm the author of the disassembly.

Huge thanks for joining!

Item drops are part of the formation data, so they do not depend on single enemies. Formations are compressed in ROM so it's not possible to edit them directly.

D'oh! I was just looking at EnemyInit* subroutines... Not anymore.

Once formation data is decompressed in RAM, all the info is saved in RAM location from $FFFF41F0 to $FFFF41FF and this section holds number of enemies, enemy groups, item drops, and possibly other stuff.

Compressed? Using some simple compression algo, like Huffman coding? I wonder why they went with that, since there is space wasted in, for example, putting the exp level data twice in to the ROM.

So I think the best is to write a script for an emulator and just poll RAM for the item drop rate when in battle.
I think I could manage doing that more easily than "dechiphering" the asm code (which I'm still not too familiar with).

[lorenzo]

Hi, I'm the author of the disassembly.

Huge thanks for joining!
Compressed? Using some simple compression algo, like Huffman coding? I wonder why they went with that, since there is space wasted in, for example, putting the exp level data twice in to the ROM.

The compression algorithm used is Kosinski; here's a link explaining how it works:

http://segaretro.org/Kosinski_compression


The same compression algo is used for dialogues as well. Since the decompression is known, it shouldn't be too hard to make a program to decompress the data and make edits. I thought about making one, but I'm busy with other stuff. It's also likely someone else will do it. It will come around eventually.

I'm not sure why they had a copy of the EXP table either; it's likely they wanted to have an EXP table with different values for something else which was scrapped at a certain stage of development, but instead of deleting it, they left a copy of the other exp table.

[Zucca]

I'm not sure why they had a copy of the EXP table either; it's likely they wanted to have an EXP table with different values for something else which was scrapped at a certain stage of development, but instead of deleting it, they left a copy of the other exp table.

The only reason for another exp tables, I can think of, is characters could have different level paths. Like in Shining Force 2 - you can promote characters and they start again at level 1. But also you can promote them with a special item that, once again, branches the promoted character into a new exp level path.

Anyway. Thanks for your tips. I'll start setting up an emulator which has support for scripting.
I'll be kind of brute forcing the values out by jumping from battle to battle then.

[etony33]

I feel like we're getting close! And by we, I mean you.

[Zucca]

I feel like we're getting close! And by we, I mean you.

I started to looking at some emulators that support scripting... I've normally used libretro, but I haven't found any evidence of scripting capability.
Then there's BizHawk. While it's almost all I'd need, its coded in C# and thus needs .NET or Mono. That isn't much of a big deal but the build process assumes that I have Visual Studio of some kind. There isn't absolutely no build files for Linux or any *NIX OS. Although There is one guy who uses BixHawk on Linux so I might have luck... eventually.

Then there are all the different branches of Gens. Some at least support lua scripting.

I'll be bombarding few irc channels and forums with questions. Then I'll decide which emulator I start tinkering with.

Basically: This might take some time. :\

[etony33]

My computer has Windows. If that's the issue, if you tell me exactly what to do step by step, I can give it a try.

[Zucca]

...exactly what to do step by step...

That I cannot do unless I too have the program installed and learnt the scripting interface.

[etony33]

Yeah, that makes sense.

When you do get to the point where you can start trying to gather the data, Nurvus is probably the best place. Greneris (Star Dew), Floatmine (Dynamite), Tower (Dynamite), Blauzen (Laser Claw), Zios Guard (Dimate), and Techmaster (Force Cane) all have possible drops. Only Balduel, Tarantella, and Centaur do not have a potential item drop.

[Zucca]

I'm slowly progressing with BizHawk. Although I don't know if I still face a dead end this way.
I'm also slowly going crazy. .NET should be platform independent, but my first problems were that this software is obviously only tested on Windows, which has case-insensitive filesystems only, while almost every other filesystem in existence today has case-sensitive filenames. So I ended up with several "404" errors.
I found a way for the compiler to disregard the casing. I also found offical (but in testing) package repository for dotnet/mono stuff.
The error rate now increased to over 3000. At this point I'm sad it's not Friday. I'd drink booze until midnight because of this.

While I'm doing this, I also create an ebuild (basically a script) to make this automatic. Even if people cannot utilize the ebuild they can read it and figure out which commands I use to compile BizHawk.

[Zucca]

In meantime I'll test Mame (with Mess compiled in). It should have some debugging features too...

[etony33]

For what it's worth, I just killed a Greneris 200 times and got 11 Star Dew drops. That puts it close to the 1/16 that would seem very reasonable and plausible.

[etony33]

If somebody commits a particularly heinous crime, instead of sending them to prison, we should just make them farm Star Dews. They'd be so traumatized by the experience that they'd never commit a crime again.

I've taken to using Legeon and Negatis on enemies who don't let Rune escape the first time purely out of spite. That's not a rational thing to do, but that's where I'm at.