[PSX/PC] General editor - Hades Workshop (0.50b)

[Tirlititi]

Yes it is possible to make the Mini-Prima Vista catchable.
1 ) Go edit Hideout's script and seek the functions "Theater_Ship_Miniature" (any one of those),
2 ) Right-click on the function's name and choose "Add" to add a new function related to Prima Vista's entry,
3 ) In the properties, let the Entry Type to 2 and change the Type to 3 (for a Speak button event),
4 ) Copy-paste the following script in the newly created function :

Code: [Select]

Function Theater_Ship_Miniature_SpeakBTN
    set VAR_GlobBool_158 = 0
    if ( VAR_GlobBool_159 == 1 ) {
        DisableMove(  )
        if ( VAR_GlobBool_144 == 0 ) {
            DisableMenu(  )
        } else {
            Wait( 1 )
        }
    }
    0x27( 127 )
    HideObject( 255, 0 )
    SetTextVariable( 0, 326 )
    AddItem( 326, 1 )
    WindowSync( 7, 0, 61 )
    set VAR_GlobBool_158 = 1
    if ( VAR_GlobBool_159 == 1 ) {
        if ( VAR_GlobBool_156 == 0 ) {
            EnableMove(  )
            0x27( 255 )
            if ( VAR_GlobBool_144 == 0 ) {
                EnableMenu(  )
            }
        }
    }
    TerminateEntry( 255 )
    return5 ) Change the "326" figures to your item ID ; 326 is the ID of the first unused Key item so you may use that slot to create your Mini-Prima Vista as well,
6 ) Go to the "Main_Init" function : you need to make it so the Ship won't appear again upon re-entering the field. Change these lines :

Code: [Select]

    if ( VARL_GenBool_2419 == 1 ) {
        InitObject( 3, 0 )
    }into these :

Code: [Select]

    if ( ( VARL_GenBool_2419 == 1 ) && ( GetItemCount(326) == 0 ) ) {
        InitObject( 3, 0 )
    }7 ) There's no 7th step,
8 ) Profit !

[gorildo]

Nice! Thanks.

Unfortunately, the text space on those extra key items is minimal. I guess you could replace other key items only used in Disc 1 and 2. Any save files would still be compatible, there would be no difference. It's just flags telling you either got something or not, right?

One addition to the script, that nice sound when you get treasure, "Sound2( 53248, 108, 0, -128, 125 )", I put it right before " AddItem( 326, 1 " in the script, works fine. I assume the 108 is the ID of that sound, the other numbers are identical in chests script for example. Any idea what they are?

A simple tool for playing music/sfx inside HW would be cool to help identify those sounds. I wonder if there are any unused tracks or sfx in the game data.

[Tirlititi]

Congrats for the sound, I didn't think of it ^^
108 indeed seems to be the sound ID. I don't have a clue for the other arguments but I suppose you'd expect the volume, pitch and maybe delay to be parameters. I won't add a tool for playing sounds and musics simply because I would need to convert their format (they are so-called "AKAO files", from the sound programmer's name) and I don't know of it.

However, I may do a list to easily identify them. It's only a matter of testing there.

[Satoh]

Hey Tirlititi, first, brilliant work on HW so far. I've messed with it for a while, in a lurky fashion.

Second, I've done a lot of stuff with the file structure of FFIX... or at least enough to be familiar with what's where in a few cases.
That's where my question comes in:
Main character field models are stored globally on the disc... or at least separately from the models cached in the fields themselves.
With that in mind, I'm confused as to why I can't add Freya or Beatrix(characters who are in the party model folder) to the Preload list and load them up in script.
I understand with NPC models, as they're stored in the field itself.

The option to add models to the Preload list is present, but does nothing.
I guess my question most directly is "Is the preload list just a placeholder feature?"
Changing it doesn't actually do anything, except in the editor's internal memory?

Preloading an NPC from a different field, would obviously take a lot of work... but preloading a party member seemed like it should be something that works.
I'm just trying to find out if I'm misunderstanding something, or if the feature really does nothing at all yet.



