FF6 Steam Version

I can't deny the fact that... yes that is very cool. Not to mention the fact that being PC based should allow for, well unlimited modding/hacking. (Basing this on the concept that by running on a PC it shouldn't have a hardware enforced upper limit, might have to be reprogrammed to use more hardware resources but shouldn't be a limit.) Hell, worst case could even go the "trainer" route, running another .exe to make even more things possible. There even exsist the possibility of going to the extreme and writing a whole new exe that loads the files (I did say extreme) which would literally enable anything to be done.

I didn't say simple or practical, just basing this on the flexibility of PC game modding in general. Thefact that the data is already partially mapped out because of the porting process changing so little just means the door to hacking it is already wide open. Nobody has to crawl in through the window first to unlock it from the inside.

On the other hand, this is about the same concept as the "FF6 SDK" project (actually, in the wide scope, probably even less limited that THAT project as well).

All that being said, here is what gets me: Do we really know the actual limit of the SNES version?

"We" being the community as a whole. Now yeah, you can call me flat out stubborn, maybe just old, but I know we haven't. Sure, there are limits, but I keep getting the feeling every one of them can be busted. In no way easier to do than if working with a PC version, but damn it! It can be done! ...

Okay really it just keeps pissing me off, every time I start going through the processes (snes version) and I know the answer, its right there on the edge of clear thought... then I lose it and end up with a basket full of dead ends. This part is hard to explain, and probably makes no sence in reading it, but it's true I tell ya!

The actual point to all my rambling is, I still want to know just how damn far the SNES system can be pushed. Sure, if someone had a full plan for a hack (the final product of the RotDS project for example) then sure, PC version might be the way to go because you wouldn't have to work around as many restrictions to get your final product. On the other side of things, I just happen to still be more interested in how far it can go on the snes base. Sure the kinda things I'm talking about (if completed) would almost make the SNES version, not an snes game anymore but I still know its possible.

So... yeah, PC version = Open doors. At the same time, I still get my jolly seeing all the walls knocked down on the SNES. Personal preferance I guess, but come on. What is really more fun/satisfing? Picking a weak lock and walking through a door, or busting through a brick wall, incredible Hulk style?

I think practically the SNES version is the most moddable. As for its limits, stuff like VRAM is already pushed to a certain limit in general. Some stuff can still be expanded with proper tools (example FF6LE+) but at the same time if you want heavy changes you have to be able to rewrite larges portions of sometime obscure code and maybe modify code new tools.

The PC version might have certain limits the SNES version has since it seems to relies heavily of the original data structure. Little to nothing is know about its code also.

That been said even if there was a PS4 remake nothing stops you of trying to test new boundaries on the SNES version. There's no comparison to do, everyone gets his satisfaction from something different, me it's in general tools development and coding, which the PC version (and still the SNES one) offer great opportunities.

For sure, as you said, gotta do what you enjoy.

Course, as far as the tool making concept goes, (again my personal opinion) more versitile tools are always a winner. Regardless of how you look at it. Granted, for the most part, the tools we have now cover just about everything you could expect a tool to do (most things not tool-editable at this point are just way to versitile to program, events for instance.)

