Another update

I'm almost done with Wall Market. Like, completely. I've rid the dependency on the power packs and I'm ready to release the code, but there's some silly nagging display thing that's preventing me from being happy with it. I just got a new laptop that runs Windows 10 and that makes the controls look a little weird. Most of them are the same color, but while some are white like the system style dictates, some are the classic Win 95 themed grey color. I'm not sure how this happened.

So now I'm, what, nearly a YEAR behind. :(

Let me tell ya what's been happening that's prevented me from doing further work on this. First of all, I've been working on the 60fps project and gotten a lot of good details for it. That's taken most of my free time that I would have devoted to coding for the next and final WM update or continuing on PrCMDI. I managed to slow the effects to make them not play at 4x speed, but they're still essentially in their 15fps glory. That caused the summons to go all wacky, however. I tracked that down and fixed part of it only to realize that the summons are drawn as models and get redrawn per frame they are told. I still haven't isolated where that drawing comes into play so they tend to disappear. Also, I've got a slew of animation script "fixes" to make some other effects be in the same 15fps mock-up. Unfortunately, the list isn't complete so I don't know how many I still have left to alter. Now, for the main problem I've been having. Last May I got a new HDD for my laptop (which is what I do all this programming and reversing on in case you didn't know). I went from the 650GB that HP packaged with the machine I have to a 1TB I bought from Best Buy. Pretty slick I thought. Well, only sort of. I had to reinstall my OS and all the drivers (of course) and all my programs. When that happened, my video card decided to start retiring. At first it seemed like a driver issue, but replacing the original HDD gave the same errors I was getting before. Well that can't be a software issue then, eh? Over the next several months it just got worse and worse at deciding it didn't want to work. So I finally got a replacement System Board for Christmas (a weird thing on my list to be sure) and lo and behold IT has the same problem! I convinced the people that it was purchased from that I do know what I'm doing with it and asked for a replacement. I'm waiting on it to get to them now and they'll ship me a new one. I'm HOPING that this new board will solve the problem and I'll be able to actually USE my laptop.
ADDENDUM: YAY! I finally got a replacement for the faulty System Board that works! I've been dying to re-play Dead Space 2 and finally can! :D

Sourceforge page

Just created a sourceforge page: https://sourceforge.net/projects/proudclod/

PrC is finished.

I'm done with this hanging over my head. The original PrC is finished and I'm putting it to pasture. You'll note the new links over to the left there. It's no longer an alpha build and the source is right below it. I'm also not storing it at GameFront anymore. They've changed their policies on file storage and it's not as "safe" as mediafire. In any case, the only change is the item drops/steals now work the way they should. There are probably some other things I should do to it, but it works with most of what it does. The AI editing may not be perfect, but that's what the source is for. It never really worked the way I wanted and I've probably been doing it wrong all along. Oh well, PrCMDI will come along eventually to realize my dream so put up with this for now. :) If you don't want to put up with this, then rebuild it! :D On a completely unrelated note, WM just had a birthday/release-day) so I did too. My outstandingly awesome wife got me a present that I really wanted, but didn't want anyone to actually buy for me. :) Did I mention she's awesome? 'Cause she is. OK, she got me the Wii U Wind Waker bundle AND three games! Yeah, awesome!! :) She may have gotten it to shut me up about it though.

I AM still alive

I'm trying to put the final touches on WM and put it out to pasture. Someone a while back suggested that I show previews of the growth curves as represented with HP, MP, stat, and Exp gains. I was exploring that option yesterday when I came to a realization: I wrote HORRIBLE code to handle that. The entire time I was writing WM it was with the assumption that I was controlling everything from the main form and all code should reside there. This has been proven to be a terrible practice for legacy code handling and it just became a God Class. I have proven the folly in God Classes with what I'm now trying to do and, now to make a long story short, will have to completely re-write the whole stat indicator thing. This may mean it takes a LONG time to do as I am increasing losing time to devote to either WM or PrCMDI. It will get done one day. After that, it's xml-based labels and values and I'm done with it. I'll release it with the source and someone else can have a go at it if they want.

Restore Type revisit

