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 - nfitc1

Pages: [1] 2 3 4 5 6 ... 120
Same. I came up with a good idea, but suck at graphic design and couldn’t pull it off if I tried.

General Discussion / State of current wiki
« on: 2022-05-26 20:52:38 »
Is the replacement qhimm wiki gone? This page doesn't seem to exist any longer. I don't remember the last time I checked. Probably years.

Head canon, no matter the source, is just that. “If it didn’t happen on screen it didn’t happen.” All we saw is Midgar being overgrown after 500 years. According to the other sources (AC, DoC) the events in this game did not cause the extinction of humanity.

Troubleshooting / Re: OG PC disks or Steam release?
« on: 2022-02-04 19:42:59 »
All of the mods should work fine with the OG disks. The Steam edition needs a small tweak to get mods to work, but they all work with both versions. Apart from that, Steam won’t need a no-CD patch and has a speed up cheat. My disks work except for one video file that is corrupted on the first one so I can’t play with disks anymore. I have my videos saved on my drive and the registry pointed to them as the source of the FMVs.
My take is if you have working disks then don’t bother with the Steam edition. I have made minimal changes to my config and it all still works fine for me. I also stay away from board drama so I couldn’t advise about what topics not to bring up.

Hmmm. Why do you think there's a boosting stat for the two it wants to win?

Observation. I have no hard evidence, but I've seen the lower speed chocos win over higher speed with better sprint. There might be more going on, but it looked like they were "favored" because they were making better use of their speed and sprint. Otherwise you could just bet on the two with the highest speed stat and win every time.

I'm going to provide some preliminary speculation based on my own observations on this minigame.

Stats are important, but in the end it's all random. Whether the chocobos will sprint or if they will veer left or right and at what time. The chocobo's rank is based on a holistic calculation of all its stats. I can't tell you HOW that calculation is performed. The higher the intelligence, the less they will swerve. The higher the stamina, the longer they can sprint. yadda, yadda.

It also seems like there's some external data at work here. As the race begins, the game just "boosts" some of the positions. It sort of chooses which two it wants to win and gives them some stat-independent advantages at random intervals. These two are more likely to win and it's just completely random whether they do or not. The highest ranks don't always get boosted either.

What I would do: Since you have identified where these are in the PSX memory, what you can do is make a savestate before the chocobos begin running, check the winners vs losers, reload the save, swap the winners' stats with the losers' stats and see how that affects the outcome.

Addendum: I haven't seen ergonomy_joe for a while. Not saying he's not reading the forums. I still do, but I rarely post anymore.
I have looked at the chocobo.wat file, but it doesn't seem independent enough to parse into individual files. This is a "big" hassle in the lgp files too. They don't contain enough metadata on their own to be used separately. It's all contained in the exe file where different fragments start and their size.
However, looking at the bytes inside it looks like it contains several parts that consist of default values for some things. Possibly even proprietary AI scripts which I can't immediately find handlers for. I say that because they LOOK like scripts, but not asm code. It's more like the WM scripts or Field scripts, but they're quite short. It also likely contains the modeling info for the different tracks though the model data and textures for the objects are saved independently in the chocobo.lgp file.

General Discussion / Re: FF7-PSX Tifa slots
« on: 2022-01-13 17:36:26 »
WallMarket cannot help. I can't give you actual memory addresses, but on the PC version(s) it's in the executable as a byte array of 0s, 1s and 2s. It's a 10x16 array and should be searchable in any hex editor. Sometimes knowing what to search for can help you find it. I can't guarantee that information helps.

First four "rows" are like this:
Code: [Select]
01 02 02 02 02 01 01 01 01 01 01 01 01 01 01 01
01 00 02 02 02 00 01 01 01 01 01 01 01 01 01 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 01 00 02 02 00 01 01 01 01 01 01 01 01 01 01

The rows of 0s are "buffer" rows for the unusable X-3 limits

It's actually in the Battle AI script so Proud Clod can (should anyway) be able to prevent the "defeated flag" from getting set for both.

I don’t know if an editor is in use yet, but the easiest way to make a mod is to modify the world map scripts. As soon as the battle ends their flag for defeat is set and they disappear. Change the script to prevent this defeat flag from getting set and they’ll stay for repeat battles. You could edit your save and reset their defeat status manually. You might not get more than one reward I forget how the reward script works exactly.

