I mimicked the directory structure in your CUT file on my drive, then tested it. Worked perfectly. Granted I didn't use the actual Atari emulator (NeoGenesis was closest to hand - I assume the emulator you're using does support loading ROMs via CUT files?), but I stuck it in the Atari folder, and renamed a Castlevania ROM to Tic-Tac-Toe...

If the ROM path were different on your system, or if the emulator didn't support ROM loading via CUTs, I'd still expect the emulator to at least start. Given that it doesn't, the path to the emulator might be incorrect.

If you're absolutely certain that it's all accurate, then check whether this trouble is with CUT files, or if it also happens when attempting to load programs in the "usual" way.

By the way, just in case you didn't know, you can take screenshots within XBMC by clicking in the left thumbstick.

I was afraid of that.

I think we may have introduced a bug while loading cut files. I'll have to have madmab take a look.


EDIT:

To elaborate, I believe it is trying to load the emulator, but the problem lies afterward. You get a black screen, then you get the XBMC logo as if XBMC just started over (leading me to believe that it did actually start up the emu, but failed somewhere between that and loading the rom from the zip file).

As far as I know, all XPORT emus support command line launching, right?

I have no problems loading this emulator otherwise.



EDIT2:

Weird... it works perfect for Atari 7800. No problems at all loading the games. Either we did something to the 2600, or it never worked for that system in the first place. I can honestly say I've never tried .CUT files for that system in the past.

Could somebody try making .CUT files for the latest XPORT version of Atari 2600 for me? I still can't get them to work on madmab's newest beta.

So far, I've gotten the following to work with .CUT files without any problems (That is to say, there are perfect .CUT sets for the following systems):

Atari 5200/800
Atari 7800
Chip8
Colecovision
Gameboy/Gameboy Color/Gameboy Advance
Genesis/32x/Sega CD
Atari LYNX
NES/Famicom Disk System
Neo Geo Pocket/Neo Geo Pocket Color
Odyssey2
TurboGrafx 16 (CD Games are going to be a HUGE chore to make)
Sega Master System/Game Gear/SG-1000
Super Nintendo
Watara Supervision
Virtual Boy
Bandai Wonderswan

DOESN'T WORK:
Atari 2600 - Kicks you back to XBMC splash screen.
Pokemon Mini - Black screen/freezes XBox
Sega VMU - The .CUT creator ignores *.vms files. I couldn't zip these files up because they wouldn't run in the emu zipped.

EDIT:

Also... could anybody point me in the direction of a doc that explains how the thumbnails made from the thumbs in the .CUT folders get named when they're put in the UserData folder in XBMC?

An explanation of the naming system can be read here. See here for further discussion/code samples.

Thanks BB... I'll check those out.



Have a few issues to iron out.

1) SegaVMU cut creator doesn't work. It ignores *.vms files and I couldn't zip them up because they wouldn't work in the emu zipped.

2) TGCD games don't work in the creator. They use the .CUE file to run, but it looks like it's making a single cut for any track that was an ISO instead. Any idea how to tailor the creator for TGCD use separate so it only looks for .PCE, .ZIP and .CUE files?

3) Possible problem with PSX games. Every file for PSX games will have the same name, whether it's 1 or 4 per CD. If we have it looking only for the image file types that run, it shouldn't be a problem.

To memory, don't CUE files go with BIN files, not ISO...? Is there some sort of weird exception I don't know about here, or is that what you meant?


