Final Fantasy Hacktics

Hey thanks to iceknight I found some info.

Right now I'm working on it but so far I found what looks like to be:

- Height of panels
- If a panel is walkable or not
- Traps?

Damn, looks like my units are flying in the air.
The movement cursor follows the new height but the blueish tiles to indicate you can move on them is at the original height.

Without changing the map graphics, I suppose all I could do is changing the water's dept so that it doesn't look like units are underground or flying.

a great accomplishment, really.

How do you think maps are? Pre-set images or what?

I think there may have one thing that goes like...

0001 - Grass 1
0002 - Grass 2
.
.
.
00A3 - Rock 4
00A4 - Rock 5
.
.
.

Though, it might be hard to find...

My guess is more that each panel graphic is made of 32*32 nibbles or 512 bytes; With a 16 colors palette.

If it was stored like you suppose, we would have one big file (or many) containing all the terrains graphics, which is not the case.

Each map had 1 to 41 files anyway.

However it might be as you said, it's just that it would load the tiles withing the map files.

The only tiles I can recall that look exactly the same are the Darkness and tutorial tiles though.

bed desert might be a valuable map to check. it's almost 90% of the same terrain

However Bed Desert had 18 files... >_>

So it's a pretty complex map in terms of structure. :/

mmmh maybe you might check the battle with olan... all the tiles should be snowy and the must should be smaller and square-like

I'll give it a try. 10 files, 60% blizzard, 35% carve model, and rest for 3 other tiles.

Man, makes me think I'll have to make a new Image of my FFT,

Ovelia -> Draclau
Simon + Agrias -> Rafalak
in the first scene of the game

rofl battle at orbonne with 11 lvl99 Arc Knights Delitas

Maps being completely fucked up by my testing and more...

Want an easy map to check?

Use the Tutorial ones.

Quote from: "Zodiac"Man, makes me think I'll have to make a new Image of my FFT,

Ovelia -> Draclau
Simon + Agrias -> Rafalak
in the first scene of the game

rofl battle at orbonne with 11 lvl99 Arc Knights Delitas

Maps being completely fucked up by my testing and more...

take screens!

A while ago, I worked on deciphering the map data. I used an emulator and edited the save states to reverse-engineer the data. I don't remember how or where I found the data, but based on my old notes, here's what I found. Each square of the map has 8 bytes, and each byte's meaning was as follows:

byte 0, bits 0-1: unknown
byte 0, bits 2-7: terrain type
byte 1, unknown
byte 2, height, whole part
  (00-1E display a number)
  (1F-FF work, but display no number)
byte 3, bits 0-2: water depth
byte 3, bits 3-7: height, fractional part
byte 4, unknown
byte 5, unknown
byte 6, bit 7: can't move cursor to this spot
byte 6,  bit 6: cursor turns red on this spot
byte 7, unknown

Here's a list of the terrain types from my notes:

00 Natural Surface
01 Sand area
02 Stalactite
03 Grassland
04 Thicket
05 Snow
06 Rocky cliff
07 Gravel
08 Wasteland
09 Swamp
0A Marsh
0B Poisoned marsh
0C Lava rocks
0D Ice
0E Waterway
0F River
10 Lake
11 Sea
12 Lava
13 Road
14 Wooden floor
15 Stone floor
16 Roof
17 Stone wall
18 Sky
19 Darkness
1A Salt
1B Book
1C Obstacle
1D Rug
1E Tree
1F Box
20 Brick
21 Chimney
22 Mud wall
23 Bridge
24 Water plant
25 Stairs
26 Furniture
27 Ivy
28 Deck
29 Machine
2A Iron plate
2B Moss
2C Tombstone
2D Waterfall
2E Coffin
2F ""
30 ""
3F Cross section
C0 Natural Surface
C1 Sand area
D1 Sea
FF Cross section

The appearance of the map is unrelated to this and stored elsewhere in the map files as vector data. Not all of the files in the map directory contain vector data, but the ones that do have blocks that go something like this, if memory serves:

3-point polygons' XYZ coordinates
4-point polygons' XYZ coordinates
untextured (black "skirt") 3-point polygons' XYZ coordinates
untextured (black "skirt") 4-point polygons' XYZ coordinates
3-point polygons' texture UV coordinates + palette index
4-point polygons' texture UV coordinates + palette index
3-point polygons' normal vectors
4-point polygons' normal vectors

I have a map viewer that wrote in Python. It's unfinished, but I'll post it here later.

That is some pretty good information, if nothing else you presented it in a very organized fashion. Do you know where the data for the weather on the map is stored? Just wondering if there is anyway to customize it, or potentially change it while in a battle.

Zodiac, is it possible that there could be an FAQ section posted on the main page where people could submit information like this so that it would be easier to find and sort?

Cheetah,

I'm fairly certain that the GNS files in the MAP directory would be the place to start if you want to load maps in different weather conditions. I don't understand the GNS files very well, but I do know that they contain pointers to LBA addresses of the other files in the MAP directory. A single GNS file usually has many entries in it, so it points at several files. It was my feeling that these entries were probably grouped by weather condition, but I never determined that for sure.

The non-GNS files in the MAP directory can be one of two things, as I understand it:

1. Texture files, which are always 131072 bytes
2. "Everything else" files

In viewing the texture files, I've found that a map like Mandalia Plains, for instance, will have several sets of textures: One with very harsh shadows "baked" onto the texture, one with not-quite-as-harsh shadows, one with no shadows, etc. It stands to reason that the first is used if the weather is sunny, the second if it's rainy, and the third if it's night.

Some of the things that I've found in the "everything else" files include the map's background gradient colors, positions and colors for three (I think?) light sources, vertex data, texture palette data, animated vertex data (for the windmill, etc.), and I think the height/terrain-type data as well.

Since weather affects the background gradient and the lighting (it does, right?), that suggest that the GNS files contain instructions for how to load a map with a given weather condition. It would also mean that you probably can't easily have the weather change mid-event, since all that info (especially the texture data) is probably just determined once when the map is first loaded. Can anyone think of a counterexample within the game? A map that starts sunny and turns rainy, or something?

This message is getting long, so I'll post my map viewer in a separate message below with instructions.

-Don

Attached is a map viewer I wrote in Python. I never finished it, but it might be useful as a place to start. To run it, you'll need:

* Windows only: glut32.dll (included) in your WINDOWS\system32 directory
* Video card with OpenGL support and 16MB onboard RAM
* Python 2.5.1 or greater
* setuptools 0.6c6 or greater, which you can use to install:
* PIL 1.1.6 or greater
* pyopengl 3.0.0a6 or greater
* numpy 1.0.3.1 or greater

To run it from a regular command prompt, type:

python map2gl.py <path_to_map_directory> <map_number>
So, for example:

python map2gl.py D:\MAP\ 25
This is assuming D: is the FFT CD. It should also work in Linux, where it would look something like:

python map2gl.py /mnt/cdrom/MAP/ 25
Maps on the CD are numbered 0-125. (Look at the .GNS files.) There are a few maps that cause the program to crash when they load, so if the first one you try doesn't work, try a few more. While it's running, you can drag the mouse around to rotate the camera, or press these keys:

