News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: The Console Tool (by Low Lines)  (Read 252384 times)

DeathbyGiantChicken

  • Guest
Re: The Console Tool (by Low Lines)
« Reply #340 on: July 26, 2011, 08:35:52 am »
I've been running into a snag when trying to use this tool with the Ghost Trick rom.

The compressed files are in .lz format and have [1LMG] after the names. I'm aware that LZ files, in hex view, begin with something like 0x100. With these files though, they start with the text '1LMG'. Is this another type of LZ77 compression? I don't seem to be able to extract these files.

I've tried Googling for '1LMG' but haven't found anything.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #341 on: July 26, 2011, 09:37:23 am »
@DeathbyGiantChicken
Normally magic numbers mean you are dealing with a structured format, and when you get a magic number and no google search results, then that probably means that it's an undocumented (private) proprietary format. File extensions generally share little relation to what is actually contained in a file. If you post a few sample files and/or post the locations of the files in the rom (ie folder1/folder2/file.lz) people can have a look at them, but this will only really happen if there is some level of interest as there are tons of custom file formats out there. As I've mentioned before my goal is to eventually fully support SDK and common file formats and implement a plugin system so people can write their own plugins for custom formats. Its a long ways off from that but if I'm given a spec on a file format that I can decode into something that can be loaded into ctool, I'll add it.

@Auryn
Zoom, and  AUTO-reload (ie a popup that says "hey you changed this file without my knowing!! do you want to reload it?") are some good suggestions. Replacing the banking combobox with a layers styled ui is sort of what I'd like to do with it, however I was considering doing something more like this (http://www.lonerobot.com/images/FBHH.jpg, note this is just an example I found with a quick google search), but I can also see what you mean with the bank layering.

viperzerof-2

  • Jr. Member
  • **
  • Posts: 47
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #342 on: July 29, 2011, 09:34:04 am »
could you if possible add this format I need the models for an important project
http://ps23dformat.wikispaces.com/Ace+Combat+4
only if its not to much of an issue this is coming from someone with only a basic idea of how this works

AzuShin

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #343 on: July 31, 2011, 09:40:18 pm »
Would you mind adding a another support, if you can?
.DAT
->.CAB
-->.BIN
-->.BLD
http://dl.dropbox.com/u/32409323/Rips/TOPX_DAT_BIN_BLD/e001%281%29.7z

The .dat has a FPS4 header, which FPS4Dumper can dump.
Then there's a cab file, which any windows, mac, etc tool and uncompressed.
The .BIN, I'm think this the cell data, like the NCER files in NDS games.
The .BLD is the graphic and palette. You can view it TitledGGD, but piece those together would be nearly impossible, or at least very time consuming.

Auryn

  • Hero Member
  • *****
  • Posts: 650
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #344 on: August 01, 2011, 12:05:28 am »
I am back to make critics / precisations for my own suggestions :p
The auto reload should only check if the loaded file has changed when the CT window becomes active.
So that CT not starts bothering about file changed as soon that somebody change a value in an hex editor.

The multi layer thing is relativelly usefull especially if the layers are not loaded to the same coordinates (like I later noticed with my work :p).

@viperzerof-2/AzuShin: CT want to be a general tool for all console but I don't think Lowlines will start implement support for specific games very soon.
As for the formats from you listed, .dat/.bin can be anything and in the most games they are archives in special format created for that game so the same applies to the above sentence.
Anyway Lowlines is busy with school so there will probably not be a new version of CT before fall/Christmas.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #345 on: August 15, 2011, 09:51:24 pm »
It's always good to have a bit of nostalgia :)

I have got NSBMD models nearly up to the same level as was in v2.0, however it's taking a little while since I'm introducing proper implementations of fixed point numbers. With that said there's already a handful of things I'll have to update in the format spec later once I get these little buggers fully working again and figure out the unknown parts. If anyone can point me to a good tutorial for matrix decomposition (ie where you separate translation, rotation, pivot from a combined 4x4 matrix into their native/raw values, ie xyz) that'd be a great help.

Putting that aside, I'm happy to say that I've gotten pretty much every archive and image/graphic format that has ever been supported in earlier versions into the current build, including partial support for a bunch of others such as PowerVRTextures and Valve VTFs and S3 Texture Compression. All up that works out to be about 30 formats that at the very least will open in ctool. I've now got some reasonably good color/image parsing routines that make adding support non-compressed images a snap :)