I don't know of any circumstance where there'd be more then two files per CD (You'd either have an IMG file, an ISO file, or both a BIN and a CUE file, right?). Could you provide examples of where this figure'd be higher?

(ISOs might be accompanied with MP3 files, like some SegaCD emulators accept - not really the point here, I suppose...).

The TGCD games I have are ripped into ISO/MP3 files. Controlling these files is the .CUE files.

The CUE file is the only file in the folder for each game that share's the games name. For example, here's what Bonk III looks like:

CD - Bonk III - Bonk's Big Adventure.cue
track01.mp3
track02.iso
track03.mp3
track04.mp3
track05.mp3
track06.mp3
track07.mp3
track08.mp3
track09.mp3
etc....

Only by selecting the .CUE file can you launch the game, which turns out to be a good thing for us since it's the only file inside the folder with a name for the game we're launching.




PSX games generally come in several formats (at least these are the only ones I know that work on XBox):
BIN
BIN/CUE
CCD/IMG/SUB
CCD/CUE/IMG/SUB
ISO

Here, we would want the program to make a shortcut for every BIN, IMG & ISO file... while completely ignoring the CUE, CCD & SUB files. This is completely different than the TGCD games where you would only want to recognize the CUE file instead of the ISO files. It's just the matter of how each emu handles the CD's differently.

I see. Indeed, it'd be quite difficult to get the program to automatically determine which extension to use based on the system, so what I've done is stick the list of the extensions it hunts for in the INI file ("CutCreator.ini").

So, all you gotta do edit that list to replace ISO with CUE when dealing with the TGCD games, and change it back to normal when dealing with other systems (eg PSX).

This also allows people to add whatever other extensions they want to work with (eg VMS) without bugging me to do another compile. Shoulda done this ages ago.

Thanks man. That ought to solve any extension issues just fine.


One more request....

Is there a way we could have another .ini file made where we can put the 3 directories the 2 batch's ask for?

Where is your parent rom directory on your PC?
Where is your parent rom directory on your XBox?
Where is your emu located on your XBox?

This would be really nice to have so you can make a different folder for each system and easily update the shortcuts in the future if you add any new games.


Thanks again bud. You've saved me months of work with your different scripts you've created for me,
~Rx

I've added some parameter support that should sort all that for you.

"GenerateDirectoryListing.bat" takes two arguments, first is the target search directory, second is where the ROMs are located on the console.

"CutCreator.bat" also takes two: If you use "/defaults", it won't ask you any questions when it runs (it'll assume everything in the listing/INI files is correct). You may also specify an alternate INI file to use by simply throwing in its name as an arguement as well.

What this means in practical terms is that you can create your own batch files to run the programs for you, using pre-determined inputs. The contents of a batch file designed to work with, say, your Atari 2600 ROMs would look something like this:


Where "Atari 2600.ini" is a copy of the original "CutCreator.ini", but modified to work with that specific ROM set (eg, you'd set the "EmulatorXBE" line to read "F:\Emulators\(04) ATARI\2600\default.xbe").

Running this new batch would first create the directory listing file, then create the shortcuts, all in one go. Create one of these batches for each platform, and from then on you can very quickly generate new CUT listings just by double clicking 'em.

Edit:

You could also add a third line to move the CUTs from the output folder to where you actually want them to end up, if you wanted. It'd read something like this.

Took me a while to figure out what you were talking about, but wow... that's awesome!

Thanks for the tips. I'll make one for each system and give instructions on what to change if anything you have is different than what I have.





Got a new one for ya now..... Say somebody got this all set up, but now their only problem is that they have to organize the .CUT files by hand (like I did). Is there a way that we could use the listing output to make another .BAT file convert all the PNG files in the main "Output" folder to TBN files, and then move them next to their respective .CUT files?




EDIT: We're not actually "converting" the images. A simple rename from *.PNG to *.TBN is all that needs to be done.

Create a batch file in your PNG folder that reads like this:

There are many different sub-folders. How would you get them all to go to the right place with that command? Wouldn't you somehow have to use the directory listing file to do so?

... Sub-folders of what? Systems? Genres? Or do you mean art?

A while back you altered the program so if you used the batch on the PC instead of the python script on the box, it would also scan all sub-directories and make cuts for them. Depending on the system, there can be about 20 sub-folders (licensed, unlicensed, pirate, etc.) that these cuts are located in, as well as pointing to.

The trouble, is that I had to move all of the TBN files into the correct folders by hand, using the Compare feature in FlashFXP. This added quite a long time to the process.


I was hoping that there could be a way that we could use the directory listing file to move these TBN files into the correct folders where the .CUT files exist with a click of a button instead of doing this all by hand every time. It would make sense if we could somehow use the directory listing file to do this, since the TBN images share the exact same name as the games in that file, except they have the .TBN extension.


It's too late for me, since I've already completed this work, but maybe it would be useful to others who don't want their file structure as rigid as mine and would rather make their own .CUT files without all the hassle.

I know what I'm asking is complicated BB, so please let me know if you need any clarification for what I'm attempting to have automated here.

Thanks a ton,
~Rx

No, my memory's been jogged and I understand now. Reckon I'll scribble something out tomorrow.

'scuse the delay.

"GenerateDirectoryListing.bat" now accepts a third parameter, the path to your art directory (be it filled with wide thumbs, box art, screencaps, whatever - just so long as the filenames match those of your ROMs, and use JPG or PNG extensions).

When provided with this parameter, it'll create a secondary listing file ("Thumbs.lst") in addition to the usual "listing.txt". "CutCreator.bat" will use this to copy your art into the Output folder, while renaming the images to use TBN extensions as it goes.

Hence you could create a new "automated" batch file that reads like this:

Cool man... no worries on the delay. I've moved on to other things at the moment but plan to check this out and see if we need to do anything else. I'm going to try to make a package of TBN files and configs with the instructions to change any directories if people have my stuff but haven't stayed true to the layout.

Thanks,
~Rx

Hey BB,

For that "PC Art Path" what would be the variable I would put so that it ran the commands from the current directory, no matter where it is?

What would be the one if I wanted it to run from a folder called "Thumbnails" in the current directory?


Kinda like how "D:\" is the signifier for the current directory on the XBox.



EDIT: Figured it out...

"%CD%\Thumbnails\"

I still haven't gotten anything to work with the new code yet, but I'll let you know how it goes.




EDIT 2: I'm using the following code for the A7800.bat

CODE

call GenerateDirectoryListing.bat "F:\XBox\F\Media\A7800\Roms" "F:\Media\A7800\Roms" "%CD%\Thumbnails"
call CutCreator.bat /defaults "A7800.ini"

Now when it runs, instead of automatically doing the generate directory listing, it asks:

Type the parent folder you wish to scan:




Did I do something wrong with the .bat file code, or is something broke since the new code to handle the thumbnail files has been added?


Nevermind.... I screwed some things up. I think I know what happened. Let me work on it some more.

Wow.... this works great now that I got it working.

Only question is, will this work on Windows 7? I'm trying to get somebody else to use it and test that it works and they can follow the instructions to alter directories, but it keeps telling them that it doesn't understand the command "java" even though I had him install java and reboot.

That's the only answer he could come up with as to why it doesn't recognize java.



EDIT: Nevermind.... nytmar3 figured it out: INSTRUCTIONS TO FIX JAVA IN WINDOWS 7 AND VISTA




So..... no questions at this point. Everything is working PERFECT! Great job man.

Thanks,
~Rx

Edit by BB: Attempted & failed to fix the broken hyperlink. Seems the forum software just doesn't like the apostraphes.

Yes.

Everything works perfect for all .CUT files for all XPORT emulators. I've verified them and everything is good. Even when you launch a PSX game that uses a different core, it will work properly.



Now I need to figure out N64 and CoinOPS. I also need to get 3D boxart done for N64 since we never did that. I forgot about the .CUT files, even though the emu doesn't display anything really.



Does anybody know if FBL 1.3 supports command line launching?

Okay bud.... one more thing and it looks like we're home free on this finally.....


FBL 1.3 does indeed have .CUT file support.... unfortunately, it is in a slightly different format for some reason.



According to the readme:



If you've got a good idea about how to do that, could you send it to me? Don't replace the old .CUT creator or link above as it's basically perfect. I just need a slightly different version for FBL on the side that doesn't put ".zip" or ".iso" or whatever after the file name.

THANKS!!!!
~Rx

Regarding the "can't find Java" thing, it has to do with 64bit versions of Windows - they like to store all their apps in different folders depending on whether it decides they're 32 or 64bit. Somehow this messes up the path to Java. Not sure whether it's Microsoft's or Sun's fault - it's either or both...

Regarding the FBL paths, just tell the CUT creator to use ROM-path-type "C". Should work fine like that.

Cool and CRAP at the same time....




Cool: That totally worked on the .CUT files.

Crap: The game label for every game is the zipfile name, which really sucks. Can you think of a way to make Arcade games have the full names, based off of any ini files or whatever from CoinOPS and FBL?






EDIT: If you don't have these files and it would make it easier for you, I could provide you with files with the full rom name for each system. I figure you already have them, but thought that I could offer them up. In fact, my Favorite's list for FBL has "fixed" names.... most of the names in that system are very undesirable for me, so I'll get them to you.

The only question would be which such game index file to use.

The closest thing I have to hand is "gamelist.txt" (included with FBA-XXX Pro v1.28), which seems perfect for the job - but I don't know if that would be suitable for use with FBL (which I don't currently have a copy of). If you have a different file in mind, pastebin it or something and I'll take a look.

