WallMarket / Proud Clod Final Fantasy 7 editors

Got a few more....

2012-01-26T09:46:00.001-06:00

4280|Gil Stolen
4290|Item Stolen

Used in conjunction with Attack Property 6 and 7 to know how much gil/what item was stolen in case the player defeats the thief.

More reason to make the xml-based text files

2012-01-12T14:05:00.001-06:00

So I've been prodding around in the code looking for new things to discover. Lo and behold I found two interesting things:

1. 9X damage calculations do NOT use the secondary equations
2. secondary damage equation X6 DOES NOT EXIST!

This is why I wanted to add the xml that will allow the user to update their descriptions of various things like damage formulae descriptions.

EDIT: I forgot to mention. 9X is ONLY used by Manipulate to determine if it will "connect" or not.

Update your WallMarket.dat and ProudClod.dat files.....

2011-12-21T08:24:00.000-06:00

So while doing some digging in the executable I found something rather interesting about the AX damage formulae. Turns out they're directly related to the currently blank "Additional Effects" descriptions. Believe it or not, these formulae are using those effects to alter the damage and power of the attacks! So damage formula A0 uses effect 0A, formula A1 uses effect 0B, etc. Check it all out on the wiki.

Now for the more exciting news. I previously stated to a small number of individuals that adding behaviors based on elements would require handling each attack that used that element. If you want to add a counter for a fire elemental then you'd have to make checks if the previous attack was Fire, Fire 2, Fire 3, Ifrit, or Beta. This isn't that convenient if your weapon has a fire elemental attached to it. You can still do fire damage without causing those attacks. WELL, there happens to be a AI battle address that tells you what elements the attack uses.

2120|Attack Element(s)

You can add that line to the .dat files. Oddly enough, this appears to work just fine, but it's never used in any scripts where it would make sense to use. I know there is some enemy that actually does a check if the previous attack is Fire, Fire 2, etc to see if it was attacked by a fire elemental. Like I said before, it won't know if a fire-imbued weapon attacks it though.

That's not all either! There's another address of interesting note. The Attack Properties also get a varible!

2160|Attack Properties

That's the same as the Special Attack Flags as it's labeled in the wiki. This has the potential of determining a few things like if the attack damaged MP, HP was drained, it was a critical hit, etc. Counters can get even more complex now with all this new info. There might even be one for statuses that the attack inflicts or heals. I know there are still at least two values that aren't known that the game DOES point to. There's a 2170 and a 2180 that I don't know what they do. I'll have to look it over.

Additional optimism for AI script separation

2011-11-16T10:18:00.001-06:00

I was thinking about it this morning (as I was trying to get my daughter back to sleep) that instead of actually running byte-per-byte comparisons on AI scripts that have the same lengths, I can just generate CRCs per script as they load! That way I can compare the CRCs with the lengths to determine if two scripts are identical The possibility of two different scripts with the same length and the same CRC is so close to 0 that logic states it's impossible. As a result, that will turn an "n log n" function into a "< 3n" function! With over a thousand unique scripts that's a vast improvement!

EDIT:
Success! Let me give you an idea of what this does now. In the following list, each listed actor is unique. The entries below the actor's name indicate that there is an AI script present in that section and the number next to that section is a unique script ID assigned as it is read in order:

Mystery Ninja
0: 127
1: 128
3: 129
15: 130

Mystery Ninja
0: 127
1: 128
3: 131
15: 130

Mystery Ninja
0: 127
1: 132
3: 133
15: 130

Mystery Ninja
0: 127
1: 132
3: 134
15: 130

Mystery Ninja
0: 127
1: 132
3: 135
15: 130

Mystery Ninja
0: 127
1: 132
3: 136
15: 130

So with those six actors and 24 active script blocks, there are only 10 unique scripts between them! The init and custom event 8 blocks are all identical and most of the main scripts are the same. The only thing that uniquely identifies them is the "death counter" which will set the level that Yuffie joins the party at. This is just the kind of thing I'm trying to solve. Instead of wasting space copying three identical scripts twice. This way we can create more intricate behaviors and counters while maintaining synchronicity between all six (or a set of six) without having to modify all six.
Slick, right? :)

AI Blocks not so static....

2011-11-04T14:24:00.001-05:00

So this just occurred to me. The pointers to AI scripts are just pointers to a script that gets run until it hits the 73h byte, right? Well it seems to me that this is a grossly underused system. What it does right now is have pointers to the pointers per enemy per script with the actual scripts in between:

[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 0's Scripts][Enemy 1's Sections][Enemy 1's Scripts][Enemy 2's Sections][Enemy 2's Scripts]

That seems pretty wasteful. You could do it this way as it is without modification or worry that it'll blow up:

[Enemy 0's AI][Enemy 1's AI][Enemy 2's AI][Enemy 0's Sections][Enemy 1's Sections][Enemy 2's Sections][All Scripts]

What's the advantage? SHARED AI SCRIPTS!! Let's say that we want Enemy 0 and Enemy 1 to behave the same way. They have a 40% chance of not attacking every other turn or so. Why not let their main scripts point to the same script? Oh, but now you say "but their attacks will be different. Unless they're using the same attack that will be useless!" No it won't. Consider this as a script:

0x000: 12 00A0
0x003: 61 0131
0x006: 72 000F
0x009: 12 00A0
0x00C: 61 0146
0x00F: 90
0x010: 60 20
0x013: 02 00A0
0x015: 92

Starting from the beginning we're loading attack ID 0131h and executing it, but starting at 009 we're loading attack 0146h and executing it! This can pose a problem for jumps, but if you pre-load attack variables in the init scripts then you can easily share a more complicated Main between two actors!

This can also be used to share counter-attack behaviors (like running) and a few other things.

Man, I'm awesome. B)

Whoops. I forgot to finish this thought.
One thing I can think of right now that can be changed is that stupid "A Chocobo!!" init script that's shared by EVERY enemy that is in a formation with a Chocobo. They're all the same script so they could all share it and free up space for more complicated script behaviors.

As a result, I was thinking of adding another category to the list of things this handles. Adding AI as a section would be great. That requires naming each one and comparing them one-by-one. That takes time. There are some easy ways to shave off this time like comparing lengths first. There can never be more than 28,672 unique AI scripts contained in the scene.bin and they can have wildly different lengths. The ones with different lengths are obviously not a match.

Also, this would be super difficult and confusing to have to load the scene.bin each time and parse through it like this. I could have PrCMDI create it's own database save with everything already parsed out that it could load much faster than the scene.bin could. You could save as this database (which could be legally freely distributed) and just export to a scene.bin that could be used by the game.

Yep, still awesome! B)