Remember way back when I wrote on the Restore Type and not really know what it does. Well, I know what it does now. I can't believe that I hadn't noticed this before. I'm a bit dumb-founded that no one clued me in to this or that I just never saw it or whatever. It determines a small window that comes up in battle that shows HP, MP, or Status of the player characters.
So get this, try to use a Potion in battle and the item menu is so large you can't see your characters' HP. So a small window comes up indicating current & max HP. This is determined by the Restore Type value. The Ether will bring up a similar window with MP and most status curing actions (eg. Hyper) will bring up a window that will cycle statuses that the characters have.

Except now that I know what it is, I don't know what to call it. "Status window"? "Party Detail window"? "Affecting Type Window"? It's just a little vague on what I should call it. I'd like it to be short and sweet to fit as a label in WM & PrC. Anyone have a better suggestion?

EDIT: I'm calling it "Party Condition Sub-menu" or just "Condition Sub-menu". I think that's descriptive enough.

Comments

So I'm apparently getting spammed in the comments sections. Don't think too much of it. I'll mark them as spam when I see them and they'll get deleted. I actually did make a little progress on PrC the other day. I have a working method of assigning actions, animations, and cameras to an enemy. What I REALLY want is a way to make a preview of that for the user. I can display the individual pieces of the models with textures on them, but the animation still doesn't make any sense to me. That and camera scripts aren't wholly understood so I couldn't guarantee that any preview of that would be correct. This would also mean loading up more files in memory. Not a difficult feat, but time consuming. I also thought about adding in action effects, but they are grouped in the exe rather than the archive so that's probably out. It'll be slow going from here on out. I'm still doing bits and pieces of things to it so this project will be alive until I'm done or dead.

Not related...

So yesterday, my not-yet-17mo daughter got a hold of one of my PSP cases that had a game in it. Somehow she got the case open, got the game out and closed the case. So what is the first thing she decides to do with her new treasures? She puts the game in her mouth (thankfully psp games are very hard to damage by physical contact) and begins shaking the case up and down while shaking her head side to side. She apparently thinks this is the funniest thing she's ever done by herself and begins giggling like crazy at this new coordination she didn't know she had. My wife (who is the only one with her) hears this and realizes something suspicious is going on and promptly takes both things away and calls me at work to tell me to put my things up. I can't help but laugh that it happened and be sad that I don't have any evidence of it other than her word. This is likely the funniest thing she'll do all year and I missed it. :(

After how many months...

Finally got around to opening PrCMDI's source and started tinkering again. Biggest reason why I didn't do anything before is I was crashing the designer with a custom control that I finally figured out was creating an infinite loop. I've since solved this and all attack data is correctly being processed by the appropriate window. I'm going to finish the enemy data window next. That probably won't take as long now that SpooX has posted a pretty recent PDF with the contents of the wiki. After that it's formations then a lot of GUI cleaning before a public beta! It sounds like fewer steps than it is so be patient. :) WM is fairing pretty well, but the source is in terrible shape. I mean, which would you rather have? A single 448K file with 80% of the source code in it or 28 organized files totaling 286K containing all the source in it? Needless to say it's very difficult to navigate and find where certain things are happening that need changing. Still, it's mostly ready for release. After two more adjustments it's done and I'm finished with it.

Removing Dependencies

Partially based on a not too friendly conversation I had with a user about this, I'm going to remove WM's dependency on the VB Power Packs. I didn't like using them for only a minor graphical flair so I'm switching to the more acceptable practice of using the Graphics class to draw lines (which I should have done in the beginning). This will be implemented in the final WM version which will also accompany the releasing of the source for WM and PrC. Don't think that's wholly a good thing. The more I look at the code in WM the more I hate it. It's full of bad coding practices, commented code, not documented, etc. It's not a good example of my coding ethics today. There's still the possibility of implementing xml with it, but that will take time to hunt down all the text I want to be changeable. PrCMDI will continue to be closed source.

Back to it a little