Autodesk 3DS models open, though as I'm still in the process of refining the generic modelling data structures, they currently only display wireframes.

Am still having a bit of trouble gettings ISOs working properly (last time I tried, I got folders that opened in on themselves to inifinity O.o), but they aren't a priority atm. On a side note, keyboard navigation in treeviews is now implemented (including hitting enter to open) ;)

The Hex Viewer has also had a bit of work done too, with proper interaction with the editor panes (highlighting, selection, wip editing support), as well as a data inspector for converting values. There's still a lot more I want to do with it however it is at the far end of my priority list right now.

Finally, after brushing up my knowledge on class reflection, ctool now automatically loads all format plugins dynamically (meaning I don't have to add each new plugin to a list when I create a new class), which although currently happens internally, opens up for the possibility of a plugin based system (where plugins are loaded in from a folder) as I had always hoped to be able to do down the track. Again this isn't a real priority right now,but at the very least its something to think about :p

NCER, NANRs and the other SDK formats haven't been added yet as there's still a few issues with assets management that I have to sort out before I can do them. The idea at least is that I'm making use of class inheritance so an NANR could be treated the same as an NCGR in the sense that when you get to more complicated formats like NMCR, all you have to worry about is calling your assets' .getImage(); method and it will "magically" return the correct image without over complicating the implementation. It is also meant to reduce all graphic editors into one, which was one of the major problems I ran into in past implementations. All a bit complicated atm, hence why I'm working on NSBMDs right now :p

With all that being said, I've got assignments to do and not a heck of a lot of time to do them @_@ but I quite like mention about an update in Fall. Living in a place where we don't have the four seasons, I'm used to hearing that term with movie and game releases. So..."CTOOL IS COMING THIS FALL!!" or at least as long as I get what needs to be done until then :p

Friedslick6

  • Jr. Member
  • **
  • Posts: 22
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #346 on: August 16, 2011, 03:12:16 am »
Oh yay! Another update~
Thank you for your continuous work on this project. I hope you can find the time and resources neccessary to work on it further :) .

RetroHelix

  • Full Member
  • ***
  • Posts: 147
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #347 on: August 16, 2011, 03:57:27 am »
I'm quite sure I mentioned this in the context with something else but have you heared of quickbms? Maybe you could implement support for mexscript/bms into your tool.

May console tool become better then SeƱor Casaroja's Noesis (in terms of supported formats). Keep it up. :thumbsup:

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #348 on: August 16, 2011, 12:00:54 pm »
That modelling tool looks cool despite the dodgy look and feel of the website :p I also think that I'd be an old man before I will ever be able to support that many formats :p On a side note, I dislike the use of DLLs and how they behave, putting aside the fact that I would have no clue on how to implement them even if I wanted to :p Any sort of third-party plugin support would probably be in the form of scripts or Java JAR files. This would also then reduce the opportunity of bad stuff happening as would be the case with DLLs if I understand it all correctly.

The QuickBMS on the other hand looks really interesting!! The BMS language looks pretty easy to implement, however scripts would need some extra header information in order to work with ctool (hypothetically speaking of course).

Here's example of the current structure of a file format class...

Code: [Select]
package ctool.file.formats;

import util.file.*;
import util.file.defaults.*;
import static util.Common.*;
//Imports a bunch of convinence methods mostly for quick and easy data conversion
//ie
//int i = getInt(byte[] data, int offset, int length);
//float f = getFloat(byte[] data, int offset, int length);
//String s = getString(byte[] data, int offset, int length);

/**
 *
 * @author lowlines
 */
public class CustomFormat extends util.file.formats.DFormat /*or any of its subtypes, ie DArchive, DImage, DPalette*/ {
public CustomFormat(DPath path) {
//DPath is a super class of DFormat and is basically your handle on FileIO in ctool
//In its basic form, it points to a File, otherwise it will recursively call to its parent
super(path, int fileType, String mimeType, String formatName, String extensions/*(separated by commas)*/, int byteOrder, CIcon customIcon);
//The are various super constructors you can use, but this the most robust one so you can see what information ctool currently uses
}

@Override
public boolean isValid() {
//This by default checks if the file has a valid file extension but you can put your custom detection here (ie hasMagic("NCGR");,
//which is a built in method that can be called)
}

protected void openFormat() {
//Code goes here
//File handling is all done through inherited methods
//ie read(), read(long offset, long length), read(long offset, long length, boolean decompressed)
}

protected void exportFormat() {
//Haven't implemented exporting yet but this would most likely be how you would do so
}
}