Overdue....

2011-10-17T12:22:00.000-05:00

So I realize I have no legal/moral obligations to do anything with this project. I still must confess that I feel bad for not having done much lately. Then I look at my month-old daughter and realize that nothing else matters as much. I haven't given up on this, but it might be a while before I get back to it. Just hang tight for now. When baby's not so demanding and work isn't so backlogged I'll come back to this.

As it is, I believe WM is done. I was planning on making the menu text display as text edit, but I'm clearly not up to that with my current level of skill. I'll put most of the remaining effort into making PrCMDI when I get around to it.

August already?

2011-08-12T16:39:00.000-05:00

For those that don't know, I'm expecting a little one in a few weeks. As such I haven't had much time to do any side-project developing. I have done a bit and have a really neat looking basic PrCMDI that I want to make a YouTube vid of. I need to get some recording software and find a microphone first, but it'll be awesome! At least, I'm excited about it. It's going to have a "kinder" interface than the current PrC. Less clunky and jumbled looking.

PrC alpha4 now

2011-06-09T10:43:00.000-05:00

That was rather embarrassing. See if you can find the error:

int16 StatBaseAddr = 0x298;
for ( x = 0; x < 3; x++ ){ SceneFile[x * 2] = (int16)ModelIDs[x] && 0xFF; SceneFile[x * 2 + 1] = ((int16)ModelIDs[x] && 0xFF00) >> 8;
StatBaseAddr += x * 184;
Array.Copy( NewStats[x], 0, SceneFile, StatBaseAddr, 184 );
}

If you see it, good for you. Don't feel bad if you don't get it though. I don't think there's a C++ equiv for Array.Copy( array, int, array, int, int) so I'll just tell you that it copies a certain number of values from one array into another.
See it yet? Follow StatBaseAddr for each loop:

x = 0: StatBaseAddr = 0x298 //first enemy's data
x = 1: StatBaseAddr = 0x350 //second enemy's data
x = 2: StatBaseAddr = 0x4C0 //beginning of attack data!!

So technically, the third enemy's data was getting saved, but in the wrong place. :( I changed that StatBaseAddr += x * 184; to StatBaseAddr += 184 and moved it to below the Array.Copy line and it saves just like it should now. Problem solved. :D

PrC alpha3

2011-06-08T00:18:00.001-05:00

New version with some bug-fixes.

PrC alpha2

2011-05-15T11:37:00.000-05:00

Made a few bug fixes mostly related to enemy stats. Item names can be imported from KERNEL.BIN/kernel2.bin now.

I'd like to update the help files of these, but I think I lost the sources for them. I don't have them on the same system I develop on so I can't look for them right now. :(

New Proud Clod!

2011-05-02T09:56:00.000-05:00

By popular demand (a total of one request :) ) the alpha version of PrC 1.5.0 is being released. It might not be perfect, but it's been a year since the last one and I KNOW that one's not perfect.

It can now modify enemy stats! Pretty neat, huh? Formation AI still isn't cooperating and I'm going to address that around the same time as the disassembly (which isn't working at all). A few other things have changed too. See the first post in the official topic for more details.

Let the FF9 reversing commence

2011-03-08T17:00:00.002-06:00

A little side-project for the moment is I'm trying to help gjoerulv figure out the CRC checks on the save games. Initial feeling is "hopeful".

UPDATE:
I found the "Data corrupted." text. It's at 0x00112D81 in the FF9.IMG file. I'm not sure what that translates to in PSX address or how to get to that, but I'm getting closer. ;)

UPDATE2:
Let's see if it will let me save this.
That text is located in FFIX.IMG:Dir00/File39h/0x02B0. Relative Location is 0x0290 and some index of constant strings I don't remember.

Don't think to deeply about this

2011-02-16T15:38:00.000-06:00

It's not completely ready yet. Click for better view.

Meaningful changes

2011-02-08T15:45:00.000-06:00

As some of you might be aware due to posts on qhimm, WM is going through a pretty big change now. I'm trying to make the text work correctly and even make it more non-English language friendly. (Did you know that the exp range for a character is between 31851 and 8123024? You can't make a character need exp outside of that range to get to level 99. Just thought I'd throw that in.) As such, there are going to be two major changes and several minor ones.

First off, WallMarket.dat will be OUT and WallMarket.xml will be IN (yay!). WallMarket.xml will have all the battle info that WallMarket.dat had, but it will be structured differently and not have the character map at the beginning that wasn't really working anyway. It will have things like attack descriptions and materia types in it that if you don't like the way I wrote it, you can re-write it or translate it into a different language. This would allow for multi-language support under most conditions.

Secondly, the text boxes are going to change to look like they would in the game. So instead of seeing the name of the item in black against a white background, you can see the actual font used by FFVII against the default FFVII dialog background colors! This, of course, will mean you can import your own font faces in case you're using a different one! That will probably be in a directory and require an entry in the xml to distinguish between which one(s) to use.

Lots of minor things are going to be changed too like the weapons' menu actions not updating correctly or the materia subtypes not changing properly, etc. Exp curves will now max out at the level 99 value whatever that will be so you can get the clearest view of the growth curve. Drop-downs menus will expand to fit the name of the things that contain them. Lots of really neat stuff. :D

PrC will probably undergo SOME of these changes too (definitely the xml idea), but not many. I don't know if font changes will be worth what I'm doing to WM because of the low level of text usage in the scene.bin. I'll probably still allow for raw data manipulation, though.

A "fix" to the embarassing error

2011-01-24T08:45:00.001-06:00

Apparently, someone got me to take a closer look at what was happening. As it turns out (I believe), the whole "text from the WallMarket.dat file" thing is screwed up. I only did that for people that wanted to use a different font type and I never got around to implementing that exactly. What I'm going to do next is create a default font face based on the game's used font and allow users to substitute their own in there. That would eliminate a LOT of processing when saving text because it will be saved as binary already and won't have to go through decoding/encoding when loading stuff. That will likely cut down on loading time immensely. Expect that to take a while in coming though. I only vaguely remember my PoC working, but I haven't done anything to WM or PrC that relates to it.

On another note, I'm happy to announce that I've finally ordered a new laptop! This will replace the four year old one whose screen barely works with a pretty snazzy one. I feel a little traitorous because it's an HP (for now anyway) and I don't really like buying computers from corporations. I don't have much choice anymore sadly. No one really "builds" laptops from the ground up. :( Here's hoping this one lives up to what I want out of it.

Another embarassing error

2010-12-21T15:01:00.000-06:00

So I finally found someone that had an error that I could play with. Armorvil was kind enough to send me his kernel2.bin that wasn't loading correctly. Well, WM wasn't loading it correctly at any rate. He thought it was weird that once WM failed to load it, the original text would still be displayed. Indeed it is a bit strange, but that's because it's already loaded the text from the KERNEL.BIN that the PSX uses. So if it tries to load kernel2.bin and fails, WM will use the KERNEL.BIN text that it keeps handy. Pretty neat, huh? :)

