Final Fantasy Hacktics

QuoteDo you know whether you can trigger map events (like doors opening, or the map switch that happens when the sluice opens) within abilities? Because that might make it easier to do a water-raising spell, for instance.

Nope, I'm not too familiar with the map events.
Zodiac or Lasting Dawn is probably the best at it.

But that is a good idea. I can watch how the game "refresh" terrain.
Some battle like "1 vs 1" with Gafgarion force you to open the gate, which change the terrain.

Very excellent news Gomtuu, about the map editor. I have actually been sketching map designs in my spare time...

Anyways so I did mapslit on MAP098.7 and for file MAP098.7.100.lbg.3.bg this is what shows up in NotePad:
<h"øð334

Now I thought all the files generated by Mapslit were meant to be edited in a text editor, this isn't even the correct amount of bytes as far as I can tell. What am I doing wrong?

Quote from: "Cheetah"Very excellent news Gomtuu, about the map editor. I have actually been sketching map designs in my spare time...

You'll probably have lots of time to get those sketches just right...

Quote from: "Cheetah"Anyways so I did mapslit on MAP098.7 and for file MAP098.7.100.lbg.3.bg this is what shows up in NotePad:
<h"øð334

Now I thought all the files generated by Mapslit were meant to be edited in a text editor, this isn't even the correct amount of bytes as far as I can tell. What am I doing wrong?

Ah, I thought you meant it was printing funny characters. Funny characters in the output files are normal because all mapsplit does is split up the binary map data into separate files. You still have to edit those files with a hex editor. The reason it doesn't look like the right number of bytes is probably because Notepad is guessing that the file is a text file with multi-byte character encoding.

I wanted to make mapsplit produce text output eventually, but I never got that far.

So all mapsplit does, really, is make it easier to find the data you want to edit. Once you've edited the split files, you can use mapjoin to combine them into a working map. Also, mapjoin will warn you about certain things, like a chunk not being the right size, so it does make the editing process a little less error-prone.

My problem was that I wasn't accounting for the random 3 bytes that show up at the end of the BG file, hence my confusion. I have that all figured out now, but now I'm stuck on another part. Here is my basic problem:

I have done some color changes for a map using event instructions, but all those changes get revert to defaults when a spell is cast that changes the colors. So I figure I should just change the map directly instead. I have the background working, but now I can't get the color of the map or the characters to work. I have been making changes to amb light but have notice no changes. Do I need to change some of the dir light, and if so could you explain how the work in more detail?

So I messed with dir-light rgb, and it appeared to change the angle of the lights creating weird shadows but no changes to the color. I tried changing dir-light xyz and there once again appeared to be no changes... I super stuck now.

Hmm... Try changing every byte in the lighting/bg chunk to 0. If you still have light after that, then most likely there is something else affecting the light colors. (Maybe the event instructions?) Or there could be a bug in mapsplit. Did you try your recombined map in map2gl, or in the game, or both? If map2gl and the game render it the same (both with unexpected light when the lighting chunk is zeroed out), then there's probably a bug in mapsplit. If map2gl shows a dark map and the game doesn't, then there's probably something else affecting the lights.

For reference, the ambient light is the minimum light level. In other words, the darkest part of an object will always be at least as bright as the ambient light. Directional lights add more light on top of that minimum, but unlike ambient lights, they don't light all sides of the object evenly. Sides (vertices, really) that face the light will be brighter, and sides that face away from it will be darker. The vertices' normal vectors determine the direction each vertex is considered to be facing for lighting purposes. The more similar a vertex's normal vector is to the directional light's XYZ (or, if I have it backwards, then the more similar a vertex's normal vector is to the exact opposite of the light's XYZ), the more that vertex will be illuminated by the light.

Okay well I did some more experimenting with changing values to 00 for dir-light rgb and xyz, and I can confidently say that I think mapjoinsplit works fine and that I'm just not understanding how the colors are getting adjusted. For instance whether I change just rgb or just xyz to 00 for all values, they both look exactly the same in game. Though i suppose that is possible...

Either way I'm still stuck and am continuing to experiment to see if I can get it to work. I took lots of screen shots to document just in case you wanted to see what it was turning out like.

PS: I'm sorry Gomtuu but this stuff is driving me nuts. Just tell me how this represents 3 sets of RGB colors and maybe I will get this. This is the data in map 98.7's dir-light rgb file converted to decimal:

224 9 224 9 224 24 192 10 96 11 64 23 96 11 0 12 128 21