Remember back in the day when WM was being created and all the functions and properties were still being discovered; And how I had to release a new minor version just to update the description of a thing? Well say "screw you" to all that now. PrCMDI's going all xml and going to be using external strings to represent everything now. I recently helped a modder add quadruple and quintuple AP growth on weapons and armor and he'll have to manually edit the weapon/armor data using the raw data editor in WM. There's no option for greater than Triple AP growth in the drop-downs on the weapon or armor tabs because the unmodded game ignores values that are greater than 3. Well, now PrC (and eventually WM) will allow for additional changes like that. For example attack effects only range from 0 - 35 (23h) right now. However, if one adds a 37th effect to the executable, they'd have to edit the raw data in WM. There's no way to do this in PrC so enemy attacks couldn't have this. The new xml feature will allow you to add a 37th effect to the menu if you're awesome enough to know how to do that. I've already added all the texts and tested it. It works great! If I need to make a change to a damage formula or get a description wrong I just change the text in the xml and it's reflected in PrCMDI. This xml is also going to store things like text characters and element names so WM/PrC will be easier to use in other languages. It will also store battle variable and opcode descriptions so you can change them around if you wish. Point is, this is going to make WM/PrCMDI much easier to use. This will be WM's last version and I will likely release its source along with it. The source looks sloppy, but consider that I wrote the majority of it three years ago. :)

Happy Birthday WallMarket!!...almost

Four years ago, WM was in the middle of beta testing. It's gone through a lot of iterations and bug fixes to get where it's at. It still has some issues, but I'm still proud of it. I created it because I wanted to start a new game of FFVII and I learned there wasn't a tool that would let me have more materia links on the Buster Sword. After googleing my way on to the forums at qhimm I discovered what it was partly known and contributed much to what wasn't. Good times. Back to the point of this blog. So in the interrim between Skyrim and Black Mesa: Source not much has happened at all. I keep picking up PrCMDI and deciding that lots of things need to be restructured. Real life work is picking up, my daughter is starting to walk, lots of things are happening that demand my attention. This being a personal project is lowest priority to me. It still has the potential to be the greatest modding tool FFVII will ever see, but it's going to take a while in the making.

Overdue update

For those of you who haven't been watching very closely let me break it down to what is on the table now. I've been discussing strategies with other VB.NET users who are supposedly knowledgeable about such things and they think that 32 drop-downs with 800 entries (the action lists) is poor design. They don't know the specifics yet, but I'm really not certain anything else will do. I've played with the idea of a listbox that the user can click on to enable editing, but that seems a bit clumsy and adds extra clicks that I don't think the user should have to do. On the other hand, populating each listbox does take forever for each enemy form loaded.

Since I finally got time to play Skyrim I've been doing a lot of that and mostly neglecting PrC. I'll get back to it when I'm satisfied with my killing sprees in Skyrim.

I've also been "commissioned" to see how the texture effects can be safely extended from 15 fps to 60 fps without having to alter the animations themselves. What I've found is that the graphics plugin handles all of that. Since I've gotten Aali's OpenGL driver I can't see how the delivered plugin handles it. It looks like the exe dumps some values in specific places that the graphics driver reads and does things with. I have to do more investigating....

Check it out....

Nearly a full month's time gone and hardly a single line of code written. *sigh* Well, the good news is that I'm just a few hours away from being finished with my last undergraduate class of my life. I've got the final to take this afternoon so I'll be burdened by one less thing in life.

Speaking of life, my daughter is finally getting to that six month mellow period. We've started sleep training and it's going surprisingly well. She had a rough night the first night, but she got better the next few nights. Her naps seem to have gotten better too. She was taking four or five less-than-hour-long naps before and since we started making her sleep in her crib she has taken at least one hour-and-a-half long nap per day. Yesterday was the first time she got over four hours in three naps. :D Non-parents and parents of normally sleepy babies wouldn't understand, but this is a big milestone for all of us.

Anyway, back to PrCMDI! I've had many long nights thinking up a strategy for what I want to do with it. First of all will be save files that are NOT scene.bin files. That will open up the possibility for a lot of features like saved histories, comments, and just a bunch of other things. That will make saving and distributing changes super easy compared to how it is now. This way you won't have to compile the scene.bin and compare it to an original one. You'll still be able to compile the data into a scene.bin, but the raw data save will keep the data much better organized.
I'm also still super happy with the way it's being organized now. The current PrC and WM are just these massive classes that handle the data and are interdependent on each other. PrCMDI already has a dozen individualized modular classes that only raise events to each other. I'd like to get most of the code off of the form classes like they are now and concentrate solely on display from there.

Addendum:
Oh yeah. Bosola also suggested some helpful changes to WM so I might be adding those in soon. I might re-write WM again too. It would still look about the same, but the code needs a lot of untangling.

Got a few more....

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

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

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

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

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

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.