On a slightly different note, do you have any theories (its listed as unknown, but I'm curious about conjecture) on what the second argument to SetModel does? the argument generally appears to be the same for party characters (that is, Zidane is usually given 93 as the second arg, and Vivi is given a different one, but its usually the same for the same character).

It occurs to me that the parameter might be a radius for the collision area, so models don't clip into each other.

[Tirlititi]

Thanks Satoh !

About preloading models, yes, that's kind of strange. The preloading list does exist in the game's data and you really modify it by adding another model. However, it seems to be not sufficient... It might have to do with this 2nd parameter though, as I don't have a clue about what it does. It might be what you say, but the Moogle on the World maps actually have a 200 value, which is quiet large if it's a collision size...

[Satoh]

I did some testing, I have an answer on the second parameter of setModel.
It determined the height adjustment for message windows, the 'player is here' pointing cursor, and probably some other 2D UI elements.

That's why the moogle's is so high, it's already a flying model.
Incidentally, you see similar things in pigeons, which fluctuate between 93 and 37, which I assume is for the ones that fly versus sitting on the ground.

It also seems to affect the head's up and down tilt for head-look operations. When I set Zidane's to 255 his speech bubbles appeared nearly at the top of the screen, and he looks up into the sky instead of straight ahead when talking to Blank, who is about the same height, right in front of him.

Hope that helps in some way.

[Lein]

This is very cool, love that you can edit the battle scene models. Will you make it possible to export and edit the character models too in the future? I was looking at the backgrounds and noticed some of them have animations, how exactly do these animations work. Are tiles being animated? I really wish I knew how they made those pre rendered backgrounds, it's so neat to be able to put unlimited amount of detail into an enviroment like that, I have tried to replicate it in various programs and it always ends up being a major hassle.

But looking at the backgrounds in this editor confuses me, anyone know how these work Textures on planes?

EDIT: I tried to add a sign to the first battle scene, when you fight the fat man. Exported the textures and the obj file then imported it into blender and added the sign, I edit one of the textures and applied that texture to the sign. Reimported it but it seemed to not work, is it even possible to edit the battle scene models/textures?

It broke, I see the parts of the texture is from my custom made texture but the uv's are messed up. I had a custom model but it seems to not have been loaded. I don't understand what the palettes are for, also there are so many texture slots, could anyone who understand how the scene editor works make a small video tutorial showing the process of replacing or editing the battle maps?

[Satoh]

HW doesn't truely need the option to export character models, as there are programs that do that already, and exporting them into a usable format would require a lot more effort than, say, making the preloading work.

In theory preloading would source a model and its animations from an existing field, and inject them into the archive that holds the field you're trying to change.

Which would of course be a complicated undertaking, but it wouldn't involve any format alteration. (I'm currently contemplating that issue myself)

That's not to speak for Tirlititi directly or anything. I'm just stating how I see it. There are more important features, and there's a lot of scripting opcodes which are indecipherable...

As for battle scene import, I think its likely that it doesn't work perfectly (as I said before, converting between model formats is no simple process), and possibly you may not have handled the textures correctly... I've never tried it myself. The textures the game uses are a specific 256 color palettized image format, so they can be recolored multiple times, while remaining very small on the disc. This means most images will not work, as they will be in raw 16million color formats.

Of course it's also just as likely that the feature is simply buggy, not for lack of effort, but just because PSX games are pretty strict about what they can and can't load, so any seemingly benign tweak may simply be impossible without better understanding the format.

Some games can only load vertices that fit in an area that is no more than 127 integer divisions away from 0 in any direction. Other games may go as high as 32767. It could simply be that whatever you tried to change, wasn't something the game could load, or possibly, wasn't something the conversion function could handle. There's a lot of possible points of failure with things like this.