Anyway, what the problem really was is that the buffer I had allocated for uncompressed file size wasn't large enough for the text he had compressed. I try to dynamically allocate memory so not to use too much or too little so I just set the uncompressed buffer to twice the compressed file's size. Not a bad theory, but his compression ratio was GREATER than 2:1! That means the resultant uncompressed file is MORE than twice the size of the compressed one so the buffer I had allocated to hold it was no longer large enough. Bummer. Since I know now that the normal limit for uncompressed text in FFVII.exe is 27K (refer to previous entry) then I set the size to 32K (since I know that Aali's customizations allow for larger text sizes).

Also, I've been getting complaints that after lots of editing, sometimes the text will get jumbled and confused with other texts. I believe this is a problem with the way I'm compressing text on listboxes. So if you had.....something like... aww, heck with it. I have no idea what it thinks it's doing. It changed

Cotton Dress
Satin Dress
Silk Dress
Wig
Dyed Wig
Blonde Wig
Glass Tiara
Ruby Tiara
Diamond Tiara
Cologne
Flower cologne
Sexy Cologne
Member's Card

into:

Cotton Dress
Satin Dress
Silk Dress
Wig
Dyed Wig
Blonde Wig
Glass Tiara
Ruby Tiara
Diamond Tiara
Colog lower colog Sexy Colog Member's Card
lower colog Sexy Colog Member's Card
Sexy Cologne Member's Card
Member's Card

If anyone has an explanation or theory as to how "ne\n" gets changed into " " let me know.

NEW UPDATE!!!

2010-12-10T16:24:00.000-06:00

Rejoice! I actually did something! DLBP from qhimm contacted me two days ago and requested that enemies be able to be synced across the scene.bin. So I did. Since I was able to copy/paste enemies already (although they should really be called "actors") I just used that to copy the enemy data and AI and replace others using the same model. THAT'S THE TRICK, THOUGH. Every enemy uses a different model number even if the contents of the models are identical. There are at least six different Chocobo models alone and all of them are identical except for the files that contain them. Obviously you wouldn't want to replace the Wonderful Chocobo with the Poor one, so I'm going to have to restrict it by model ID. Characters of the same model ID can be synced with its copies. For example, Grunt (model ID of 0013h) exists in eight different scenes. I want to modify all of them, but to keep it straight I can now just modify one and say "sync all enemies with model ID 0013h". It's actually a rather quick process and I'm pleased with it's performance.

If another custom enemy is using that model it will be replaced, name and all! The way to prevent that is set the custom enemy to some bogus model number (which is being moved to the new stat editing screen) and then do the replacement then switch the custom enemy back.

Long overdue news

2010-12-09T16:29:00.001-06:00

You ready for this? I got nothing. Really. This has been a tough last quarter-year for me and I haven't had the chance to even look at the code for either WM or PrC. I was taking a class that just ended today, I had two (sort of, it's complicated) deaths in the immediate family within a week of each other, my lappy's finally hit the big one, and I got a new laptop at work which won't take my external backup of my older one that had all my FFVII reversing info on it.

I'm not back to square one or anything, but I haven't had IRL time to devote thought to these projects. Hopefully, come the new year I'll be less constrained and have a new laptop.

I haven't given up on or lost motivation any of this. There just technically isn't time to do anything with it.

A little random thought....

2010-10-08T08:34:00.000-05:00

WM 1.4.5 is out now and the links to it are on Qhimm's forums. Blogspot is being a pest and won't let me update them. When I'm able (and remember to) I'll do that. A few things were added and fixed so check them out.

Last Saturday was WM's second birthday! Or do you call those "compile days" for computer programs? Meh, one of the two I'm sure.

Since that's done I've been working on a camdat editor. I'm getting closer to what I want it to be. It's really basic because most of the cam script is unknown and I'm just basing it on what I DO know. Mostly what codes take what arguments and such. It's not done, but it's coming along nicely. Of course, the last 10% of it is likely going to take 90% of the time as usual.

Restore Type?

2010-09-27T11:27:00.000-05:00

I'm sure I've written about this before, but I wanted to remind myself. I've been digging through the exe again trying to find out what the "Restore Type" really is in Attacks and Items. Well, it looks strange. For Attack's part, it looks like that byte is ignored completely. It does something for Items though, but it looks like only in the menu. Here's the deal. There's basically a function I called GetRestoreType that takes two parameters: A constant that tells it which RestoreType to get, and an index. The constant can be 0, 2, or 4. Anything else and it acts like a 0 was passed.
Passing a 0 returns a null value, passing a 2 would return an Attack's RestoreType, passing a 4 would return an Item's RestoreType. Well, the game never passes it a 2. Attacks' RestoreType is pointless. Here's how it breaks down:

Outside of function:

0x6D9A4E
if (getRestoreType(4, ItemIndex) != -1) call some_sub(-1, -1, 15h)

0x6D9D37
if (getRestoreType(0, "Something") != -1) call some_sub(-1, -1, 15h)

long getRestoreType(int constant, int Index)
{
   int tempRestoreType = 255;
   long returnValue = -1;

   if (constant == 4)
   {
      if (Index < 127)
      {
         tempRestoreType = ItemData(Index).RestoreType;
      }
   }
   elseif (constant == 2)
   {
      tempRestoreType = AttackData(Index + 72).RestoreType; //E.Skill Attack Indexes
   }
   if (tempRestoreType != 255) returnValue = tempRestoreType;

   return returnValue;
}

Then, after the function calls mentioned above, the returned value is checked against -1 and a sub is called. Thing is, the one that passes a 0 will always return a -1 so that one's worthless. The one that passes a 4 returns the item's RestoreType just fine, but doesn't seem to do anything with it once it has it.The sub that is called is sub_6D0AF9(-1, -1, 15h) with an unknown function. This is its code:

