Another embarassing error

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

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

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

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?

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.

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

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

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

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

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

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

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)

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

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

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

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!

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

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

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

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

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.

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

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

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

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

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