It seems likely to me, that adding new vertices, probably won't work without first deleting an equal number from some other area in the scene, as well as counting triangles in the same way. The disc has limited space for storing these things (very very limited) The game also has specifics on what it can and can't do with UVs (some programs can't handle one vertex having multiple sets of UVs).

And as I said, you probably used the wrong kind of image.

[Lein]

Yes I'm just an amateur, programming isn't my thing. I prefer creating stuff, so all this is really nothing I can comment on. But still I think it's a very nice tool you've made, mostly because you can see how they made the backgrounds, something I would be very interested in knowing. The elements that are being animated in the backgrounds seem to act like gifs. I don't understand the technical stuff of how the they made the backgrounds work.

As far as I understand it to not mess up the perspective on the backgrounds the camera is static and it's the background textures on the plane that is being animated as the character moves around? But what about the collison mesh, it's so confusing anyone who knows how they made that prerendered stuff work? I think it might be a lost art, unlimited detail in a background is something that with the higher resolution that games can be run in today could look really neat.

[Satoh]

First: I in no way intended to imply that I had anything to do with developing Hades Workshop. I'm just a technically minded guy who kinda understands how the game works.

Second, the backgrounds are static images, and there's a script function that replaces some of the tiles with other tiles stored in the same field map, waits a number of frames, and then replaces them with another tile. I don't comprehend 100% how that works yet, but I am quite certain I can spot it when I see it.

You're mostly right on how the camera works, except that it can be changed and moved in the game for specific things. There are a few scenes where the camera moves during a cutscene where the video replaces the background, like in the Evil Forest just after escaping Alexandria at the start of the game.
The camera also moves when looking at different angles of the same room in a map... this happens rarely, but is first seen when Baku (in a dragon mask) jumps from the door. That door is not a new room, just a different camera angle, with a different background image applied to it.

To properly comprehend how that works, I should explain that the walls of a map are actually determined by the shape of the floor... or in other words, you can walk anywhere there is floor, and you can't walk where there is no floor. This theoretical floor is called the walkmesh, and is a 3D model.... just an invisible one. You can actually view a map's walkmesh in HW by opening the script editor and switching the tabs down in the lower left corner.

I'm not sure on the practical side of replacing images, as I said I haven't tried it, but in theory, all you need to do is make a render or painting of the area you want to replace, cut out portions of that picture that need to layer on top of the character in the foreground, and probably some stuff with chopping the image into tiles... I don't think HW handles that yet... for the same reasons it doesn't do preloading models correctly: It would involve a lot of shuffling data around in a messy complicated way.
background images are stored as a collection of 16color palettized tiles that are 32x16 and there can be... I'm not sure exactly how many palettes for a full map. Part of me wants to say 32 per tile package... and some fields have multiple tile packages... The game is kind of a mess looking at it from a 'I want to make changes' standpoint. It was all done for hardware limitations of course, and it performs admirably as a game... but its certainly not user friendly for mods. I'm honestly astonished HW has so many working features.

About character models and such, most of that can be viewed by a program called noesis. You can look that up on your own, as I'm not totally sure how Qhimm handles that topic these days. Last time I came around it was kind of a hotbutton.

As for 'how they made the backgrounds' themselves... They did it in a 3D modeling program, put in loads of detail, rendered a high quality image, then shrunk it until it was small enough to fit in the game. No big mystery really. And actually, some of the stuff you see in the scene may actually be lower in actual quality than the models you see in realtime in modern games... even as old as early PS3 games. They only look nicer most of the time because you don't see them up close. A lot of them have really terrible texturing (there are a few original high definition renders floating around the internet, but only a few), but it looks nice enough when its pixelated. Its kind of like looking at 1990's 3D cartoons... they were amazing at the time, but you look back and realize how awful they really looked up close.

For an example of how the animated tiles work, you can look at Environment Tab > Field Tab > Prima Vista/Engine Room > Edit Script > Function Code1_Loop.
In Code1_loop you should see a number of SetTileAnimationFrame(...) calls. That's where I'd look to start understanding it.
It also helps to be able to run the game with the patch automatically loaded, rather than having to actually patch a copy of the game every time you edit something. I find frequently changing, exporting a PPF patch, and using an emulator that automatically loads the patch while running the game, is an effective way to learn how code works.

[Lein]

Even on the PS4 today it would be difficult to achieve as much detail as is in this scene for example.

Rendered scenes today can look fairly realistic, look at this for example, digitally created.

Compare the two above to what the playstation 4 can do.

The thing with pre rendered backgrounds is that they don't even have to be rendered, they could be photos.

Creating the pictures isn't hard, even animating parts of it isn't hard. I could easily make the branches in the photo above wave or have it rain or simulate a river. If the camera is static it wouldn't even be so hard creating a walkmesh and have a character run through the picture, you would have to know the lens the camera used but it could all be done fairly easily. For perfect accuracy you would ideally have to put out two paralell lines in the photo so you can figure out the perspective lines and where the vanishing points are.

The problem is understanding how the pictures are layered on top of each other and how the cameras are panning through the picture. As far as I know there is no engine that does this automatically today, what would be even more interesting than being able to rip out models and put them into the game again would be someone implementing a pre rendered background feature in unity or unreal or some other engine. This Hades program could maybe give hints on how to program such a feature?

[Satoh]

Oh, I see, you want to replicate the functionality of FFIX, in another game engine?
I can respect that, I've wanted to do something similar for a while, but lack the experience to make a robust engine like FFIX.

I don't know that its exactly how FFIX does it, but the you can make a camera pan by altering the width and height and offset parameters of the frustum in any engine that lets you alter the camera matrix. This would keep the perspective vanishing point locked in one place,(in 3D) while moving the rendered image around on the screen.

Does that help?

As for the layering, unity allows for rendering layers, such that even if an object is behind another, it gets rendered later, and thus on top of everything else.
I suspect the hardest part about replicating FFIX in Unity would be the battle stuff.

As for using the models... that's a tricky subject. I have them, but because of the way they export, one model only supports one animation, so in order to use them one would need to export a duplicate of each model, for every animation. I'm strategizing how to get around that.

For now, I think the best option would be to try to work around the problems you might face in HW, as some cool things can be done with it, if not everything you might wish.

For example, beginning the game in the Festival of the Hunt (which is my pet project for HW. End goal: have a choice in playable character, more enemies and getting into scraps with the other participants.)

[Lein]

The rendered scene that would be moved around by the width and height offset parameteres would consist of several layers of background, also the "walk mesh" and the character would be in perspective, but how would those move around as the textures on the planes are panning around. I think this is by far the most difficult thing to do, harder than creating a battle system. No doubt they didn't use planes like in the image below when they made the FF games, they had figured out some easy pipeline for creating these backgrounds.

Something as simple as:
1. Setup camera
2. Place objects.
3. Render out scene.
4. Create walkmesh.
5. Send the stuff away to someone else who would put them into the game within 2 min with a few clicks.

There are other 3d objects in the scene other than the player too. I think creating those pre rendered backgrounds might be harder than a battle system. A static camera is easy, an animated camera that is lined up with the perspective of all the 3d elements in the scene, mind boggling. Good luck on your mods.

[Satoh]

When the camera pans around a scene in FFIX, the camera position does not change. Only the edges of the frustum are altered. It's easy to manipulate cameras in that way in Blender, and the same kind of matrix is used in Unity, though it does require some scripting to alter the camera matrix in that way...but its not really difficult.

The background images aren't rendered anywhere in the scene at all, they're UI elements that have a layer number, which represents a 'distance from camera', and is used to determine when the image is rendered. Closer imaged to the camera get rendered later, so they appear on top of other images and objects.

What I'm trying to say is, its not as difficult as you seem to think it is. Unity already has all the functionality you'd need to do it, probably in only a small number of lines of code, using generous amounts of Camera.ScreenToWorldPoint(...)

You're thinking about the maps as though they're 3D scenes, when really the only 3D part about them is the walkmesh and character model. Everything else is done through 2D layering the same way as menus and speech windows.

As for the camera moving around the scene, it doesn't happen, except in a select few places, and that uses prerendered video with characters dropped on top of it. Those scenes don't support objects overlapping the character models at all, and you can see them actually in front of the foreground in some of those scenes, if only for a few frames, because of that limitation.

[Lein]

But if not all of the walkmesh is seen in the camera view and you run to the right, the background image is scrolling but the walkmesh remains static or is it the walkmesh that moves around while the character is being static. Because when you reach the edge of the camera view and the walkmesh goes beyond the camera view, how are you suppose to see the character if he walks off camera. The walkmesh and the characters would have to "scroll" with the background picture no? I'm no doubt missing something.

[Satoh]

What I'm trying to say is, computers can render cameras "off center", which is to say, you can move the portion of what is being rendered around, without changing the focal point of the lens, only the edges what it sees. This is what FFIX does. (You'll note in a few places, the character models seem to stretch ever so slightly at different places in the map, that's because they're past the part of the camera lens that would normally be clipped off, and the perspective calculation has become unrealistically drastic....It's hard for me to describe it, but I may be able to show you with a picture.


Here we see two cameras. the pointed part on the bottom is where the camera is, and the rectangular part is 'what it can see'. On the left is a normal camera. Its focal point is directly in front of where it is in space, and what it can see is equal on the left and right of that focal point.
The right camera also has its focal point directly in front of it, but what it can see, has been shifted far off center, to the right, with anything to the left of the focal point being cut off completely, but much more being visible to the right of it.


Here we see the camera on the left, looking at a cube that is slight off center from it.


And here we see the what the camera on the right sees when looking at the cube from the same location and pointing in the same direction as the first.

Note that the cube looks exactly the same, but appears in a different region of the render area. This is because the camera's position and angle never moved. Only the edges of its periphery were changed.

You can imagine it like being able keep your eyes pointed forward, but shifting your brain's attention to the things in the corner of your eye, instead of what they're pointed at.

That's what I mean by "changing the frustum matrix"

[Lein]

Can the frustrum size be animated in blender, or do you have to animate the camera with scripts. Can the frustrum size track an object through the viewport. I want to try to recreate one of the pre rendered backgrounds in the blender game engine. Do you have the code or would it be difficult to type out?

We could use this as our background, since you can walk under that bridge it'll really sell the effect. Let me know if you could do the code, then I'll start recreating the walkmesh in sketchup and create an updated final fantasy character to run around in the scene. Because we're in a modern engine the character will be able to cast shadows, if you're interested let me know.

By the way I appreciate the explanation.

[Satoh]

I honestly don't know anything about the blender game engine. There is an addon that allows you to animate just about everything in blender, called AnimAll. Turn it on and you should be able to keyframe any property by hovering and pressing I. The property you want for the frustum will be in the Camera settings (with the camera itself selected that is, not the regular render settings) and its called "Shift" there will be one for X and one for Y. I don't know anything about object tracking. I know blender has it but I don't know if it has the features needed for FF style panning.

I honestly don't have the time to do any coding for it in either Unity or Blender though, otherwise I'd probably have shown an example... Also finally, lets not get too far off track, this is a thread for Hades Workshop.
Recreating the functional engine of FFIX would probably be best discussed in its own dedicated thread... though I've never had luck actually recruiting coders who had more experience than myself, which is probably what you'd need to do, if you don't know how to code...

Also, worth noting, FFIX for PC will be out soon enough, and may open the door for a lot more modding possibilities.

[Lein]

Ok Hades related question, when I try to export the field backgrounds, I want to keep the layers but when I export the background it seems to only export half of the background. Shouldn't there be many tiff files that you could layer in photoshop.

[Tirlititi]

Thanks for the SetModel parameter Satoh, and for the interesting explanations ^^

Battle Scene importing (and even exporting) is not working well indeed. That's a part of the program I started a long time ago and I didn't got back fixing things there, mainly because they're quiet messy to begin with. Actually, I think the best I've ever done with that is exporting a scene, modify the position of 1 vertex and import back the model. The fact that it worked was a big success for me ^^"
I don't think you can use another amount of materials than the default one (and maybe you can't use another amount of vertices either).
Also, the exportation is partial because some scenes have animations (such as Trance Kuja's battle scene, where the crystal is seen floating behind him).

About the field backgrounds, you can export them :
1) Either one by one using the "Background: Manage" button and then "Export". This way, all the checked tile blocks will be exported as different layers of the .tiff image (unless you merge them). I don't know for Photoshop, but Gimp asks about using those layers as new images or using them as normal layers when I open the .tiff image with it.
2) Either by file batching. This way, all the tile blocks will be exported.

