[PSX/PC] Battle editor - Proud Clod (1.5.0/FINAL)

  • Thread starter Thread starter nfitc1
  • Start date Start date
Status
Not open for further replies.
i will see what i can do while i am in the file... 99 shouldn't be too hard to find, just like 70, but there will be a lot of places to check & change, so if i do find it, it will probably take some time. i will get to work on it, and i hope i find it as well so that more psx/pc mods are available, as in difficulty mods for both versions.
 
And a little warning; the different versions of ff7 use different structures and the solution for the PAL UK version (for example) might be different from the solution for the NTSC US version...

Anyway, the multiplier is at 0x0031F14F and 0x0031F19E for the PC version 1.02:

Offsets:Code: [Select]
Code:
0x0031F14F - for actual price when selling0x0031F19E - probably just for display in shops
I don't know anything about the coding language in which ff7 was written, so I can only see bytes in hexadecimal, and since the PSX version is encoded in a different binary language, it'll be impossible to get anything by looking for a string of hex-values.
 
Last edited:
well i found a 46 near an area in the file with the main menu names (item, magic, materia... and the fury/sadness names in the menu as well), but the only master materia i have is sneak attack... my other materia didn't master for some reason >_>. time to whip out the save editor (the shop value did not change, but one affects the visual value, one the actual value, and so if i found the actual sell price, then i cannot know until i sell.

also, does the price that you get for unmastered materia go up based on ap (as in 1ap = 1 gil), or does it go up based on the max price and master ap cost? i mean it sells for 1000, and masters at 10k, would it raise 1 per ap gained, gaining master price at 1/10 of the master requirement, or would it gain 1 gil for every 10 ap gained, making it max out when mastered? i know all doesn't do this, but for smaller capped materia, if it raises one gil per ap, then it could max before hitting master, or possibly go over the cap, selling for more than master with high enough ap, and then kicking back to master price when mastered.

meh... i'll just cheat and make all enemies in the train graveyard give 65535 ap apiece :P. felt nice to master a restore materia in one go... but sux that it wasn't the right value, so the price wasn't altered at all >_>.

you are sure it isn't in the shopmenu.mnu file? there are only 84 instances of the 46 hex number, so i could try them all (those are excluding the ones in visible text strings)
 
Last edited:
Unfortunately, there are a lot of 46s to get through  :-D

And I don;t know anything about what part of the code determines the AP based price, but in any case, the selling cost raises by 1gil for every AP, so if materia are given a low price (and the master materia multiplier is low as well) they will sell for more when they have a lot of AP than when they are mastered.

I don't think it's in the shopmenu.mnu file, but I can't be certain. I suppose there's no harm in looking.
 
well, the bottom most part of the shop file doesn't have it at least, but iwasn't really surprised by that. the scxx file has 255 46's in it, so that could take some time. i know changing one of them to 10 makes the menus and such not appear :P. and of those, 224 (or 234, lost count) are possible spots it could be.

just have to do some error checking then when editing the master price and the master ap cost then, or make less sellable for a good bit, making the sellsable ones as high selling as they take to master, making it essentially an ap to gil conversion. what makes the materia with a 1 master cost stay at one sell price all the time, is it just setting the sell price to 0, and the game automatically makes it a max of one?

in the pc version, there are two 16 byte sections where the value is (it is inside the section, fourth byte in), one for the actual sell price, one for the shop's display (apparently), and all but two bytes in these two sections are the same, one before, and two after the value. maybe something similar will appear in the slxx file, even if the formats are different, the layout "should" be similar for the section it is in. the value might appear in two almost identical areas, and should be pretty close together. i hope i am right about this.
 
Last edited:
in the pc version, there are two 16 byte sections where the value is (it is inside the section, fourth byte in), one for the actual sell price, one for the shop's display (apparently), and all but two bytes in these two sections are the same, one before, and two after the value. maybe something similar will appear in the slxx file, even if the formats are different, the layout "should" be similar for the section it is in. the value might appear in two almost identical areas, and should be pretty close together. i hope i am right about this.
I've been looking for something just like that (although I haven't been looking very hard  :-P)

Something tells me it might not be quite as straightforward as that, but it will probably be less tedious than trying out all of the 46s.
 