7th Heaven / Re: random battles bug?
« on: 2021-10-10 13:05:18 »
That’s a SLUT problem in the KERNEL.BIN file. Make sure the KERNEL.BIN and the scene.bin file you are using are synced

General Discussion / Re: Help about 9999 limit
« on: 2021-08-06 14:58:16 »
Which version?

General Discussion / Re: FF Pixel Remaster
« on: 2021-07-08 03:01:49 »
Pretty much every Japanese font is fixed-width. The higher the resolution the more detail you can put into the kanji. I’ve seen FF7’s Jap font and its characters are so small and ambiguous (though context would make them obvious). They’re all 24x24 pixels and with 48x48 you can get way better looking characters. When you translate that size into a variable width font with too small space between the characters it ends up looking squished. Just increase that blank space from 0 padding to 2 px on the menus and the problem would probably resolve itself.

Yes, the GS/RT values were way off. I must have typed something into my calculator wrong and just kept on keeping on with the transcription error. The encounter chances are actually

Code: [Select]
GS/RT1 5120
GS/RT2 10240
GS/RT3 21504
GS/RT4 32768

I'll update the tables above accordingly so there's as little duplicate data as possible.

According to your table: the chance of getting Mideel2 with a mastered lure is 21.9% * 50% = 10.95%
I thought the mastered lure went up to 20. It does not. You are correct based on the wording I gave.

And thanks for doing some practical tests on these values. I still can't get my game to load and test them myself. :(

Yes. 1.5 is still being worked on. It's a MAJOR rewrite of a lot of internals and a few visual differences. It will hopefully make problems like this easier to identify and resolve. I'm so sorry for the (years-long) delay. I don't get a lot of dedicated time to it.

I guess I didn't make myself clear in either of my previous posts. It looks like Terrace didn't do enough digging into the actual calculation of the encounter rate to actually pick the formation as they can be pretty different depending on your lure rating.
The World map is divided up into 16 "regions" which can have any of four "zones". These regions/zones don't have to be exclusive, but I assume they are. When a battle is triggered, the first two things the battle module does is check if you are in a Forest (for the mystery ninja fights) and haven't recruited Yuffie or if there are chocobo encounters in the encounter list for that region/zone combination.
IF your party is in a zone that has chocobo encounters AND you have a greater-than-zero chocobo encounter rate the battle module will then perform a calculation based on your lure value vs the encounter chance I posted above. This check behaves as follows:

Code: [Select]
Cchance = RND[0..255] << 12 / (lure rate)
CEncounter = (Chocobo Battle 1 chance)
Chosen Battle = -1

If Cchance < CEncounter Then
   Chosen Battle = Chocobo Formation 1
   CEncounter = CEncounter + (Chocobo Battle 2 chance)
End If

If Cchance < CEncounter Then
   Chosen Battle = Chocobo Formation 2
   CEncounter = CEncounter + (Chocobo Battle 3 chance)
End If

If Cchance < CEncounter Then
   Chosen Battle = Chocobo Formation 3
   CEncounter = CEncounter + (Chocobo Battle 4 chance)
End If

If Cchance < CEncounter Then
   Chosen Battle = Chocobo Formation 4
End If

If Chosen battle = -1 Then
   <pick a random battle from zone's encounter table>
End If

Let's take a look at the Cchance values:

Code: [Select]
Lure rating on the top
RND down the left
4 8 12 16 20 24 28 32
0 0 0 0 0 0 0 0 0
1 1024 512 341 256 204 170 146 128
2 2048 1024 682 512 409 341 292 256
3 3072 1536 1024 768 614 512 438 384
4 4096 2048 1365 1024 819 682 585 512
5 5120 2560 1706 1280 1024 853 731 640
6 6144 3072 2048 1536 1228 1024 877 768
7 7168 3584 2389 1792 1433 1194 1024 896
8 8192 4096 2730 2048 1638 1365 1170 1024
245 250880 125440 83626 62720 50176 41813 35840 31360
246 251904 125952 83968 62976 50380 41984 35986 31488
247 252928 126464 84309 63232 50585 42154 36132 31616
248 253952 126976 84650 63488 50790 42325 36278 31744
249 254976 127488 84992 63744 50995 42496 36425 31872
250 256000 128000 85333 64000 51200 42666 36571 32000
251 257024 128512 85674 64256 51404 42837 36717 32128
252 258048 129024 86016 64512 51609 43008 36864 32256
253 259072 129536 86357 64768 51814 43178 37010 32384
254 260096 130048 86698 65024 52019 43349 37156 32512
255 261120 130560 87040 65280 52224 43520 37302 32640