Being file objects, the DFormat class uses a parent/child hierarchy making it very easy build complex data structures like archives (and should make editing them a breeze), or for adding internal assets (ie a palette inside an image). Its still a work in progress, but the whole structure has come a LONG way from where it was back in the beginning. Any plugin support would have to implement all functionality of this structure in some way in order to work. Just off the top of my head, BMS scripts could have a couple of word sensitive comments at the top of the file that would hold the header information necessary. I might have a go at writing a BMS script loader later, it would be super cool if I get it working because that would potentially mean I've added support for a bunch of formats without doing anything XD

[edit]

After a bit of researching I've gotten a good handle on BMS. However there's a fair bit of variation in the language including undocumented commands etc. It's definitely a viable plugin format that can (and probably will) be supported in the future however as most of the BMS files I've come across so far deal with files in games I don't have access to or make use of various compression and encryptions that aren't yet supported, it's a bit difficult to debug a script loader for it (since the goal here is to support scripts already written by people). So if anyone could pm me files of supported BMS formats that could really help that along. It would be good to have a mix of simple and complex scripts to test with.
« Last Edit: August 16, 2011, 10:16:56 pm by Low Lines »

Blazer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #349 on: August 17, 2011, 01:14:19 pm »
Hello there,

This is an awesome looking tool so far and it has a lot of support for a lot of files. However, I'm saddened by the fact that it doesn't support .ca, .ma, and .md files. These work similarly to .nsbmd and .nsbca files (I don't know about the .ma files, unfortunately).

I used your doc (I do think it's yours) here--http://llref.emutalk.net/docs/?file=xml/bmd0.xml#xml-doc and dissected the header of a file ripped from Fire Emblem 12, a game I'm currently translating. I need to translate the logo and the opening which use the aforementioned file formats; however, no program supports them despite the format of the .md file being so similar to the .nsbmd file. If you could somehow give support for these files, I would appreciate it very much.

I actually made a post asking for help but did not get anything so I continued to research even harder and found myself here. Here is the link to the post which includes screenshots and downloads for files of the file types I mentioned, as they may prove useful.

If you could at least give any information on how I might edit them, it would be greatly appreciated. Regardless of whether you're able to help or not, your work is very well done, and I hope you continue to make progress in your endeavors. ^_^

~ Blazer

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #350 on: August 17, 2011, 01:21:47 pm »
They look like they're compressed to me, the 0x11 first byte is a dead give away :p Doesn't the latest version (v3.0 or v3.1) decompress them properly?

Blazer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #351 on: August 17, 2011, 07:32:19 pm »
I already decompressed them, of course. It's not about decompressing it as much as it is finding some way to edit it. The decompressed graphics are shown in that link I gave. And your program doesn't like any files that aren't the supported file formats IIRC from what I tried.

Perhaps this is out of the scope of your program, in which case I apologize

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #352 on: August 17, 2011, 09:11:19 pm »
I am 99.99% positive they are SDK formats compressed with the LZ77 variation used in NDS games.



The model is some sort of image blown apart which I'm guessing comes back together in the animation. Assuming you don't have any problems with decompressing they should load up in v2.0 just fine, (note this is last public version where models and textures were supported). Obviously you can't edit them with ctool yet, but my point is these aren't custom formats.

An NSBMD is just a container which can have a MDL0 section and sometimes a TEX0 section. If you understand the Nitro container structure its actually quite easy to split them apart and put your texture in a NSBTX file in a hex editor, that way at least you aren't dealing with all the model info as well.

Probably what the real issue you are dealing with is that about half of the textures are compressed using the NDS texture compression format which is a lossy format like JPEGs. So not only would you have to export them to native images but you would then need a compression routine to compress them back into the appropriate format, otherwise it'd be like having a BMP in your texture files :p As far as I know, no ones made a compressor yet but it's on my to do list somewhere down the track.

Blazer

  • Jr. Member
  • **
  • Posts: 6
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #353 on: August 18, 2011, 06:20:10 pm »
Sorry, I only meant that these formats were something I was unfamiliar with and couldn't find any documentation on and couldn't figure out myself. I'm not a veteran or experienced hacker, I just kind of used logic to figure things out, and these things were out of the range of my logic >_>

Quote
Probably what the real issue you are dealing with is that about half of the textures are compressed using the NDS texture compression format which is a lossy format like JPEGs. So not only would you have to export them to native images but you would then need a compression routine to compress them back into the appropriate format, otherwise it'd be like having a BMP in your texture files :p As far as I know, no ones made a compressor yet but it's on my to do list somewhere down the track.

So uh, let me try and understand this: the whole file is compressed, and within that are compressed textures using some compression that doesn't have a compressor program made for it (and possibly not even a decompressor). Even if I could decompress it, inserting it like any other graphic wouldn't work, so I need the compressor too...

I think I got a few details wrong, I'm sorry, this is not an area I'm familiar with. If you could clarify this a little bit more, I'd really appreciate it so I could learn this stuff. Thank you for your patience and help. ._.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #354 on: August 18, 2011, 06:45:58 pm »
File compression the way I see it is where the goal is to reduce the file size as much as possible without the loss of data. This is generally utilized when you have lots of repeated strings of data (ie lots of 00s etc), the same technique is also used in lossless image formats such as PNG. Lossy compression, which is something used in images and audio (obviously including video as well) is where the goal is to compress the data, losing some of the data at the same time in order to get a smaller image but is still visibly acceptable/appealing. If you recall seeing JPEGs with lots of like specky dirt on them, that's the result of lossy compression and the more it is compressed, especially when the process is repeated on the same image, the worser it gets. This can be done in a variety of ways making it rather difficult to just edit an image in a tile editor since you aren't dealing with raw information.

ctool can decompress some some texture formats which includes the texture compression format used in NDS games, however atm the only option you have with them is to save a raw copy of the image to the clipboard, thus losing palette information and so forth. As I've already pointed out, you'll probably have to jump between versions in order to get to this point as certain functionality was only supported in specific past versions. This will all change of course starting from the next version (at least I am hoping so), but for now that's the best I can offer to your problem.

I'm also not a real expert with compression algorithms so I'm quite happy if I'm just able to decompress something with 100s of errors. But to write a proper compressor (even a simple one) will be a lot of work and I most certainly don't plan on racking my brain anytime soon :/

But although re-compressing your edited graphics might not be feasible atm you can still technically modify them, it just that you'd have to either save them in raw 16-bit color format (that's RGB5 with no alpha) or as 256-color paletted image. Both instances you obviously lose your alpha channel (although I don't think this specific file uses alpha anyways), and generally will have a larger file size too.

[edit]

On closer inspect, that file actually has a LOT of alpha channel usage including translucent effects. Your best option would be to create the translated graphics from scratch and then convert them in (I'm assume you're doing a translation here?).

[edit 2]

Here's the texture data extracted as an NSBTX.
http://www.mediafire.com/?zywh7m1r6qje7na

[edit 3]

In an effort to better understand 3D Modelling in the NDS I've sort of branched out and had a look at some other games with a strong emphasis on 3D. For now this would include Star Fox Command and Kingdom Hearts 368/2 Days.

Star Fox Command has a lot of raw data files including a custom container format with the magic stamp "chnk". It's an odd format in that every node is preceeded with the chnk header, which both defines the objects type and where or not it is a sub chnk or a data file. All data types a preceeded with "MGL" which I'm guessing is the short name of the sdk used to build the game.

So far I have figured out MGL Palettes, Textures, and have partially figured out Mesh files which are actually 90% DS geometry commands making them fairly easy to add support for. The fact that even header chunks in Mesh files were actually command dumps got me looking at unknown data in the Official SDK formats with that in mind and has helped me figure out a few more things :)

Moving on to KH368/2 Days there is an absolute ton of Model resources to sift through in it, most of which are hidden away in countless container formats. To that end, I've started to put together a few specs on the container formats, since a general google search turned up next to nothing or very poorly written documentation.

Code: [Select]
KAPH/D2KP
$0000 4 Magic "KAPH" or "D2KP"
$0004 4 Padding[0]
$0008 4 0 FAT
$000C 4 1 FAT
$0010 4 2 FAT
$0014 4 3 FAT
$0018 4 4 FAT
$001C 4 5 FAT
$0020 4 6 FAT
$0024 4 7 FAT
//
$0000 4 Number of Files
// Repeats * Number of Files
// Offsets Block
$0004 4 Offset
// Lengths Block
$0008 4 Length

// Types for KAPH
0:NSBCA
1:NSBVA
2:NSBMA
3:NSBTP
4:NSBTA
5:
6:
7:NSBMD

// Types for D2KP
0:NCLR
1:NCGR
2:
3:NCER
4:
5:NANR
6:NSCR
7:

A few things to note is that KAPH files deal with 3D and D2KP deal with 2D, but the file structure is identical other than what files are stored in each FAT table.

Code: [Select]
P2
$0000 2 Magic "P2"
$0002 1 Number of Files
$0003 1 Has Name Table Flag (00h=No, 80h=Yes)
$0004 8 Padding[00h]
$000C 4 Header Size (0x200, 0x400, etc)

//Offsets
Offsets Table = 0x10
Lengths Table = offTable + Math.ceil(numFiles/2) * 2 * 2
Names Table = lenTable + numFiles * 4

// Repeat * Number of Files
// Offsets Table
$0000 2 File Offset * 0x200 + headerSize
// Lengths Table
$0000 4 File Length & 0xFFFFFF
Type (>> 24) & 0xFF (00h or 80h)
// Names Table (Not always present!!)
$0000 8 File Name

This was a bit of a pain to figure out and still might be somewhat buggy, but as far as I can tell this should work on most P2 files.

Code: [Select]
0C Archive
$0000 4 Magic 0x0C000000
$0004 4 Length 1
$0008 4 Length 2 (Seems to coincide with File Size)
$000C 4 Number of Files

// Each file begins with a header block which allows
// the parser to jump to the next file in the archive
// until Number of Files is reached

// File Header
$0000 4 File Size (includes 8 byte header)
$0004 4 File ID

Now looking  at the models about 80-90% have at least one spastic vertex with others that look terrible. This could be happening due to a number of reasons including the likely possibility that the rendering order which ctool loads them is wrong (ie a polygon is drawn before the matrix stack is loaded appropriately).

There is also the bone command 09h. Although some models that have it still appear to load properly, I'm sure this command has some significance due to the data length. It is a variable length command which from what I can tell must somehow load/copy/clone other stacks into empty stacks with some possible calculations done on them in the process.

Here's a sample 09h command:
Code: [Select]
09 05 03 010140 040540 030480

09h Command ID
05h Target Stack ID
03h # Sources

// Source Data 1
01h Source Stack ID
01h ?? ID
40h ??

// Source Data 2
04h Source Stack ID
05h ?? ID
40h ??

// Source Data 3
03h Source Stack ID
04h ?? ID
80h ??

The number of sources can be either 2 or 3 as far as I've so far seen. Just looking at the data, its clear it wants to do something with the stack, as the stack IDs all refer to previously assigned stacks, however its the last two variables in each source data that's got me stumped. Particularly the last variable, which can have a seriously varying value.
« Last Edit: August 22, 2011, 12:25:07 pm by Low Lines »

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #355 on: August 29, 2011, 10:17:23 am »
Games developed by Griptonite store most of their files in a Glob.bin, of which I have figured out the file structure for.

Code: [Select]
Griptonite Glob.bin

$0000 4 Header Size / First File Offset
//Number of Files = Header Size/4-1
//File Offset * Number of Files
$0000 4 File Offset
//File Length can be calculated by finding the difference
//of the current and previous file offsets

//The GlobFiles.txt contains names for all files in container,
//it can be found by checking for a size match (numFiles*0x40)
//Each name takes up 0x40 bytes with a 0xA as the last byte
//and whitespace (0x20) after the name

Interestingly though I was having a look at Green Lantern - Rise of the Manhunters I came across some interesting files.

These files, although labelled as common SDK formats don't read like they're supposed to and with a quick look at the hex it looks as though they use some kind of byte/block swapping to make it more difficult to read them.

Here's a sample file...
http://www.mediafire.com/?4t556x0vu42xda5

At a glance this file is NSBTX texture file that was LZ77 compressed and then byte/block swapped with a 0x60 added to the start of the file. You should also be able to spot in a hex viewer the BTX0 stamp (and if you're familiar with the format header, parts of that too), all jumbled or written backwards. Even LZ77 compressed generally most of the header is stored uncompressed making it easy to spot regardless of how the file is obfuscated.

If anyone is keen at all to have a look what I'd like to know is whether this a specifically some custom obfuscation as I assume it is or is it an actual/known compression format?

Also the reason why I was looking into this was because the Ben 10 games generally have a good variation of good/bad models to test with.

Koetsu

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #356 on: August 29, 2011, 12:41:23 pm »
Looks like a neat 3D viewer. I can't wait to try it out.

Fall, you say?
« Last Edit: October 13, 2011, 08:44:36 pm by Koetsu »

henke37

  • Hero Member
  • *****
  • Posts: 643
    • View Profile
Re: The Console Tool (by Low Lines)
« Reply #357 on: October 25, 2011, 11:18:49 am »
Think you can throw in some support for the utility.bin format? It should be a 15 min job. It's another of those file formats that contains a nds style filesystem. The format is very easy: fntOffset, fntSize, fatOffset, fatSize.

Low Lines

  • Full Member
  • ***
  • Posts: 173
    • View Profile
    • lowlines
Re: The Console Tool (by Low Lines)
« Reply #358 on: November 26, 2011, 09:53:41 am »
Added support for Utility.bin, and several archive formats in Harvest Moon: Island of Happiness / Sunshine Islands, which I had to figure out in an attempt to rip all the sprites (and game data) for my own play through of the game since there's a serious lacking in a decent online guide (with images) on the web. Through that I discovered it was pretty easy to build a batch exporter for graphics. Although it's currently hard coded specifically for what I needed it for, I would like to eventually add support for customizable exporter functionality in ctool down the track, I'm just not sure on the best approach as of yet. Right now I can see two options, an action based system like photoshop or a script based one that would allow for use of regexp and filter options to make customized export routines.

Since I've had other stuff to do, I haven't really done much work on ctool over the last couple of months, and I probably won't work much on it until I've played all the games that have finally come out (like Skyward Sword ^_^), which will probably get me stuck back into ctool once I've played them all. I am on holidays (well sort of) so I plan on working on it over the next couple of months until uni starts up again in March.

Now to the thing I said about coming this Fall...As to the reasons mentioned above, ctool obviously isn't at the level I wanted it to be before I release the next version, HOWEVER as I have sort of promised a release before the end of the year, I thought of a compromise :)

I will *try to* add support for any file formats requested here on this thread from now until I choose to release the next version (which will be before 2012). This means any archives, palettes, images, textures or models that you would like supported. I'd prefer documentation, but I will look at undocumented formats too. Adding support for new formats takes far less time and effort than doing more work on ctool core functionality, so I think people would get more out of it than me just working on what I've prioritized up until the next release.

Right now NCER support is still being worked on, so NANRs may or may not be supported come the next release, but I will also get image exporting working too. Exporting as in ripping them as flat PNGs. I will also make sure to have archive exporting added too.

Any requested formats that do not get supported come the next release will go on a to-do list which I'll try and work my way through for future releases.

I still plan on working through my priority list in the meantime, but this way I can spend more time working it. Note that the list below is just to show what my plans are for ctool, so take it more as food for thought down the track.

1. Get all past format functionality working (NCER, NANRs, etc), this is purely getting all past formats viewing at the same level or above to what they were in past versions!!
2. Add viewer support for 3D file formats (models, animations, collisions, etc)
3. Add edit/export/convert/create functionality for all format types. Note: This includes UI work and various other things and is going to take a long time to do properly, especially for 3d models!
4. Work on Hex Editor
5. Add built-in tools/widgets. Ideas I have in mind atm include:
- Tile Viewer/Editor add-on for the Hex Editor
- Built in calculator (modelled after the XP calculator).
- Diagnostics Tools (ie archive/iso file allocation, usage statistics, etc)
- Any other small tools that might be useful for hacking. I'm up for suggestions, but keep in mind this is last on my priorities!

samurai goroh

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
    • My page
Re: The Console Tool (by Low Lines)
« Reply #359 on: November 26, 2011, 02:54:08 pm »
Added support for Utility.bin, and several archive formats in Harvest Moon: Island of Happiness / Sunshine Islands, which I had to figure out in an attempt to rip all the sprites (and game data) for my own play through of the game since there's a serious lacking in a decent online guide (with images) on the web.
Well, I know of a page that has good information regarding those games (and HM games in general), perhaps you already know about it, but any case, these are the links...:
Harvest Moon: Island of Happiness
Harvest Moon: Sunshine Islands
I'm the best in the universe, remember that [F-zero X]