well i found something... it causes the shop menu to either cause the game to crash, or just stop loading (pointer to the file maybe?) when altered, and another similar to it doesn't seem to affect the shop menu at all, but doesn't change the master price either. i will tinker some more with it, maybe it is just a pointer, and the actual value i am looking for is nearby?

also, my computer froze on me, so that put me a little bit behind...

ok, it is definitely a pointer to the menu folder or something, because even the regular menu is forzen/bugged out by the changed value... time to move on.

i also found a value that when changed cut off half of the first line of text (the top half, not removing text... making only the bottom half of the text visible)... it seems likt i may have to manually change every value one at a time until i find the right one...

going to search the shopmenu.mnu file again... just because the pc version has things in the exe doesn't mean the psx one has it's info in the main file (the .exe has the info there, but it doesn't have the menus split into separate files, just has one lgp file for the menu stuff, so it is possible that the value is in the mnu file for the psx).
 
Last edited:
well, there are only 42 spots in the shopmenu.mnu file that i havent changed (changed all in one fell swoop, it froze, then i changed everything that was below ~42c0, so all that is left to change is the stuff mixed in above. it shouldn't take too too long to find, though i may have to stop here shortly, since my friend is over.
 
Last edited:
ok, from what i have seen, if it is stored as a 46 hex number, which it should be, then it isn't in the shopmenu.mnu file from what i can tell, though i did find some unusual things (all were changed from 46 to 10):
0x17bd - selling materia would freeze the game
0x2929 - same as above, but for buying items (froze on entering the buy screen though)
0x2d02 - changed all itme buy prices that were shown to 16777215, still cost the same as usual though
0x2dc0 - screwed up the item icon in the buy windo (not the sell window though)
0x301d - causes it to freeze when selling a materia
0x3052 - changed the sell prices to 1 (not sure if it actually sold for 1, didn't check)
0x316e - made the prices very odd (not 16777215, but very high), made the remaining gil off as well, but sold as if nothing changed, so normal sell price
0x4151 - froze the shop on entering

i am still going to bet that it is in the slxx file, since that is like the .exe of the psx version, unless it isn't stored as 46 or some reason, but i am not going to check right now. i want to check for some more ai unknowns, a much easier thing to do than search a large file for one (or two) values.
 
Well you dont have to do it, gotta give you props for trying.  Hopefully you dont quit like i did, but take your time.

Man i'm messing with too many games and i really wish i knew something about compression.

Edit:  0x3052 - changed the sell prices to 1 (not sure if it actually sold for 1, didn't check)

IF this one works i'm happy with this also lol.  Need to check on it later.
 
Last edited:
it was for the actual items, not materia, so it wasn't what you were looking for.

4280|ReturnedGil - the gil an enemy gives as soon as they are killed
4290|ReturnedItem - same as above, but for the items

these are how the vice type enemies (thieves) give back the item they stole from you, but it can also be used to have any enemy give an item/gil right away when killed.

ok, is it possible for an enemy to not drop an item, even with a 63 chance of dropping it? because if  they aren't able to not drop it, then the area from 41a0-41bf may have some effect on the drop rate, since i had one occurrence without any potions, and a few with only one drop...

and bug report, if you click on open with a scene.bin already open, then cancel out, and try to save, it will give an "invalid path" error, likely because it stopped pointing to the current open scene, and became pointing to nothingness.

i also think that something with PrC is causing internal issues with my computer, as i have gotten multiple BSoD (blue screen of death) errors, all with the message IRQL_NOT_LESS_OR_EQUAL, and the most recent one happened after experiencing the previous bug a few times (may not be related), but it did cause some oddities with the ai (like the newfound variable not setting right), but now it is working and i was able to get it to drop an item on the first attempt this time, while the bugged time was causing errored items to appear in my inventory.
 
Last edited:
ok, PrC bug time... when trying to add something to a blank section of ai, if the first thing added besides the end statement is a string to be displayed, and then you click tab/enter/click away, the thing will give you an error message, as well as making the script vanish, and the only way to get around this is to click back onto the script section you tried to edit, skip past the error, and reenter your info (it will allow you to add the script with no trouble the second time around)
I think this is now fixed.

also, i noticed at some random time when trying to change an opcode from 12 to 10, the field where the newly entered 10 was, was completely blank, and iirc the hex offsets were all screwed up, and there was no end statement in the disassembled code, though it was in the actual script (side effect i am guessing, fixed when i reentered the opcode).
I think this is fixed too.

and something else that has been bugging me for a little while, but i kept forgetting to post, was the problem that occurs when filling a box, then clicking into another box without hitting enter or tab, the data stays, and everything is seemingly fine
Not planning on fixing.

and bug report, if you click on open with a scene.bin already open, then cancel out, and try to save, it will give an "invalid path" error, likely because it stopped pointing to the current open scene, and became pointing to nothingness.
Fixed in two lines.

Also fixed a bug where trying to enter a 93 or A0 opcode in a blank script would crash the program.

Added a new feature. Currently very basic (but fully-functional) because most values are unknown and making this was easier than making a lot of "unknown" fields.

I'm also considering a multi-pass disassembling feature that would pass through the script more than once (hense "multi-pass") to make a more accurate disassembled code. No more of that scripts ending in an else block, etc. Only thing is that it would probably take more time. For longer AIs this could take minutes. Of course the single-pass disassemble (the one that's there right now) would still be there, but another button would exist below it to allow for multi-passes.
 
Last edited:
looks good, i think that i am correct on half of the battle setup 2, i have to do more checking though, but got tired of  havng to recreate the scene.bin from pieces :P.

still trying to find the drop/steal (and morph :P) items in the ai, but finding the gil/item drop thing that is used from the thief enemies like vice, so i can use that as a last resort if needed.
 
Added a new feature. Currently very basic (but fully-functional) because most values are unknown and making this was easier than making a lot of "unknown" fields.
Oooh, I like the look of this  :-D

I'm also considering a multi-pass disassembling feature that would pass through the script more than once (hense "multi-pass") to make a more accurate disassembled code. No more of that scripts ending in an else block, etc. Only thing is that it would probably take more time. For longer AIs this could take minutes. Of course the single-pass disassemble (the one that's there right now) would still be there, but another button would exist below it to allow for multi-passes.
As long as both options are there, this sounds like a good idea as well.
 
heh... i found a set of flags for making an enemy receive a status when hit (similar to setting an attack to a 63 chance, but for all attacks received), gonna check to see if it works for magic as well and not just attacks (using blade beam with death on it caused an enemy to not be hit by it, and be made unable to be completely killed... i had to use life so i could kill it :P). going to check for more about it, but it starts on 4040, and should end on 405f.

still not entirely sure on the mechanics behind it, because i killed one enemy, and the other gained shield, not the original one hit.

it seems to not cause the status to the main enemy, but causes it to the other enemies in the group... it could just be to the other enemies of the same name... still more checking to do :P. it caused a status to a guard hound when set to an MP, so it could be used on bosses to give their allies a status when hurt (does not work on the first enemy so far, even with two of the same in battle).

ok, from what i can see it acts like a status version of blade beam, causing statuses to enemies in the same row, but will work at any time. however it will not work on the original enemy so far...
 
Last edited:
OK, I uploaded the working version for now. There is no multi-pass that you can use yet. As soon as I figure it out I'll let you know.

The current one is actually between a one and two pass. It's decoding everything line by line then going in and spacing everything out. This is, of course, much of what I want to change with the multi-pass, but keeping track of all the jumps is hard. So far it's doing about four passes and it's still not right. Don't take that to mean it's going to take any longer.
 
Yeah, the formation editor looks good!  :-D

I noticed that the 0x402C flag was unknown. When it's checked, the death animation (red fadeout) will not occur. And when the enemy is killed, the idle animation will simply continue. Well, at least this is true on the single enemy I tested it on.  :-P There kinda was a huge facepalm in the AI of my "phoenix boss" where the enemies' models wouldn't be visible when revived. Thus I checked the 0x402C flag and upon death the idle animation simply continued (though not targetable and quite dead).

And I use the 0x4020 and 0x4023 flags unchecked to make the enemies unmarketable, invisible and not needed to kill to end the battle. I can't quite remember but as I recall 0x4023 is the targetable flag. At least if both are unchecked, the above is true. Sorry if this was old news.
 
yeah, i said about the NoDeathAnimation flag a little bit back and the 4020 is the flag to make them invisible, and you will also need to turn off the main battle script and enable the death flag (not quite sure on this) to make them stay dead.
 
Status
Not open for further replies.
Back
Top