Well I have been at this all weekend and I'm giving it a rest for now. I am finally starting to understand dir-light rgb, but I am just unable to get the results I want. Apparently every other byte in dir-light rgb is filler because I deleted the 1st,3rd,etc bytes and nothing changed. Now I have things very close to what I want, but now whenever I change any byte it changes one of the lights to green and I can't figure out why. Most of my tests have been in game, but now that I'm doing the same things in Map2gl it all looks completely different. So I'm totally stumped.

The first screen shot is the closest I have gotten doing map editing (you can see the values I used for dir-light rgb at the top) and the second is what I want to achieve, which I did using event instructions.

Sorry, I only just noticed your last two posts here. I'm not sure I can explain your results off the top of my head, so I'll do some experimenting and get back to you. Meanwhile, here are a few thoughts:

• If you change the XYZ (direction vector) values to 0 but not the RGB values, I would still expect the lights to go dark, so that's fine. The direction vector is essentially multiplied by the color, so if either one is all zeroes, you're going to get black. And if the direction vector isn't very long, the light will be dim. A reasonable direction vector length is 4096, so you could go with (0, 4096, 0) or (2896, 2896, 0) or (2365, 2365, 2365), etc. Use the Pythagorean Theorem.
• My guess is that the every-other-byte thing you're noticing is just because the low byte of each 16-bit value doesn't make a very big difference compared the high byte.
• You are aware the RGB values for the lights are stored RRRGGGBBB, right? That's something that's easy to miss, and if you did miss it, you'd get totally unexpected results. (The XYZ values, on the other hand, are stored XYZXYZXYZ. Weird, I know.)

1) Yeah okay that makes sense about the direction vectors and rgb values. Normal vector's still confuse the life out of me and lucky I don't need to deal with them yet.

2&3) Yeah I understand that the rgb values go RRRGGGBBB, but I guess I'm still confused by the dividing points. For this map the dir-light RBG in decimal is:
224 9 224 9 224 24 192 10 96 11 64 23 96 11 0 12 128 21

So I changed it to:
0 9 0 9 0 24 0 10 0 11 0 23 0 11 0 12 0 21
and everything looked exactly the same as far as I can tell, and thus I'm interpreting it to be formatted like this:
RGB for Light 1: R = 9, G = 10, B = 11
RGB for Light 2: R = 9, G = 11, B = 12
RGB for Light 3: R = 24, G = 23, B = 21

Those are the assumptions I am going off of right now. If those other values to play into the equation some how I would love to know it and it might be what is messing me up.

Thanks for all the help Gomtuu!

PS: If you change it to:
224 0 224 0 224 0 192 0 96 0 64 0 96 0 0 0 128 0
The map looks just as if you had made everything 00.

You're basically right, except that the values are 16-bit. So:

RGB for Light 1: R = 9 * 256 + 224, G = 10 * 256 + 192, B = 11 * 256 + 96

And so on. Does that help?

Each pair of numbers represents one value. Since the first number in a pair is 256 times less meaningful than the second number in that pair, changing it doesn't make much difference. It might even end up being identical because of rounding.

Sorry Gomtuu I'm still a bit confused, because I thought the max an RGB value could be is 256, and now you are telling me the RBG values for the first light are:
R = 2528, G = 2752, B = 2912

There must be something I'm missing about the programming/theory/logic behind this because that is making no sense to me.

Quote from: "Cheetah"Sorry Gomtuu I'm still a bit confused, because I thought the max an RGB value could be is 256, and now you are telling me the RBG values for the first light are:
R = 2528, G = 2752, B = 2912

There must be something I'm missing about the programming/theory/logic behind this because that is making no sense to me.

I left that part out because it's a little more technical and not all that important, but if you want to know...

Basically, the Playstation hardware expects the RGB values for the light colors to be fixed-point decimal numbers with 12 bits after the decimal place. In other words, the red value is really 2528 / 4096 = 0.6171875. A value of 4096 (which is a 1 with 12 zeros after it in binary) really means 1. (The same goes for normal vectors, by the way, which is why I said 4096 was a reasonable length for a normal vector.) That's just the way the hardware is set up to do all the calculations it needs to do on the lighting. Later on in the rendering process, the color values get multiplied by 255 and rounded to integer values, so values ranging from 0.0 to 1.0 get mapped to integers from 0 to 255. But for the first part of the calculations, they're 16-bit values. If they were 8-bit during the calculations, the graphics wouldn't be as good because you'd lose too much data to rounding too early in the rendering process.

You don't really have to worry about that, though. All you really have to know is that a reasonable value for a light color is between 0 and 4096.

Oddly enough I think I actually understood that. Well at least enough to help me, thanks for the long answer . I'm getting closer to getting this right.

