326
Scripting and Reverse Engineering / Re: Editing the battle scripts
« on: 2017-05-09 20:25:48 »
Both the field and the battle scripts have access to the entirety of the savemap.
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.
327
WIP / Re: [FF7PC] The Big Bug List - post bug reports here
« on: 2017-05-08 19:10:19 »
You should probably do it at the end of each field script. That way you can Game Over at a reasonable time. In the case like this, where you do damage then heal, it would kill at the appropriate time and not mid-dialog.
328
General Discussion / Re: Need Primary Stat Level Up Increase Formula (FF7)
« on: 2017-05-08 17:51:54 »Also, it's confirmed...This is known. It's a floating point error when the graph gets high. I've corrected it in the not-yet-released version.
You have an off-by-one error in wall market:
[img]
329
WIP / Re: [FF7PC] The Big Bug List - post bug reports here
« on: 2017-05-08 16:34:03 »
Which part of the main loop? The field's main script or the game's main loop?
330
General Discussion / Re: Need Primary Stat Level Up Increase Formula (FF7)
« on: 2017-05-08 16:27:04 »
And the Wall Market I'm currently working on will display the values a little more prominently. As it is you have to hunt for the values you want.
331
WIP / Re: [FF7PC] The Big Bug List - post bug reports here
« on: 2017-05-08 16:23:08 »I think the function needs to be able to do that in other places though. To be able to revive or kill based on simple assignments to HP of a character. I'm not sure where else it's used. What was really needed was a function to set HP to an absolute number rather than "decrease" and "increase". They likely came up with the idea of "make HP 1 after being hit with the needles" later in development.Then the fault is in the field script. I just checked it and it just removes 501 HP and restores 1. That will heal all dead characters.
What I am doing for Weapon is simply making these needles and so on an instant death or other bad effect like decrease HP. If all 3 chars are 0 HP, then game over. The latter is already another bug (all 3 chars can be dead on field), which will need fixing.
What needs to happen is the field script needs to be rewritten AND new codes need to be added. It needs to remove 500 and trigger the game over if all HP are 0. As you mentioned before there is no way for the field to check the HP of the party members. That needs to change. Codes 3C and 3D could be hijacked to return the HP and MP values of the party members.
332
General Discussion / Re: Need Primary Stat Level Up Increase Formula (FF7)
« on: 2017-05-08 15:55:21 »
Do you have the game? The KERNEL.BIN is in your %installation directory%/data/kernel folder.
It reads the curve data and initial stat values from in the file and projects a range of possible values for each stat at each level in the Inital Data -> Character Growth tab. Select a character and a stat and it will show you a graph that is reasonably accurate.
It reads the curve data and initial stat values from in the file and projects a range of possible values for each stat at each level in the Inital Data -> Character Growth tab. Select a character and a stat and it will show you a graph that is reasonably accurate.
333
General Discussion / Re: Need Primary Stat Level Up Increase Formula (FF7)
« on: 2017-05-08 11:55:25 »
Wall Market already does this, but this interface looks cleaner.
Stats of equipped items don't factor in to this equation. Neither do sources.
Stats of equipped items don't factor in to this equation. Neither do sources.
334
WIP / Re: [FF7PC] The Big Bug List - post bug reports here
« on: 2017-05-07 17:02:44 »Make sure to specify which tab. There are a few #14s... though I assume you mean Field #14.didn't notice the tabs. Yes, I meant the field bug. The trick is "don't revive, but don't kill either". The field opcode probably needs an asm edit.
335
WIP / Re: [FF7PC] The Big Bug List - post bug reports here
« on: 2017-05-07 15:40:34 »
I bet I can fix number 14 (reviving dead characters with damaging scripts). That'll either be a field fix or a exe tweak.
336
Scripting and Reverse Engineering / Re: In-Battle Menu Refresh, and Limit Gauge address
« on: 2017-05-05 21:48:42 »Hmm... it seems to work only when it feels like it. Like I'm pretty certain I saw the Limit Bar go down at some point, but at another point both Cloud's and Barret's were nearly full at the end of a battle and they were both still that high when I entered the next battle.
It should happen to every character that survives the end of the battle (meaning if they are dead at the end of the battle their limit bar will not be affected, but at that point it should be 0, right?). There may be some cases where this code doesn't activate, but I'm pretty sure it happens any time experience is gained (you didn't have all characters run from battle).
337
Scripting and Reverse Engineering / Re: In-Battle Menu Refresh, and Limit Gauge address
« on: 2017-05-05 18:02:17 »SO NFITC1, you'd be adept with asm too?Sure. You could PM me any time.
Once we figure out a solution for this guy think you could help me with something?
338
Scripting and Reverse Engineering / Re: In-Battle Menu Refresh, and Limit Gauge address
« on: 2017-05-05 17:32:20 »Regarding max HP, I presume there's no way to modify the correct value then?
I sense that I misrepresented what's happening and why your approach doesn't have the desired effect.
During battle, each actor (technically even the "set pieces" like the manholes and the tiny bronco) has a unique array of data that stores things like status, attack power, HP, MP, MHP, MMP, etc. For all damage calculations and status considerations the game uses this array to perform its calculations against. However, the menu at the bottom of the screen does not. At the beginning of the battle the battle module reads the data from the save data for the characters and creates the menu from these values. During a normal battle, MHP/MMP are NEVER UPDATED. The only exception is the battle arena which essentially rebuilds the menu from this array at the end of every battle. That's how the break materia/half HP/level down effects work. They adjust the character's data and the menu is rebuilt. There is no way to trigger this in the middle of a normal battle.
As for the limit changes, get a hex editor and make the following changes:
Code: [Select]
Address: Former Value: New Value:
=========================================
0x1C60A4 8B 8A
0x1C60A5 45 8A
0x1C60A6 E0 C0
0x1C60A7 8A 8D
0x1C60A8 8A 9A
0x1C60A9 C0 00
0x1C60AA 8D D0
0x1C60AB 9A F9
0x1C60AC 00 90That should halve the limit bar value at the end of each battle for each character. Limits will be hard to get at upper levels after this.
339
Scripting and Reverse Engineering / Re: In-Battle Menu Refresh, and Limit Gauge address
« on: 2017-05-05 16:06:57 »
Neither are possible with AI.
The Max HP value is not really meant to be manipulated. The Battle Arena actually modifies the correct value, but the AI changes what is essentially a virtual value that is the monitored value rather than the displayed value.
The second one requires you to change the asm that stores the limit value in the save map. Reasonably easy change from 005C6CA4 to 005C6CAC.
The Max HP value is not really meant to be manipulated. The Battle Arena actually modifies the correct value, but the AI changes what is essentially a virtual value that is the monitored value rather than the displayed value.
The second one requires you to change the asm that stores the limit value in the save map. Reasonably easy change from 005C6CA4 to 005C6CAC.
340
Scripting and Reverse Engineering / Re: FF7/FF8 Steam Frame Limiter Bug
« on: 2017-05-04 16:23:08 »
it looks like 40AB4B is called once at the beginning of execution and the result is considered a global constant. It's stored in a big array along with certain graphics handler pointers and window setting values.
I understand why the sleep function was created in the first place and modern conventions say stay away from it, but this port dates back to '99 or '00 so it's not likely that the problems of these processor-level functions had been exposed.
I understand why the sleep function was created in the first place and modern conventions say stay away from it, but this port dates back to '99 or '00 so it's not likely that the problems of these processor-level functions had been exposed.
341
Scripting and Reverse Engineering / Re: FF7/FF8 Steam Frame Limiter Bug
« on: 2017-05-03 19:05:07 »
0040AB4B has some interesting clues as to how the variable is formed. It's using timeGetTime to determine how many milliseconds it takes to perform a certain number of operations and how fast it can perform one operation and basing the time between frames on that.
Actually, no. It makes FAR less sense than that. It contains beautiful snippets like this:
That's the most meaningless use of timeGetTime I can imagine. It doesn't do anything and it looks like it's literally designed to waste time. The next snippet at least makes some sense:
40AA12 gets the value from rdtsc (Read Time-Stamp Counter). Then it calls 40AA62 that then compares the two results and returns the delta. Essentially this is reporting the delta of rdtsc with a one second delay, but only sort of. From the documentation of rdtsc:
That's a strange way of saying that what is returned may not be the exact value of the TSC (Time-Stamp Counter) by the time the instruction is completed.
In any case, this delta is what is the basis of the function DLPB mentioned at 4020C0. Because of the non-guaranteed read accuracy this won't directly represent a second and when this value is divided by whatever is passed to it.
1A78DC0 is the rdtsc delta divided by whatever passed value is.
1A78DC8 is 1000 divided by whatever passed value is.
The combination of these values and a few other sets a sleep function between frame draws (4020F0). That's where the inaccuracy lies. RDTSC and Sleep aren't serialized functions so their effects aren't exact. It probably works WAY differently on PSX because all the hardware is identical. Since there are hundreds (thousands maybe?) of PC processors you'd have to include a timing function to set the sleep function (which is the wrong way to do it).
Actually, no. It makes FAR less sense than that. It contains beautiful snippets like this:
Code: [Select]
v3 = 1000;
v4 = 1;
if ( v4 >= 0 ) v3 = v3 / v4;
for ( i = timeGetTime(); i OR FFFFFFFFh <= 2 * v3; i = timeGetTime() ); //purposefully wait until timeGetTime's lower DWord value is less than 2000; BUT WHY?!
i = timeGetTime();
while ( i == timeGetTime() ); //This will have a small difference, but it never does anything with this delta
That's the most meaningless use of timeGetTime I can imagine. It doesn't do anything and it looks like it's literally designed to waste time. The next snippet at least makes some sense:
Code: [Select]
i = timeGetTime();
sub_40AA12(&v2);
while ( timeGetTime() - i <= v3 );
sub_40AA12(&v5)40AA12 gets the value from rdtsc (Read Time-Stamp Counter). Then it calls 40AA62 that then compares the two results and returns the delta. Essentially this is reporting the delta of rdtsc with a one second delay, but only sort of. From the documentation of rdtsc:
Quote
The RDTSC instruction is not a serializing instruction. Thus, it does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed.
That's a strange way of saying that what is returned may not be the exact value of the TSC (Time-Stamp Counter) by the time the instruction is completed.
In any case, this delta is what is the basis of the function DLPB mentioned at 4020C0. Because of the non-guaranteed read accuracy this won't directly represent a second and when this value is divided by whatever is passed to it.
1A78DC0 is the rdtsc delta divided by whatever passed value is.
1A78DC8 is 1000 divided by whatever passed value is.
The combination of these values and a few other sets a sleep function between frame draws (4020F0). That's where the inaccuracy lies. RDTSC and Sleep aren't serialized functions so their effects aren't exact. It probably works WAY differently on PSX because all the hardware is identical. Since there are hundreds (thousands maybe?) of PC processors you'd have to include a timing function to set the sleep function (which is the wrong way to do it).
342
Scripting and Reverse Engineering / Re: FF7/FF8 Steam Frame Limiter Bug
« on: 2017-05-02 22:36:14 »That's not how a proper limiter should work at all. You can't just put an extra 0.5 on if things aren't working out for you lol.Since when has "proper" stopped Square from doing things?
343
General Discussion / Re: Final Fantasy IV: The Complete Collection. Hold more than 48 items in inventory?
« on: 2017-04-17 14:18:25 »
There's not one and won't be one. This would require nearly an entire rewrite of the mechanics of the game to account for the larger inventory.
344
FF9 Gameplay Releases / Re: [FF9] 0 AP Mod
« on: 2017-04-12 18:48:17 »
Sounds like a pain blast to play. All equipment would need to be rebalanced to be workable at all points in the game.
345
Scripting and Reverse Engineering / Re: FF7 PC possible program?
« on: 2017-04-03 14:27:29 »I thought there was a directory tree in magic.lgp hmm..Hey, halkun. It's been a while.
There is a listing of folders, but within the internal structure of the magic.lgp there is no link between the files and folders. I've analyzed the archive several times in the past and there just isn't any indication of what belongs with what. The only thing that binds them together is in the exe. The game just knows which file to look for (I think based on the file's position, not offset, in the archive). The folders might be completely ignored too. This is VERY poor programming (as most video games are), but at the time those conventions had not been well established.
346
Scripting and Reverse Engineering / Re: FF7 PC possible program?
« on: 2017-04-02 16:45:40 »
@sithlord48:
The biggest problem is the file names are duplicated a lot. There are probably 6 files like 01.tex or similar. Every time I go into the code with the purpose of figuring these files out I am always astounded that it works at all. Most of the code references poly files or rsd files that somehow get the correct texture/model. It makes more sense on the PSX because all the files to one action are archived together. Some "genius" at Eidos decided to make one master archive (magic.lgp) and save no directory structure in it. While that does make it harder to mod directly, it also makes it a pain to separate these files manually.
The biggest problem is the file names are duplicated a lot. There are probably 6 files like 01.tex or similar. Every time I go into the code with the purpose of figuring these files out I am always astounded that it works at all. Most of the code references poly files or rsd files that somehow get the correct texture/model. It makes more sense on the PSX because all the files to one action are archived together. Some "genius" at Eidos decided to make one master archive (magic.lgp) and save no directory structure in it. While that does make it harder to mod directly, it also makes it a pain to separate these files manually.
347
General Discussion / Re: 20 years late is better than never!!!
« on: 2017-04-02 16:38:57 »Oh man, why the DS Remake? The PSP remake is by far the best version of this game.
Yes, but no proto-babil.
348
Scripting and Reverse Engineering / Re: FF7 PC possible program?
« on: 2017-04-01 22:03:47 »
I'd love something like this too. Aali's driver could theoretically do this, but since we don't have the source we might be able to wrap it somehow. I've been toying with this idea for years and can't make a good solution.
349
Scripting and Reverse Engineering / Re: Help required making old ff7 modes windowed.
« on: 2017-03-20 03:18:38 »
Except this was created when DirectX 5 was the latest version. You'll have to find docs to those methods and replicate it with DX9 methods.
A lot of the mechanics of drawing seem to be related to absolute positioning on the screen. I don't know how well that'd translate to windowed coordinates.
A lot of the mechanics of drawing seem to be related to absolute positioning on the screen. I don't know how well that'd translate to windowed coordinates.
350
FF7 Tools / Re: [FF7] KERNEL.BIN editor - WallMarket (v1.4.5)
« on: 2017-03-20 00:16:48 »
Fascinating, but it doesn't belong in this thread.