You can calculate the rest on your own if you'd like, they're not really important. What is important is at the point that the calculated Cchance is LESS THAN the encounter rate of the zone then you will get a chocobo battle. This is why with a maxed out lure rating of 32 you'll always get a chocobo battle. The largest Cchance is 32640 which is less than each zone's last formation's encounter rate. We can reduce this a little further into two more graphs: Chance you will encounter a chocobo, and chance of each formation is encountered based on lure rate. Here's the chance you'll encounter a chocobo formation by zone:

Code: [Select]
8 12 16 20 24 28 32
Farm 75 100 100 100 100 100 100
Junon 50 75 100 100 100 100 100
Other locations 25 37.5 50 62.5 75 87.5 100

I don't think lure rate of 4 is possible unmodded so I omitted it. If a chocobo battle IS to be encountered, here's the percentage chance of each formation based on the lure rate:

Code: [Select]
8 12 16 20 24 28 32
Farm1 25 28.1 37.5 46.8 56.3 65.6 75
Farm2 25 28.1 37.5 46.8 43.7 34.4 25
Farm3 25 28.1 25 6.3 0 0 0
Farm4 25 15.6 0 0 0 0 0
Junon1 25 25 25 31.3 37.5 43.8 50
Junon2 25 25 25 31.3 37.5 43.8 50
Junon3 25 25 25 31.3 25 12.5 0
Junon4 25 25 25 6.1 0 0 0
GS/RT1 15.6 15.6 15.6 15.6 15.6 15.6 15.6
GS/RT2 15.6 15.6 15.6 15.6 15.6 15.6 15.6
GS/RT3 34.4 34.4 34.4 34.4 34.4 34.4 34.4
GS/RT4 34.4 34.4 34.4 34.4 34.4 34.4 34.4
Wutai1 25 25 25 25 25 25 25
Wutai2 25 25 25 25 25 25 25
Wutai3 25 25 25 25 25 25 25
Wutai4 25 25 25 25 25 25 25
Snow1 9.4 9.4 9.4 9.4 9.4 9.4 9.4
Snow2 9.4 9.4 9.4 9.4 9.4 9.4 9.4
Snow3 40.6 40.6 40.6 40.6 40.6 40.6 40.6
Snow4 40.6 40.6 40.6 40.6 40.6 40.6 40.6
Mideel1 21.9 21.9 21.9 21.9 21.9 21.9 21.9
Mideel2 21.9 21.9 21.9 21.9 21.9 21.9 21.9
Mideel3 28.1 28.1 28.1 28.1 28.1 28.1 28.1
Mideel4 28.1 28.1 28.1 28.1 28.1 28.1 28.1

Percentages are approximate. Some formations cannot be encountered with higher lure ratings because the Cchance is never less than the value of the previous formations. ie, Farm4 cannot be encountered with a single mastered lure because the Cchance maxes out at 52224 at that lure rate and that will be caught by Farm3 since it's encounter chance is >73k.

To find the chance to encounter any of these individually as a broader function of "will I encounter this formation when a battle occurs", just multiply these two values together.
For example, the chance of getting Farm1 with a level 1 lure is 25% * 75% = 18.75%
the chance of getting Mideel2 with a level 1 lure with a level 2 lure is 21.9% * 62.5% = 13.7%

You can probably work that out based on the information I posted above. With a maxed out lure rating of 32 you're guaranteed a chocobo encounter each time. They're not quite selected the same way a random battle is. If your lure value is high enough you will get a chocobo battle, else it will be a regular battle. Are you talking about encounter rates? Those are a little different and don't work the same way on the WM than they do on the fields.

