Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - JeMaCheHi

Pages: [1]
Cactilio (the Spanish name for Cactuar) is a little program to edit the battles structure on FF8. It's the first time I code a GUI program so... be comprehensive ah?  ;D Also, any advice/constructive criticism will be appreciated.

  How to use it:

  • Extract the scene.out file from battle.fs. I recommend using myst6re's Deling:
  • Open Cactilio, go to File->Open and select your scene.out file.
  • Select an encounter number and hit the "Load" button. You won't be able to modify anything until you load an encounter. When you want to switch to another encounter, you'll have to select it and hit the Load button again.
  • If you want to modify an enemy parameter, you have to select its index on the left part of the application. Once you've done it you can start modifying that enemy's stuff.
  • When you're done with your changes, just go to File->Save and save your file, but DON'T JUST OVERWRITE THE OLD ONE, sometimes you can mess up things when editing the scene.out file and if you overwrite the previous one... well, you know what will happen : /

  • Implement the ability to edit the battle.fs file directly
  • Continue researching the scene.out unknowns
  • Improve the stages name list
  • Improve the GUI
  • Probably more stuff I'm leaving on the way...
If you don't understand something about how scene.out works, you should take a look at this links:
Thanks to kaspar01, who made a list of stage name which was very useful:
Thanks also to myst6re, whose src from Deling was very useful when I felt lostwith Qt.

  Improved GUI
  Fixed enemy coordinates. Now you can set them from -32768 to 32767, a more logical range.
  Fixed some stage names (to be honest, don't even remember which ones...)
  Initial release

Download Cactilio v0.2
Github page here

Tonberry: Enhanced v2.04 by JeMaCheHi and mavirick
External Texture Support for Final Fantasy VIII
*Beta version, please let me know if there is something preventing you from using it


Hello! (I'll borrow Omzy's header, hope you don't mind bro :D )

Broken cache fixed!
I've been working Mavirick and I have been working on an enhanced version of Tonberry, as many of you would know from its original thread. You should check Omzy's original post to learn about its functioning.

What's new?:

  • Persistent textures - modders now have the ability to designate textures as "persistent," meaning they will never be removed from the cache. This feature should be used primarily for the core textures, such as those replaced by SeeDReborn.
    • To mark a persistent texture, simply precede the name of the texture with a bang/exclamation mark (!) in the relevant hashmap or objmap .csv. For example:
      • !sysfld00_13,8637763346649579509
    • Please be aware that filling the cache with persistent textures will lock it in place and all subsequent textures will fail to be replaced, so use this feature with discretion.
  • Significant performance improvements - although dampened in part by the increased complexity of the persistent textures, Tonberry should be running faster than ever due to some major cache optimizations and an improvement to the way we handle the core (SeeDReborn) textures.
  • No hard limits on cache_size - the cache size no longer has a hard minimum size of 100. You can now set it to 0 to disable the cache and texture replacements altogether, although Tonberry will still be touching each in-game texture and checking for replacements (that never exist). This feature should be entirely ignored by average players but could be helpful for modders. Note that you can also set your cache_size too high and cause memory overflow exceptions! If you do not have LargeAddressAware enabled for your FF8 executable, your cache_size should be no larger than 250.
  • Actually disabled textures - before, textures that were disabled with a star/asterisk (*) were not handled any differently; Tonberry would simply fail to load the replacement texture when it looked for a .png file beginning with the asterisk character. Now these textures are actually excluded from the internal hashmap, which should yield a slight increase in performance and keep these textures out of your \tonberry\debug\noreplace folder. If for some reason you want these textures to show up in your debug\noreplace folder, simply change the asterisk to any other character--just so long as the texture name in the .csv does not match any file in your \textures folder.
  • 2.02 broke collision resolution--textures from the collisions.csv hashmap were not properly stored in the cache, which caused bad replacements and glitching textures especially on loading screens and in menus; this issue is resolved
  • We fixed the little issue with debug folders. Now unsupported textures will be on "unsupported" folder.
  • Even more code optimizations!! We love code optimizations ;)
  • Caching system fixed (now it really works, I swear it!)
  • More code optimizations (as usual  ;) )
  • Completely redone texture caching system
  • New option added to prefs.txt(cache_size) to set the maximum cache size
  • New option added to prefs.txt(texture_dir) to change textures directory
  • Lots of code optimizations
  • Better objmap organization
  • Source code tweaks. Hashcode searching should go a little faster now
  • New option added to prefs.txt(debug_mode) and comments
  • Better hashmap organization
  • Some compilation tweaks which should make Tonberry run smoother