As Satoh said, field backgrounds are composed of tiles, which are 16x16 little images (potentially transparent). Those tiles are then packed into tile blocks, which is what you see in HW.

By the way, if you happen to know about image format and have an idea for a better one than .tiff, let me know ^^
.tiff seemed to me the most standard format that supports multiple layers, but if photoshop can't read them as layers, that's a problem.

[Lein]

Yes tiff doesn't seem to have any layers when you open it up in phtoshop. Might be a problem in the future if you'll ever make it possible for people to reimport pictures. But I doubt anyone will ever do that, you can't make the backgrounds higher resolution anyway. I'm trying to recreate the pre rendered effect in another engine and I thought I'd use one of the backgrounds from ff9, if I could export a character model from the game and it's animations too. I could basically recreate a scene exactly as it is from ff9. It's not a big deal, but if you want it to work you could maybe make it work somehow.

[Satoh]

Yes tiff doesn't seem to have any layers when you open it up in phtoshop. Might be a problem in the future if you'll ever make it possible for people to reimport pictures. But I doubt anyone will ever do that, you can't make the backgrounds higher resolution anyway. I'm trying to recreate the pre rendered effect in another engine and I thought I'd use one of the backgrounds from ff9, if I could export a character model from the game and it's animations too. I could basically recreate a scene exactly as it is from ff9. It's not a big deal, but if you want it to work you could maybe make it work somehow.