Based on your table, a level 1 lure will give each battle encounter a 25% chance of being a chocobo battle "everywhere else" which isn't true because North of Rocket Town and Costa del Sol regions have higher chances of an encounter (about 58%). The Farm and Junon are correct, though. That "everywhere else" only applies to Wutai's, Mideel's, and Snow Field's tracks.

If you need a more detailed explanation and an actual table I might be able to provide one tomorrow.

Each polygon of the WM has a flag that labels it as having chocobo tracks. If you are on one of those polygons and your chocobo rating is > 0 (max of 32) then it will check for a chocobo formation.

A "random" encounter byte will be chosen from the encounter PRNGLUT and be multiplied by 4096 then be divided by the chocobo encounter rate. If the chocobo formation encounter chance is greater than this rate, then a chocobo battle will be selected. There are 28 chocobo formations

Code: [Select]
Area formation chance
1,0,0 38 24,576 - Farm
1,0,1 39 49,152
1,0,2 3C 73,728
1,0,3 3D 98,304

2,0,0 4E 16,384 - near Junon
2,0,1 4F 32,768
2,0,2 50 49,152
2,0,3 51 65,536

4,0,0 62 5,120 - outside Gold Saucer desert
4,0,1 63 10,240
4,0,2 68 21,504
4,0,3 69 32,768

8,0,0 98 5,120 - North of Rocket Town
8,0,1 99 10,240
8,0,2 9C 21,504
8,0,3 9D 32,768

9,1,0 0A2 8,192 - Wutai island
9,1,1 0A3 16,384
9,1,2 0A6 24,576
9,1,3 0A7 32,768

B,1,0 0CA 3,072 - Snow fields
B,1,1 0CB 6,144
B,1,2 0CE 19,456
B,1,3 0CF 32,768

C,0,0 0D6 7,168 - Outside Mideel
C,0,1 0D7 14,336
C,0,2 0DA 23,552
C,0,3 0DB 32,768

I can't guarantee those locations are accurate and don't worry about what the area column means; They're not the point. What IS the point is that the value in the encounter rate has to be LESS than any of these numbers in order to encounter a chocobo in the designated area. If none of these formations are selected then a random battle in the region will be selected. There's some other check I don't recognize that doesn't influence the calculations at all.

For example, I'm in the area around Junon with two max level chocobo lures. The chocobo rating is capped at 32.
A battle check occurs and the PRNGLUT gives me a 36.
36 << 12 = 147,456
147,456 / 32 = 4,608
Chocobo Formation 4E is encountered

If the PRNGLUT gives me 160, then I get
100 << 12 = 655,360
655,360 / 32 = 20,480
Chocobo Formation 4F is encountered

From an old post of mine:

Just change those values to 90 90 instead of what I suggested and they’ll get full exp instead of half or none

I noticed that in the other kernel.bin structures. Does it actually save enough space to justify the wasted bytes? Or is it an issue of speed?

I believe it's an issue of design. This is designed to work on a 32-bit environment so it likes to have sizes that can "cleanly" fit into 32-bit chunks. It can do other sizes, of course, but accessing is just easier if everything is "rounded off" to the nearest 32-bit measurement. It's a preference of the compiler, I'd imagine. By default it adds lots of padding to try to prevent memory leaks and the like.

Has anyone tried zeroing out the first eight dummy bytes to see if anything happens?

Yes I have. They are actually spacer/padding values because the Item data structure is derived from Action data structure. In order to make them loadable by the same method, the first eight bytes of Action data is just dummied out. I have verified this by reversing the PC executable extensively.

Where can I find a listing of names for each item in order?

I assume it's 256 items, with a dummy item for empty slot.

I assume no one has a listing of item names, and I'll have to rip them myself to prevent mistakes.
1. Are they index-addressed fixed-length, or pointer-addressed null-terminated?
2. Are they ASCII or some other weird format that lacks the standard ASCII subset?
3. If it's pointer addressed, is there any weird stuff for duplicated names or entries without names?

Found item and materia digits on GameFAQs, in a Gameshark FAQ.