For now there's no much done, actually I didn't want to release anything until I had something more, but Mcindus convinced me to do it :-[ . Due to recent mods have been more and more numerous, I thought this simple update will make our lifes easier when it comes to modify your hash1map.csv file.
Now we have redone the whole caching of textures, this is gonna run with no sweat. Most of you will be able to run animated textures smoothly. We've added the possibility to change the path where the "textures" folder is stored, so you can place it on an SSD drive for even more speed. You can also tweak the cache size to fit your needs. Just refer to the prefs.txt file on "tonberry" folder for more info.
Next step: new hashing algorithm, and potentially zero collisions.


Download v1.6
Download v1.61
Download v2.01
Download v2.02
Download v2.03
Download v2.04

This is how it works:
  • We now have two new set of folders: { [your FF8 directory]/tonberry/hashmap and [your FF8 directory]/tonberry/hashmap/disabled }and { [your FF8 directory]/tonberry/objmap and [your FF8 directory]/tonberry/objmap/disabled }
  • In that "hashmap" folder you can put a set of *.csv files, with hashes that previously was at hash1map.csv
  • In that "objmap" folder you can put a set of *.csv file, with the previously set at objmap.csv
  • You should create a different .csv file for each mod hashes. You can name them as you like, but make sure they have *.csv extesion

Which advantages provide us this new directory system?

  • We now can release mods directly with its .csv file, just ready for copy-paste and make it work. Plug and play!
  • We can obviously split the "hash1map.csv" file into smaller ones.
  • We won't have to deal with the old massive "hash1map.csv" file, we won't have to look for duplicated hashes... etc.
  • We can disable certain mods by just by moving its csv file to the "disabled" folder.
It's fairly similar to Tonberry's previous versions
  • Install VC++ 2010 Redistributable (x86)
  • Extract directly into your FF8 directory (I'll call it [FF8Folder] from here)
  • Copy all your hash files to [FF8Folder]/tonberry/hashmap folder
  • Copy all your obj hash files to [FF8Folder]/tonberry/objmap folder
  • Copy the rest of .csv files (collisions.csv and hash2map.csv) in "[FF8Folder]/tonberry" folder (Thanks Mcindus for pointing it out)
  • Download and copy the corresponding textures to [FF8Folder]/textures (on its propper directories, off course!)
  • Check the prefs.txt file for configuring your particular Tonberry instalation. You will find instructions on it!
Hashmap files collected by Mcindus:

Just put these in (/steamapps/common/FINAL FANTASY VIII/tonberry/hashmap)

Project Eden
SeeD Reborn (English)
SeeD Reborn (Spanish)
SeeD Reborn (French)
SeeD Reborn (German)
Tripod (English)
Tripod (Spanish)
Tripod (German)

Other hashmaps:
Project Hellfire  G.F. Summons hashmap

**EDIT 2/20/2015**
The hashmaps to SeeD Reborn and Tripod have been updated! These updates should fix any current missing textures issue!
Spanish and French SeeD Reborn versions added!
Spanish and German Tripod versions added!

To-do list:
  • Improving the hashing algorithm to be faster
  • Reducing collisions to zero (or nearly zero) with a new hashing algorithm
  • Redesigning the texture caching system to greatly speedup the whole system
  • Take a new approach in handling native game's textures so we can separately use 128x128 texture objects
  • To provide a better debug system, instead dumping the textures by random numbers.
Known issues:
  • The game crashes when using Squall's limit breaks around some enemies (especially Tonberry in the Centra Ruins) while both RebirthFlame and LunarCry are enabled. Fixed...? I have not been able to replicate this crash since using 2.04. While I never isolated the cause of the crash in earlier versions, I believe 2.04 to have fixed the problem. If this is not the case, please let me know.
  • If the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. Fixed! The persistent textures feature should allow these textures to be kept in the cache indefinitely (see "What's new?").
  • Some users are experiencing random crashes when using Tonberry with Project Eden. If you are having this or any other issue please post here with details so I can look into it. Until more is known about the crash, my best advice would be to save frequently. Fixed! This exception was caused by memory overflow errors; make sure your cache_size in \tonberry\prefs.txt is 250 or less.
  • The overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration.
If someone is having trouble with it, please post it here and we will try to resolve it.

Thanks to Mcindus for helping me with the testing and...
Thanks Mavirick for your interest and helping with the new hashing algorithm joining the development!
Thank you Omzy for making original Tonberry, changing FF8 graphical modding forever

An important note from Omzy:
*For future modders who are hashing textures, please keep or upload a copy of the debug output textures themselves. If the hash algorithms change, this hashing will have to be re-done and it will be much easier if we have all of the original dumps.*

Hi everyone!

I've been making a little research on FF8's scene.out file for the last few days, and wanted to share with you my findings. I will update the thread with any new info I get. Also, since any of this information is on the wiki, it would be cool if someone puts it in there (I think I cant).

First of all, I wanted to thank to random_npc, because I read on a post of him that scene.out contained enemy encounters and that they was stored in 128byte blocks, which was very helpful. From there, here are my findings:

  • scene.out doesn't have header, which means that first line is first encounter.
  • As said before, each 128 byte block is an encounter (we'll call them that way from here), and file has 131072bytes, so there are 1024 encounters. A lot of them are not used in the game (when I say a lot a mean A LOT), so in a future mod, many new encounters could be programmed
  • Each encounter can have up to 8 enemies, but if more than 4 are shown at the same time, the game will crash. This could seem stupid, but it's not. If you think about some battles, like final battle (where we have 8 enemies), they are be shown scriptedly, it takes more sense
  • Each encounter has a clearly defined structure: first 8 bytes controls global aspects of the encounter, and the 120 remaining ones controls features relative to each enemy.
  • Each encounter has two cameras for the begining animation. The game will use one of them randomly, but I checked experimentally that the game will pick the first camera most of the times (for each 5 battles, the game will use the first camera around 4 times). That's why I called the first one "Main camera" and the second one will be the "Secondary camera".

Encounter Structure

As told you before, each 128byte block (from now on we'll simply call it "encounter"), has a defined structure. Each section from the 8th(included) refers to each one of the eight enemies defined. In other words, is divided in eight sub-blocks or "slots".

Here's what I have:

0x001Section 1: Battle scenario. The value here corresponds to the number in the a0stg???.x files (into battle.fs file). You have to convert it to hex
0x011Section 2: Flags to configure some battle parameters and it works like 8 binary flags (see below)
0x021Section 3: Main camera animation.  This is for the battle entrance animation (when the party and the monsters appear). (See below about cameras)
0x031Section 4: Secondary camera. Works exactly the same as the main camera, but this one will be used less frecuently.(See below about cameras)
0x041Section 5: Hidden enemies. Hides an enemy for each bit in the byte.  Also works like 8 binary  flags. An activated flag means that this enemy is hidden (see below for "enemy flags")
0x051Section 6: Not Loaded enemies. Show the enemies that are been actually fought. Loaded enemies will attack you. You can attack them, though. Also works like 8 flags. An activated flag means that this enemy is not loaded.(see below for "enemy flags")
0x061Section 7: Not Targetable enemies. Show the enemies which will apear in the target window. Careful with this, if you put untargetable enemies battle will never end. Also, loaded enemies will attack you even if they are not targetable, so be careful again. Once more, this section works like 8 binary flags. An activated flag mean that this enemy is not targetable. (see "enemy switches" too)
0x071Section 8: Enabled enemies. This section will specify which enemies will be loaded at the begining of the battle. Even if there's only 1 or 2 enemies, you can enable more enemies through enemy AI scripting(See this video to see what I mean). Also works like eight binary flags. An activated flag means that the enemy is enabled. If an enemy is not enabled, the 3 previous sections will be ignored. See below for enemy flags.
0x0848Section 9: Enemy coordinates. Its a set of 6x8 bytes which describes each enemy's coordinate in (x,y,z) format. So, first 6 bytes would be enemy 1's coords, next 6 enemy 2's ones, and so on.
0x388Section 10: Enemies. Each byte represents an enemy. To know what enemy you're working with, you can check the c0m???.dat files in battle.fs. You just have to convert it to hex and add 0x10. Be careful, if you put numbers under 0x10 as enemies, battle will crash.
0x4016Section 11: Still under research.A certain enemy also has always the same value, and some of this values can be repeated between enemies. Slots with no enemies always have the value 0x00C81
0x5016Section 12: Still under research. A certain enemy also has always the same value. Slots with no enemies always have the value 0x00C81
0x6016Section 13: Still under research too. For a certain enemy has always the same value but different from section 12 and 13. Slots with no enemies always have the value 0xEA60
0x708Section 14: This is enemy relative, a certain enemy always have a certain value, e.g. Bite Bug always have 4B. There's only a few values used here: 38 91 0A 64 C8 2D 7B 4A 34 01 4B 02(when an enemy's not used), however setting it to any other value seems to do nothing.
0x788Section 15: Enemy level. Each enemy level is 1 byte. Numbers from 0x0 to 0x64 are fixed levels up to 100. From 0x64 to 0xFF... Still don't know because it makes weird things...
1: 0xC8 is the code to target self in AI script code for enemies. I wonder if this has some kind of relationship... I'll keep searching.

About binary/enemy flags.

Sections 2, 5, 6, 7, and 8 works as binary flags. This means that each bit enables/disables something. When the bit is 1 it means the flag is enabled. When is 0, the flag is disabled. Since the 8 flags forms a Byte, I'll list in form of hex sums, from Most Significant Bit to Less Significant Bit:

For battle configuration (Section 2):
   +0x80: Not random fight. Every scripted battle has this one enabled.
   +0x40: Force back attack (you will be back attacked, not the enemy xD).
   +0x20: Force surprise attack (as before, you are the one surprise attacked)
   +0x10: Doesn't show exp screen at end.
   +0x08: If you set this one up not exp will be gained at the end of battle (like in boss battles)
   +0x04: Shows the timer. Like in dollet withdraw combats.
   +0x02: Can't figure it out. Some boss battles have it enabled but don't know its functionI'm stupid. This disables victory sequence.
   +0x01: Can't escape.

For Sections 5,6,7 and 8:
   +0x80: 1st enemy flag
   +0x40: 2nd enemy flag
   +0x20: 3rd enemy flag
   +0x10: 4th enemy flag
   +0x08: 5th enemy flag
   +0x04: 6th enemy flag
   +0x02: 7th enemy flag
   +0x01: 8th enemy flag

About cameras.

Each encounter has two cameras, as explained above. Each camera is represented by a byte, but each byte stores two things: The camera number, and the camera animation. The camera number is stored on the most significant nibble of the byte (4 bits) and the animation is stored on the less significant nibble of the byte. I called it "Camera number" because I had to name it somehow, but I'm not even sure if they're different cameras, or just are "sets" of animations. Anyway, we'll call it that way until we find a better one. Also, a few considerations about these camera parameters:

  • Camera number. It can take values from 0 to 3. The original scene.out never has greater values. Values greater than 3 will result in no camera animations, having a fixed camera. Some stages have less than 3 camera numbers. This leads me to think that this camera stuff is really stored on .x files, and this values are just pointers, or indexes, or something of the kind.
  • Camera animation. It can take values from 0 to 7. The original scene.out never has greater values. Values higher than that will result in the same as that value minus 8. This is because the last bit of the nibble is ignored (still don't know why). Sometimes the camera has less animations than 7. In that case, if you use a number greater than actual animations, taking into account that the 4th bit is ignored, will result in a fixed scene.

An important note: If you put an enemy that "summons" another one (Ultimecia summoning Griever, Sphinxara summoning jelleye...) it will summon the enemy from certain slot. This means that if you put that enemy in another battle, it will still summon that slot, because (I think can confirm)  that summoning is scripted in its AI (in c9m???.dat) as an enemy ability.

I've also made a C++ class that stores a chosen encounter from the scene.out file. I've implemented a little command line program to see info and change some things, but since I don't know anything about GUI programming and interacting with a cli program will be pretty tedious, I think I'll stop developing it xD.

Well, I'll update this thread with my findngs. Also, any help will be appreciated :D

Update: Some pics to show up!

You can put any enemy you want:

However, sometimes enemy palletes could crash. Also, you should be careful with certain enemies like GF's or bosses as Seifer because when killed, they won't dissapear, fade out, or run away.

Encounter list

A guy from gamefaqs called aladore384 made a pretty complete list of every encounter. Since it's very useful, I'll post it here. To edit a certain encounter in the scene.out, all you have to do is to get its encounter number, convert it to hex, and multiply it per 0x80, and you'll get the offset.
For example, lets say you want to edit Omega Weapon encounter:
  • You find its number in the list: 462.
  • Now you convert it: 462 = 0x1CE
  • Multiply it for 0x80: 0x1CE*0x80 = 0xE700
  • That's the offset you have to search for in the scene.out :D

Update July 2015
Sections are updated with my new findings, flag stuff are (I think) better exlained, and I started developing developed a GUI tool to modify the scene.out without all the hex pain.
Link to the tool thread:

Completely Unrelated / Inserting tables on a post?
« on: 2014-12-02 11:00:57 »
Hi everyone. I was writing a long post and wanted to put a table on it, but since WYSIWYG editor doesn't provide a button to do it, I directly writed the code for making it. However, it's still not showing up. There's no way to show a table in this forum...?

General Discussion / Old FF8 Trailer
« on: 2014-08-04 20:08:13 »
Hey look at this guys! I found an old trailer for FF8 on youtube. There's a lot of curious scenes in it  :o

Did you know it? It was rinoa to be a SeeD too? Or it wasn't the escape supposed to be in the SeeD exam?

Hurry up guys! We have that two games on for 6,50€ ($8,7). If you haven't one of them or the two, it's your chance! The offer will expire in 6 and half an hour from now!

Gameplay / [FF8] View/edit/adding battlefields/encounters
« on: 2014-07-18 16:01:56 »
Hi there everyone. After a closest read to the wiki, play with scripting, opcodes, and learning some files's internal structure, I'm wondering if could be posible to edit the battlefields. And, by battlefields I mean the encounter itself. For example, changing the background, or grouping some enemies that aren't in the original files.

I've also seen in the wiki that RAT and MRT stores that kind of data, however I can't find those files anywhere in game's data. Anyone knows where are them? I'd like to take a closest look at them, because, for battle formation, the only info the wiki gives is "MRT file contains 4 * two bytes. Each two bytes is a battle formation ID. ", but I'm not looking for it's IDs, but the formation itself. I also suspect that *.x files could be some relation to this. I do not know how to find out it, though

Any help will be appreciated. Thanks in advance guys!

Troubleshooting / [FF8] Steam and original PC differences?
« on: 2014-07-15 12:47:47 »
Hi everyone. First of all, I wasn't sure about where to put this, so I did it here after all. Please move it where it proceeds if needed. Now I go with my question:

I want to learn about FF8 and I've been reading in the wiki, but now I'm noticing that there's no differenciation between original and steam version. For example in the data file format article, there's the three types fl, fs, and fi, but nothing about different versions are told.

I know that Steam version is a direct port from the original with some additions, but not sure about how different they are. I mean, the files seems to be the same, and some mods that worked with the original will do with the Steam, but others won't.

I'm not very sure about how to check this, and I'd really appreciate if someone could point me in the right direction.

Thanks in advance!

Pages: [1]