some_sub (long val1, long val2, byte offset)
{
   *[0xDC2068 + offset] = 1;
   if (!(val1 = -1 || val2 = -1))
   {
      *[0xDC3630 + offset * 98h] = val1;
      *[0xDC3630 + offset * 98h + 2] = val2;
   }
   *[0xDC3630 + offset * 98h + 8] = (([0xDC3630 + offset * 98h  + 4] - val1) >> 1);
   *[0xDC3630 + offset * 98h + 10] = (([0xDC3630 + offset * 98h  + 6] - offset * 98h) >> 1);
   *[0xDC3630 + offset * 98h + 12] = 2;
   *[0xDC3630 + offset * 98h + 14] = 2;
   call off_91E638[offset*4];
}

For items, the offset will always be 15h so we can fill in the blanks and simplify:

some_sub (-1, -1, 15h)
{
   *[0xDC207D] = 1;
   *[0xDC42B0] = (([0xDC42BC] + 1) >> 1);
   *[0xDC42B2] = (([0xDC42BE] - C78h) >> 1);
   *[0xDC42B4] = 2;
   *[0xDC42B6] = 2;
   call off_91E68C;
}

off_91E68C is labeled as some system function "__initp_misc_winxfltr_88". I have no idea what that means. Winxfltr looks like some kind of error message library. The other addresses are part of a large set that I don't see any significance to in the code, but I'm sure there is one once the game is running.

That's all I have on this.

See? I still got it.

2010-09-24T08:58:00.000-05:00

WM:
I've modified the Materia Tab in the spirit of the Attack, Item, and Weapon Tags. The Materia Type is to be split into two types. Materia type is handled in this way.

PrC:
So I just looked back into the function that finds orphan AI lines. An orphan AI line is one that can't be called because there's no jump to it and the code always jumps around it. It happens in quite a few AIs. I just found at least seven in Eligor's Main script. Why did I bother identifying 7 lines out of over two hundred? Because by deleting those 7 lines the AI disassembly works the way it ought to. Errant jumps always made it spasm and think there are too many if statements and go all wacky.

New limitation

2010-09-21T16:38:00.004-05:00

I just learned, while trying to find something else, that the maximum kernel2 text size for the PC version is 27K (27648 bytes) including all file headers. The PSX is likely smaller than that. This is a limitation I'm going to impose in the next version.

So sorry...

2010-08-25T16:03:00.002-05:00

I'll admit it. I've been bad. I've received two donations and delivered several promises about the impending new version and I haven't released anything in nearly five months. Well, I'm tired of that. I'm tired of going to sleep at night knowing that I'm keeping people waiting. Let me try to explain where I'm at since it's been over a month since my last post.

First of all, my job has gotten a bit more demanding. That's where I've done most of my developing of this. It's hard to code for a while on these projects then have to do some more code on a job-related project. I get paid to work so that takes priority over almost everything else. Unless someone's willing to donate more than my monthly salary for this (which is HIGHLY unlikely) then that's the way things are going to stay.

Secondly, I'm still frustrated that I can't get the models to display correctly. I've got someone who would be willing to help me find out how to perform the vector transformations. However, I will probably just put this aside and save it for the update AFTER the one I'm trying to get out.

Thirdly, The disassembly looks different and wrong in the in-progress edition of PrC. I've got to fix it before I release this or it won't work for most people's purposes. It also allows stat editing that Hojo does AND the formation AI that T.Fergusson brought up a while back will be editable too. I hope to have it working completely soon. Things have also moved around. The buttons for Edit AI and Animations have been removed and placed on menu items. I thought the buttons looked tacky anyway.

That's what I got. During my down time I have been taking a break from this, but now I feel ready to get into it again. Hopefully, this will be ready by WM's second B-Day. Oh, WM is done and ready for the most part. There's not much change to it though.

What's holding this back....

2010-07-14T13:55:00.003-05:00

So I've dropped hints along the way that the next versions of WM and PrC are going to be better than they are right now. This is true. They will. ;) But what's holding them back?

Well, I want to release them at the same time. WM isn't having any significant change other than it will let you choose the damage equation more easily. PrC is going to see a wealth of change, but it's going through some testing right now. All I have to do is make this become this and it's smooth sailing the rest of the way. For those that don't know, that first picture is probably the hardest part. Everything else is positioning and rotating.
It can already display the battle backgrounds fairly well too since they (at least most) don't really have any animations. Textures' transparencies aren't being handled correctly, but I think that's a known flaw in the way DX9 handles textures and transparencies. There's also some gradient blurring effects going on that I'm not going to mess with. I just want to be able to produce correct-looking models for the battle preview.

That and the disassembly of AI is taking a new turn and not looking right. I still have some work to do on that. That's probably going to be a cake-walk compared to getting these models to display correctly.

Forgot to Publish this post.....

2010-06-18T14:49:00.002-05:00

Whoops. I started to write this yesterday but forgot to hit the "Publish Post" button. It's important too because I need some feedback.

In the spirit of my last post I've started allowing enemy stats to be edited. Problem is, enemies already have a window devoted to attacks and animations and the like. In order for it to be as editable as possible, I'd like to have it all enemy-related data be on one window. Problem is that's a LARGE window for all that. :( These have been important features of PrC for a while too so I don't want to bury them deeper. Re-arranging these things the way I REALLY want them to be would be a nightmare. It can be done, but that means changing almost EVERY layout and making everything larger. I may do something like that in the future since I need some MDI practice, but let's focus on the present for now.

I did away with the "Edit AI" and "Animation/Formation" buttons. They were always an eyesore to me. Instead I made new menu options that contain them. Now it'll take two clicks to get to each of these instead of one, but I don't see that as being a horrible thing.

So the feedback I need is this: should I try to combine the animations page with the stat page or just make links to them both from the other?

Also, for item drops/steals/morphs I have it ready to open a KERNEL.BIN/kernel2.bin file to read the item names. I don't want to use the stock names (especially in English) so I suppose I have to load these. Should I make it mandatory? If I do that, why not copy the attack data from the KERNEL.BIN attacks and make those static within the scenes that contain them?

Enemy editing....

2010-06-14T15:37:00.002-05:00

So long ago I decided that I didn't want to make too many tools obsolete with WM/PrC. So far, with the additions I've made I've done just that to no fewer than five existing tools.

Scenester

Scene Reader

SceneEdit

Teioh (though some people find this has an easier interface to use for simple edits)

ff7dec (a KERNEL.BIN separation tool)

There are at least three different authors to these, but I don't remember who made ff7dec so it may be four. Anyway, I didn't want to take any fame/glory from anyone else so PrC doesn't edit the enemy stats like Hojo does. Well, it feels a little foolish now to allow editing of 7256/7808 bytes even though the remaining 552 bytes are known. So I think I'm going to have to byte the bullet and just say I'm going to allow editing of these now. That feature is still in progress so it might take some time to get it to look good.