I had every plan to reimport new backgrounds at some point. Not everyone cares about a higher resolution.
As I stated Lein, there are other programs that already export the character models and animations to usable formats.

[Tirlititi]

From my point of view, Photoshop is faulty there, cause I found the .tiff layer format in some official .tiff documentation. I don't see why Photoshop doesn't support that feature (as said, Gimp does).

Well then, since SE decided to keep the release of the Steam version for later, here is the v0.33 :
 - Added a MIPS editing feature. MIPS is the coding language shared by all the PSX games. It's the deepest level of game modifications and shouldn't be used carefree. More infos below.
 - You can now add and remove several things, so you don't need to recycle another item to create a new one :
 --- Add/Remove texts in text blocks and battles,
 --- Add/Remove enemy groups,
 --- Add/Remove enemy spells.
 - Completed the list of spell effects, though I only know the effect of "Defless" among the new ones : it unconditionally divides both defences by 2.
 - You can now use the field models of most of the playable characters. Indeed, the problem was that you don't only need to add the character's model in the preloading list, but also link it to a script's entry. The related "InitObject" call is a necessary step to preload the 3D model.
 - Added a background artwork image. It was made by Maxa' and I'm really glad of it


Here is the step-by-step method to use one of the playable character's model on the field :
1) In the target field's script, choose an object's entry. You'll replace that object by your playable character's model, so you need to choose one you won't use anymore. Modify the scripted events and whatever you want in that object's script ; don't touch the "Init" function yet.
Note : in some future version, you'll be able to add new entries, so you won't have to dummy one. You may also keep the old entry's script and thus use both objects (the old one + the new character's) using a trick : use a global variable and increment it in the object's "Init" function. This way, you'll be able to identify different instances of the same entry and give them different models. See the script of Linblum Soldiers in "Brahne's Fleet/Event" in disc 2 for an example of that system : there's only 1 entry for 2 different soldiers.
In any case, the important thing there is to note the chosen entry's ID (the number used in the related "InitObject" call).
2) Change the Preloading stuff of that field and add your character's model. Here is the list of the ones that can be used for now :