As I've said before, tools that are more hack friendly and versitile, always kickass. Verse most tools on the self now that can't handle fairly basic hex edits without breaking the tool. On that subject (if the PC version really is that close in data structure, an editor that was versitile enough to edit all (or at least several different versions) would seriously kickass, epic without doubt. Pipe dream maybe, but come on, standardized tools? Switch versions without having to learn new tools...

Back on topic, can't argue with the greatness of molesting a PC version of the game without having to relearn everything from scratch. Course, one of the reasons snes is popular is because its easy to get started. Tools that even a 10 year old can learn to use, resulting in the desire to learn hex (even to a minor extent) when they hit the limits off the tools. While the PC version may be easier to make advanced changes, the "gateway" drugs aren't there to get a person hooked.

BUT, there is something else to look at, even if the PC game itself doesn't tickle your fancy. There are alot of PC game modders out there that have never touched a ROM. New ideas in the pool, maybe even mods that can be converted over to SNES versions. Not likely but possible sure.

I've got to stop trying to make post while I'm half asleep. Way to much rambling. Last comment though, I still get the feeling there is a way around vram. The SNES is just to versitile overall, combine that with emulation methods. Yeah there has to be a way to "fix" it.

All said and done, still good to hear of progress being made. Doesn't matter what the final result is, don't see it being bad in any form.

I worked a bit on the rom.bin map (literaly a GBA JAP version map). Thank to Drakkhen for some entries as his contribution is about 50%.

U = untested
T = successfully tested
F = Testing did no change in game (failure) <- nothing so far
DAT = Data
PTR = Pointers
MAP = Map related data

Code:

520000-53B3E7  U MAP    Location Tile Assembly (Variable * 76 entries)
53B3E8-53B4CB  U PTR    Pointers to Location Tile Assembly (3 bytes each * 76 entries)
548446-58B274* U MAP    Location Map Data (Variable * 351 entries*) *SNES data, probably different considering Dragon's Den map(s)    
5F589A-5F58EF  U MAP    Pointers to Location Tile Properties (2 bytes * 43 entries)
5F5EF0-5F6231  U PTR    Map event triggers pointers (2 bytes each * 417 entries) point to a map?
5F6232-5F78ED* U DAT    Event triggers (5 bytes each) *Potential Ending of data according to data format
5F78EE-5F7C3B  U DAT    Monster Sketch Commands (2 bytes * 423 entries)
5FCE18-5FD017  U DAT    Monster Rage Commands (2 bytes * 384 entries)
61B928-61C33B  U DAT    Monster Formation Auxiliary Data (4 bytes each * 645 entries)
61C33C-61E906  U DAT    Monster Formation Data (15 bytes each * 645 entries)
62A000-62A47F  U DAT    Shop Data (9 bytes each * 128 entries)
62A480-62A5D4  U DAT    Esper Data (11 bytes each * 31 entries)
62A618-62AA53  U DAT    Colosseum Battle Data (4 bytes * 271 entries)
62ACAC-62B22A  T DAT    Character Initial Statistics (22 bytes * 64 entries)
62B61C-62BC33  T DAT    Chest data (5 bytes each * 312 entries)
62BC34-62CC1D  U DAT    Magic Data (14 bytes each * 291 entries)
62CC64-62EC25  U DAT    Item Data, regrouping weapon, armors, relic, etc.. (30 bytes each * 270 entries)
679800-679873  U PTR    Pointers to Battle Event Scripts (2 bytes each * 58 entries)
679874-679CFF* U DAT    Battle events scripts (*approximate ending according to last pointer and following data in SNES ROM).
6E1880-        U MAP    Location Properties (417+ elements, 33 bytes each)
711190-71198F  U DAT    Assigment of monsters formations (8 byes each * 256 entries)
71BB9C-71C238  U DAT    Monster item stolen / dropped (4 bytes each * 423 entries)
71D34C-71D68D  U PTR    NPC data pointers (2 bytes each * 417 entries) -> point to a map?
71D68E-7223A7* U DAT    NPC data (9 bytes each, 2193+ entries) -> *Ending offset of SNES data
726B86-727221  U DAT    Monster control commands (4 bytes each * 423 entries)
727FD8-728325  U PTR    AI Script Pointers (2 bytes  * 423 entries)
735A82-735E9F  U PTR    Pointers to Entrance Triggers (2 bytes * 527 entries?) -> some unused ones at end of data?
735EA0-737915* U DAT    Entrance Triggers (6 bytes each) *End of SNES data
728326-72C9E7  T DAT    Monster AI (423 entries)
7379A6-73AE86  T DAT    Monster stats (32 bytes each * 423 entries)
75BDFC-75E247  U MAP    Location Tile Properties (Variable * 43 entries)
79F400-79F5FF  U DAT    Magic Points Earned per Monster Formation (1 byte * 512 entries)
7A0000-7E90FA  T DAT    Events
7FF88E-7FFBF1  U DAT    Monster Event Formation Packs (4 bytes * 217 entries)

I added FFVI Explore 0.3 to the tools page. I'll add any PC version tool here (with author permission).

For existing mods you can visit this page: http://steamcommunity.com/sharedfiles/fi...=591798883
To participate in steam version modding discussions or just lurk, it's here: http://steamcommunity.com/groups/ff-modd...ssions/10/

Nyxo's twitter account: https://twitter.com/rivernyxx

On a side note the game exe can be decompiled in C with utilities like IDA Pro (paid utility but you know, to*r*nt*) . The exe manage everything UI, sound and graphics related and *possibly* game logic (example, the equivalent of bank C2 for combat system). There are hundreads of calls in the exe to the rom file that Nyxo is trying to identify. I've looked at the code but it's a bit hard to understand, less than an uncommented ASM disassembly though.

Eventually when we get a general data editor and subsequently an event editor and map editor, I might add a Steam version dedicated subforum if there is interest.

Edit: ROM map update: http://madsiur.net/rom_bin_map_V2.txt

Everything tested so far had an impact in game. Still big chunks like map related data and formations / packs need to be verified. I'd say I'm halfway through basic tests (a least one data change on every data kind).

http://madsiur.net/rom_bin_map_V3.txt

Well, molds are History of the past, as far as the PC version is concerned. I scaled the leafer from 64x64 to 256x256 and there was no problem. You can even have two giants leafers at the same time. Only small thing that needs adjustment is the hand pointer when selecting the monster but this test was only to check if molds were important or not.

One leafer: https://youtu.be/4aPFHkDuOxQ

Two leafers: https://youtu.be/ELoPr2kbvtw

Are those changes made in the ROM or in the exe? Well a file connected to the exe anyway?

And while it shouldn't have any different results, what happens if you do that to a Narsh guard and fight them while on mtek armor?

Interesting info to say the least.

It looks like they should do more than five damage.

That kind of flexibility would be helpful for a lot of people.

Are those changes made in the ROM or in the exe? Well a file connected to the exe anyway?

I actually just resized the monster on its sheet. Monsters all come on a 256x256 individual sheet, I just scaled the leafer. The obb once decompressed contains 4000+ files, a lot of them being graphics you can open right away with Gimp. They have a 256 color palette, even if the leafer use roughly 50 colors he has a 256 colors palette (most of them being black). The pink background must always be index 255. Cropping and pasting the leafer to a new image lose that palette because even if the new image is indexed, Gimp will make some sort of optimization, reducing the palette to least colors, like around 50 for this example. At that point, you can't have transparency because you lost your index 255.

And while it shouldn't have any different results, what happens if you do that to a Narsh guard and fight them while on mtek armor?

I'm confident it will have the same result. There's no VRAM issue here I think, though it should be tested to be 100% sure.