I'm also still working on being able to copy/paste whole enemies between scenes. I'm getting closer. Still some errors occurring, but it's getting closer to working.

Another random update

2010-05-28T09:48:00.002-05:00

Since I'm leaving town for the weekend I won't be able to touch any of these. Let me tell you how things are going now.

WM/PrC:
These are looking good. I made an enemy copy/paste option at the request of Armorvil. I THINK it's working correctly. The only thing it doesn't do is add that enemy to the formations. That's a dangerous thing to do anyway so I may not do it even though I was considering replacing them with the enemies you copy over (but imagine copying Diamond Weapon and pasting it over Grangalan Jr.Jr. INCLUDING it's formations! )% ). That wouldn't work because of Grangalan (& Jr.)'s AI. They are the ones that call out the invisible, untargetable Jr Jrs at a certain point. Also for this reason it's dangerous to just blank out enemy formations. This kind of stuff is also just as dangerous with the Chocobos. Trying to copy them or replace them is dangerous. Well, copying them isn't that bad, you'd just need to change the AI dramatically. :)
Another note is that I found a simple one-line function to replace a two line function I've been using since Sept '08 when I started using this. Go figure, right? ;) I'm constantly reminded how little I really know about what I'm doing. :D

Tiny Bronco:
If you remember me mentioning this you deserve a cookie. I've been tinkering with this prog for a while, but I don't want to say too much about it since I'm not sure it's going anywhere. However, I've recently decided to look at it again. It's a mess. I haven't done anything with it in so long I've forgotten how it all works. It looks sloppy too.

FF7.exe:
I was playing around with the Item properties trying to see how some of them work when lo and behold, I found the Enemy AI data in the memory! The game does something really strange with it. It seems to write to it, make a pointer to it, then ignore it. I didn't find where that pointer went so it's a little worthless at the moment. Still, it's a step in the right direction of figuring out what the ASM does with different values. I believe Akari already knows where this is handled, but it's exciting to have found this by myself too. :)

Other:
So I was playing around with a TIM viewer of my own design when sl1982 (Head of Team Avalanche) requests a TEX dumper. Because of the work I've done on Tiny Bronco I suggested that I could throw one together real quick combining the two. So I did. :) He's happy with the result and I'm now apparently the Head Programmer of Team Avalanche. :D So far that's all I've contributed. That's apparently enough at the moment, but I'm sort of on retainer for any other extracting app they might need. Those won't likely be released because they're real specific need things. Oh well.

Can't think of anything else right now. Have a good weekend! Happy Memorial Day to those whom it applies!

Sad news (but not TOO sad)

2010-05-20T12:36:00.002-05:00

I'm not giving up on these projects. I still have several pending ideas for it. Now that I've laid those fears to rest. :)

I've just been digging through the executable trying to find the data the game uses to manage the in-menu/out-of-battle item usage. Turns out it's all hard-coded. Not just the data, but the functions are hard-coded into the executable. D: This makes it nigh impossible to just edit to achieve a particular result such as healing only a certain percentages of HP/MP.

HOWEVER, I did find that it's possible to remove functions from items entirely! This can be done in one of two ways: Changing the item's function location to what I call "Item Use Complete" which is just a series of jumps to the end of the over-all "use item" function. Or just disabling their use in the menu via WallMarket.

Here's how menu item usage works:

When you select an item the "use item" function will search through a list to see what function that particular item has. It's just a list based off the items' index. There are 13 functions. Then one of THOSE functions are called and things happen. If the item happened to be a source then it goes through another list of functions based on the source index. Here's some pseudocode on using a Hyper:

Item Index is 0D
ItemFunction(0D) is 8
do function 8

function 8:
if character does have fury
play "incorrect" sound
else
if character has sadness
cure sadness
else
inflict fury
end if
play "item use" sound
decrease item quantity
end if

The phoenix down is kind of odd. Since the death flag doesn't carry over out of battle it checks if the character's HP are 0. The only conclusion for the game to make if that is true is that the character is dead (this is how the battle engine decides if a character is dead at the beginning). Then it heals the character by it's maxHP bit shifted right by two (1/4 MHP).

In case you're curious and want to explore more, the address of the item functions can be found at 0x7175E2.

Progress is being made....

2010-04-27T08:28:00.003-05:00

I'm struggling with getting this new feature to work. I didn't pre-write it this time because I need real data to test with. This requires replacing one form object with another and sort of "gimmicking" my way through getting them to work together. Most of the code I wrote originally was with the understanding that it would read data directly from the grid that you enter data on. Now it's going to be storing data in a different way and I have to re-write whole sections of code. That means not only do I have to write 200+ lines of code to handle a different data type, but I have to do it in a way that takes data from a new data structure. It's currently mostly lame as it is and I'm likely going to re-write it to be more processor friendly. *sigh* The work of genius is never complete. :(

EDIT: I'm making better progress now. Currently when you want to change something in, say, Eligor's Main script, you have to wait over 5 seconds for the changes to happen. This is because it's changing all the jump addresses for you (albeit, not very efficiently)
Now, because of the new structure I'm using it took a grand total of .765 seconds! That's going through the entire script about 160 times replacing jump addresses.

So color me an idiot....

2010-04-16T12:48:00.002-05:00

I just learned today that the opening credits to FF7 (where they play the prelude and all) is actually present in the PC version! I'm not a patient person when it comes to intro screens so I just try to get through them. You can cancel the entire intro sequence starting with the Eidos logo vid. If that Video doesn't load then it just goes straight to the "New Game/Continue" screen. I never let it get past that Eidos logo before canceling it. I thought it would go straight into the credits part, but it skips that too! So the prelude actually is in the PC version. For the past, what? 12 years of owning this?, I never knew!

Now WINE flavored....

2010-04-14T14:02:00.003-05:00

Of all the things I keep getting amazed by, someone found out how to install the .NET runtimes on WINE. Now WM and PrC can work in Linux!

Check it in action:
WM: http://www.youtube.com/watch?v=Jm9VmQkvgSs
PrC: http://www.youtube.com/watch?v=mVuE_H7iUg4

It even clued me into a few errors in PrC's checking of the KERNEL.BIN file. I thought it was a WINE thing. Some of those errors are so I can't fix them. It's also really slow displaying all those controls. I think this is a WINE thing (or maybe a framework thing since he's using 2.0 and it is *supposed* to require 3.5) so, again, nothing I can do about it.