Code: [Select]

Vivi (8)
Dagger_Bis (76)
Zidane (98)
Dagger (185)
Freya (192)
Beatrix (204)
Quina (273)
Eiko (443)
Amarant (509)
Steiner (5489)I don't think you can use battle models ; there seems to be a problem when using them.
When you add the model, you're asked for a number : enter the ID of the previously chosen entry.
If you don't have enough space, you need to remove some other object.
3) Return to the field's script and modify the "Init" function of your character's entry. Here are the different setups for the animations and sizes :

Code: [Select]

    // Vivi
    SetModel( 8, 61 )
    SetStandAnimation( 148 )
    SetWalkAnimation( 571 )
    SetRunAnimation( 419 )
    SetLeftAnimation( 917 )
    SetRightAnimation( 918 )
    SetObjectLogicalSize( 20, 30, 44 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 65, 57 )

    // Dagger Bis
    SetModel( 76, 91 )
    SetStandAnimation( 2089 )
    SetWalkAnimation( 2086 )
    SetRunAnimation( 2091 )
    SetLeftAnimation( 2088 )
    SetRightAnimation( 2084 )
    SetObjectLogicalSize( 20, 26, 42 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 89, 4 )

    // Zidane
    SetModel( 98, 93 )
    SetStandAnimation( 200 )
    SetWalkAnimation( 25 )
    SetRunAnimation( 38 )
    SetLeftAnimation( 40 )
    SetRightAnimation( 41 )
    SetObjectLogicalSize( 20, 24, 40 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 97, 61 )

    // Dagger
    SetModel( 185, 91 )
    SetStandAnimation( 2089 )
    SetWalkAnimation( 2086 )
    SetRunAnimation( 2091 )
    SetLeftAnimation( 2088 )
    SetRightAnimation( 2084 )
    SetObjectLogicalSize( 20, 26, 42 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 89, 4 )

    // Freya
    SetModel( 192, 94 )
    SetStandAnimation( 2556 )
    SetWalkAnimation( 2553 )
    SetRunAnimation( 2558 )
    SetLeftAnimation( 2555 )
    SetRightAnimation( 2551 )
    SetObjectLogicalSize( 26, 34, 48 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 105, 53 )

    // Beatrix
    SetModel( 204, 100 )
    SetStandAnimation( 2978 )
    SetWalkAnimation( 2975 )
    SetRunAnimation( 2981 )
    SetLeftAnimation( 2980 )
    SetRightAnimation( 2974 )
    SetObjectLogicalSize( 20, 20, 30 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 104, 48 )

    // Quina
    SetModel( 273, 92 )
    SetStandAnimation( 3228 )
    SetWalkAnimation( 3237 )
    SetRunAnimation( 3230 )
    SetLeftAnimation( 3235 )
    SetRightAnimation( 3227 )
    SetObjectLogicalSize( 40, 48, 60 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 65, 45 )

    // Eiko
    SetModel( 443, 63 )
    SetStandAnimation( 7503 )
    SetWalkAnimation( 7518 )
    SetRunAnimation( 7506 )
    SetLeftAnimation( 7516 )
    SetRightAnimation( 7514 )
    SetObjectLogicalSize( 20, 24, 38 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 65, 5 )

    // Amarant
    SetModel( 509, 122 )
    SetStandAnimation( 8307 )
    SetWalkAnimation( 8316 )
    SetRunAnimation( 8312 )
    SetLeftAnimation( 8310 )
    SetRightAnimation( 8314 )
    SetObjectLogicalSize( 30, 35, 50 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 65, 0 )

    // Steiner
    SetModel( 5489, 104 )
    SetStandAnimation( 2001 )
    SetWalkAnimation( 1996 )
    SetRunAnimation( 2005 )
    SetLeftAnimation( 1986 )
    SetRightAnimation( 2010 )
    SetObjectLogicalSize( 30, 35, 50 )
    SetAnimationStandSpeed( 14, 16, 18, 20 )
    SetHeadAngle( 97, 32 )You can unfortunatly only use those 5 animations each time. The other character animations are field-dependant.