I'll post it sometime tonight in the PM (US), hopefully.

I know exactly which file to send you on FBL, but I'll have to investigate CoinOPS.



I'm a little burnt out at the moment. Going to need a nice long sleep soon. I'll get it to you tomorrow and we'll figure it out.

FBL Favorites

Hey BB...

Here's the FBL favorites list with the fixed romnames.


The first line of the doc is how many favorites entries there is.....



After that, there is 7 lines for each game. The first line is the zipfile name without the extension. The second line is the name we want displayed with the .CUT files.

I've got all the .CUTs and images for MAME now BB, but they still look like crap with the "gibberish".zip

What would you need from me to get these changed to the real names? We'd need just the *.cut and *.tbn to be changed to full names.

Oh! I saw your post stating "I will post the list", but never saw the new post icon to indicate that you later had posted the list... After a few days I figured you'd forgotten about it.

With any luck, I should have some time tomorrow evening to take a look at it. At a glance, I see that the INI doesn't always follow the rules you stated, but hopefully it won't take too long to get it parsed.

Cool

And I'm still trying to figure out or get somebody to tell me which file CoinOPS uses to make the long names as well.

I figure with both sets I may have to do some manual work, but if we could get a majority of them renamed that would be great.

Well... I can't find anything good for CoinOPS, so I'm just going to rename 3,200 files by hand I guess....

If you could figure out the FBL from that document though, you'd be saving me about 8 hours of manual labor probably

Hey Rex,

Every single game name is hardcoded inside the MAMEOX.XBE, that huge file of ~40Mb.
You will need to HEX EDIT the file to be able to see its contents, and the only thing you
can do it to REPLACE letter/numbers from the game names with BLANK SPACES, keeping
exactly always the same number of characters coded in the executable.

If you add one new letter (that was not there) you will be adding 1 byte to the program,
and the whole universe will burst over your head.

You can do things like, transforming:
S h i n o b i ( B o o t l e g )

Into:
S h i n o b i _ _ _ _ _ _ _ _ _

Where the char _ represents blank spaces.

Something like:
S h i n o b i [space][space][space][space][space][space][space][space][space]


That's it.
C.

Yeah... Thanks cospefogo, but I'm not looking to actually change any names in the emu itself. I'm just looking to change the *.CUT and *.TBN names for the shortcut files for command line launching in XBMC.

Hopefully with that favorites list I made for FBL we can get the process automated for Final Burn Legends and the Shared roms. Looks like I'll have to edit about 2,600 more CoinOPS files by hand. Hopefully we'll have the shortcuts ready to ship in a few days.

Later,
~Rx

Nevermind on this BombBloke

Changing the file names does nothing. It displays a name that's inside the .CUT files themselves.

The "Label" field

I have no idea how to fix this in a way that won't take me another month, so I'm just going to upload them as-is

Sorry, family stuff kept me busy yesterday.

I coulda told you that changing CUT filenames does nothin'. Even if it did, FATX would cause all kinds of problems - you should know that already! It was already my intention to simply alter the label tags. I'm not sure why this would require any large amount of time once my coding work is complete?