Either way, now our Linux pals can enjoy these. :)

Getting closer to a new feature for PrC!

2010-04-12T11:15:00.003-05:00

So as per Terence Fergusson's post about Battle Specific AI I've created a new function to allow the editing of such. All it does at the moment is view the AI.

Check it out!

A few things about WM are fixed, but not yet released.
1. Now the objects won't stay disabled when moving from attack tab to another tab if the attack's index is greater than 127.
2. Item Cams now show the correct camera anim index (they were incorrect in a few instances I hope no one ran into). They are saving correctly in version 1.4.0, it's just switching between tabs that might cause a few problems.
3. TFergusson also clued me into why his and my HP values weren't agreeing (see aforementioned post). I was performing the entire calculation in floating point scope until the end. That apparently changes the range of values quite a bit. After I rounded a specific number down I got much closer to his numbers. I'm not spot-on because "achieving max HP requires that you must take lower than max gains at some levels...." This is apparently true also for some min values. However, I don't really care enough to go through EVERY permutation looking for the highest and lowest values per level. For some levels that would mean following almost a thousand potential branches. The projected ranges are now within 8 HP (in most cases 5 or less) of his calculated values at level 99 so I don't really see a need to get mine to sync perfectly with his. His are more accurate, but WM's are only for a general idea of how the stats will increase.

A little side-note

2010-04-06T08:56:00.002-05:00

So I was screwing around with the co.bin after being pointed to it by Terence Fergusson as being the source of the slots and images. I've managed to make a simple extractor of the slots and the images. It has no applications at the moment, but I might be convinced to turn it into a simple slot editor. It wouldn't change the way the slots worked, but it might be funny to change things up on the player; Making them think they're getting "Restore HP" and really Breaking Items or something or just making all the images the same and not showing what effects they have! :D

Correction made

2010-03-29T09:35:00.001-05:00

It was quickly brought to my attention that the animations and allowed attacks weren't saving properly. This has been corrected and re-uploaded. Sorry for that

Your patience has paid off!!

2010-03-25T14:14:00.000-05:00

I finally finished the tweaks I was planning to WM and PrC. They should both run faster and lighter (you might not notice the lighter, but it's there). PrC has a few tiny new features that I doubt anyone will notice unless I point them out.

New to PrC:
Battle Preview has been changed and there are more options for editing positions and camera and such. I'll let you figure out what they are.
Searching for unused indexes doesn't take as long as it used to and it won't make a box that fills the screen.

New to WM:
Curves will report who is using them.
Initial equipment materia can be viewed just by moving the cursor over the materia picture! Makes it easier to see who has what.

Fixes to both:
Strings in the AI work now! I was accidentally blanking them out in PrC and not saving them correctly in either. It's all good now. :D

A few things more should be in each one, but nothing spectacular. I think everything saves correctly. I'm not entirely certain, so if you find something that you changed but didn't save let me know. The new code they both use can get a bit tricky.

Getting closer. Two things I'd like to share...

2010-03-20T02:32:00.000-05:00

So I want everyone to know at least two things:

1. I'm not dead.

2. I'm still making minor adjustments to WM and PrC. My biggest inspiration came today for little changes in PrC that I hadn't considered before. Some will seem pointless; Others have been long overdue. WM is getting a few minor feature additions as well. Some of which I've already described. The most important thing is that the AI editing be correct. That's always the oddest thing about these programs. The system I created to use it is, well, unique. No one can really tell me the best way to do it because it's never been done. In fact, at this moment (literally while I was writing this post), I've come up with a new way of doing it I'd like to try. Hopefully it will speed up the display and changing of values and such. However, I'll save that attempt for a later version and just get this one pumped out. I THINK I finished it yesterday afternoon, but I had to leave it in a hurry so I didn't get to test it. It's not likely going to be tested thoroughly before I update it so if you get it you should definitely save the version 1.3.3 that's up now. I'll leave the links where they are and just add 1.4.0 to the list. Code changed EVERYWHERE in WM and only on the formation page (and a little extra elsewhere) in PrC. If anyone finds bugs please report them. Preferably as comments to a recent post of mine.

Updates will come soon and I'll post again when they're here.

Finally got to PrC too.

2010-03-03T11:38:00.001-06:00

Thanks to some off-time due to a business trip, I managed to "reduce PrC's virtual footprint". It didn't have as big an impact as WM had, but it's still smaller. It lost 79K in size to make it come in at 601K. Pretty good I think. I believe it retains all its original functionality while a few minuscule new features make the process easier to use. For example, using the current version of PrC, try making an attack with an index of 8000h and then searching for unused indexes. Go make a sandwich and come back and see if anything has happened. Maybe it has, but your screen ought to be covered with a single box that looks like it has no end. With the change I recently made that box will never be that large. It will display ranges of empty values rather than listing them 1-by-1. So instead of it saying "0100h, 0101h, 0102h," like it does now, it'll say "0101h - 0102h". Which comes in handy when there's a large range of values that are blank, say "03E2h - 7FFFh" :).

As for string editing in AI, I really haven't addressed that yet. There are so many things that could go wrong with editing AI as it is. I DID, however, add a cancel button to the AI editing. If you make a change that you don't like you can cancel and re-open the window to start editing from the base again.

Another check off the list...

2010-02-23T09:07:00.000-06:00

OK. I'm done with streamlining WM. It didn't do as much good as I had hoped. It only reduced the file size to 630K. The goal was at or below 512, but to do that I'd have to take out the Ms. Cloud graphic and the materia link graphics. Not worth it IMO. The Materia Links could be replaced by using "O", "=O", "O=", "ʘ", "=ʘ", and "ʘ=". It's hard to even consider that after having the actual materia link graphics from the game. I even used the actual images for materia in WM too so that's out.

I have decided that I'm going to add a few new features even though I thought I was done with feature additions to WM.
First of all, and least interesting, it annoys me that you have to click on a character's initial materia to find out what it is. I'm going to make it to where you just have to hover the cursor over it and the name will show up. I'm considering showing level and AP in that bubble too, but that might not be useful.
Secondly, and MUCH more interesting, I'm going to add a "Add All" button to the initial items and initial materia lists. Cool idea, huh? ;) Of course, we can't have those buttons with out "Maximize Stock" and "Master All" features too, can we? :D
I'm down to one line to be changed in WM before I add these features, but I'm still trying to work out what that line should be.

PrC won't be bereft of updates, but it's much more boring than either of those so let's not get your hopes up. The only thing I can think to do is programmatically more complicated, but you might not even notice the difference.