Now, about MIPS.

The available MIPS code is the one from the battle system. Every time you're in battle, that's the code running in the background and processing everything. A convenient part of it handles the spell effects and that's the main modifiable thing for now. You can modify the different assembly-like instructions and they are displayed a bit more readably on the right. The spell effect scripts are called at the "Effect Point" of spell animations. Be sure to check the help ; though it is far from complete, it's still a first introduction to it.

Let's start with a relatively simple example : the effect of "Pure Damage". It consists of these lines.

Code: [Select]

$2 = $29[51] & 0xFF
nothing
$2 = $2 | 0x1
$29[51] = $2 & 0xFF
$4 = $17[8]
nothing
$3 = $4[5] & 0xFF
nothing
$2 = $3 << 1
$2 = $2 + $3
$2 = $2 << 3
$2 = $2 + $3
$3 = $4[7] & 0xFF
$2 = $2 << 2
jump 0xB4CC0
$3 = $3 + $2

// What lies at 0xB4CC0 :
jump 0xB7918
$29[54] = $3 & 0xFFFFThe $ things are placeholder for variables (RAM registries actually). There are 31 of them, most of which that have special purposes.
The brackets are used to retrieve or store a data from the memory. While non-brackets can be seen as temporary variables, for calculation purpose, the brackets ones are used to communicate with the whole system.

Let's get a closer look :

Code: [Select]