I'll probably skip on pulling game titles from that MAME XBE, though. I could hard-code an extractor to grab the string array out of the executable, but for every new version of the XBE that gets released, I'd need to update the extractor... and a dynamic reader (which could handle any version) is a bit out of my league (it'd need to parse machine code...).

Anyway! I'll probably have a new generator up in the next few hours or so.

Done.

However, on testing with my (tiny) NeoGeo ROM collection, I see that there doesn't seem to be all that many listings for de-crypted games in that "favorites.ini". For example, the first three Metal Slug games (1, 2 and X) will be detected correctly (as they were never released with encryption), but only encrypted versions of the later games in the series will be picked up (eg, "mslug3" instead of "mslug3nd")... And seriously, who wants to keep their games encrypted?! They take longer to load that way, and the compressed file size is typically around double for encrypted sets.

Well..... I'll take a look at it and see if I can do anything with it that isn't too much work. Even if we can do the FBL automated, I can't imagine I'm going to find the desire to change the label field in 1,600 CoinOPS CUTs though.

We'll see how ambitious I'm feeling this week. Maybe I can get some help on this from other members.

Figured out a solution of sorts to deal with the missing sets in "favorites.ini". If it can't find something like "mslug3nd", it'll chop the rightmost character off the end and search again, and then repeat once more if that also fails.

Sticking with the "mslug3nd" example, it'll match it with "mslug3", and decide that the ROM must be a child of that entry. Since I can't accurately have it determine which child in all cases, it'll simply put the suspected parent/child relationship in the label, and leave it to the user to figure out.

For eg,

"Metal Slug 3 (mslug3nd, child of mslug3)"

And if people don't like that, they can either get an INI file that covers all the child sets, remove the child sets from their collection completely, or manually edit the labels when the generator's finished its work.

Of course, if even that process fails to get a match, it'll just use the filename as the title, same as before.

Regarding CoinOPS, one way to get around the problem of compatibility with future releases would be to rip the list from that XBE to text format, then distribute the document with the CUT Creator package. That way, updates to CoinOPS wouldn't matter. Though I'd first want to get permission to distribute that list (from whoever coded up that XBE file), and I'm not sure who to ask.

It would probably be easier to get the list from source, too, rather then trying to read it from the compiled XBE. Even better would be a copy of the original list used during the development of the source (which I imagine would look somewhat similar to FBL's INI file).

What do you mean exactly?

A zipped/rar'd encrypted set will be much larger then a zipped/rar'd decrypted set. To memory, the difference for Metal Slug 3 is about 30mb.

The two versions contain the exact same data, but the encrypted version has it stored in a much more "random" format - compression alogrithms get better results with "predictable" data. Note also that emulators can't run encrypted ROMs, they have to decrypt them before execution anyway. I really have no idea why people bother to distribute encrypted versions. It's kinda like the old "zip file stored in another zip file" stupidity, only worse.

False. The encrypted / decrypted sprites data of Neogeo games has exactly the same size. It is only a descrambling algo based on XOR tables.



It is not stupid. It is just a proper way to reference things, and keep accurate roms sets. Related to mslug3, the decrypted set will use all parent's roms (P-X, V-X, M1) and contains only the decrypted C-X roms, so no waste of space on the HDD.

It is definitly useful to use decrypted sets on low RAM / CPU plateform like Xbox, as it saves a lot of time but poor interest with a recent PC hardware, the loading are pretty fast.

Kiss,

While it's true that the sets are the same size whether encrypted or decrypted, we're talking about compression potential here. The amount of space they take up when uncompressed is irrelevant to my comments, and certainly doesn't prove them wrong.


C as well as P, in this particular case.

Think about it. If you're storing the complete parent set in addition to the child set, then right off the bat you've got two effectively identical copies of well over half the game (those C ROMs are large and numerous).

If that isn't bad enough, one of these copies is taking about roughly double the drive space as the other (as encryption is not compression friendly), and takes longer to load if you try to play it.

This is why people often merge the required parent ROMs into the child set (eg using ROMCenter), then remove the parent set from their collection completely. There's no logical reason not to treat the decrypted versions as parent sets, and remove the encrypted versions altogether. OCD doesn't count as a logical reason, before you bring up the matter of perfectionists who want every ROM ever in the "original format" stored on their drive. All decrypted ROMs lose is encryption.

It's like someone found a file stored in ACE format with minimal compression, then decided that instead or repacking it in a ZIP/RAR, they'd distribute it in both ACE and ZIP format. Together. It's pointless idiocy.

Ok, i thought you were speaking of the size of the uncompressed files.



Think about that. In my case i use only two arcades emulators: MAME and FBA. Except decrypted sets and some extras hacks (also demos), they absolutly use the same Neogeo roms sets, as FBA try to match MAME sets. So basically i've a common Neogeo folder for both emulators.

What will happened if i merge the parent roms into a clone set?

- The set will be usable only for FBA, as MAME doesn't support decrypted sets.

- I can't remove the parent encrypted set, otherwise i can't play the game with MAME

So i'll need to duplicate more data. It will be the mess, it will use much more HDD space, so it is definitly the best method in my case. Not a "matter of perfectionists", just the right thing at the right place.



Each one is own trip. You don't understand why some people wanna keep their sets accurate, and on my side i don't understand why people merge the sets and remove the original one.



Pointless comment. You can think i'm idiot i don't care.

I do realise that with current emulators, users are forced to distribute ROMs in this way, though I wasn't aware that MAME was so limiting - obviously it can run decrypted sets (very few sets are encrypted in the first place, and it'd need to decrypt those that are prior or during execution anyway), so it's just being picky.

Another example where you're forced to keep the encrypted parents is when multiple children exist, assuming you want all available children in your collection (eg, emulators typically won't let something like mslug3b6 treat mslug3nd as parent by default). Merging in that circumstance would also lead to data redundancy.