I would have said use Wall Market, but lots of people are having problems with it because Power Packs 3 doesn't work with the current edition and it's hard to find now. :( I've removed that dependency for version 1.5, but that version is still too far from release-ready.

The Damage Calculation page links to a detailed Damage Formula page, but there's nothing there.

The actual link is here. For some reason this wiki doesn't like altering links even if it is to the same wiki.

I assume that the power in this page is Item byte 0x0F ?
Are there programs you recommend to extract the kernel subfiles and ungzip them?

Is there a GUI program that does one or both jobs?

If not, is there anything I can call in a python script to ungzip them and then gzip them later (I prefer to newb-proof things as much as I can)?

Has anyone written something I can reuse (open source because lol it's a python script I ain't compiling shit) to deal with gzips if the best scenario for users is making new scripts to deal with the kernel?

Cebix has tools to do this stuff, though they're python 2.7 and have some other dependencies.
Shouldn't be too hard to port the code I need to Python 3, and grab whatever license he uses.
If I were you, I'd just crack open a save state and search for the first few bytes of item data. If that doesn't work, search for a set of adjacent and very distinct bytes, first using XVI32's count function, then the search function when you get a small enough data set.

Wall Market, but see above. :(

Item format is here:
In fact, the first nine sections of the KERNEL.BIN entries should interest you:
Most of that is my work so I'm the one to ask questions of on any of those sections.

The KERNEL.BIN gets unpacked into the same location in RAM each time the game is loaded. I know where the pointer to the PC values is (nine Dword values at 7BA070 point to the locations in memory where each of the sections end up), but it might not translate the same for PS1. PS1 might unload the KERNEL files into the same addresses each time.

Let's start with something simple like items. What format do you want the data in? Can you give me an example?

I think I see what you're getting at. I haven't done much PS1 emulator hacking, but since the RAM is always the same it shouldn't be difficult to find the data. I know the entire KERNEL.BIN (where all the battle-related object data is) is always present in memory during battle so it should be in a static place each time. It can't be too hard to find it.

I've got data for battle related stuff (except for encounter tables), but it's not super well organized. Every byte and most bits have documented functions too. Just tell me what you need and I'll work with you.

What de-hardcoding hack are you thinking about? It seems possible to un-hardcode some things with the right memory hooks. To my knowledge there are no such hacks for battle-related mechanics.

Enemies MDef% (magic evade) stat always = 0, I have not seen a single monster with this stat more than 0, but, I didn't check every monster. Enemies MDef% (magic evade) stat is found: current HP of the monster (in battle) + 33 bytes, in the PC version of FF7 (2012) v1.06. If this stat is increased manually, to 77 or 88, then the monsters evade magic, such as Matra Magic.

I was meaning more about the Dex bonus not applying to enemies. Enemies have no value set for their magic evade. For Dex and evade purposes, it's looking at the actor and target's 40A0 (Dex stat) and 4078 (phys evade) values. The Dex bonus does not apply to enemies. There is an enemy check I overlooked because it's written weird.

Also, the accuracy is affected by darkness status, Flash command and Deathblow command .
Physical Chance = (Actor's Dex / 4) + (weapon's hit rate / 2) for darkness status and Flash command
Physical Chance = (Actor's Dex / 4) + (weapon's hit rate / 3) for Deathblow command

Actor's evade = (Actor's Dex / 4) + Actor's Physical evade
Target's evade = (Target's Dex / 4) + Target's Physical evade;  for monsters Target's evade = Target's Physical evade; without (Target's Dex / 4)
HitChance = Physical Chance + Actor's evade - Target's evade

The Dex bonus also applies to the Actor's evade calculation. Enemies will not receive it at all. I'll update the calculation page.

I was surprised the actor's evade factors into it. It might make more sense to just divide dex by 2 for the actor  (or not at all) and accomplish the same goal. Then the mechanics make more sense that accuracy is more about the actor's personal skill and less about their equipment. It does explain why a hit rate of 255 always connects. Only Ruby Weapon and its tentacles have evade stats high enough to overcome that.

TFergusson said this:
" enemy's Df% will not get any bonus from their Dex - for monsters, it's considered the final stat. However, Dex is still used to help increase the enemy's chance to hit, for example.  Enemies also do not have a MD% stat, a weakness that is useful to exploit."
I didn't notice an enemy check at that step. I'll have to double check that.

Pages: [1] 2 3 4 5 6 ... 120