ijkl (to rotate the camera)
JL (to rotate the camera to the previous or next 45-degree angle and stop its rotation)
o (to toggle between orthographic (isometric) and perspective projection)
x (to toggle display of axes: R=x G=y B=z)
0 (to stop the camera's rotation and zero its position)
-= (to dolly the camera out or in)
_+ (to decrease or increase the camera's focal length in perspective projection mode)
[] (to go to the previous or next map)
Esc (to quit)

Feel free to use it any way you like, and let me know if you have any questions.

P.S. - Here are some screenshots of my map viewer, in case you think I'm just full of it. Notice that it can do perspective projection as well as isometric, so there's no way these were taken in an emulator.

-Don

you kick ass! this way zodiac's guesses can be verified offgame too?

you, zodiac and melonhead are on the way of doing the impossible!

karsten

...WOW!! When on earth did you make this program, that is some really impressive stuff. I sadly will likely never get your program working on my computer, I'm a mac guy, but this is a very big contribution. Are you planning any more additions to the program? Thanks for the info about the weather, it didn't occure to me that there even good be animations happening on the maps till you reminded me of the windmill. Seems like that was rather underused in the game.

Had to download pkg_resources & install it but it still doesn't work. :/

C:\Documents and Settings\Mikaël Blais>"D:\Program Files\Python\python.exe" "C:\
Documents and Settings\Mikaël Blais\Bureau\map2gl09\map2gl.py" G:\MAP\ 25
Hit ESC key to quit.
Traceback (most recent call last):
  File "C:\Documents and Settings\MikaÙl Blais\Bureau\map2gl09\map2gl.py", line
580, in <module>
    main()
  File "C:\Documents and Settings\MikaÙl Blais\Bureau\map2gl09\map2gl.py", line
528, in main
    glutInit(sys.argv)
  File "d:\Program Files\Python\Lib\site-packages\OpenGL\GLUT\special.py", line
309, in glutInit
    _base_glutInit( ctypes.byref(count), holder )
  File "d:\Program Files\Python\Lib\site-packages\OpenGL\GLUT\special.py", line
56, in _base_glutInit
    return __glutInitWithExit(pargc, argv, _exitfunc)
  File "D:\Program Files\Python\lib\site-packages\OpenGL\platform\baseplatform.p
y", line 258, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInit
WithExit, check for bool(__glutInitWithExit) before calling

Karsten,

Thanks!


Cheetah,

According to the file creation dates on my computer here, I wrote map2gl about a year and a half ago. Hard to believe it's been so long!

Back then, I couldn't find a community out there for FFT hacking, so I just had my own interest in the subject to keep me going. That only went on for a couple of months. I haven't worked on it much since then, but finding this website has sparked my interest in the subject again, I must admit. I might just pick up where I left off...

By the way, I've never tried map2gl in OS X, but there's no good reason why it shouldn't work as long as you've got the Python stuff I listed installed. Would you mind giving it a try? I'd like to see if we can get it working.


Zodiac,

Sorry! I think you're getting that error because you're missing a DLL file that I forgot to mention. Download GLUT for Win32 here:

http://www.xmission.com/~nate/glut.html

Copy the glut32.dll file into your \WINDOWS\system32 directory and then try running it again. Let me know if that helps.

-Don

I can actually get this working on my computer?!?! Yeah no worries, I will definitely give this a real good attempt. I will just pm you any questions I have about installing and the like.

There have been a lot of advances here in hacking this game real recently Gomtuu, so now is the time.

Nah, you included glut in your archive. I only tried to put it in Python's dll folder.
I just didn't try system32.

I... can't say what's wrong myself in all of this but doesn't look like OpenGL likes the format of the GLized map.

OpenGL.error.GLError: GLError(
        err = 1281,
        description = 'unvalid value',
        baseOperation = glTexImage2D,
        pyArgs = [
                GL_TEXTURE_2D,
                0,
                GL_RGBA,
                2048,
                2048,
                0,
                GL_RGBA,
                GL_UNSIGNED_BYTE,
                '\x10\x10\x10\xff\x10\x10\x10\xff\x10...
        ],
        cArgs = [
                GL_TEXTURE_2D,
                0,
                GL_RGBA,
                2048,
                2048,
                0,
                GL_RGBA,
                GL_UNSIGNED_BYTE,
                '\x10\x10\x10\xff\x10\x10\x10\xff\x10...
        ],
        cArguments = (
                GL_TEXTURE_2D,
                0,
                GL_RGBA,
                2048,
                2048,
                0,
                GL_RGBA,
                GL_UNSIGNED_BYTE,
                c_void_p(148570164),
        )
)

Zodiac,

Argh. I get a similar error on some maps and I've never known the cause. Have you tried multiple maps? It's possible some will work and some won't, if it's an error similar to mine. Mine doesn't work on maps 53 and 55, but all the other maps work AFAIK.

From Googling the error message a little, it sounds like I should be using display lists instead of vertex/texture/normal arrays. They're more compatible, I guess. Maybe faster, too. Unfortunately, I wrote map2gl before I knew about display lists.

Anyone else having any success with it?

-Don

from greega's page, 43 is Warjilis port like the one you posted.

I tried 1, 2 , 3, 25, 43 and all resulted the same.  

And it takes about 3-7mins for my computer to process the whole thing for a map just to end up with an error.

Wow, that long? On my computer--even on my previous one which was a few years old--it only takes a few seconds. Is your computer relatively new?

Well I think I have some good news. I've adapted the code to use display lists instead of vertex arrays, because I read they were more compatible. Indeed, on my computer this fixes the maps I was having trouble loading. And it seems to have fixed a little texture glitch I was having on most maps, too.

Plus, I threw away some old code that was looping through the polygons eight times to sort them various ways. This was a measure I was taking to try to get transparent textures working, but then later on I found out I didn't actually need to do it, but I never removed the code. So loading a map should be considerably faster now.

Let me know if this new version helps any.

Still no luck. I'll try downloading the alpha version you posted of OpenGL instead of the latest beta I downloaded. I presume it should fix it.

I believe I have all the stuff I need that you listed and now it is just a matter of how to get it all installed. It will be a little bit before I figure it out because I have no experience with this stuff and not enough time.

I'm glad that you are continuing work on it though. What are the limits and requirements for the size of the maps?

Well, I don't know what to do anymore... the process still always stops at glTexImage2D.

MAN... :/

Zodiac,

I've prepared a version that tries to detect the error you're getting and continue in textureless mode if it occurs. (It'll still work normally if it can, so this isn't a fork or anything.) Seeing the maps without textures isn't great, but it's better than nothing, right?   Let me know if it works.

If it has to use textureless mode it'll print an error that looks like this:

QuoteError: Unable to define texture. Continuing with textures disabled.

It may also say something like:

QuoteThe texture is too big for the video card. Max size supported: 1024

If it does, I'd be interested to know the number that it gives you.

map2gl does load a rather large texture (2048x2048x24bpp, which works out to 12MB), and I guess not all video cards support textures that large. That's the best explanation I can think of. What kind of video card do you have?

The texture should really only be 256x1024 since that's the actual size of the textures on the CD. The problem is that the game applies any one of 16 palettes to the texture before using it on a particular polygon in the scene. Since I don't know if/how I can do this in OpenGL, what I did was just put 16 copies of the texture in memory all at once: one copy for each palette. Lame, I know, but it always worked for me.

What I'll do next is make a version that, if it's unable to define the whole 2048x2048 texture, falls back on using a single copy of the 256x1024 texture without any palettes applied (just grayscale or something). That way, you'll at least be able to see something other than gray polygons with lighting and shading.

-Don

*takes off glasses*

*smashes glasses into the wall*

My God... This is probably one of the biggest developments I've seen. Absolutely amazing. I'll give it a try, as well.

Welcome back, Pixy.

Good to be back.  

The FFT hacking scene is truly turning into something bigger than I had imagined. The biggest ROM hacking scene I can remember is the Sonic ROM Hacking scene, and it was enjoyable. However, I see infinite possibilities for FFT now. I recently saw the battle sprites that were decompressed, and the Red Mage edits, which look wonderful. I stumbled upon this, too, and my jaw dropped for a quick 3 seconds. I can't say I'm big on programming or artwork, but I'm extremely impressed by and thankful for the big heads here that just keep surprising me.

I wonder what could be next?

... I have a 8mb.

Don't laugh >_>

I can't even change it since there isn't a graphic card slot.

Fucking IBM computer.

I'll just use this computer I'm on right now if that the problem (500mHz, 128mb Graph card, 320mb RAM).

Zodiac,

Mystery solved! Hehe. You should have better luck with the other computer. Meanwhile, I've updated the requirements on my original post to be more accurate and helpful.

http://auritech.byethost13.com/viewtopic.php?p=2111#2111

Wow, I didn't know George Greer's page was still around. The old URL I had for his FFT:IP page didn't work anymore... Anyway, I feel I should give him some credit because the tools he made gave me a lot of good info when I was starting out with map2gl.

http://www.m-l.org/~greerga/fft/

A.W.E.S.O.M.-O

Can you tell us about the commands?
I know that:
- Zoom Out
+ Zoom In
o Toggle RAW/Perspective view
x Toggle colored axes
i +Vertical
k -Vertical
s Toggle X-ray(dunno what else to call it :O)
b Toggle day/night

but not anything else.

I didn't think the Deep Dunjeon was completely black by default, what a shame.

May I suggest a few things?

- Wider window (about 1.5x this size); or even better, fits to screen by default.
- Add buttons to control X & Y too, that would allow me to easily rip the maps and put clean stuff for event editing/modifying starting locations.

Is the default background loaded from the map files? if not I'd rather have something lighter than complete black.

Entrance to Murond is completely black ;(

Zodiac,

Glad to hear you got it working!

The starting window size is 640x480, but it's not fixed at that size. You should be able to resize/maximize it.

You don't mean that all the maps have black backgrounds, do you? If so, there's something wrong. map2gl uses the background color information that's stored in the map files, so you should see a blue gradient on Map 85 (Mandalia Plains), for instance. Most interior maps have a black background in-game, though, so that's what map2gl shows. It'd be pretty easy for me to add a key that would override the background and set it to some other color, though. Suggestions? I'm thinking magenta would work well, since it's not used too often. But I wouldn't recommend spending a lot of time making screenshots yet, because several maps still have rendering glitches. 16, 21, 33, and 51 are just a few examples.

The Deep Dungeon maps have all their lights set to black by default, but IIRC, when lighting is disabled in OpenGL, the maps show up nicely. (If lighting is off in OpenGL, everything is effectively lit with 100% white light all the time.) I've been meaning to add a key to toggle lighting. Just haven't gotten around to it.

Map 53, Entrance to Death City, is a strange map. Its GNS file is kind of funny, and I'm still trying to figure out the details of the GNS format. The reason it's not rendering is because my program isn't finding any vertex data because it's looking in the wrong place. I still have to figure out how to make it look in the right place. Does anyone have a screenshot, by the way? I don't remember what the level looks like.

I'm not sure what you mean about "control X & Y." Do you mean control the rotation of the map? Here's a more detailed explanation of the keys. I'm putting it in a code block to make the letters easier to tell apart.

[: Select previous map
]: Select next map
k: Decrease camera's altitude angle by 2 degrees
i: Increase camera's altitude angle by 2 degrees
j: Decrease the speed of the camera's rotation around the Y axis
l: Increase the speed of the camera's rotation around the Y axis
J: Stop camera rotation. Set camera's azimuth angle to the next even multiple of 45 degress
L: Stop camera rotation. Set camera's azimuth angle to the previous even multiple of 45 degress
0: (zero): Stop camera rotation and set altitude angle to 0 and azimuth angle to 0.
-: Dolly the camera farther away from the map
=: Dolly the camera closer to the map
o: Toggle between orthographic (isometric) and perspective projection
_: Decrease the camera's focal length (in perspective projection only)
+: Increase the camera's focal length (in perspective projection only)
s: Toggle whether the black polygons around the edges of the map (which I call "skirt" polygons) are displayed
x: Toggle display of axes (X=red, Y=green, Z=blue)
b: Toggle "bright" mode (see below)

You can also click the mouse and drag to rotate the map arbitrarily.
"Bright" mode is a hack, and is not related to day or night weather conditions. Because of differences in the way the PSX and OpenGL implement lighting, the maps tend to look very dark in OpenGL. As a temporary solution, I've added this mode, which basically draws the polygons in two passes: once normally, then again using a blending mode that adds the two passes together. It's not very accurate, but it makes many maps look better, so it's on by default. Some maps look bad because the light and color get exaggerated, though, so I made a toggle for it.

I should really put a README file in the zip and put the requirements, installation instructions, command-line usage, and available keys in it. Maybe I'll include that in the next release.

Gomtuu are you saying that the Deep Dungeon does have textures applied and that you can make it look normal? You get some screenshots of that and the internet would love you.

Dunno why I said X & Y, what I meant is to put a +2˚/-2˚ hotkey for the X axis too.

Well, I can wait before taking screenshots. Thanks for telling.

I remember pressing b in many DD maps and everything stayed black.

As for resizing, I can't: pressing minimize/expand/quit all result in GL closing.

Zodiac,

Quotewhat I meant is to put a +2˚/-2˚ hotkey for the X axis too.

Ah, I see. Yeah, I can do that... Hmm, I'm running out of keys. Hehe.

QuoteI remember pressing b in many DD maps and everything stayed black.

Sorry, I didn't mean to imply that toggling "bright" mode would make the Deep Dungeon maps visible. I was just explaining its purpose and clarifying that it wasn't related to day/night or weather conditions. Getting the Deep Dungeon maps to display requires an extra feature. I've just added this feature, and I'll release the new version soon.

QuoteAs for resizing, I can't: pressing minimize/expand/quit all result in GL closing.

Do you see an error message when this happens? It's definitely not supposed to quit when you resize the window...

Cheetah,

Yes, the next release of map2gl will allow viewing Deep Dungeon levels by toggling ambient light on/off. Here's a preview!

Oh my gosh that is so sweet. You just layed the smack down on the DD Gomtuu. I need to get this thing working on my computer.

Here's a new version of map2gl. It includes several new features, including an intermediate fallback mode when full textures fail to load (should work on your 8MB card, Zodiac), and a handy-dandy README file with installation instructions, controls, a changelog, etc.

Note: I'm no longer including GLUT for Win32 because it's a third-party thing, it's not required by all environments, and it's easily found on Google.

Cool!

I'll try it in a few minutes.

Traceback (most recent call last):
  File "D:\Python25\Lib\site-packages\OpenGL\GLUT\special.py", line 111, in safe
Call
    return function( *args, **named )
  File "D:\Documents and Settings\Lucile Boisvert\Bureau\Python\map2gl.py", line 241, in ReSizeGLScene
    InitPerspective()
  File "D:\Documents and Settings\Lucile Boisvert\Bureau\Python\map2gl.py", line 193, in InitPerspective
    glOrtho(-orthobase, orthobase, -orthobase / aspect,
ZeroDivisionError: float division
GLUT callback forcing low-level exit on error: float division
OpenGL does try to resize but in the end it just closes. And this is the first time I remember getting an error, well whatever.

Zodiac,

Well, it looks like "limited textures" mode is working. Unfortunately, as the name suggests, it's... well... limited. It's really only there so that the program doesn't completely give up when it can't get as much texture space as it wants. See my earlier explanation about the 16 palettes (http://auritech.byethost13.com/viewtopic.php?t=20&start=30#2165).

There are a few more things I can try in order to get the textures working on that card... I'll take another stab at it. For now, it should look okay on your other computer.

That ZeroDivisionError you're getting is odd... I've put some error-detection code in so we can catch that and see what's in the relevant variables when it occurs. That'll be in the next release.

-Don

zodiac, i think we should use the map viewer and everything else for a good webpge overhaul, that might be useful for advertising the page more and sending other helpful people here

I want to make a complete new PHP design first though. ;o

The ripped maps (from a later version of this program) will be used in the walkthrough and a section designed for event editing (so one can know where is the good coordinates to send a character walking) or even the unit's starting place/facing position.

For anyone that wants to modify battles, it will be EXTREMELY handy.

Yet another release! This version adds a simple terrain height viewer (press t), a new texture fallback mode, and new camera controls. It also includes the error detection I talked about for window resizing. Please let me know what it says when you resize now, Zodiac.

The textures now behave as follows:

• Try to use full textures.
  
• If full textures fail, try to use half-size textures. This takes the 2048x2048 texture image and scales it down to 1024x1024, so really it's a quarter of the memory and should only require about 4MB of video RAM. Half-size textures will look chunkier than the full textures, of course, but I still haven't found a way to get full-size textures working in 8MB. I still think it's possible, but it'll take more work.
  
• If half-size textures fail, try to use limited textures. This is the same limited mode that Zodiac was using when he took that END screenshot. Instead of using 16 copies (one for each palette) of a 256x1024 texture, it uses a single copy and applies a false grayscale palette.
  
• If limited textures fail, continue with untextured polygons.

-Don

I'm glad you are making so much progress on this project Gomtuu. I still haven't been able to devote enough time to getting this working yet, but I'm still really excited about this. Do we know enough about maps to have one of the ones that wasn't used in the game for a battle used for one for one (aka having a battle on the boat)? Oh and were are the textures for the tiles stored?

Cheetah,

If you read the enclosed README file and everything goes well, it shouldn't be too much of a hassle to install. (I hope!) Let me know if you need help, of course.

The textures themselves are easy. Every 131072-byte file in the CD's MAP directory is a 4-bits-per-pixel 256x1024 texture image. The problem is the palettes. Maps contain up to sixteen 16-color palettes, and each polygon tells the game to render it with one of those 16 palettes. So to dump a texture and have it look good, you'd have to make a program that read the palette choices and UV coordinates for each polygon from the mesh files and used them to apply the right palettes to the right areas of the texture image. And hopefully the UV polygons wouldn't overlap... I do understand enough about the data to do this, it'd just be a matter of implementing it and making sure it was foolproof... Another approach is to output the whole texture once for each palette and hand-pick the good areas from each image. This would be easy to code (in fact, it's what map2gl already does internally), but its output would be less convenient.

As far as using non-battle maps for battles, there's nothing I know of yet that would stop us from doing that. Non-battle maps even seem to have terrain info (i.e., the heights of panels, whether you can stand there, etc.) built in.

Just for fun, I tried something really quick: I edited the GNS file for Orbonne Monastery so that it pointed at the texture and mesh files for Port of Warjilis, then started a new game. I've attached a screenshot of the result. I'm kind of surprised it worked at all, but it's not quite there yet... It got stuck a few lines of dialog after this, probably because it couldn't figure out how to make Gafgarion enter. Not bad for only editing 8 bytes, but I don't think this is the ideal way to accomplish what you're talking about. I think it would have more to do with events than maps. I don't know anything at all about events, though.

Zodiac,

Can you shed any light on Cheetah's map replacement question? Have you found an event instruction that means "load map X"? By the way, where are all the event instruction scripts stored? I see your list of event instructions in the Data section of the website, but I don't know where to look for the scripts on the CD. I looked around the website and the forum but couldn't find any mention of it.

That is actually quite the result, especially for a complex event like the opening. I believe that FFTPatcher or one of the other programs has some power around unit placement and event scripts such as having all the characters on the map from the beginning and not walk in, so the problem encountered here might be really easily fixed. So the map looks a little garbled, is that just the angle?

Events have no influence of map loaded, neither music. Although there are instructions to stop playing a music and switch to the next one (no control of which it will be either).

Here's a preview of what I've been working on lately. For the past few days, I've been trying to learn more about some parts of the map file format that I didn't/don't know much about. The result is:

• Much better terrain mode. I now understand where the information about the appearance of the terrain cursor (the blue or red square that hovers just over the selected terrain tile) is stored, and can overlay this information on top of the map.
  
• Better support for cutaway mode. The game stores information about whether or not each polygon is visible from different azimuth angle ranges. For example, it can make the south wall of a building disappear when the map is viewed from the south so you can see inside. I was supporting this behavior, but only with textured polygons. I've now implemented support for cutting away the untextured black "skirt" polygons, so you can see inside maps 11 and 33 now. Many of the other interior maps also benefit from this.

I also found some interesting information in the Orbonne Monastery map file that controls how the door texture animates when Gafgarion opens the door to exit the building. What I don't know is how the game knows that the data I've found is an instruction to animate a texture. There's nothing that looks like an instruction; it's basically just a few texture coordinates and a duration, so there must be something (in an event script?) that tells the game how to use that data. Something like "Now animate textures using animation data chunk #5." Zodiac, do you know where the event script is for the beginning of the Orbonne Monastery battle? I'd like to look over that.

I've attached some screenshots of the improved terrain mode and skirt cutaway support.

-Don

There is one and I named that instruction use field object.

IIRC that door's ID is 0x02.

[F2] Start(xF2, xF2, xF2);
[19] Camera(-320, -1744, 1168, -114, 528, -32, 992, 1);
[6B] PlayBgSound(x01, 0, 24,x00,xFF);
[3C] Unknown(x02,x01);
[11] UnitAnim(x34,x00,x0002,x00);
[11] UnitAnim(x86,x00,x0002,x00);
[3B] UnitSprAnim(x34,x00, 0, 0, 13,x01,x01, -114);
[11] UnitAnim(x00,x00,x0002,x00);
[2E] BgColor(48, 56, 48, 48, 56, 96, 0,x00);
[33] FieldColor(x04,xFD,xFF,x03,x00);
[F1] Wait(2);
[66]
[4D] Unknown(x60);
[1D]
[19] Camera(608, -768, 1168, -178, 656, -32, 3072, 286);
[19] Camera(608, -672, 1136, 142, 1344, -32, 3296, 128);
[19] Camera(1024, -400, 720, 334, 2432, 0, 3808, 80);
[19] Camera(960, -288, 800, 382, 3008, 0, 4064, 88);
[19] Camera(927, -128, 816, 413, 3582, 0, 4096, 100);
[1E]
[F1] Wait(20);
[F1] Wait(200);
[1A]
[04]
[1E]
[1E]
[1E]
[04]
[E5] WaitForInstr(x06,x00);
[2E] BgColor(184, 188, 119, 16, 29, 61, 1,x01);
[33] FieldColor(x04,xF8,x00,x04,x01);
[F1] Wait(10);
[2E] BgColor(48, 56, 48, 48, 56, 96, 4,x00);
[33] FieldColor(x08,x00,x00,x00,x04);
[F1] Wait(45);
[6B] PlayBgSound(x12, 127, 127,x01,xC8);
[F1] Wait(170);
[2E] BgColor(113, 124, 106, 16, 16, 24, 1,x01);
[33] FieldColor(x00,xFF,x00,x02,x01);
[F1] Wait(10);
[2E] BgColor(48, 56, 48, 48, 56, 96, 4,x00);
[33] FieldColor(x08,x00,x00,x00,x04);
[F1] Wait(30);
[6B] PlayBgSound(x12, 127, 127,x01,xC8);
[E5] WaitForInstr(x04,x00);
[19] Camera(927, -128, 816, 413, 3582, 0, 4096, 2);
[63] Unknown(x89);
[49] Unknown();
[45] Shadow?(x83,x00,x01);
[4A] Unknown();
[10] DisplayMessage(x10,x11,x01,x00,x34,x00,x00, 0, 0, 0,x01);
[E5] WaitForInstr(x01,x00);
[19] Camera(728, -188, 504, 366, 3584, 0, 4096, 64);
[F1] Wait(50);
[10] DisplayMessage(x10,x12,x02,x00,x86,x00,x00, 1, 0, 0,x01);
[E5] WaitForInstr(x01,x00);
[19] Camera(728, -412, 504, 302, 3584, 0, 4096, 64);
[F1] Wait(30);
[21] PlaySound(x004C);
[55] UseFieldObj(x02,x00);
[57] Unknown();
[5F] MoveUnit(x17,x00, 6, 8,x00,x00);
[3B] UnitSprAnim(x17,x00, 0, 0, 13,x00,x01, 302);
[32] UnitColor(x17,x00,x01, 0, 0, 0, 0);
[F1] Wait(2);
[44] Materialize(x17,x00);
[32] UnitColor(x17,x00,x08, 0, 0, 0, 1);
[3B] UnitSprAnim(x17,x00, 0, 0, 0,x00,x01, 302);
[6F] Unknown(x17,x00);
[28] OrderMovement(x17,x00, 6, 6,x00,x00, 8,x01);
[29] StopWalking(x17,x00);
[11] UnitAnim(x17,x00,x0002,x00);
[4B] Unknown();
[5F] MoveUnit(x83,x00, 6, 8,x00,x00);
[3B] UnitSprAnim(x83,x00, 0, 0, 13,x00,x01, 302);
[32] UnitColor(x83,x00,x01, 0, 0, 0, 0);
[F1] Wait(2);
[44] Materialize(x83,x00);
[11] UnitAnim(x83,x00,x0003,x00);
[32] UnitColor(x83,x00,x08, 0, 0, 0, 1);
[3B] UnitSprAnim(x83,x00, 0, 0, 0,x00,x01, 302);
[6F] Unknown(x83,x00);
[28] OrderMovement(x83,x00, 5, 8,x00,x00, 8,x01);
[29] StopWalking(x83,x00);
[11] UnitAnim(x83,x00,x0002,x00);
[2D] Face(x83,x00,x00,x00,x00,x00);
[5F] MoveUnit(x02,x00, 6, 8,x00,x00);
[32] UnitColor(x02,x00,x01, 0, 0, 0, 0);
[F1] Wait(2);
[3B] UnitSprAnim(x02,x00, 0, 0, 13,x00,x01, 302);
[6F] Unknown(x02,x00);
[44] Materialize(x02,x00);
[11] UnitAnim(x02,x00,x0003,x00);
[32] UnitColor(x02,x00,x08, 0, 0, 0, 1);
[3B] UnitSprAnim(x02,x00, 0, 0, 0,x00,x01, 302);
[6F] Unknown(x02,x00);
[11] UnitAnim(x02,x00,x0002,x00);
[F1] Wait(12);
[21] PlaySound(x004C);
[55] UseFieldObj(x01,x00);
[57] Unknown();
[10] DisplayMessage(x10,x11,x03,x00,x17,x00,x00, 0, 0, 8,x01);
[E5] WaitForInstr(x01,x00);
[F1] Wait(30);
[11] UnitAnim(x34,x00,x0003,x00);
[F1] Wait(12);
[3B] UnitSprAnim(x34,x00, 0, 0, 0,x00,x01, 302);
[F1] Wait(12);
[11] UnitAnim(x34,x00,x0002,x00);
[F1] Wait(12);
[10] DisplayMessage(x10,x11,x04,x00,x34,x00,x00, 0, 0, 4,x00);
[E5] WaitForInstr(x01,x00);
[F1] Wait(8);
[10] DisplayMessage(x10,x11,x05,x00,x17,x00,x00, 0, 0, 8,x01);
[E5] WaitForInstr(x01,x00);
[F1] Wait(25);
[60] Unknown(x00,x3C);
[F1] Wait(25);
[11] UnitAnim(x83,x00,x0003,x00);
[F1] Wait(10);
[11] UnitAnim(x02,x00,x0003,x00);
[F1] Wait(30);
[11] UnitAnim(x86,x00,x0003,x00);
[F1] Wait(10);
[11] UnitAnim(x17,x00,x0003,x00);
[F1] Wait(10);
[11] UnitAnim(x34,x00,x0003,x00);
[F1] Wait(10);
[11] UnitAnim(x00,x00,x0003,x00);
[F1] Wait(10);
[22] NextSong(x01,x60,x00);
[1C] Unknown(x02);
[76] DarkScreen(x00,x01,x0C, 64,x00, 4);
[E5] WaitForInstr(x36,x00);
[78] DisplayCond(x08, 60);
[E5] WaitForInstr(x38,x00);
[78] DisplayCond(x00, 60);
[E5] WaitForInstr(x38,x00);
[77] RmvDarkScreen();
[E5] WaitForInstr(x36,x00);
[1C] Unknown(x01);
[DB] TextStart?();

Very interesting! This fits well with what I found in the map file for Orbonne. Here's a hex dump from MAP056.48:

0008028: 5500 e001 1000 0100 0000 0000 0000 0403 000f 0000
000803c: 0203 b200 0500 2800 0c03 b200 0000 0501 0001 0000
0008050: 0203 b200 0500 2800 0703 b200 0000 0601 0001 0000
0008064: 1603 5800 0500 2800 2503 5800 0000 0701 0001 0000
0008078: 1603 5800 0500 2800 2003 5800 0000 0801 0001 0000
Line 2 (counting from zero) reads something like this:

Words 0-1: Destination texture coordinates (words*, lines)
Words 2-3: Width and height of area to copy to these coordinates (words, lines)
Words 4-5: Source texture coordinates (words*, lines)
Word 6: ?
Word 7: Low byte: ?
Word 7: High byte: Number of frames in the animation
Word 8: Low byte: ?
Word 8: High byte: Delay (in screen frames?) between frames of animation
Word 9: ?

* I don't understand what the 03 in the high byte is for yet.

By experimenting, I've found that line 2 (counting from zero) plays when the door opens, and line 1 (counting from zero) plays when the door closes, which matches your UseFieldObj call parameters. I'm betting the script that plays when Delita steals Ovelia references the last two lines to open and close the back door. I haven't tested that, but the texture coordinates match an area of the texture that looks like the back door.

The first line (line 0) seems to be related to palette animation for the water texture, but I haven't figured it out yet.

You can tell if a map file has a block like this by looking up the pointer at location 0x006c in the map file's header. Then seek to that address in the file.

Here's another release. Along with the features I mentioned above, here are the changes:

• Added magenta background mode for chroma keying.
• Made default window size 800x600.
• Instead of the half-texture and limited-texture fallbacks, map2gl will now use a fallback mode that splits the 16 different palette-renderings of the texture up and stores them in separate texture objects instead of putting them all into one big texture object.

This new separate-texture fallback mode should decrease the video RAM requirement without decreasing the quality of the image. The tradeoff is that, while map2gl is in this fallback mode, it will run more slowly than it otherwise would because some overhead is required to switch to the right texture before drawing each polygon. In this mode, map2gl runs at about half or a third of the normal speed on my computer, but it's still quite fast. With limted video RAM, there may be even more of a speed impact because the textures will have to be copied into video RAM frequently. But it'll look good!

Try it out, Zodiac. If it's really, really slow, some optimization is still possible, so let me know.

-Don

Quote from: "Cheetah"So the map looks a little garbled, is that just the angle?

I'm don't know why that is. The maps store information about when to make certain polygons disappear (see explanation of cutaway mode (http://auritech.byethost13.com/viewtopic.php?p=2392#2392)), so I'm guessing that the wrong cutaway info is getting loaded. But I'm not sure why that would be...

-Don

Unable to use monolithic texture. Trying separate textures instead.
Whoever looks like the routine ended up with a break instead.

Besides what Cheetah mentioned, it's working awfully good.

Good job man.

And IMHO don't try too hard to make it work with my 8mb video card kay? I can just use another computer.

Quote from: "Zodiac"

Code Select Expand

Unable to use monolithic texture. Trying separate textures instead.
Whoever looks like the routine ended up with a break instead.

Besides what Cheetah mentioned, it's working awfully good.

Good job man.

I'm confused. You said "the routine ended up with a break", which sounds like it didn't work, but then you said it worked well. And Cheetah was talking about something else (the screenshot I took using a hacked ISO in an emulator). Are you saying you're seeing "garbled" maps like that, but with map2gl?

QuoteAnd IMHO don't try too hard to make it work with my 8mb video card kay? I can just use another computer.

If it works now, then... too late!

Coming soon...

Looks nice! Is that just a palette swap?

It did on my mother's comp but not on this one.

With a 128mb card I didn't notice much slowdown. I tested and I got up to 3 full turn around per second with your rotating function.

By the way I still have no way of resizing at all.still just closes openGL for me.

Quote from: "Zodiac"Looks nice! Is that just a palette swap?

It isn't just a hack, if that's what you mean. :(

Quote from: "Zodiac"With a 128mb card I didn't notice much slowdown. I tested and I got up to 3 full turn around per second with your rotating function.

With the 128MB card, you don't see the "Unable to use monolithic texture. Trying separate textures instead." warning, do you? If you don't see that warning, then it's running in monolithic texture mode (the default), which is the faster of the two modes.

Quote from: "Zodiac"By the way I still have no way of resizing at all.still just closes openGL for me.

A few versions ago, I added some code that should print a more helpful error message than the default one. Can you tell me what it says now when you try to resize?

Actually I was asking if the game only loaded another palette instead. But you answered it anyway.

Resizing manually and clicking enlarge doesn't provide me any errors.

Only minimize does:
Tried to divide by zero.
Aspect: 0.000000, W: 0.000000, H: 1.000000
Obviously those happen no matter how I try to resize/minimize the window.

This is really cool stuff about the weather conditions. It is pretty crazy that they have all these weather conditions for maps, and then didn't use many of them. Are there any settings for snowy weather, or is snow only on the specific levels that have snow normally?

No, snow doesn't seem to be a weather condition in this sense. To make a map snowy, you'd need to edit the texture palettes at the very least, but to get it to look good, you'd probably need to edit the textures as well.

Hmm... Now that you mention it, I can't remember: Do the snowy maps ever actually have snow falling (like the raindrops on rainy maps), or is it just that the ground looks snowy?

Anyway, besides the weather conditions, for the next version I'm working on swtiching from GLUT to wxPython as the window environment. The benefit is that I'll be able to add a menu bar with File > Open and such, hopefully eliminating the need to run map2gl from the command line. I'll also be able to add GUI stuff for easier controls and a more informative display. wxPython is supposed to be cross-platform, too, so it shouldn't pin it to a specific OS. I think it's fairly likely that it'll also fix Zodiac's resizing problem.

I've already made some good progress on this, but I need to re-implement the keyboard and mouse controls at least before I release it.

Another release. This version might be a little shaky; I'm still getting the hang of wxPython. But I've already added some nifty features thanks to wxPython like a file chooser, an information window that shows (and lets you double-click to load) the different weather conditions the map has (just listed by the numeric indexes as found in the GNS files for now), and a camera window that shows the camera altitude and azimuth angles.

You should no longer need to run map2gl from the command line, provided Python associated itself with .py files when you installed it. You still can, though. Same as before, except you don't specify the map path and map number anymore. Just "python map2gl.py".

You'll need to install wxPython (http://www.wxpython.org/download.php#binaries) to use it. The Python 2.5 Unicode version is probably what you want.

Let me know if you have any trouble with it. Zodiac, I think there's a good chance this will fix your window resizing problem, since the code that reports the window size works completely differently.

Nice! DD works properly now (because of weather conditions) and Entrance to Murond works as well. =D

Well the first weather does. :/

This is worth every bit I download even if I have dial-up.

Ah, I hadn't even noticed that about the Deep Dungeon maps. Cool! While testing them, I always switched to full ambient lighting mode, so I didn't see any difference.

Yep, map 53 works partially in 0.15, and even better in my current development version because I've improved the way map2gl figures out what to load and from which files. I also recently discovered a block of data in some map files that has to do with positioning and rotating animated polygons like the windmill's blades and gears, so that's what I'll be working on for the next release.

-Don

Sounds promising

Oh yeah, I forgot to ask, is there any way to have the correct zoom display? so that I can see every pixel at 90˚ alt and not blurry.

Oh, you mean so the texture pixels are 1:1 with screen pixels when viewed straight-on? Yeah, that's probably not to difficult, actually. I'll see what I can do.

Yeah... I have trouble finding the right words lately. <_<'

I've got animated polygons implemented, at least for most of the simple animations. Finally! There are apparently some more complex polygon animations that I haven't really scratched the surface of yet, but here's a peek.

By the way, from looking at the source for fftpspext.c on Google Code it looks like the GNS files haven't been identified in fftpack.bin yet. I think I found them. I'm attaching a file that lists the first line of each GNS file I found. I don't know which file is which or how long each one is yet, though.

The format is a little different from the PSX version, which isn't surprising since the PSX GNS files point at the resource files by their LBA addresses on the CD, and that probably doesn't translate well to the PSP. Also, there are 123 of them whereas the PSX CD has 121.

I'd like to see if I can make map2gl read the PSP maps eventually. It'd be interesting to compare them, and I'd like to know what those 2 extra maps are.

-Don

Those are amazing screen shots Gomtuu. Having it zoom to show the correct resolution was definitely a must. I am definitely curious about those two new maps as well.

Those extra maps probably are related to Balthier or other "extra" sidequest on the PSP version.

NeXaR: That's what I'm thinking, but I don't really remember any new maps from what I've played of the PSP version. It's been a while, though.

Here's the latest version. It includes a better data-finding algorithm (so map053 works better), basic support for animated meshes, and a new "in-game zoom" mode, which closely approximates the zoom level I measured in epsxe. It's not actually a 1:1 texel-to-screen-pixel ratio (it's 5:7, to be exact), but it's what the game uses, which I figure is more meaningful.

this map thing looks great... setting it up doesnt seem to work for me tho...

Zozma,

Where are you running into trouble? Maybe I can help.

BTW, if anyone's curious, development of map2gl hasn't stopped, but it's been slow lately. A friend got me back into World of Warcraft, and then SSB Brawl came out, so I've been preoccupied. But I have done a little work on it, including reorganizing the code somewhat and improving the user interface.

To be honest, there's not much information left to decypher in the map files themselves. Most of the stuff that's left has to do with animated textures and animated polygons, and I already sort of understand these sections, it's just a matter of implementing them. Not that that will be really easy...

Some things I would like to find that don't seem to be in the map files are:

• Trap/move-find-item locations
• Squares you can place units on when entering a battle
• Scenario list (i.e., how does the game know that the first thing it should do is load map062 (Chapel of Orbonne Monastery) and play a certain event script, and then the next thing it should do is load the rainy version of map056 (Orbonne Monastery) and play another event script, etc. Or, how does it know that when you visit the Mandalia Plains dot on the map, it should load map085 and do a random battle?

I've been trying to figure these things out, but haven't had any luck so far. If anybody has any clues about where to find them, I'd love to know. Based on George Greer's file list (http://m-l.org/~greerga/fft/#Information-Files), there aren't a lot of places left to look. I hope they're not hard-coded in a way that's difficult to figure out and/or change.

Move find items are in BATTLE.BIN
Offset: 0x8EE74

And I'd bet the rest you mentioned is there too.

Told melonhead about it so he should put it in his next update.

Don't worry gomtuu, I'm playing way too much Valkyrie Profile myself.

Quote from: "Zodiac"Move find items are in BATTLE.BIN
Offset: 0x8EE74

Aha, so they are... Thanks! I'll have to work this into my next version somehow.

008f3c4: 0010 01f0 4410 13f1 4c10 33f6 8610 3bf7  ....D...L.3...;.
         ABCC DDEE ABCC DDEE ABCC DDEE ABCC DDEE
Looks like A and B are coordinates and D and E are the common and rare item... Is C the type of trap?

Quote from: "Zodiac"And I'd bet the rest you mentioned is there too.

I'll definitely check it out.

Quote from: "Zodiac"Don't worry gomtuu, I'm playing way too much Valkyrie Profile myself.

If only we didn't like games so much, we'd have more time to hack this game.

-Don

Yep you guessed right.

0x01 Degenerator
0x01 Death Trap
0x01 Sleeping Gas
0x01 Steel Needle

melon told me there were extra in the PSP version (multiplayer). Considering one of them can invoke a random summon, that's pretty broken.

I've been working on trying to find the scenario data lately. I just made some progress tonight; there's a list of scenarios in attack.out at 0x10938. Entries are 24 bytes wide. While experimenting with the data, something funny happened that I thought I'd share. See pic. I'm still working on figuring out the data. I'll post here when I know more.

Maybe the first battle was meant to be a tutorial? Pretty interesting though, I wonder what else is there.

Hahaha! I don't know why that is so hilarious to me! But taking the completely serious storyline and seeing Gafgarion say that, just makes me guffaw with laughter! But this sounds great that you are making progess on the scenarios. Anything else of interest that you've found, so far?

Here's what I was able to decipher tonight:

Each scenario has at least two lines. Most of the data in lines other than the first is duplicate/ignored, as far as I can tell. I have no idea why the number of lines varies.

The first scenario is Ovelia's prayer in the chapel of Orbonne:

First line:
0x10938: 0100 3E00 0033 3400 0100 0000 0000 0000 0100 0000 0000 0000
         AAAA BBCC DDEE FFGG GGHH HHII II          ZZ xxxx xxxx JJJJ

Last line:
0x10950: 0200 3E00 0033 3400 0100 0000 0000 0000 0100 0300 8100 0000
              xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx KKKK LL   xxxx


x = duplicate, ignored data
A = Scenario number: 1
    (Just an index for this list, apparently.
    Also, whichever event is numbered "1" always plays first.)
B = Map number: 0x3e
    (MAP/MAP062.GNS)
C = Weather: 0
    (Doesn't influence whether the rain animations are used)
D = Day/Night: 0
    0 = Day
    1 = Night
E = First Music file: 0x33
    (SOUND/MUSIC_51.SMD)
F = Second Music file: 0x34
    (SOUND/MUSIC_52.SMD)
G = ENTD entry: 0x0100
    (Looks like this matches the "Game Events" list.)
H = Character placement grid, 1st Squad
    (Placement grids are found in ATTACK.OUT at 0xbbd4)
    (For first scenario, using this makes the placement screen garbled.)
I = Character placement grid, 2nd Squad
J = Event script: 0
    (Scenario 1 seems to be a special case because Event Script 0
    plays just fine. Using Event Script 0 on scenario 3 causes wrong
    text to display.)
    (Also seems to control which scenario block the "next scenario"
    byte is read from)
K = Next scenario: 3
    (As indexed by A)
L = 0x80 = World map follows this scenario
    0x81 = Another event follows this scenario (K)
    0x82 = Game reset follows this scenario (side effect, or intneded?)
Z = Not sure yet, but setting it to 1 makes Ramza mandatory on
    character placement screen
That funny text in my previous post was caused by event script 0 behaving strangely in scenarios other than scenario 1, I think. Event script 0 works when used with scenario 1 (which is the way it normally is), but changing scenario 2 to use event script 0 makes the game read text from the select-button help text for statuses, for some reason. Other event script substitutions I've tried seem to work, so this is a special case for some reason.

I spent a lot of time digging through ASM traces for this data, so it's nice to finally know where it is! It should make things interesting...

We'll have to find out where the data's stored that controls the character placement screen before battles, because that screen is garbled when you turn it on for a scenario that didn't use it before.

-Don

Hmm, at first I thought that "0x34" might have been what ye olde Debug Lists used. But it seems that is far off, as that is labeled as monsters. In any case this is quite a large step! Well done!

WAIT!

QuoteH = 0x80 = World map follows this scenario
    0x81 = Another event follows this scenario (G)
    0x82 = Game reset follows this scenario (side effect, or intneded?)

does this mean that we can already make a chain of battles?!

anyway, stunning work!

edited: by the way, shouldn't be a code like 0x79 or 0x83 (saying random numbers actualy) that pops out the save screen inbetween battles?

gomtuu, this absolutely ROCKS. I'll have to talk with you a little about asm because I'm not sure what are the instructions it uses to read words/bytes.

I'm a bit deceived, I though the map's starting music would be there.

I love how far we have progressed though.  

haha what door did they come from!?

Quote from: "Zodiac"I'm a bit deceived, I though the map's starting music would be there.

I should've been wearing my headphones when I was playing with those numbers! It does look like the "33" byte up there is the music track... I have a trace that says music_51.smd and music_52.smd get loaded when this scenario starts, and 0x33 == 51. I'll test this out in-game when I get a chance.

Quote from: "karsten"does this mean that we can already make a chain of battles?!

It does! But we really need to figure out the character placement screen before this will be as flexible as we'd want it to be.

Quoteby the way, shouldn't be a code like 0x79 or 0x83 (saying random numbers actualy) that pops out the save screen inbetween battles?

Good point. I'll have to look for that.

Happy hacking, everybody. I'll see what else I can find out about this chunk of data...

Quote from: "trickstardude7"haha what door did they come from!?

No door, they just appear out of thin air.

Does the weather you mentioned affect elementals? because Zeakden & Zigolis' weather had no effect on elemental attack. I'm not sure if there are others.

I made next scenerio 0x0117 for fun and it ended up at the gates of riovanes castle, I had the regular character placement and instead of Rafa I had Ovelia. I was against the usual enemies though. Then, Instructions from the first event followed (I was like wtf, I just passed that event). Ramza starting opening dialog boxes with you're soaked in water so you can't move. A knight came out of nowhere acting as rad and all.

At some time, the dialog box wouldn't close so I just close the emulator.

Just for the record, when I was editting Zirekile Falls I accidentally looped the event to go back to the beginning. The second and third times around, instead of saying what they were supposed to, people said stuff like what Gafgarion said.

Quote from: "Zodiac"Does the weather you mentioned affect elementals? because Zeakden & Zigolis' weather had no effect on elemental attack. I'm not sure if there are others.

Good question! I don't know yet... My guess is that it doesn't, since it doesn't control whether the raindrop animations are used. But maybe.

Quote from: "Zodiac"I made next scenerio 0x0117 for fun and it ended up at the gates of riovanes castle, I had the regular character placement and instead of Rafa I had Ovelia. I was against the usual enemies though. Then, Instructions from the first event followed (I was like wtf, I just passed that event). Ramza starting opening dialog boxes with you're soaked in water so you can't move. A knight came out of nowhere acting as rad and all.

Only the first line of each scenario block has a non-zero event script (from what I've noticed so far), and scenario entry 0x0117 is the fourth line in that scenario block. This made the game load event script 0 with that map, which is the same thing that was happening to me in that "soaked in water" screenshot. Try 0x0114 instead; that should work better. (Or change the event script for 0x0117 from 0x00 to 0x57.)

As for the characters in your party, this is another sticking point. My best guess right now is that event scripts can add characters (including guests) to your party, either silently or with a Join Up option. Do you see any evidence that the initial random generics get added to your party in the first few event scripts? Where are these scripts, by the way? Are they in TEST.EVT?

-Don

Quote from: "Zodiac"I'm a bit deceived, I though the map's starting music would be there.

I've confirmed by editing the ISO that the 0x33 byte (now labeled D) is indeed the music file the map uses! I updated the spec above.

Updated the spec again, above. I discovered the function of a few more bytes, and I had some things wrong before, like the ENTD info.

Ohh, so that's why... Yeah all the events are stored in TEST.EVT and it will be much easier now to know which Event Script is loaded for each Event.

You can see yourself in FFTPatcher. The event with cadets hold all cadets that join you with their equipment and all. There MAY be something else about them that grants them higher brave/faith, I'd have to check.

Units that join as a guest or as a permanent unit is not influenced by the event.
You can make a unit join permanently, ask to join, or make a human come as a guest using FFTPatcher.

As for the weather, it snows at Zeakden but Ice isn't stronger. It snows in the battles to go save Reis and Ice IS stronger. So those two aren't linked. It may be possible that which map's texture is loaded had a direct influence on Elemental damage.

Vincent, about that one, events will always loop indefenitely if the games read an unset instruction. Just 0x00 after an instruction and your event is screwed.

Quote from: "Zodiac"Ohh, so that's why... Yeah all the events are stored in TEST.EVT and it will be much easier now to know which Event Script is loaded for each Event.

Cool. Is there anything that displays or edits these right now? I don't see it in FFTPatcher (0.205)... The closest thing I see is the ENTD info.

Quote from: "Zodiac"You can see yourself in FFTPatcher. The event with cadets hold all cadets that join you with their equipment and all. There MAY be something else about them that grants them higher brave/faith, I'd have to check.

Ha, that's neat! I never realized that the cadets in the military academy scene become your initial party... Funny!

I'd imagine there's an event instruction to raise Brave, since your Brave gets raised based on how you answer questions in the events (Event Script 5, I think, for example).

Quote from: "Zodiac"You can make a unit join permanently, ask to join, or make a human come as a guest using FFTPatcher.

I see "Join After Event," but I looked at ENTD entries 0x0188 (Military Academy) and 0x0110 (the cinematic at Orbonne where Rad, Alicia, and Lavian ask to join) in FFTPatcher, but I don't see what makes a character join silently vs asking to join. Where's that?

Quote from: "Zodiac"As for the weather, it snows at Zeakden but Ice isn't stronger. It snows in the battles to go save Reis and Ice IS stronger. So those two aren't linked. It may be possible that which map's texture is loaded had a direct influence on Elemental damage.

My point was just that the weather chosen from the GNS isn't the only thing that affects weather-related stuff, but yeah, it's still possible. Although, the weather byte during the Zeakden battle is 2, but during the Colliery levels, it's 2, then 3, then 4... Hmm...

Given what we call the "sprite" which also assigns the main job of the unit:

0x00-0x7F (special units)
None: -
Join: Ask to join permanently
Save: -
Both: Join as Guest

0x80-0xFF (generics and monsters)
None: -
Join: Ask to join permanently
Save: -
Both: Join Silently

That's the simple reason

Ah, I see... That's kind of a weird way to do it. Oh, well.

Hey, guess what I found? The data that controls the character placement screen. It's in ATTACK.OUT at offset 0xbbd4. There are 768 12-byte entries, though not all of them are used.

4218 2300 0401 0003 0401 0100
AAAA AAAA BBCC xxDE FFGG HHHH

A = 5x5 bitmap
    (ffffff01 is solid)
    (a9d62a01 is an S)
B = X coordinate of center of 5x5 square relative to map's (0,0) square
    (signed)
C = Z coordinate of center of 5x5 square relative to map's (0,0) square
    (signed)
x = Padding
    (Always 0x00)
D = Orientation
    (0x00 = W)
    (0x01 = S)
    (0x02 = E)
    (0x03 = N)
E = Orientation, with bitmap rotated
    (Same as D, but also rotates the 5x5 bitmap)
F = Number of characters allowed in squad
    (1 - 5 are valid. Making this 6 and adding a 6th character crashes ePSXe.)
G = Map number
    (Just for reference?)
H = Placement ID number
I also realized that the scenario data optionally includes two character placement grid numbers, for when there's a 1st squad and a 2nd squad, so I updated the scenario data spec (http://auritech.byethost13.com/viewtopic.php?p=3202#3202).

Here's a placement bitmap I made while I was testing it out:

oo nice you guys are getting far with the maps, good job!

Vincent will be able to limit Zirekile to 3 Characters so all will be well. :O

Man, this will help a lot in many situations.
Don't you know how to add a second squad?

I do know that some Event doesn't play and it strangely has 4 units for 1st Squad, and 2 units for 2nd squad. The battle never plays and the event just ends there. It's the one right before the last one; battle at Igros. I'm not sure if the squads' size are the reason for this.

Quote from: "Zodiac"Don't you know how to add a second squad?

Yes, it's in the scenario data (http://auritech.byethost13.com/viewtopic.php?p=3202#3202).

Quote from: "Zodiac"I do know that some Event doesn't play and it strangely has 4 units for 1st Squad, and 2 units for 2nd squad. The battle never plays and the event just ends there. It's the one right before the last one; battle at Igros. I'm not sure if the squads' size are the reason for this.

Do you mean it's like that in the real game, or is this something you tried? I guess if the real game had a bug like that, we should be able to fix it now!

O ma gawd. I'm fixing Zirekile Falls right now.

O wait, I have to find which on is Zirekile Falls first...

I spent most of today working on TEST.EVT, trying to figure out the structure and the event scripts. Other than this site's data page about scripts (http://auritech.eu/EI.htm), and Zodiac's earlier post (http://auritech.byethost13.com/viewtopic.php?p=2399#2399) with the script for the Orbonne battle, does anybody know anything that could be useful?

What I'm working on is filtering the good text from the duplicate text. A lot of the text is in there many times. I figured out a little about the overall structure of the file, but there are big blocks whose purpose I don't know. Within the blocks that seem to be important, though, I understand the structure pretty well. And I've been working on parsing the scripts using Zodiac's data (mostly) and a little extrapolation of my own. The reason I'm parsing the scripts is so I can use the "DisplayMessage" instructions to know exactly which text strings to read...

At this point, I have a program that looks through all of TEST.EVT and can print out the scripts similar to how Zodiac did it in his post. The thing is, without accurate information about the width of every instruction, things can get misaligned and give you false positives and false negatives. But, even so, the output is fairly decent right now.

Does this sound interesting to anyone, or is TEST.EVT pretty well understood at this point?

-Don

Did you get my decompiler or did you code it yourself?

Quote from: "Zodiac"Did you get my decompiler or did you code it yourself?

Hehehe. I didn't know you had a decompiler, so I coded it myself... Where can I get yours?

Gee, it'd be nice if we had some kind of website where we could organize the facts we've discovered to make them easy for others to find...

-Don

Quote from: "gomtuu"

Quote from: "Zodiac"Did you get my decompiler or did you code it yourself?

Hehehe. I didn't know you had a decompiler, so I coded it myself... Where can I get yours?

Gee, it'd be nice if we had some kind of website where we could organize the facts we've discovered to make them easy for others to find... :P

-Don

I've told Zodiac to put his source out on the web like I do for LionEditor and FFTPatcher, but he won't listen :P

I tried to mess with TEST.EVT a few months ago but didn't get very far. Looking at my notes, each event in the file is either 0x1800 or 0x800 bytes long, and they alternate between the two. Except in four cases where the blocks are 0x2000 bytes long.

Some of the blocks start with 0xF2F2F2. I think these are dummy events. Others start with a 2 byte integer. This is a pointer to the address in the section where the text starts. The event instructions themselves tell the game which line of dialogue to use in the event.

For example, at offset 0x4000 is the integer 0x8F9. Jumping forward to 0x48F9 shows the dialogue for the "God help us sinful children of Ivalice" event. The text for the event seems to end at 0x4D76. The rest of the data in this block is garbage from another part of the game.

Thinking about it again, it might be that all blocks are of equal length (0x2000 bytes).

Hi, melonhead. I like your work on FFTPatcher, by the way. Have you seen the developments in this thread with scenarios and placement grids? It'd be nice if that could make it into FFTPatcher some day. I don't have a lot of interest in writing an editor with a GUI and everything, but you seem to do that pretty well.

Quote from: "melonhead"I've told Zodiac to put his source out on the web like I do for LionEditor and FFTPatcher, but he won't listen :)

Quote from: "melonhead"Thinking about it again, it might be that all blocks are of equal length (0x2000 bytes).

Yeah, I think the game always loads 4 sectors (0x2000 bytes) of TEST.EVT into RAM, but it looked like sometimes (always?) there's a good chunk with the text you want and at least one F2F2F2F2 chunk loaded along with it.

I noticed some of the data in TEST.EVT is probably Japanese. Is this just stuff that didn't happen to get overwritten during localization?

-Don

probably it's the famous sound novels that got canned....


by the way i noticed that we could add back all the character's quotes that were taken away! also with yours super-human skills, one day we might even able to restore the sound novels, or to re-open the hidden debug mode...

it's so sad that i couldn't get my hands on that review/debug copy of FFT it was outside even my most exaggerate expenses

There was no way I'd decompile manually an entire event script :/, plus I talked aabout my decompiler a few times...

Sheez, I got owned... I always checked the events in a savestate which the 4 first bytes are overwritten with 0xF2F2F2F2. I thought that's what normal for an event.

I'm not sure what that Japanese text is for at all.

karsten, that's not really likely as the sound novels doesn't happen on a map or loads any character or anything. And that guy was a fucking jerk. $600 for just a burnt debug FFT disc, go to fucking hell.

We're the only FFT hacking community and that price is way off. Not possible he'd sell it for 600 bucks in his entire life.

Quote from: "karsten"probably it's the famous sound novels that got canned....

The sound novels are in SNPLMES.BIN.

Quote from: "Zodiac"Sheez, I got owned... I always checked the events in a savestate which the 4 first bytes are overwritten with 0xF2F2F2F2. I thought that's what normal for an event.

So maybe the sections that start with 0xF2F2F2 are the real ones and the rest are dummies.

Quote from: "melonhead"So maybe the sections that start with 0xF2F2F2 are the real ones and the rest are dummies.

I doubt it. I know what he's talking about; in RAM, the data does have F2F2F2F2 before it, but it's not that way in TEST.EVT.

Might I see your program? I just want to compare.

Here's mine: http://auritech.byethost13.com/decompiler.rar

Just put TEST.EVT in the same folder.

Yeah, I'm curious to take a look at yours, too. Here's mine. It takes the path to TEST.EVT as a command-line parameter and outputs to stdout. It requires Python, but no funny libraries.

Edit: This version is set up to just print the text used by DisplayMessage() calls, but if you want the event instructions too, just uncomment the "print disasm" line.

I wasn't able to output so whole thing in a file so it took 5mins for my cmd window to reach the end after printing all the instructions and text.

I'd still have to include text so my decompiler can match yours. Now it's just doing crap by taking every block of 0x2000 then decompiling it and stopping at 0xDB.

Quote from: "Zodiac"I wasn't able to output so whole thing in a file so it took 5mins for my cmd window to reach the end after printing all the instructions and text.

Sorry, sometimes I forget that not everyone is familiar with the command line. You can pipe the output to a file by adding "> decoded.txt" (or whatever filename you want) after the command. So, if you ran it like this:

C:\Documents and Settings\Zodiac\Desktop\temp>python dectestevt.py D:\EVENT\TEST.EVT
Do this instead:

C:\Documents and Settings\Zodiac\Desktop\temp>python dectestevt.py D:\EVENT\TEST.EVT > decoded.txt
That'll create a file instead of outputting everything to the console.

This probably isn't a big surprise, but I've been working on incorporating the trap data and character placement grid data into map2gl. Here's a preview. Magenta squares are traps/items. Green squares are starting locations, and of course the triangles point the way the character initially faces. I still have to test it more, but it's working fairly well.

great, really! your work is astonishing

hmm this map thing looks great but have no idea what im doing when it comes to python...

you know what i love about this site? everyone sees it and everyone can contribute something different... i myself can do sprites... this map thing i dont get at all tho id love to... i just cant get it.. but perhaps if i make certain event battles someone could make some edits for me limiting the amount of characters you can put in? heh.....

Zozma, I've sent you a PM since you didn't seem to notice when I offered to help before.

And if there's anybody else who wants to use map2gl but can't, I'd be happy to help you through it. I regret that it's not as easy as downloading a program and double-clicking it, but I don't want that to stop anybody from being able to use it. There's really not all that much to it, just a few programs you have to install. I can even basically do it for you with Copilot (//https://www.copilot.com/) if you want.

Edit: By the way, map2gl is not an editor. It just views the maps.

-Don

Here's the latest version. Changes:

20080401 - 0.17

• Added preliminary support for placement grids.
• Added support for traps and Move-Find Item data.
• Gave friendlier names to GNS items in info window.
• Reorganized code a lot.
• Added controls to camera window.
• Improved texture transparency. No more flames in black boxes.

thank you gomtuu, weather im able to figure it out or not from your assistance, i really appreciate this.

Wow Gomtuu you have made amazing progress on this. I'm glad that everyone is collaborating so well on this project.

Welcome back, Cheetah. Yes, there have been some interesting developments while you were gone.

Good news, everyone! (Or Windows users, at least.)

I've finally succeeded in creating a map2gl exe file! This means you don't have to install any weird garbage on your computer to get map2gl working; just download, unzip, and double-click on map2gl.exe!

The zip file is ridiculously huge at 10MB, so I don't think I can post it to this forum directly, but here's a link (http://www.gomtuu.org/fft/map2gl18-bin.zip). Try it out!

As for the non-Windows users or those interested in the source code, don't worry, I'll still be releasing the source whenever I release a new version.

-Don

That is great news Gomtuu. I think I am one of the few mac users around here so I think this will help out a lot of people. Plus I have means of getting this stuff running and will need my own windows machine to run most of the programs used around here anyways.

what a great thing .... figuring out what to set up just to run it turned out to be a nightmare for me lol...

Will you release a regular python version too?

10mb takes me about 45 minutes to download...

Yeah, I'll keep releasing Python versions. The only changes from 0.17 to 0.18 are some fixes for the README file and the fact that 0.18 is able to be built into an EXE, so I didn't think a Python release of this version would serve any purpose.

Since when can we do all this stuff with the camera? so sweet! :O

Seriously there are only 2 things left that I want to see from this program:

- No more graphic glitches
- Enemy starting positions

With those two more things I'll be able to create all the necessary screenshots for the site. =)

you forgot a most important thing!

A MAP EDITOR!

Quote from: "Zodiac"- Enemy starting positions
- No more graphic glitches

Enemy starting positions wouldn't be too difficult for story battles since we know where the scenario data is and I can use it to cross-reference map numbers with ENTD entries. But I haven't found anything like that for random battles (though I'm working on it). Of course, it'd be really nice if I could also read the sprite data and put enemy sprites on the map, but I know next to nothing about sprites at this point. I thought about using the item sprites to show the items you get from traps as well, but I'm not quite ready to do that yet either.

What graphical glitches are you talking about? Can you describe when they happen and/or post screenshots? I do know of a few minor glitches: one has to do with lighting on moving polygons (like the gears in the windmill shed) and another makes things look funny if you set the zoom level and FOV angle to extreme values.

Quote from: "karsten"you forgot a most important thing!

A MAP EDITOR! :) I thought about announcing something like that on April 1st, but I decided against it.

-Don

Quote from: "gomtuu"The zip file is ridiculously huge at 10MB, so I don't think I can post it to this forum directly, but here's a link (http://www.gomtuu.org/fft/map2gl18-bin.zip). Try it out!

When you uploaded this file, did you accidentally muck up the permissions on your /fft/ directory? I get 403 forbidden when I try to access it. You had some great info there.

Quote from: "gomtuu"Of course, it'd be really nice if I could also read the sprite data and put enemy sprites on the map, but I know next to nothing about sprites at this point. I thought about using the item sprites to show the items you get from traps as well, but I'm not quite ready to do that yet either.

This sounds awesome. Thanks to some guys involved in the Q-Gears (http://q-gears.sourceforge.net/) project, I've had some success in assembling sprite frames from the random tiles.
(From THIS (http://istaken.org/fft/KANZEN.SPR.palette00.png) to THIS (http://istaken.org/rtload/kanzen/out44.png))
More: http://istaken.org/rtload/kanzen/

Oh Melonhead that is awesome. Being able to do a quick preview of sprites in the different frames will definitely speed up the process of making custom sprites. Much better then inserting the new spr file into the ISO, loading up the game, and then waiting for ever to preform each of the motions you want to see in motion but having it happen all way too fast.

Gomtuu I like your idea of having the enemy sprites showing up on the map preview. Very nice little touches.

Quote- No more graphic glitches

Would that mean to be able to use more than 10 different sprites per battle?

Quote from: "melonhead"When you uploaded this file, did you accidentally muck up the permissions on your /fft/ directory? I get 403 forbidden when I try to access it. You had some great info there.

No, all I did was move it here (http://gomtuu.org/fft/trans/). Funny, I mentioned my site to Zodiac once when I first told him about map2gl through email, before I really knew what you guys had already figured out here. Once I saw the things you were working on, I didn't think my site had much info you guys didn't have already. So I never mentioned it on the forum (as far as I remember). I didn't think it'd be missed. Hehe.

Quote from: "melonhead"This sounds awesome.

Keep in mind that this feature is in the "gee, that would be neat" stage of development. :)

Quote from: "Desocupado"

Quote from: "Zodiac"- No more graphic glitches

Would that mean to be able to use more than 10 different sprites per battle?

No, I think Zodiac means that my map viewer has glitches I need to fix. I don't think he's talking about anything in the game itself.

I don't know if it's normal for the cutaway mode but I always have graphic glitches unless I'm at 30 degree altitude or lower.

And I don't know if the other one happens frequently but the blue panel is under the texture?

Other than that I had trouble switching with the new mode & cutaway mode, it would sometimes ignore when I pressed "t" and was stuck in either off or on mode... this seems very random as I can't easily reproduce the effect.

Quote from: "Zodiac"I don't know if it's normal for the cutaway mode but I always have graphic glitches unless I'm at 30 degree altitude or lower.

That's not a bug, it's a feature. The map files contain information about which angles each polygon is visible from. This is used both to avoid drawing polygons that wouldn't be visible anyway (which is what's happening in your screenshot) and to avoid drawing polygons that would obscure the scene (MAP011 is a good example of this). It's important for map2gl to support this feature so it can display maps the way the game does, but it can be annoying when you view maps from angles they weren't designed to be viewed from. That's why cutaway mode is on by default, but has a toggle. BTW, the maximum altitude without glitches should be 38 degress. I'm fairly sure that's what the altitude is when you elevate the camera during a battle.

Quote from: "Zodiac"I had trouble switching with the new mode & cutaway mode, it would sometimes ignore when I pressed "t" and was stuck in either off or on mode... this seems very random as I can't easily reproduce the effect.

The reason you can't always toggle cutaway mode and terrain mode has to do with which part of the map2gl interface has focus and can intercept keyboard events. I'd have to learn more about event handling in wxWindows to fix it.

As a workaround for now, you should be able to click the mouse once in the main viewer window to get map2gl to respond to keyboard commands. I plan to add some more GUI interface stuff to let you control those things without the keyboard, too, but I haven't gotten around to it yet.

Quote from: "Zodiac"And I don't know if the other one happens frequently but the blue panel is under the texture?

Yeah, that one is relatively rare, but I do hope to fix it. It's because I don't know exactly where to draw the terrain tiles. I'll have to do some tests in-game to see if I can figure that one out. This also affects the bridge on Zirekile Falls (MAP083) and the arches on Underground Book Storage Third Floor (MAP059), to name a few.

Quote from: "Zodiac"- Enemy starting positions

I worked on this today, and while I was at it I added a Scenario Chooser (in the File menu), which uses the data in ATTACK.OUT to make a list of scenarios. When you choose one, it loads the map with the proper weather, ENTD, and placement grid information for that scenario. So that'll be in the next version. The ENTD information is frequently wrong about where things are, though. I assume this is because the characters get re-positioned by event scripts, but maybe I'm just reading the data wrong? Anyway, here's a screenshot of a map that works well:

Well Gomtuu, you certainly know your stuff.

Have you checked the map on chapter 2 the Execution Site the wooden platform that is so high you must have fly to get there was there an item?

Quote from: "Sen"Have you checked the map on chapter 2 the Execution Site the wooden platform that is so high you must have fly to get there was there an item?

Nope, here are the items (the magenta squares). They match the Move-Find Item FAQs on GameFAQs.

Note that this is a map where the ENTD info doesn't work very well. This is partly because, when a square on the map has two heights (like a bridge and the ground beneath it), I don't know how the game decides where to start the unit. So map2gl just draws the starting location tile on both heights for now.

You still around Gomtuu?

Quote from: "Cheetah"You still around Gomtuu?

Yeah, I've been lurking now and then. But no, I haven't been working on map2gl for a few weeks now... My interest in it has waned for now, I guess. That's how it tends to go with my hobbies...

Well I'm very excited to say that I finally found a way to get map2gl working for me. I had to get Parallels working on my mac, but the map2gl.exe works great and fast too. This is certainly an awesome piece of programming, I have just spent about two hours just poking around with the maps. The weather affects and map info overlay are especially cool. There are a lot of locations that are barely seen or not at all that are really cool. The four room map is especially cool, and it seems like it would make for a rather fun spot to battle. Though I suppose as a map viewer you have pretty much completed your task. Are there any other features you were hoping to implement? I would personally like to see a tile ripper so that I could get a better look at the graphics used. Much more than that and you would be making a map editor, which of course would be amazingly exciting.

Glad you got it working!

Quote from: "Cheetah"Are there any other features you were hoping to implement? I would personally like to see a tile ripper so that I could get a better look at the graphics used. Much more than that and you would be making a map editor, which of course would be amazingly exciting.

It's so far from being a map editor that I don't even want to think about it.

As for a tile ripper, that's somewhat complicated. There isn't really a concept of graphical tiles, it's just a bunch of textured polygons, and I've explained before about the difficulties with the textures (http://auritech.fantopolis.com/viewtopic.php?t=20&start=52#2326). It wouldn't be impossible, but I haven't really put any effort into it yet.

Some features I'd like to add to map2gl in the short term are:

• Add a tile-by-tile terrain inspector using a cursor similar to the in-game cursor. When the cursor is on a tile, display information about that tile's height, surface type (grass, river, bridge, etc.), traps, and items.
• Improve representation of items. Instead of just turning the tile magenta, display the item's name and possibly its icon on the tile, or off to the side with a line pointing to the tile.
• In terrain mode, display a number on each tile indicating its height.
• Add more GUI controls so you can toggle lights, terrain mode, etc. via the GUI or the keyboard.
• Allow camera panning, not just zooming and rotation.

Some medium- to long-term features I'd like to add are:

• Display unit sprites on their starting locations (as read from ENTD files) instead of just turning the tiles orange.
• Implement the more complicated polygon animations, like doors swinging open, the clothes on map047, which I think are supposed to sway in the breeze, and a few others.)
• Implement texture animations, like water and lava. Some gates also open via texture animations. (They become transparent.)
• Use event instructions to determine character starting positions, since the ENTD information often doesn't show you where the units really are when the battle starts.
• Add ability to view PSP maps.
• Texture export.
• Polygon mesh export, as 3DS or something.

Some fantasy features that may never happen are:

• Allow custom textures to be substituted for the in-game textures, so you can (manually) create high-resolution, full-color versions of the textures and then have map2gl display the map with those instead of the normal textures.
• Execute event instructions so you can watch cinematic sequences. (Note that this is a fantasy feature and may never happen.)
• Fully re-implement the battle engine! (Yeah, right.)
• Map editor.

All very cool and exciting sounding stuff. I  able to see the "textures" with the graphics viewer I'm using, but I have no idea how it is actually organized and i couldn't find anything that looked like a palette for anything. So I think I kind of understand what you mean about there not being textures. Is it like there is just one picture file with all the textures for one map on it, but how each part is divided and use is completely unique to each map?

Besides maybe messing with textures on maps I only have one other though about map editing. Do you think you know enough about the map information to kind of "complete" the cutscene maps? Like how not all the transparencies activate correctly from some angles (angles never ment to be seen), and how the black fill isn't always present. Just figuring out some of those things would make some of the existing maps actually playable.

Is there really unit placement information stored for every map? If so why?

geez just reading the post of Gomtuu right now it seems that maps are EXTREMELY complicating in Final fantasy tactics because in other games its so simple because some are 2-D so the complications are minimum but FFT maps are 3-D so there is A LOT more work to implement a program to correctly edit them, so all I have to say so far to Gomtuu's progress is amazing work!

Quote from: "Cheetah"I'm able to see the "textures" with the graphics viewer I'm using, but I have no idea how it is actually organized and i couldn't find anything that looked like a palette for anything. So I think I kind of understand what you mean about there not being textures. Is it like there is just one picture file with all the textures for one map on it, but how each part is divided and use is completely unique to each map?

I didn't mean to imply there aren't textures, just that they're not organized in a way that would make it easy to extract and manipulate them.

The system used for applying textures to the polygons is referred to as UV mapping (http://en.wikipedia.org/wiki/UV_mapping), and it's very common in 3D graphics in general. The trick is the weird way that the palettes work. Different areas of the texture image are rendered with different palettes, and the only way to know which areas get which palettes is to look at the polygon data, which contains a palette index for each polygon and UV coordiates for each of the polygon's vertices. The UV polygons might even overlap (I don't know if they do in practice, but there's nothing stopping them techincally), so it's not 100% guaranteed you'd be able to get a clean representation of which areas use which palettes.

Quote from: "Cheetah"Do you think you know enough about the map information to kind of "complete" the cutscene maps? Like how not all the transparencies activate correctly from some angles (angles never ment to be seen), and how the black fill isn't always present. Just figuring out some of those things would make some of the existing maps actually playable.

For the visibility angles: I know how you'd have to do it (what data you'd have to change), but I don't know how it could be made easy. The polygons aren't sorted any particular way that I know of, so you'd need a way to locate the polygon you wanted to change. I could add a feature to help with that into map2gl, but it'd still be kind of clunky.

As for the black fill, that's a matter of adding more untextured black polygons wherever you need to cover something up. To do that, I think you'd need to make the map files larger, which might be okay most of the time, but for some files there might not be room without moving the files to different blocks on the CD...

Quote from: "Cheetah"Is there really unit placement information stored for every map? If so why?

I know, isn't that weird? My guess is that it was really easy for them to make the placement grids with whatever program they used to make the maps, so they just always added them in case they needed them later.

...

Either that, or I'm reading the data wrong. But it looks right most of the time, right? And it's even better with the scenario chooser, since it only uses the placement grids the game would've used for that scenario.

Quote from: "trickstardude7"FFT maps are 3-D so there is A LOT more work to implement a program to correctly edit them, so all I have to say so far to Gomtuu's progress is amazing work!

Thanks! :)

You know, now that I'm thinking about it, just because the map files can store arbitrary 3D meshes doesn't mean that a map editor would have to let you create arbitrary 3D meshes. We could start off with an editor that only lets you do certain kinds of things. It wouldn't let you edit existing maps, but you could create new ones from scratch.

The editor wouldn't even need a 3D interface necessarily; it could represent the terrain data schematically somehow (or even as text) and then generate polygons from that behind the scenes... Texturing would still be tricky, but not beyond reason...

Hmm... Why didn't I think of this before?

i would personally just be happy if i could get enough of the program to open long enough to let me change the music on a certain map or change the number of units you could place... i never manged to get it to run

I like where you are going with this Gomtuu. The maps can actually be very simple in design but very effective. They are just a grid, with each square adjusted to a relative height, and then a "top" at a certain angle and direction. A thought for a visual representation of the maps would be to display them as a collection of bar graphs. So you could be looking at one column of the Z direction, and all the different heights of the X grid panels in that Z column would be represented. Then by going through all the Z columns you could setup out entire map. Then of course you could switch to looking at the X columns(or rows) and it would be like looking at the map from a different direction. So that one bar graph just represented a slice of the entire map.

Well I hope that makes sense because it is kind of hard to describe, but I think it is a decent idea to set up the kind of parameters you are looking for without having to actually manipulate things in three dimensions. Or at least I hope so...Of course this would only work for very simple maps, without stuff like archways or windmills.

Quote from: "Zozma"i would personally just be happy if i could get enough of the program to open long enough to let me change the music on a certain map or change the number of units you could place... i never manged to get it to run

What was the last PM you got from me, Zozma? I sent you 2 messages that sat in my Outbox for a long time, and now they're not there anymore, and they're not in my Sentbox either. I'm just wondering if you got them. If you didn't, I can try to remember what I said and send again.

Anyway, map2gl isn't an editor. It won't let you change the music or the number of units you can place on a map. I don't think there is a program that edits these things yet, so you'd have to use the specs I posted in this thread and edit the data manually.

oh, i see ill read up more closely. i can play around with a hex editors and stuff i know how to do that much, just cant seem to run this afterall, all that I REALLY want to do is change how many units are allowed in certain battles and the music that plays.

Hey! I see the site's been updated and has a download link for map2gl. Cool!

But you only posted the source version, which is harder to get working. You might also want to post the EXE version so people don't have to install Python and all that other junk. I linked to the EXE version in this post (http://auritech.fantopolis.com/viewtopic.php?t=20&postdays=0&postorder=asc&start=120#3677).

What's new, by the way? I haven't been checking the boards much. Has any new and interesting data been uncovered?

Well, as you see I'm currently working a lot on the site, and I'm not really doing anything else. As soon as I finish the beta, I'll go back to the events scripts.  

Oh, in regards to that, can you tell me everything about the structure of TEST.EVT and of an event? there's not much to say, I just don't get how the game determines it has to load which block and how the pointer for text is working (although I haven't even check that ;o).

Because in the end, if I want to make an event editor that can edit ATTACK.OUT and TEST.EVT I'll need that.

Ah, gomtuu! Well, I've tried my best to record all the music, events, and maps according to Attack.out and the info. has been sent to Melonhead, though one thing that's odd... you said Snow and Rain weren't involved with the Weather tag? Also it seems that if the event had always gone back to the map screen, there's no way to stop it from doing so, but you can force events that normally did not go back to the map screen to go of course, though I wonder what problems that could cause...

Good to see you are still poking around Gomtuu. You even got credit as a staff member on the new site.

I know you aren't working on this stuff much. But do you have any advice on how I might go about changing the textures for the maps? I know where at least parts of them are located and importing and exporting them shouldn't be a problem. I'm just confused about where the palette information is stored more than anything.

Cheetah,

I'll answer your question first:

Quote from: "Cheetah"do you have any advice on how I might go about changing the textures for the maps? I know where at least parts of them are located and importing and exporting them shouldn't be a problem. I'm just confused about where the palette information is stored more than anything.

As you may know, there are three basic types of files in the MAP directory:

• GNS files, which are indexes that point at the other two kinds of files so the game knows which set of files to load for each weather condition / room arrangement,
• Texture files, which are always 131072 bytes because they're just 256x1024x4-bits-per-pixel bitmaps, and
• Mesh/terrain files, which store vertex XYZ, UV, and normal vector data; texture palette data; and data about terrain heights and surface types.

The easiest way to identify the third type of file is by exclusion: They're not named .GNS and they don't happen to be 131072 bytes. There's also a way to identify them using the GNS files, but that's a little more complicated.

If you look in these mesh/terrain files, the first thing you'll see (the first 0xc4 bytes) is a table of contents made up of 32-bit pointers to other locations in the same file. These pointers are as follows:

0x0040: Vertex data
0x0044: Color palette data
0x004C: [only occurs in map000] ?
0x0064: Lighting + background color data
0x0068: Terrain data
0x006C: Texture animation data, including water and event-driven animations
0x0070: Animated palette data
0x007C: Grayscale palette data
0x008C: Extended polygon placement and animation data
0x0090: Extended polygon data 1
0x0094: Extended polygon data 2
0x0098: Extended polygon data 3
0x009C: Extended polygon data 4
0x00A0: Extended polygon data 5
0x00A4: Extended polygon data 6
0x00A8: Extended polygon data 7
0x00AC: Extended polygon data 8
0x00B0: 0x380 unknown bytes, then polygon visibility angle data
The above list skips some entries in the TOC. That's because those entries are zero in all the map files. They don't point to anything.

To find the data you're looking for, seek to the location of the appropriate pointer and read a 32-bit little-endian integer. So, for the palettes in map085.7, you'd seek to 0x44:

0000044: 2c6d0000
This tells you that the color palettes start at 0x00006d2c (in the same file, map085.7). Seek there, and you'll find a block that contains 16 palettes, each of which is 16 colors (32 bytes) long. They don't always use all 16 palettes, but the block will always be 512 bytes long. It just might be padded with zeros (totally transparent palettes).

In map085.7, this block looks like this:

0006d2c: 0000 480d 2709 0605 c400 a300 8200 6100 6905 1022 cd19 8b11 2809 e604 c500 e500
0006d4c: 0000 480d 0605 c400 a300 8200 313a ce31 8c29 4a21 2919 0719 e610 c510 a40c 830c
0006d6c: 0000 690d 2709 0605 c400 a300 6905 480d 313a ce31 6b21 2919 0719 e610 a40c e500(And then 13 transparent palettes.)

Each color is 16 bits, little-endian. The highest bit controls transparency; if the color is black and this bit is 0, then the color is 100% transparent. Otherwise, the color is 100% opaque. After the highest bit come 5 bits of blue, then 5 bits of green, then 5 bits of red.

Hope this helps!

By the way, to determine which file you need to look at to get the palettes you want, just pay attention to map2gl while it's loading a map. It'll say something like "Reading color palettes from /cdrom/map/MAP085.7"

Haha this is great information. Now it will just take a few weeks for me to absorb the information. But basically what I'm getting is that the palette for the textures is with a different part of the map information, which makes sense. Then with the information you gave me I should be able to find the palettes and adjust them in a hex editor. Does this sound about right? Also is there different palette information for the different weather conditions, or is it a prerecorded blanket adjustment to the colors (hope that makes sense)?

Amazing information as usual Gomtuu.

Quote from: "Cheetah"But basically what I'm getting is that the palette for the textures is with a different part of the map information, which makes sense. Then with the information you gave me I should be able to find the palettes and adjust them in a hex editor. Does this sound about right?

Yep, and remember, you should be able to preview your changes easily in map2gl.

Quote from: "Cheetah"Also is there different palette information for the different weather conditions, or is it a prerecorded blanket adjustment to the colors (hope that makes sense)?

I don't think the palettes themselves are adjusted, but sometimes two weather conditions share the same palette and just have different lighting. Sometimes the different weather conditions do use totally separate palettes, though. For example, map 85 only has palette data in map085.7 which is shared by all weather conditions, but map 56 has palette data in every mesh file except map056.0.

I wrote a program for my own purposes a while ago called lsgns.py that outputs a list of the resources contained in each map file. Let me know if you're interested. You'd need Python to run it, but you wouldn't need all the funky libraries map2gl needs. I guess I could make an EXE version, too, if there's interest.

Quote from: "Cheetah"Amazing information as usual Gomtuu.

Glad I could help!

Quote from: "LastingDawn"you said Snow and Rain weren't involved with the Weather tag?

My hunch is that the weather and day/night info from ATTACK.OUT (http://auritech.fantopolis.com/viewtopic.php?p=3202#3202) doesn't influence weather-based spell damage, but I don't think I ever tested it. I'm pretty sure that it also doesn't determine whether the raindrop animations are displayed. I think I remember noticing that the event script number (J in that table) did determine whether raindrop animations were used, but I'm not sure about that. As far as I know, the ATTACK.OUT weather and day/night data only tell the game which map texture and mesh files to load. In other words, they indicate which GNS entry to use.

Quote from: "LastingDawn"Also it seems that if the event had always gone back to the map screen, there's no way to stop it from doing so, but you can force events that normally did not go back to the map screen to go of course, though I wonder what problems that could cause...

Oh, it doesn't work both ways? That's a bummer.

To me, probably the most exciting thing left to figure out about the game is how the scenarios themselves interact with the map screen. If we can figure out how to make the map draw different roads and cities after each scenario, and how to control which cities launch which scenarios, then we can do some pretty neat stuff.

Unfortunately, I've already spent a lot of time working on that and I didn't get very far.

No luck in that department? Any success, any interesting anecdotes to share on the subject?

That is most definitely an interesting subject regarding editing the world map. I'm not sure I have even found which file contains the image of the world map, do you know?

I would definitely be interested in a program showing this information, though it would be easier to run an EXE. If you could some how incorporate a way to quickly edit the palettes that would be amazing.

Quote from: "Zodiac"Oh, in regards to that, can you tell me everything about the structure of TEST.EVT and of an event? there's not much to say, I just don't get how the game determines it has to load which block and how the pointer for text is working (although I haven't even check that ;o).

I don't really know anything about TEST.EVT beyond what we talked about earlier (http://auritech.fantopolis.com/viewtopic.php?p=3379#3379) in this thread and the program I posted (http://auritech.fantopolis.com/viewtopic.php?p=3422#3422)...

As for how the game determines which block to load, that's just letter J in the scenarios in ATTACK.OUT (http://auritech.fantopolis.com/viewtopic.php?p=3202#3202), right?

Quote from: "Cheetah"I'm not sure I have even found which file contains the image of the world map, do you know?

According to George Greer's site (http://sh3llz.com/~melonhead/greerga/#Information-Files-World), I think that image is in WLDTEX.TM2 in the WORLD directory.

But, obviously, the roads and city dots aren't part of that map. They're drawn on top of it as needed.

Quote from: "LastingDawn"No luck in that department? Any success, any interesting anecdotes to share on the subject?

I did find a block of data that had to do with city locations, but it didn't affect where the dots were drawn, IIRC. I think it only had an affect on where the city's cursor hotspot was. That is, the city looked like it was in the normal spot, but you had to move the cursor to a different part of the map to select it and go there.

That block was in WLDCORE.BIN at 0x2ddfc. There were 43 locations, each one being 64 bits long (two 32-bit signed little-endian integers?) But that doesn't do us much good by itself.

This little quote from the Final Fantasy Investigation Project might be of interest and answer your questions somewhat!

"wldtex.tm2
    Summary: The world map graphic, with the location data embedded in it.
    Format: 256-color palette images of 240x240, 256x240, 240x300, and the rest unknown. Investigation pending."

FYI: I submitted map2gl as a utility on romhacking.net (http://www.romhacking.net/). It appeared in yesterday's "New Submitted Utilities" announcement on the home page.

Good to hear, romhacking.net is a pretty awesome community.

Hey, I was going to make Treasure chests in my Chocobo Wars patch, but  is there a "Chest" type floor? I was going to make chest-type obstacles that have an item hidden either in front of the chest or on top of the chest.  I don't think putting chests from units will work, since anyone can open them.

Edit: Excuse me, can we even edit maps like that yet?

yay! finally i understand this stuff

is there some sort of list of weather?
and what about weird times of day like sunset with the red sky...?
sorry new to this stuff

Maps only have a limited amount of palettes, whoever through event editing it's easy to make a sunset or such, just use ColorBg & ColorField. Well, when I release the event editor.

cant wait to see that event editor :P

Uploaded, now we need to make a big sections for the instructions.

umm maybe im missreading the readme file...

am i not editing the right text file? i tried to screw up the intro scene just to see if it worked but no changes occurred.

Hmm? In the event compiler?

Much greatness!! Map viewing and deciphering is just a small leap away from editing!

After a long break, I've started working on map2gl again!

Thanks to GodBeastX, I decided to try to use shaders to solve the 16-palettes problem (i.e. copying the map texture into memory 16 times). Actually, I had wanted to use shaders for a while, but for a different reason: the default ("fixed") shader in OpenGL doesn't work the same way as the PSX, so the lighting in map2gl has always been a bit off. So I'm trying to kill two birds with one stone. I haven't done the 16-palettes thing yet, but I do have a shader implemented that produces results that are similar to (and sometimes more accurate than (and sometimes less accurate than)) the fixed OpenGL shader.

There are also some never-released changes (http://www.ffhacktics.com/forum/viewtopic.php?p=3845#3845) I made shortly after I posted the previous version (0.18). The biggest thing is the scenario chooser. This lets map2gl use the scenario data in ATTACK.OUT to pick the proper room arrangement, weather condition, and placement grid for a scene, and the data from the ENTD files to show enemy and guest starting positions. It's still not perfect because event scripts can change lighting/backgrounds and move characters around, but it's an improvement. So those will be coming soon as well.

The real reason I got back into this, though, was because I want to try to make a texture editor. I think I can do it... We'll see!

Anyway, here's a screenshot from my latest dev version, compared with one from Zodiac's map guide. The older version had weird phantom trees (Actually, this makes me think Zodiac was using 0.16, which was two versions ago) and way-too-contrasty lighting.

err I ain't gonna them again, took like 3 hours of macroing.

yesss!

well, except maybe that map (and another I think?) because of the buggy trees.

Excellent, Gomtuu!

much awesomeness. that screenshot looks better than what you get in the game!

hmmm brilliant me like

Hell yeah, great to have Gomtuu working on this again. Having some of the attack.out data implement would be great. Especially with scenario editing so I could get a better idea of what the map is going to end up looking like. The shading does look tons better, if you think these screen shots look better then the actual game then it is probably because this thing is running better then the emulator you are use to seeing the maps on. Is that actually possible?

Glad you guys are still around!

Work continues on map2gl. It's been more challenging than I thought to get the shader to work (instead of using 16 copies of the texture), but it's working pretty well now. Now I'm just trying to get it to run in both Windows and Linux again. Stay tuned!

Quote from: "Cheetah"if you think these screen shots look better then the actual game then it is probably because this thing is running better then the emulator you are use to seeing the maps on. Is that actually possible?

It could be. The emulator might be running in low-quality mode and/or scaling the picture up and/or stretching it horizontally (IIRC, FFT runs in 256x256 mode, which is not 4:3), any of which would make the image look crappy.

-Don

gomtuu, I'd have a request.

I'd want the geomancy effects (or just the tiles type) of all maps along with the height of panels.

I don't care for the format, but if you could even add a function to rip those to a file it would be awesome. That's pretty much all I need beside the move-find items to complete the map section.

Quote from: "Zodiac"I'd want the geomancy effects (or just the tiles type) of all maps along with the height of panels.

That shouldn't be too hard... I'll see what I can do.

I made a program that goes through all the maps and, for each one, dumps a graphic representing that map's terrain. It's still beta, but here's a preview of Magic City Gariland (022).

The idea is, you'll be able to put these terrain images side-by-side with the overhead screenshots you've got now. Or maybe make the terrain appear on mouseover. There'll need to be a key to the surface type color codes, which I can make my program generate.

Does anybody feel like making a set of simple 28x28 bitmaps to represent the various terrain types? Using patterns rather than just colors would make them easier to identify. The patterns should be subtle, though, so you can read the heights.

There's almost too much terrain data to cram onto a single square! There's the height and potentially depth, and then there's the height of each edge of the tile for sloped tiles. Plus, there are potentially two levels of terrain on each map (e.g. a bridge and the water below it). So I'm not sure how much I should try to put on there. There's also the Move/Find item data, as you mentioned.

Well you see I'm going to add a menu to select what to display. There will be a few radio buttons and a checkbox to switch low/upper level and another to show +brave and -brave items.

This is also why I'd prefer to have data and not an image. well of course an image can do but it'd be less practical for me to code.

Really? I'm surprised that you would prefer text data. I'm happy to do that, of course, but from your description, I don't really understand what you're looking for.

Outputting the data in different formats is pretty easy for me, so maybe it's best if you give me a sample of how you'd like it formatted. That way you won't have to go through a bunch of stuff and re-format it.

Oh that is cool. Definitely include the terrain viewing option to your map viewer either way Gomtuu.

Someday I'll post a new version of map2gl... As I said, I haven't been able to get it working reliably in Windows yet (it works on my home computer but not my work computer), which has slowed me down.

For now, here's another teaser. Those white triangles in the lower right corner of the texture are UV polygons. Palette 05 is selected on the right side of the window, and those triangles are showing you which areas of the texture make use of that palette. (You can turn this feature off by unchecking "Show areas used by polygons".)

So, I'm making progress, but I still need to write the actual exporting/importing stuff. And probably a feature that lets you edit the colors in the palettes...

Beautiful looking! This looks great, Gomtuu! Decompiling all of those pieces like this!

wow this is getting exciting

Oh my god Gomtuu SOOOO FUCKING AWESOME! Seriously I am at work at midnight right now and I'm freaking out about that texture editor. FUCK YEAH!

Okay, okay I'm breathing again phew. So this will be totally huge if you get this working. Do you think you will also be able to add a feature to change what textures are used in a certain area? Might just make it easier to do like change the amount of rock or grass in a level among other things.

Well if there is anyway I can help out with this project through testing or whatever I would totally jump at the chance. Not to mention I would love to play around with these toys for a bit and come up with some sweet texture edits .

PS: I don't know if this helps but Graphics Gale does a real good job of making palettes really editable, but still having the structured correctly. So that you could just export this image as a BMP with the palettes organized in the same manner, then you could edit it in Graphics Gale while keeping the organization of the palettes intact for easy import. Not sure if that helps or not, but you should check it out. I use a similar system for getting all the different palettes to work with sprites.

Quote from: "Cheetah"Do you think you will also be able to add a feature to change what textures are used in a certain area? Might just make it easier to do like change the amount of rock or grass in a level among other things.

Are you asking whether I can make it edit the UV coordinates? It's possible, but I don't know how I'd make the user interface for something like that. For now, it won't be able to do that.

Quote from: "Cheetah"Graphics Gale does a real good job of making palettes really editable, but still having them structured correctly.

That might help a lot, actually. A problem I've run into is that the palettes themselves have alpha data in them. That is, each color in the palette has an alpha bit, so any number of colors can be transparent. Naturally, I can't just combine them all into a single transparent color, because that would discard some of the colors in the image, so I want to be able to preserve the alpha data in the palette. No common image format or image editor supports that, AFAIK. Does Graphics Gale support palettes with alpha data? If so, does it allow you to load a regular image (which would be 16 shades of gray) and then load a separate file that's just a palette with alpha data, edit the image, then save it in grayscale with a separate palette file?

If we can't find a file format or image editor that allows that sort of thing, then I'm afraid you're going to have to edit the texture image in grayscale (no palettes applied), or at least without alpha information. (Transparent colors would become black (or maybe magenta or something) when you exported the image, and then after you re-imported them, you'd have to set the alpha bit for each color that needs to be transparent.)

Funny, I don't remember that being there...

Haha Sweet.

Oh I know very little about alpha levels in Graphics Gale. If it doesn't support it though, maybe you should just have the interface for editing the alpha levels as part of the palette viewer. Good graphics editing tools aren't something you want to implement into your map viewer/editor, but just changing the alpha levels of the colors is pretty straight forward, and in most cases probably wont even need to be touched, correct? That seems like the simplest solution to me.

Oh you know how I get a little ahead of myself when it comes to this map editor. When you were talking about having it show what sections of the textures the palette uses, I thought you were also showing on the map where each palette/texture was being used. Which my ecstatic brain translated into, "change textures all over the map". But yeah the more features you add the more complicated the interface.

epic

Changing the textures definitely won't be much trouble but repositioning those textures on the map but be a lot of work. :/

I still want to see this editor done though,  I'm all for moar editing! :O

so this also will mean being able to make places like lesalia mainstreet, able to be used in battles by fixing all the wall issues?

Quote from: "gomtuu"Funny, I don't remember that being there...

That made me giggle like girl man.

Quote from: "Zozma"so this also will mean being able to make places like lesalia mainstreet, able to be used in battles by fixing all the wall issues?

Nope, I don't think so. From what I can tell, maps 97, 98, and 99 don't even have polygons for the sides of the buildings that weren't meant to be viewed.

Could the polygons be created though.

awww... those maps would be so nice to use hehe...

kudos to goomtuu's great work.

MOAR EDITING!

Quote from: "Voldemort7"MOAR EDITING!

Wish granted!

This release includes the ability to export textures as PNG files and then re-import them (presumably after you edit them). For the import to work, the PNG has to be in the same format as the exported file: 8-bit with a 16-color palette. For now, the actual color values in the imported PNG's palette are ignored, meaning you can't change the PNG's palette and expect the map's colors to change when you import the PNG. Also, although you can click on colors in the palette grid and move the sliders around, map2gl's built-in palette editor doesn't actually do anything yet. That's coming later.

See the included README file for other changes, installation instructions, and system requirements.

map2gl 0.19 binary version (http://www.gomtuu.org/fft/map2gl19-bin.zip) (32-bit Windows) (6.9MB)
map2gl 0.19 source version (http://www.gomtuu.org/fft/map2gl19-src.zip) (Cross-platform) (35KB)

The Windows binary has been tested on exactly one computer, so hopefully it works for everyone.

The source version has been tested in Windows XP on two computers and in Ubuntu 8.10 on one. It should also work in OSX, but I haven't tested it. Note that to get the source version to work, you need to install Python and some libraries. See the installation instructions in the README file for details.

Enjoy! And let me know if you have any questions.

sweet! cant wait to test this!

Exciting! Exciting!

ohhhh

that thing again where it just shut down as soon as i start..

Quote from: "Zozma"ohhhh

that thing again where it just shut down as soon as i start..

Do you know if your video card supports OpenGL 2.0? Anything made in the last 3-4 years should support it, I think. You can use OpenGL Extensions Viewer (http://www.realtech-vr.com/glview/download.html) (Windows or Mac OSX) to check. Install it, then click "Rendering tests," then the play button, and it'll test whether your video card supports each OpenGL version from 1.1 through 2.1.

You might also want to make sure your video driver is up to date.

Hope this helps!

yeah the funny thing is i had managed to get the older version to work before when you could just view stuff... lol

ohhh... 1.4 thats the version i have? really? wtf

lol crap

...2.0:
ARB_shader_objects not supported.
...2.1:
ARB_pixel_buffer_object not supported.

guess theres nothing i can do. thank you for figuring out my problem.

Quote from: "Zozma"yeah the funny thing is i had managed to get the older version to work before when you could just view stuff...

Yeah, I've made some changes since then (added shaders) that increase the OpenGL version required... The goal was to make maps load a little faster (and consume less video RAM) and to increase the accuracy of the lighting. It also simplified the code a little.

If you haven't tried upgrading your video driver yet, that might work. Or you could try running it on a computer with a newer video card, if you have access to one.

If there's enough demand, I guess I could go back to the old, non-shader way of doing things.

no, thats cool as long as everyone else can use it

ill just ask someone to make edits for me, i really dont want to change anything big except maybe making one more map with lava. and some sunsets and stuff. i can ask someone to do those if i need them.

thx for helping me figure out what was wrong, i could have spent forever on that.

Hmm well I'm having a bit of difficulty getting it running. I had to download msvcp71.dll, after that it at least started opening up. But as soon as it showed like the actual program it...closed? Obviously I want to be ripping and editing textures even if I can't quite yet implement them yet, so any suggestions? Oh and do the maps use multiple light sources? Like does the lava actually produce it's own light and shadows in this game? I don't think so but I'm curious.

PS: Gomtuu you are the man. Come by the IRC Chat sometime so we can give you more of the mad props you deserve.

Just a quick question about my error messages.

Here's map2gl version 0.20. This is a bugfix release only. It's intended to fix a bug preventing map2gl from working on ATI video cards. I don't have access to a computer with an ATI video card, so I don't know if it'll work. Please try it if you have one and you weren't able to get map2gl 0.19 running.

map2gl 0.20 binary version (http://www.gomtuu.org/fft/map2gl20-bin.zip) (32-bit Windows) (6.9MB)
map2gl 0.20 source version (http://www.gomtuu.org/fft/map2gl20-src.zip) (Cross-platform) (35KB)

Both of these ZIP files were made with 7-Zip and might not work with WinRAR.

With help from Cheetah, I was able to find and fix the ATI compatibility problem introduced in map2gl 0.19. Probably. This new version should work on both ATI and NVIDIA video cards, as long as they're relatively new (3-4 years).

map2gl 0.21 binary version (http://www.gomtuu.org/fft/map2gl21-bin.zip) (32-bit Windows) (6.9MB)
map2gl 0.21 source version (http://www.gomtuu.org/fft/map2gl21-src.zip) (Cross-platform) (35KB)

Enjoy!

Oh hell yeah it is totally working now and so kick ass. I love the palette viewer/exporter. I'm definitely looking forward to more capabilities being added to this now that it is running on a greater variety of graphics cards. Hopefully I will find some time to play with what you have so far though.

Glad to hear it! By the way, to answer your previous question:

Quote from: "Cheetah"Oh and do the maps use multiple light sources? Like does the lava actually produce it's own light and shadows in this game?

No, the lighting that the game uses isn't sophisticated enough to produce actual shadows or have objects that emit light. In FFT, there are 3 directional light sources and an ambient light source. Each light has a color, and each directional light also has a vector that specifies which direction it's shining. Basically, the closer a surface is to being perpendicular to a given light's direction, the more that light illuminates the surface. This is a very common method of lighting 3d scenes because it's fast, but it's not very flexible. Any time you see an object casting a shadow in FFT, the shadow is part of the texture.

For anyone who's interested, I just spent some time documenting a lot of what I know about the map file formats in the wiki (http://www.ffhacktics.com/wiki/Maps).

Oh this is freaking awesome information. Some Questions?

So XYZ is obvious but what is UV?
What does the tile heights and slopes have to do with the Terrian data? How is that not part of the maps polygons?
So I was looking at the textures last night and noticed the gray scales. When are these actually used and how?
Is Vertex animation data like the windmill?
Will the polygon visibility thing make it so there is an easier fix to get more maps usable? Or is it usually a case of missing polygons?

Some of that stuff you touched on in your descriptions, very good job presenting all of it. The question I have that I didn't see anything on was for objects in any given map, where are they stored? I know that there are some maps where you can get rid of the chairs, but where is the data that stores what the chairs look like and where they go? And obviously there must be some objects that are actually basically terrain with just different palettes right?

Did I ask enough questions?

I know the map viewer cant edit maps yet, gomtuu, but can we edit make appearences and such through a hex editor?

Quote from: "Cheetah"So XYZ is obvious but what is UV?

UV coordinates are texture coordinates. (This is 3D graphics lingo, not something I made up.) Each point in a polygon has XYZ coordinates to locate it in space and UV coordinates to define the area of the texture that should be applied to the polygon.

The UV polygons are the white triangles you see when you view textures in map2gl.

Quote from: "Cheetah"What does the tile heights and slopes have to do with the Terrian data? How is that not part of the maps polygons?

The mesh data only defines the appearance of the map. It's completely independent of the terrain data, which affects how the game actually works (the height your character appears to be standing on, whether you can jump up to a ledge, where your cursor shows up, etc.) You could have a map where everything looks completely flat and grassy, but in fact when you walk around there are sloped tiles, tiles of various heights and depths, and different surfaces (sand, wood floor, etc.) The terrain data is what makes the map really work; the mesh is just pretty pictures.

Quote from: "Cheetah"So I was looking at the textures last night and noticed the gray scales. When are these actually used and how?

Map2gl doesn't show the grayscale palettes I mentioned on the wiki. If you're seeing grayscale palettes, either something is wrong or it's a coincidence. The grayscale palettes are a separate set of 16 palettes, and map2gl doesn't use them anywhere. As for where the game uses them, I don't know. I haven't investigated it a whole lot, though.

Quote from: "Cheetah"Is Vertex animation data like the windmill?

Yep. There are continuous animations like the windmill, which map2gl supports, and then there are animations that I'm pretty sure are event-driven and just happen once and then end. Interestingly, the Zirekile Falls map appears to contain an animation that makes the bridge fall... But I've never actually seen it (It's not in the game, right? I don't remember it...), I'm just guessing based on the numbers. You could probably trigger it by messing with an event script on that map.

Quote from: "Cheetah"Will the polygon visibility thing make it so there is an easier fix to get more maps usable? Or is it usually a case of missing polygons?

I'm pretty sure it's a case of missing polygons, at least for the three maps I mentioned before (97, 98, and 99, I think).

Quote from: "Cheetah"for objects in any given map, where are they stored? I know that there are some maps where you can get rid of the chairs, but where is the data that stores what the chairs look like and where they go? And obviously there must be some objects that are actually basically terrain with just different palettes right?

I don't understand the second part of your question, but as for chairs and things: The chairs aren't stored separately. For map011 (Office of Igros Castle), for instance, there are several complete meshes, some of which have chairs and some of which don't. Map094 (Broke down shed: Stone building) has a version with a table in the middle and a version without, but the table isn't stored separately. These different versions are what I call room arrangements, and you can see them and switch between them using the Information window of map2gl.

That said, for maps with objects that move (like the windmill), the moving objects are stored in the animated mesh chunks, as you guessed.

Speaking of arrangements, map064 (In front of Bethla Garrison's Sluice) has a low-water-level arrangement and high-water-level arrangement. I'd be interested to know what triggers the switch from one to the other. Is it this instruction (http://www.ffhacktics.com/psx/instructions.php?id=19)?

Quote from: "Cheetah"Did I ask enough questions?

Definitely.

The bridge falling!? That would be so sweet. Okay such great information and I have so many more questions, but I suppose they will have to wait till I have time. Keep up the great work Gomtuu.

Very interesting, Gomtuu... I'll see if the bridge falling is in an event.

speaking of the falls bridge collapse thing, there is a seemingly unused effect file with an explosion that seems to run in a line, and it looks like pieces of wood are flying away from it....

Makes you wonder what they originally had planned for Zirekile, eh?

or it could have been a second go around like when delita and ovelia are at the falls once again

In case you haven't been following the Editing Maps thread, I posted mapsplit and mapjoin (http://www.ffhacktics.com/forum/viewtopic.php?p=24875#24875) there. These utilities let you split a map file up into pieces, edit the pieces (with a hex editor), and then recombine them into a map file that should work in the game.

3-4 hours later and the first bit of progress towards "completing" a map has been made. I basically just completed the bit of wall that Gomtuu started on with his initial preview. In game testing will occur next.

can you highlight the new part?

wow, its missing alot more walls than i thought. im excited to see it completed

thats a pretty nice map

I haven't had much time to code this week, but I've been working on mapsplit when I can. I think I might rename it, because instead of just chopping a map file into pieces, it's going to produce a single human-readable file that you can edit in a text editor. Then, it'll read that file and build a usable map file out of it.

It's probably still going to be a few more days until I get it all working, but here's a sample of the output it generates now for the primary mesh chunk:

# Format:
#           [ # Description of polygon (optional)
#               [(   Ax,    Ay,    Az), (   Bx,    By,    Bz), (   Cx,    Cy,    Cz)], # XYZ coordiantes
#               [(   Ax,    Ay,    Az), (   Bx,    By,    Bz), (   Cx,    Cy,    Cz)], # Normal vectors
#               [( Au,  Av), ( Bu,  Bv), ( Cu,  Cv), palette, page, (unknown)], # Texture data
#               (  X,   Z) # Terrain tile location
#           ],
            [ # Textured triangle 0 near terrain coord (2, 11, 12)
                [(   84,  -144,   336), (   56,  -144,   336), (   56,  -132,   336)],
                [(-2191, -1445,  3144), (-1120, -1030,  3803), (-1663, -1097,  3579)],
                [(168, 227), (187, 227), (187, 238), 11, 3, (0, 120, 3, 0)],
                (255, 254)
            ],
            [ # Textured triangle 1 near terrain coord (4, 2, 1)
                [(  112,   -36,    56), (  112,   -24,    28), (  112,   -24,    56)],
                [(-3408, -2088,  -895), (-1008, -3950,  -397), (-2896, -2896,     0)],
                [(148, 238), (167, 247), (148, 247), 1, 1, (0, 120, 3, 0)],
                (255, 254)
            ],
            [ # Textured triangle 2 near terrain coord (7, 4, 10)
                [(  196,   -48,   280), (  196,   -48,   294), (  210,   -48,   280)],
                [(    0, -2896, -2896), (-2568, -3009, -1064), ( -975, -1379, -3732)],
                [(168,  77), (168,  68), (177,  77), 1, 2, (0, 120, 3, 0)],
                (255, 254)
            ],

Oh so excellent Gomtuu great work. It is basically a map decompiler and compiler now. All that information there is detailed while not cluttered. Plus no more hex coordinate values! This should make is pretty easy for anyone to do this stuff after reading the info you have on the Wiki. Keep it up!

I found this online Isometric Pixel art tool the other day while looking for pixel art tutorials.

http://www.halfshag.com/iso/ (http://www.halfshag.com/iso/)

Probably impossible, but it would make for an amazing interface if we could design maps with something like this. Though right now I am just so totally pumped to this update to the splitter/joiner.

Just so everyone knows, I'm still really excited about an update to this .

I don't know if anyone has posted this but it looks like a japanese person trying to accomplish the same thing...

http://74.125.95.100/translate_c?hl=en& ... YpHTyqQ1XQ (http://74.125.95.100/translate_c?hl=en&sl=ja&tl=en&u=http://members.at.infoseek.co.jp/pearlstar/astraea/readme.txt&usg=ALkJrhiNL8y9jOmAV4UGdrJxYpHTyqQ1XQ)

The whole site is pretty interesting actually.

http://74.125.95.100/translate_c?hl=en& ... HDDQYR-hEQ (http://74.125.95.100/translate_c?hl=en&sl=ja&tl=en&u=http://members.at.infoseek.co.jp/pearlstar/index.html&usg=ALkJrhh-QBwQMXpGhSsikyrSHDDQYR-hEQ)

yess! with my new pc i can actually use this program. only thing now is it doesn't help me fix Lesalia's maps or turn DD into lava

interesting read cidIII

At Germinas Peak, given X, Y, and level value :
X = 5, Y = 0, level = 0 the terrain is Grassland and the geomancer effect is Hell Ivy.

Do you know where the the following variables are stored in memory ?
- Terrain type ("Wooden Floor", "Grassland")
- Geomancer effect (Hell Ivy, Demon Fire)
- Height (5h, 0.5h)
- Weather effect (rain, thunderstorms, snowstorms, day, night)

I need this information for movement abilities hack.

(http://img155.imageshack.us/img155/1357/geomancer2ml2.png) (http://img155.imageshack.us/img155/7351/geomancer1mn7.png)

Razele

I can give you where that information is held in the map files, but i dont know the offset for it in memory...
if zodiac knows where the ranges are, such as battle.bin is x address - y address is in the RAM, then i can easily tell you

The information in map files is enough, for Germinas Peak map.
I can search it in the memory based on map files structure.

I can't run gomtuu's mapviewer, since my VGA card is too old, and updating the driver with the official one reduce my Windows' color from 32 bits to 256 colors.

Fair enough Razele, ill get them for you shortly after i come home.

The mapviewer wont give you the bytes you need to search for anyway(not even in command prompt), youd still have to open the file and know where to look.

QuoteFair enough Razele, ill get them for you shortly after i come home.

The mapviewer wont give you the bytes you need to search for anyway(not even in command prompt), youd still have to open the file and know where to look

Thanks, but no need to search that information anymore in memory.
Gomtuu already explained most of the map's properties to me, so I learned a lot from him.

Thanks to Gomtuu's help, I know how to change the map's properties in real time :
(http://img17.imageshack.us/img17/7231/map01.png) (http://img511.imageshack.us/img511/6614/map02.png) (http://img27.imageshack.us/img27/7397/map03.png)

Wow razele, if you come up helping for the map editor, il trow a huge party for you.

Wow this is really awesome stuff, definitely could be put to very good use. Any chance of finding a way to change the weather, or raise the water level of a map midbattle?

I haven't checked how they store the weather in-game.
Gomtuu said it's not stored in the map file.

I change that map properties in psx memory, so it's possible to raise the water level.
Well, actually, it's "possible" to make some abilities like Shiva to freeze Water area to Ice, Leviathan to splash water in battlefield, or Ifrit change Grassland to Desert.

There is Ice? Splashing water!? So freaking sweet. You show me a vid of a laviathan spell raising the water level of a map and I will...go nuts.

Quote from: "Razele"I haven't checked how they store the weather in-game.
Gomtuu said it's not stored in the map file.

I change that map properties in psx memory, so it's possible to raise the water level.
Well, actually, it's "possible" to make some abilities like Shiva to freeze Water area to Ice, Leviathan to splash water in battlefield, or Ifrit change Grassland to Desert.

Wha, wha! That would be amazing!

That is pretty exciting! I didn't realize you were going for in-game map manipulation.

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

Well Gomtuu I have been trying to change the map field colors (what you call ambient light color) and the background colors of a map using event instruction, but they get reset to the default if a spell is used that changes these and I loose my cool mood lighting. So I'm thinking that I am going to need to edit the colors for the actual map and change the defaults to have my changes be permanent. So I have two question:
1) I understand that ambient light color changes the color of the physical map, but does it also change the color of the units? Because for events this is done separately and I'm not seeing anything in your descriptions that would mirror this.
2) Any chance of you releasing a new version of mapsplit soon so that I'm don't split open my head with all this hex and crazy decoding? Plus I tried using mapslit recently and it just gave me grabbled text for some reason and I haven't gotten it working right yet.

Quote from: "Cheetah"1) I understand that ambient light color changes the color of the physical map, but does it also change the color of the units? Because for events this is done separately and I'm not seeing anything in your descriptions that would mirror this.

I think the map's lighting probably affects how characters are lit too, but I'm not sure off the top of my head. It's been a while since I experimented with those variables. You might have to change not just the ambient light, but the directional lights as well.

Quote from: "Cheetah"2) Any chance of you releasing a new version of mapsplit soon so that I'm don't split open my head with all this hex and crazy decoding? Plus I tried using mapslit recently and it just gave me grabbled text for some reason and I haven't gotten it working right yet.

Actually, just yesterday I started working on a visual map editor. It's still very early (doesn't even load or display maps yet) and I don't know how long it'll take before it's usable, but I am trying!

As for mapsplit, can you PM me a screenshot or something of what it's doing?

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 (http://www.ffhacktics.com/wiki/Maps/Mesh#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?

(http://www.ffodyssey.com/fft/fft_10.jpg)(http://www.ffodyssey.com/fft/fft_08.jpg)

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

Yeah I have definitely seen these before. I found some others at rpgamer.com, where did you find these. They are mostly from the original Japanese trailer. There is also a clip of Orbonne Monastery with a freaking high bridge that looks cool, and another map with a small building surrounded by trees. Recreating these maps would be super cool. Though like you said the Zirekile Falls one is basically identical layout-wise and just looks worse.

So I decided to use the online isometric graphics program that I posted about earlier to make the map I sketched up. Pretty quick and easy tool to use. Obviously I couldn't get the dimensions and angles all that exact, but it is a good 3D representation of what I'm going for. Really I just miss Gomtuu and wished that this thread had a bit more activity...or any activity.

It looks frickin' awesome. I wish there was more activity on this front, too.

Has anyone been able to get Gomtuu's viewer to work on WoTL maps?  Or does it only work on PSX ones?

The maps are all the same to my knowledge, though I haven't tried.

Quote from: "Tersius"Has anyone been able to get Gomtuu's viewer to work on WoTL maps?  Or does it only work on PSX ones?

My viewer only works on PSX maps for now, but the map formats are not very different. If I remember correctly, the GNS files were the only ones that would cause trouble, and the difference was minor. Instead of referring to files by the sector number where they could be found on the PSX CD, the PSP GNS files just numbered the files sequentially or something.

I didn't go through all the posts but just wondering, are we able to make custom maps and put them into game?

Not yet :D)

Actually you can, it is just exceptionally difficult. Gomtuu as essentially decoded all the vital information and created tools, it is just very complicated.

Ah, I see. That map viewer tool?

The tool that actually allows you to edit stuff is the map slit/join tool. Divides all the parts of the maps into editable understandable chunks.

Hmm...I see. So does that mean we can edit a few things in the map and just load it in the game? Or it doesn't work like that? Anyway, after reading a few posts, I think I better don't mess with maps because I don't understand a thing.

What's going on Tactics hackers?

I havn't been on FFT since fftactics.org disappeared so I though people lost interest in hacking it.

And behold, people are making more progress than ever before here.

Awhile ago I did a map viewer based off the findings of the FFT Monkeys group, and at the time there was very little information on anything but the visual parts of the maps (Rendering, etc). Is there a forum post with more discovered info? I'm sure if there's enough someone could make a 3D model -> FFT Map converter pretty easily and people could make maps in 3D Studio. I could even take a crack at it if there's still interest and enough info to go around.

Welcome, here is the info you need. Gomtuu our map expert and coder actual made a custom map editor.

Info: http://www.ffhacktics.com/wiki/Maps (http://www.ffhacktics.com/wiki/Maps)

Map Editor: viewtopic.php?f=3&t=2479&start=0 (http://www.ffhacktics.com/forum/viewtopic.php?f=3&t=2479&start=0)

If you wanted to contribute to the editor that would be amazing.