I've mis-stated my point. I'm guess I'm trying to refer to those who determine how their emulators will load games, hence dictating distribution, but truthfully I simply don't know who set the current standards. Really I'm just ranting.

Ideally, emulators would treat decrypted packs as parent by default (pulling files from the encrypted versions only if need be). This would allow efficient storage and execution of ROMs regardless of which child sets you have, and regardless of whether you want to keep encrypted ROMs or not.


Really I don't even understand in what context you're using the term "accurate", but to sum up the merging arguement - to save disk space and lower loading times by pruning data you don't intend to use.

Hey Bomb-Bloke!

Where can I get the XBMC SHORTCUT CREATOR?
I can't download it anymore from the original link on the first page.

Please, can you give me a direction?
Thanks so much!

Cospefogo.

Never mind!!
Just found it on RessXtras.

Thanks BombBloke!

I'm not entirely certain which vesion made its way into the Xtras. The one on MediaFire at present is v14 (I just up the number each time I make a tweak, and log it in the manual file) - that link tests out as ok currently, not sure what happened when you tried it.

Strange!!
Now the link is working back normally.
But yesterday night I got no luck!

Anyway, the version I have has NO "Refer to FBL's "favorites.ini" file" on its internal configs. For sure mine is older than the mediafire one. But this older version worked like a charm.

I just used the listing.txt generated by the .PY code and pointed the thumb location (as PNGs) to inside my collection of MAME flyers. Since MAME roms and flyers are all specific universal names, I got 99% of success, few games had no flyers (I will correct manually).

Now I understand why RessurrectionX was after some MAME rom naming stuff - all cuts are generated using the rom name itself and not the real game name. I assume there is no other fix for that except by manually adjusting all cuts, correct?

Matter of fact I think I will keep only cuts for the best classics, so it is no big deal.

Mister BombBloke, thanks again for this VERY useful tool.
SUPERB.

Cheers,
Cospefogo.

Sooner or later I'll find a simple referrence document that can be used to automatically deal with MAME naming. Or have one shown to me. Wink wink.