Hey Gomtuu. So getting those colors is still super tricky but it is coming along. Now I'm working on using objects that are part of the maps, liking opening doors and the like. So I wanted to know if there was an easy way to find out which maps had objects to be used. Or on a more ambitious note, is it possible to add such things to a map.

Quote from: "Cheetah"Now I'm working on using objects that are part of the maps, liking opening doors and the like. So I wanted to know if there was an easy way to find out which maps had objects to be used. Or on a more ambitious note, is it possible to add such things to a map.

There are two different ways that I know of for making objects on the map move the way you're thinking. One is through texture animations, and one is through mesh animations.

With texture animations, the game just takes a rectangular area of the texture in texture memory and replaces it with a rectangle copied from a different part of texture memory. The doors on the Orbonne Monastery work this way, for example. So does the gate that you have to open when you fight Gafgarion. These kinds of animations are stored in the "texture animation instructions" block in the mesh file (and mapsplit will create a "txa" chunk for them). I do have some notes about the format of this chunk that I haven't added to the wiki yet. I actually had this chunk figured out pretty well. Texture animations are always triggered, I think, by event instructions.

With mesh animations, the vertices of the mesh actually move, like the spinning windmill and its gears. I think there are a few doors that swing open, too. The "mesh animation instructions" block (which mapsplit labels "msa") stores the data that tells the game how to move the vertices. This block is a lot bigger than the texture animation block and I don't understand it quite as well, though I had made some progress. I'll look at my notes again and see what I can get from them. I think some mesh animations are triggered by event instructions and some just play constantly, but I'm not sure about that.

As for adding these blocks, it should be possible as far as I know. You have to keep the file size in mind, of course, to make sure you don't make the file so big it doesn't require another 2048-byte sector. Or we'll have to figure out how to shuffle the map files around on the CD, which I've never tried. The texture animation block is 640 bytes, so statistically there's about a 31% chance that any given mesh file will already be too big to add one without extending the file to the next sector. The mesh animation chunk, though, is 14620 bytes, plus you have to actually add all the mesh data for the thing you want to animate, so that would always require extending the file.

I've updated the wiki to  include documentation for the texture animation instructions. I'll get to the other section later.

By the way, if you want to add a texture animation chunk to a map file, you can use mapjoin to do it. Just split the map, then create a file that has the appropriate name and size (split a map that already has texture animation instructions for an example). When you use mapjoin to rebuild the map, it should incorporate the new block. Same goes for any other kind of block you might want to add to a map file.

Again, keep an eye on the file's size. To make sure you're not making a file too much bigger, divide its original size by 2048, then compare that to the new size divided by 2048. If the whole part of the second number is the same as the whole part of the first number, you should be fine. In other words, if the first number is 10.3 and the second number is 10.9, you're okay, but if the first number is 10.5 and the second number is 11.1, you've made it too big.

If you haven't realized yet, you are a god Gomtuu. Really great information, lets see if I am understanding how they work.

So for texture animations there isn't any map coordinates used, you are just referencing the original texture location and then the next texture location so that when the instruction is called it just switches them? That is what I can gather at least. So then my question is, what would happen if the original texture was used in more than one place?

I'm a little confused about the size limitation stuff, but I think I will have to just start working with it to understand it better.

PS: Do you think one of those unknown bytes could be the trigger for what event instruction triggers this animation? For instance the event instruction for UseFieldObject is just one byte usually 00, 01, 02, etc.

Quote from: "Cheetah"So for texture animations there isn't any map coordinates used, you are just referencing the original texture location and then the next texture location so that when the instruction is called it just switches them? That is what I can gather at least. So then my question is, what would happen if the original texture was used in more than one place?

Yep, that's basically it. If two polygons both used the same texture region, they'd probably both change, so if you want to have two doors that look the same but open independently, for instance, you'd probably need two identical doors in the texture.

Quote from: "Cheetah"I'm a little confused about the size limitation stuff, but I think I will have to just start working with it to understand it better.

Files on the CD are stored in blocks called sectors, and each sector is 2048 bytes. Most files aren't exact multiples of 2048 bytes, though, so there's a little bit of room for more data in the last sector of each file. If a file is only 100 bytes, then you can add 1948 bytes to it before the file is too big. Does that make sense?

Quote from: "Cheetah"PS: Do you think one of those unknown bytes could be the trigger for what event instruction triggers this animation? For instance the event instruction for UseFieldObject is just one byte usually 00, 01, 02, etc.

I doubt it. It's been a while since I played with it, but I think they were just numbered by position, so UseFieldObject(00) always triggers the first one, UseFieldObject(01) always triggers the second one, etc.

I'm not sure where to posts these other than the maps page. Has anyone else seen these images?



They look like Zirekile Falls and Balk I, only altered.