Keep watching this blog. Updates are coming soon!

Grunt Two more to go....

2010-02-10T16:51:00.000-06:00

I'm slowly making progress on stream-lining WM into something lighter weight and I have two more modifications to make. Hopefully, this will fix a few issues and be undetectable to the end users.

After I get this mess de-tangled I'll look into doing the same to a few PrC issues. I'm not happy about the animation/formation window's loading time. I think I can reduce that time, but I can't make any promises.

S minus 100K and dropping

2010-01-19T10:01:00.000-06:00

So the WM re-writing is going well. So far I've eliminated over 100K in actual program size and I've still got a little more to go. I'd like to keep the size at or below 512K. "There's no real significance to that number, I just like it" (Guess the quote, or at least the paraphrase). Still, it's going a little slow and it'll be a while before release. Be patient as always.

PrC doesn't suffer from the same "control overload" as WM does so I can't really do much to it to make it smaller.

(EDIT: That's a lie!!! I'll get to this later when I can.)

I'm still attempting to learn how to do animations of characters too. My latest attempt (code named "Tiny Bronco" because I'm not sure it'll get off the ground) will be a supplement to kimera (http://forums.qhimm.com/index.php?topic=4194.0) because I can't use it. Not sure why, but my Vista just won't open it.

Happy New Year!!

2010-01-05T10:41:00.000-06:00

Belated Happy New Year, faithful WM/PrC users! In celebration of the New Year, I'm going through and cleaning some code oddities in WM. This should do four things:

1. Make the overall size of the executable smaller

2. Reduce the amount of system memory needed to run it

3. Increase initial load time

4. Make changing through tabs a little easier on the display

You won't likely see any new features, but bug fixes will be implemented. One glaring one of which is the sound shift error. I mistakenly assigned it the wrong value so it wasn't saving correctly. There have also been errors involving using opcode 93 in PrC and I think that exists in WM too. That'll be addressed as well.

Anyway, keep an eye out. WM v1.4 is coming soon!*

* - cosmologically relative

New version of PrC and WM

2009-12-23T11:58:00.000-06:00

WallMarket and Proud Clod have been updated. A few fixes. Nothing special. You can edit Ultimate Weapons' and Sephiroth's scripts again without it dying. Also fixed a few things with Materia not updating and description text not saving. Merry Christmas! :D

UN-No New Game+ :)

2009-12-17T11:25:00.000-06:00

There's a light at the end of the tunnel. Apparently, someone at GFAQs uploaded a save game that starts right before the first battle with the two MPs. The guards are already knocked out, but nothing they still have their potions. So it's possible to start at the beginning after the first movie, but before anything significant. I'd like to be able to tweak it, just a hair, to get it to start as AVALANCHE is jumping out of the train. It will likely take some trial & error changing to get it right.

Thanks to secondadvent for alerting me to this save file.

EDIT:
I just finished my Adamant set in Dissidia without using the FuSoYa ghost. Man, that took a while, but I discovered what a kick-butt fighter WoL is! He's my new favorite! :D

No New Game+ :(

2009-12-07T12:45:00.000-06:00

Thanks to some help I managed to find the initial point where the new game data gets dumped into. Aali told me that in the US ff7pc v1.02 this map begins at memory address 0xDBFD38. Sure enough, that's where I found it all! Seems easy enough to copy and put into a save file with other initial data from the KERNEL.BIN and such. Well, turns out it's not so easy. The game is supposed to load a save game and "pick-up" where it left off. Problem is that since my initial game didn't have any "this point here" data like the game assumed a save file SHOULD have it crashes and dies. I had assumed that it would load the data, put it all in its proper place, then start the game mode based on that data. Turns out to be wrong. I think the most thing is that continuing a game can't start with an FMV like the game starts out with. Also, there is no condition in continuing a game to start at the beginning where there's no save point at all.

So it looks like there's every reason to believe that it CAN'T work without modding the executable. I don't want to do that so the "New Game+" project is officially ended (by me).

Back to Dissidia for me....

New Proud Clod at least...

2009-11-18T15:38:00.000-06:00

So I added a few new things to PrC to make it a little more convenient. First, and most importantly, it can now use the Windows Clipboard to copy-paste! The documentation doesn't reflect this yet, but the function's there. The format must look more or less like the code displayed in the AI window. Each opcode gets its own line and values associated with that opcode must be the last few characters on the line depending on the code.

eg:
12 2060
10 4000
80
60 01
90

that copy-pastes just fine as.... kill script owner, basically. ;) The following variations also work:

12 89789985 2060
10 check me out! 4000
80
6001
90

copying that should also result in successful pasteing. A few more things have been added and not documented:
"Check attacks" button in AI editing should show you any potential conflicts in using the 92 (Perform Action) code. There are some things it won't catch, but it should be able to tell you if you try to use an attack that the enemy doesn't have access to or if the animation isn't set for.
On a related note, the allowed attacks lists have changed slightly. Now it shows the attack index (like I said it would) so you can distinguish between identical named attacks.

Have fun! Let me know if anything's wrong.

Next thing...

2009-11-12T08:51:00.000-06:00

I'm going to start working on a way to use the clipboard while editing AI. It's a LONG process, entering all that code, and no one REALLY wants to do it more than once if they can help it. Probably after this feature is working I'll release new versions with the fixes I've mentioned before.

Well....copying is the easy part. Took me five minutes max. Pasteing's a little harder. The string will have to be checked and parsed before injecting it into the code. I can do it in a few minutes, likely.

Uh-oh

2009-11-02T09:16:00.001-06:00

Someone pointed out a little WM bug to me (that's likely been around since 1.2) that'll need to get fixed. Simple enough fix too. I'm also likely going to add attack index to the animations tab so users won't have to guess at which "Pyramid" attack Reno's using. It won't tell which direction he's facing, but at least people will know that he's not attempting to face the same direction every time.

Actually, they're three different attacks so the AI knows which Pyramid to summon. That's hardly important to the issue, though.

Something's missing...

2009-10-28T08:05:00.000-05:00

So I have recently moved into a new house. My first house. A brand-new house. I'm excited about that, but unpacking takes away from lots of things. I haven't been able to do any of the enemy playthroughs that I've wanted to do because my computer isn't hooked up.

Thing is, I HAVE given more thought to the copy/paste functionality in the AI. My biggest issue was what if someone attempted to paste straight text into it. If you tried that, it would crash the program pretty hard! XP Anyway, that was with my original ideas. I've had a few more since then and I've decided that I'm going to add that feature, but do some pre-processing to make sure it's valid and paste it directly into the visible script if it is. That way people can create templates and modify them outside WM/PrC (which I really don't recommend too much because that'll screw up some jumps in some cases) and paste them into either. I know some of my devoted followers have requested such a feature and it's time I deliver.

So, two things have to happen before I do this:
1) I have to finish moving/unpacking. I can't just let it half-go.
2) I have to at least unlock the Blackjack course in Dissidia. I've completed 3 DOs and Shade Impulse with Cloud. I've got a ways to go with that. :(

Oh yeah, one more thing. The odd thing about this is that if I want it to be pasted into a text box like Notepad or whatnot then I'll have to format the data. With that in mind, I'll have to include cr/lfs (carriage return/line feed or "hard return") in the output. It just so happens that this corresponds to "-*" in FFtext. So try not to include that particular combination in your texts, K? ;) In reality it'll be up to me for that to not destroy this copy/pasting.