$2 = $29[51] & 0xFF
nothing
$2 = $2 | 0x1
$29[51] = $2 & 0xFFThese lines are adding the bitflag 0x1 to $29[51]. That "$29[51]" is a special data that will be used latter by the "jump 0xB7918" call. Note that a lot of spell effects (all I think) end with a "jump 0xB7918" call : it resolves the effect by applying the damage, the statuses, checking if the target should die or change state, run the "hit" animations, etc...
The bitflags "$29[51]" are flags about the effect on the target. The bitflag 0x1 is the one saying "This spell deals damage" so now all you have left to do is to set the amount of damage dealt.

The following lines :

Code: [Select]

$4 = $17[8]
nothing
$3 = $4[5] & 0xFF
nothingare used to retrieve the spell's power. "$17[8]" is the casted spell's data offset and the 5th data is the spell power (its written in 8 bits, just like the "$29[51]" flags, hence the 0xFF). Now the variable $3 holds the spell power.

Next are those lines :

Code: [Select]

$2 = $3 << 1
$2 = $2 + $3
$2 = $2 << 3
$2 = $2 + $3
$2 = $2 << 2You can translate them by "$2 = (($3 * 2 + $3) * 8 + $3) * 4" or, shortly, by "$2 = $3 * 100". Since the raw multiplications are slow operations (or were at the time), the devs prefered to use shifts and sums instead.
Next to it, there's also :

Code: [Select]

$3 = $4[7] & 0xFF
$3 = $3 + $2
$29[54] = $3 & 0xFFFFThe spell's accuracy is stored into $3, then added to $2  and stored into "$29[54]", which is the memory place where you need to store the damage number before the "0xB7918" call. Note that the line following a jump call is always executed before the jump actually occurs (there's a delay of one instruction).

To sum up, this code explicitely does that :
1) Add a flag "deals damage" to the effect,
2) Set the damage to 100 * Spell Power + Spell Accuracy,
3) Run the "Apply Effect" code (0xB7918 ; note that it can differ depending on your version of the game).

Check the help to have a list of useful known data addresses. You'll know how to retrieve data such as caster's or target's stats. If you're interested in modifying raw spell effects, I encourage you to check out how most simplest are done. Namely, you should check out these spell effects :
Minus Strike, Lucky Seven, Thievery, Frog Drop, Dragon Crest and Grudge (other "Pure Damage" like effects, with more complex damage formulas),
Defless, Absorb Magic/Strength (another effect than damage, but quiet simple),
Darkside, Drain and Osmose (damage/heal on the caster and use of the different flags),
Chakra (HP and MP heal, and also an example of an effect using a supporting ability),
Curse (change the elemental weakness of the target and display a special text. I suspect the element of the spell Curse to be specially randomized the same way that Roulette's target is randomized ; that's something specially handled by the battle script, but not at the "spell effect" place).

Note that there are a lot of "jump" calls that lead out of the spell effect's range - sometimes to another spell effect's function part, sometimes to another part of the battle script and even sometimes to another part of the RAM script, not battle-related -. You can try to guess what's their purpose (mainly : they do the standard damage and dodge calculations) and treat them as black boxes. You can also copy the address offset and paste it in the "Full Code" area to see the target code.

Since that's complicate even to understand the code (and even more to write one), I'll do samples of custom spell effects and post them here. If you have ideas, you can ask and I'll see if it's reasonably easy to make ^^"


Fiou, I hope some of you will find interests in this version. I'm both glad to be able to modify spell effects and disappointed to have it so complicated ^^"
By the way, to add to the masochism, that MIPS coding thing will surely be useless for the Steam version ; that's one of the first thing they'll have updated for sure.

[gorildo]

Wow, amazing work with those MIPS codes, it must be possible to do some crazy stuff with it. As an idea for spell effects, is it possible to turn off EXP/Gil gain (like the Break spell) with the Death spell or make an enemy nontargetable while Petrified?

Also, do you think it would be possible to figure out the codes on the game mechanics, to permanently remove the damage limit or use a bigger integer for HP values? What purpose could there be to using just 16 bits for that?

By the way, it's cool that you can add spells now, but then you must manually edit each enemy script. It would be nice to have some samples of scripts for casting a spell randomly or under certain conditions. But that would take a lot of space along with the other scripts, and this thread is getting crazy big. We need somewhere to collect and organize those scripts.

[Lein]

Something that my little brother would appreciate would be a much harder version of ff9. That's something I think you guys should start working on, harder bosses and enemies.