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 ... 119
1
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.

2
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. :(

3
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.

4
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
Else
   CEncounter = CEncounter + (Chocobo Battle 2 chance)
End If

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

If Cchance < CEncounter Then
   Chosen Battle = Chocobo Formation 3
Else
   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%

5
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.

6
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

7
From an old post of mine: http://forums.qhimm.com/index.php?topic=16953.msg241096#msg241096

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

8
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.

9
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 ?
Yes
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.

https://github.com/cebix/ff7tools
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. :(

10
Item format is here: http://wiki.ffrtt.ru/index.php?title=FF7/Item_data
In fact, the first nine sections of the KERNEL.BIN entries should interest you: http://wiki.ffrtt.ru/index.php?title=FF7/Kernel/Kernel.bin
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.

11
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.

12
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.

13
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.

14
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:
"...an 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.

16
https://wiki.ffrtt.ru/index.php?title=FF7/DamageFormula

That’s probably what you’re looking at. The physical accuracy is complicated and I never got around to updating it.

17
While it would make sense for there to be low res slightly-off images on the chocographs, these would obviously be far superior to work with in-game.

18
Then they're apparently using a text that WM isn't capable of modifying (possibly a different language or a text that is longer than normal). 1.4.5 isn't really equipped to resolve that, unfortunately. You can continue running the program after loading and possibly dump pieces and see if it will let you load those. You might need to edit the attack description piece before loading.

19
This is the tool to use, but this topic needs to be discussion of the tool itself like bug reports or feature suggestions not individual AI scripts you want to modify.

In the future if someone wants to make a similar change in one of their mods it would be difficult to find buried in a topic about the tool rather than the enemy or actual AI editing.

20
Yeah... I have a WIP version that goes between “working” and “not good enough” and “completely broken”. Development stalled a lot during the past year for probably obvious reasons. I still think about it, but at the current point I’m not sure what still isn’t working.

21
That’s not a question about PrC. Please start a new thread

22
7th Heaven / Re: Speed mods
« on: 2021-04-10 05:18:46 »
The steam edition has built in speed hacks and even auto-win hacks. Outside of that I don’t think there are any for older editions.

It’s certainly up to you if you want to use those hacks, but if all you want is gameplay then you would probably be just as entertained by play through on YouTube. Taking out battles is like ripping 60-75% of the game.

23
FF7 Tools / Re: WPN State Modifier...
« on: 2021-03-25 19:04:01 »
Use WallMarket. What do you want done that it can’t do?

24
Troubleshooting / Re: Quadramagic issue
« on: 2021-03-10 16:26:41 »
The 27 is the 0-based decimal index of the animation script and is not directly related to the address of the script in the ab file you want to change. No changes should have been done to the 0x270 location (that's a few bytes into animation script 36 which controls Mug). The 24 script executes, then 25, then 26, then 27.

24 begins at 0x358
25 begins at 0x36C
26 begins at 0x378
27 begins at 0x384

my recommendation is to change the bytes in addresses 0x385-0x38D to C9s. C9 (and B2) have no function so strings of them get passed over in a single frame. In fact, B2 has no purpose as opposed to C9 which is a jump destination. Let's change them to B2s instead. Functionally there's no difference, but purposeless is "safer" than functionless (there's a lecture about purposeless vs functionless in there, but such a lecture would be worthless in this scenario :D ).

Code: [Select]
0x380:   03 24 9E 00 E5 BD B0 04 00 00 F0 F7 03 29 1C FA
 -change to-
         03 24 9E 00 E5 B2 B2 B2 B2 B2 B2 B2 B2 B2 1C FA

If you don't like the way that looks, you can revert 0x38D to 29 to play that last swing animation, but everything else should stay NOP'd.  This line of bytes translates to:

03 - this is from the previous script that triggers the damage number indicator
24 - play the 0-based hexadecimal animation index 24 as defined in the rtda file
9E - effectively pause the script processing until all 3D effects have completed (animations in this case)
00 - This is an alignment byte inside the file so the scripts start on even numbered bytes
E5 - [Here begins script 27] This recenters the orientation (not position) of the actor based on the battle mode (normal, side attack, pincer, etc)
BD B0 04 00 00 - this is positioning code for the next effect code
F0 -  this creates the foot dust particles at the coords specified in the previous code
F7 03 - this triggers the damage number indicator in [03] frames
29 - similar to 24, but index 29
1C - similar to 24, but index 1C
FA - this resets the actor's position to the default coordinates for their slot in the current party and battle mode.

I think this is all the info you need to make the changes in rtab you want. For the other actors' AB files, look at the word value at 0x0D4. That will tell you the beginning address of the script I just showed you to edit.

25
Troubleshooting / Re: Quadramagic issue
« on: 2021-03-09 20:12:38 »
That's actually parts of two different scripts.

Code: [Select]
24:
FC F0 D8(00, 001A) 1A D1(04B0, 0000, 04) F0 1B F7(01) 1E 9E
25:
E5 BD(04B0, 0000) F0 F7(03) 22 9E
26:
E5 BD(04B0, 0000) F0 F7(03) 24 9E
27:
E5 BD(04B0, 0000) F0 F7(03) 29 1C FA F0 1D E5 EE

This is the entirety of Cloud's 4xCut animation script. The game just knows to play these four animations in succession. I would replace the bytes in the list script from the BD to the 29 with a C9 or something like that which does nothing. You'd have to change the animation of animation 36 (24h) or 28 (1Ch) to look like they go together.

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