New versions

2009-10-12T12:02:00.001-05:00

Just in time for Columbus Day (whoopie) new versions of PrC and WM are ready! Get 'em!

Next planned feature

2009-10-08T14:56:00.000-05:00

So I'm pretty confident that I found all the problems with PrC and WM's working now. I've been toying with the idea of loading actual battle models into PrC when the battle preview is selected. Good idea, huh? Yeah, I thought so. :)
I've also decided that there will be a little dot where the camera's focus will be. Still working on it, but I've got less and less time each day. At least for a while.

This is going to take a while...

2009-10-02T10:34:00.000-05:00

I just thought of a new thing this should do, but it's going to take a while to make. Basically, I want to indicate to the user whether or not an attack is usable by a given enemy. There are two conditions to this:
1. The attack's index is LESS than 65535 (NULL)
2. The enemy's animation associated with each attack is LESS than 255 (NULL)
If these conditions are true the background color of the allowed attack will be window colored (usually white), indicating that the attack is usable. Otherwise the background color will be form colored (varies with desktop theme), indicating that it will cause an error if the enemy tries to use that attack.
If I REALLY REALLY wanted to go above and beyond, I'd make error checking on the AI. Accounting for allowed attacks and such. But I won't. ;)

New thoughts...

2009-09-29T16:09:00.000-05:00

I fixed WM to include text changes, hopefully now under all conditions. I also added the feature to delete objects from the KERNEL.BIN. When I say "delete" I really mean "NULLify". In any given entry of an object (Weapon/Armor/Command/Attack, etc) it has a name, a description, and a set of data associated with it. Deleting the entry will blank out the name and descriptions while the data will be replaced with all NULLs. This allows the file size to be smaller for the convenience of PSX modders. There's also a large amount of data that can be removed between discs. You wouldn't need any data related to Pandora's Box until Disc 3 because you can't get it until then. You wouldn't need the text of Aeris's Limit Breaks after Disc 1, nor Sephiroth's or the "love" scripts. You get the idea, right? Well, you can now micro-manage like that to get some extra space out of it. PC modders need not delete since the size of the compressed KERNEL.BIN isn't the issue.

I also decided to allow users to delete entire scenes in PrC for the same reason. I also thought it would be nice to add some labels in the formation tab. Formations will now be referenced with the full formation ID rather than just "Formation 1", "Formation 2", etc. For example, it will now be "Form [0045]" for Formation 1 in scene 11.
Camera Coords are now grouped properly. They are labeled and two bytes are together in one cell.
Same thing with Formation Data. I'm still working out the bugs caused by joining them, but I'm getting close to being done.

I haven't uploaded either of these. I thought of uploading WM first then tail it with PrC in a few days. It just won't happen today because I lost my DSL at home for the time being (long, stupid story). I have to resort to dial-up for now (YUCK!) so no updating will occur there.

Current Issue

2009-09-22T14:32:00.001-05:00

So far, it's all been working fine. The only problem that I see is that sometimes WallMarket won't save changes made to text. This doesn't happen to me, but I know it happens to others. As soon as this gets fixed I'll formally issue my challenge once again.

Introducting...

2009-09-22T13:51:00.000-05:00

I've been in development of these two tools for nearly a year. It's gotten quite complex and I think it's time I start chronicling my efforts. I guess I should say a little about them:

WallMarket:
This was the first of the two that I made. It's a KERNEL.BIN editor for Final Fantasy 7. To those that don't know what that means, almost all non-enemy battle-related data is located here. This includes magic attack data, weapon strengths, materia attributes, accessory effects, etc. It's a LOAD of stuff. I've worked on it off-and-on for nearly a year now and I'm finally happy with the result. I'm proud to say that it can edit virtually every byte of significance in the KERNEL.BIN file! It was named this because Wall Market is a location in the game that was the trading hub of the Midgar Slums. My original desire for this was just to make the Ultima Weapon give growth slots and to increase the number of Materia slots on the armors. Since it modifies every item/materia, it was logical to name it after a large market. :)

Proud Clod:
This was originally called Heidegger and was, for a short time, little more than an attack editor for the scene.bin. This is the file that stores all enemy-related (not "monster-related" since not all enemies are monsters) data. This was originally made because it was made known to me that the attack data in the scene.bin was in the same format as the data in the KERNEL.BIN. So all this did was modify the 32 attacks in each scene. After I got further in development of WallMarket, I decided that this needed to edit much more about each enemy. The AI that guided the enemy, for example. Thus Proud Clod was born. Since this, it has been given the ability to edit enemy formations within a scene (placement of enemies, for example). It can also modify the attacks they're allowed to use. This is intended to be a companion tool with Hojo by Squall78 to complete the total manipulation of the scene.bin file! I believe I went through the data on this file and the two modify everything.

As far as my interpretation of the EULA goes, these tools do not violate it. The EULA basically says "Don't illegally distribute any pieces of this game" and "Don't reverse engineer this for the purpose of taking its contents for your own works". I'm not ripping anything out that I'm going to commercially use (or even personally use). As such, however, I do not endorse the usage of these tools to either end! The latest versions of each of these allow you to save the modifications you've made to a file that CAN be legally distributed because it is not a working piece of the game. There also isn't any "don't modify the contents of the game" for various reasons, but I would say "I can modify any byte of stored data on my computer that I WANT!"

So now that introductions are out of the way, let me say that I'll use this blog to provide information about my progress to their development. I'm not completely happy with them yet and I'd welcome suggestions to make them better. I'm pretty sure there's little more to do with WallMarket other than bug fixes, but if anyone comes up with a REALLY good feature request I'll consider it.