Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

3281

clrmame Discussion / Re: how to add CHD using clrmamepro?

« on: 26 January 2010, 08:19 »

You can't.
Rebuilder is (currently) roms only.
However the scanner can not only warn you about all kind of chd issues, it can also move wrong placed and wrong named chds to their correct place. So you can simply move a chd with any name to a rompath root (assuming you don't use that weird storing mode) and chd + name + unneeded check/fix will tell you they are wrong placed and moves them to their correct setsubfolder.

3282

clrmame Discussion / clrmamepro 3.132b released

« on: 18 January 2010, 21:55 »

3.132b

added: support for utf-8 encoding in xml datfiles
misc:  agent name for http/ftp is now set to "cmpro"
fixed: www profiler can't load from php generated urls with ?
fixed: archive comments warning is still broken for rar files
fixed: wrong illegal download folder message on clean install
fixed: explore menu option opens an explorer path for not game specific warnings
fixed: www open popmenu option shows romname in url only in the 2nd try onwards

3283

News & Communication / clrmamepro 3.132b released

« on: 18 January 2010, 21:55 »

3.132b

added: support for utf-8 encoding in xml datfiles
misc:  agent name for http/ftp is now set to "cmpro"
fixed: www profiler can't load from php generated urls with ?
fixed: archive comments warning is still broken for rar files
fixed: wrong illegal download folder message on clean install
fixed: explore menu option opens an explorer path for not game specific warnings
fixed: www open popmenu option shows romname in url only in the 2nd try onwards

3284

clrmame Discussion / Re: CMP Sub-Directory Handling

« on: 18 January 2010, 13:13 »

Good to hear it's 'fixed' for you.

As mentioned, you can have folder entries besides file entries in zipfiles like:

"subfolder\"
"subfolder\rom1.bin"

Since filenames are always fully qualified, you don't actually need the dummy folder entries and they become unneeded....the fully qualified filename is more than enough to create subfolders.

3285

clrmame Discussion / Re: CMP Sub-Directory Handling

« on: 17 January 2010, 20:48 »

Works fine here....

maybe you're talking about useless zip folder structures which can get optionally detected and removed (Settings->compressor->General->Mark useless folder structs as unneeded)

Zip can store an extra folder entry in the zipfile...which is not needed for subfolders and can be removed.

So maybe you should send me a file in question and some screenshots.

3286

clrmame Discussion / Re: CMP Sub-Directory Handling

« on: 16 January 2010, 19:29 »

Since you say that no folder is empty it shouldn't be a problem to scan them correctly.

Send me a datfile.

It should contain roms like this (old syntax, xml is similar, romnames hold fullfolder)

game ( name sub description subsub
rom ( name "bla\blablabl\blalbalbla\1.bin" size 1024 crc 12345678 )
)

3287

clrmame Discussion / Re: incompatable with some filenames

« on: 15 January 2010, 08:39 »

Well....they get skipped since they cannot be opened with the normal open functions of the win32 api....normally you don't even see a message prompt.
So I guess a prompt here and there (no idea which call produced yours) is not that hard...

Guess it's some unicode thingie....and it already depends which zip program you're using to unpack the file. With one I get a filename without the pipe (and so working on the file works fine), with a different one I get an not printable character in the filename which gets converted to a pipe as soon as you query the name.

3288

clrmame Discussion / Re: incompatable with some filenames

« on: 14 January 2010, 20:02 »

Ehe...looks like various windows programs have issues to open it...funnily enough notepad opens it....hmmm...interesting case.


edit: ok...simply putting quotes around it or using a short name conversion doesn't help to open the file. Unfortunalety "DragQueryFile" which is used e.g. when drag'n dropping a file returns the pipe symbol...wonder what else can be used to open it.

Anyway....guess it's a pretty weird filename and I wonder how it was created anyway.....maybe some unicode weirdness....nothing really to care about, isn't it

3289

clrmame Discussion / Re: incompatable with some filenames

« on: 14 January 2010, 19:44 »

ah ok....opening the file fails.....well...I will check what the System calls return in that case.

3290

clrmame Discussion / Re: incompatable with some filenames

« on: 14 January 2010, 19:42 »

wait a second..you unpacked it....I used the full archive....lemme test it...

3291

clrmame Discussion / Re: incompatable with some filenames

« on: 14 January 2010, 19:25 »

Well the pipe symbol "¦" is definetly an illegal filename character since it's used for well..piping. But I don't see that character here at all. Which codepage is your Windows using?

Here it's shown as: "iLogicAll_Espa+Ôûîol.tzx" (now I hope this messageboard does no character translation,too ...guess I have to make a screenshot then.

3292

clrmame Discussion / Re: incompatable with some filenames

« on: 14 January 2010, 18:45 »

Works fine here.
I've create a dummy dat

game ( name "test" description "blubb" rom ( name "1" size 74133 crc 1837600b ) )

and it rebuilds fine. Maybe some oem2ansi conversion issue with the dat you've used....so...please send it.

3293

clrmame Discussion / Re: Help!

« on: 12 January 2010, 19:12 »

> Both were set to the opposite, so have changed them back. This was an update over an old CMPro - must have been changed back in the mists of time.

Not really. They were never exchanged or pointed by default to a different value. Anyway, you found it, you changed it, perfect.

> Just one last item, the Fixed-Wrong-Name shows CHDs as 0/5, instead of 0/0 like ROMs and sets. Is this fixable?

If chd + name + fixname is enabled they should have been fixed and if nothing is in the scan tree, perfect, you're fine.
Which ones are still listed as wrong named after a new scan?
Maybe the 'new name' already exists as a file and that's why the rename operation fails. In this case you can manually remove the 2nd instance.

> A "Just-fix-it!" button, if you will!

Well, 1st of all, clrmamepro grew to a monster over the last 13 years (it's 'PRO' due to the input from several in-deep-collector groups, devs etc who got some weird requests which the common user doesn't have to care about.
For the common user it's actually set to some good defaults already and he/she only has to:
1) load a dat in the profiler
2) setup a rompath in settings
3) go to the scanner and hit scan.....This lists everything which is wrong...and if you enable the fix options, it will fix them....

Maybe the rewrite in 2026 will bring you a one-touch only functionality.

>Should I be parsing merge tags on the ROMs, too?

If you like...you will gain a little bit of diskspace...but in days of multi-terabyte hds...who cares

3294

clrmame Discussion / Re: Prob with Modifying url lists

« on: 12 January 2010, 15:13 »

Well, your request can be done if I change the url functionality a bit to support the common variables (%r, %s etc...) so you don't have a pre/post string anymore but a simple url with placeholders....then you'd be able to not specify a setname...

I will think about it.

3295

clrmame Discussion / Re: Prob with Modifying url lists

« on: 12 January 2010, 10:02 »

you can't get http://www.xxx.com/10yard.pdf

since it's lacking the setname. Coming from your dat, the setname is 'arcade' <game name="arcade">
The setname is always pasted after the prestring and before the poststring.

I also wonder why it creates http://www.xxx.com/arcade./10yard.pdf for you.
In detail I wonder where the "." after 'arcade' comes from if you used xxx;http://www.xxx.com/;/%R
There is no "." in there (unless you used a new dat where the setname is "arcade."

3296

clrmame Discussion / Re: Prob with Modifying url lists

« on: 12 January 2010, 09:41 »

actually for your example xxx;http://www.xxx.com/;/%R should do the job...(note the missing .)

It would open: http://www.xxx.com/arcade/005.pdf in case you right-clicked the rom-issue 005.pdf line in the set-issue line of 'arcade'.

xxx is the site alias
http://www.xxx.com/ is the prestring
'arcade' is the setname
/%R is the poststring where %R gets replaced with the rom name...

so prestring + setname + poststring results in: http://www.xxx.com/arcade/005.pdf

Don't forget to restart clrmamepro after modifying the urls ini file(s).

3297

clrmame Discussion / Re: Prob with Modifying url lists

« on: 11 January 2010, 19:11 »

Well, first of all, be sure what a setname and what a romname is. roms are inside sets. Like pacman(.zip) is a set with let's say bla1.bin and bla2.bin romfiles. So what do you want to open at http://www.xxxx.com then? pacman or bla1/bla2.bin?

clrmame builds the final URL for the site as follows:

prestring + setname + poststring

so 'xxx; http://www.xxx.com/%R;' matches:
xxx = site alias for menu
http://www.xxx.com/%R = pre string
and an empty poststring
the setname is the selected by the clicked entry

So yes, you will end up with http://www.xxxxx.com/bla1.binpacman for the upper example if you clicked on the rom (not the set).

If you want to access 'pacman' you need to use:
xxxx;http://www.xxxxx.com/;

If you want to access 'pacman.zip' you need to use:
xxxx;http://www.xxxxx.com/;.zip

If you want to access the selected rom in the set and assuming the set is not zipped you need to use:
xxxx;http://www.xxxxx.com/;./%R

Note, the setname is always pasted after the prestring and before the poststring.

3298

clrmame Discussion / Re: Help!

« on: 10 January 2010, 20:14 »

Well, "missing but fixable" can be fixed by turning on 'fix missing'.

However you don't need these chds since they are identical to the chd in their parent sets. And there, they already exist (since cmpro reports them already as fixable). So your output is a bit weird unless you used "not-merged sets".

So, please check the following (actually these are default settings...I doubt you changed them):

Profiler->Options->Parse Disk Merge Tags should be enabled (this is needed to allow the merging of disk images in case of they are have differently names defined)
Profiler->Options->Don't create dummy clones should be disabled

Your prefered merge mode is fully merged as you already told me, so that should be fine.

Then please do a "new scan" to recheck if these messages reappear.

...and of course I assume you're using a MAME binary to get the database data from and no 3rd party dat file...

3299

clrmame Discussion / Re: Help!

« on: 10 January 2010, 09:27 »

>One Zip file, containing a dump of the ROMs on the cabinet circuit boards. One CHD file per disk in the cabinet, so maybe multiple CHDs to cover hard disk and laser disk, tops. All files uniquely named to easily identify them, all in one directory. What needs more than this?

well, you haven't read carefully. That's exactly how MAME stores files.

"all in one directory" - that's your rompath (ok, usually people use more than one since they want to group sets
"one zipfile containing a dump of the ROMs" - correct, that's the 'set'.
"CHDs..." - there you got the choice how to store them, either 'your' way in a rompath root or in a set-subfolder (where the roms stay in their zipfile)
(Like d:\mame\roms\area51\area51.chd and d:\mame\roms\area51.zip (for the roms).

MAME supports zipped and unzipped sets, in case of an unzipped set, you quickly see the general storing method: rompath\setname\file 1 ... file n.


But of course, MAME also supports merging of sets....where you merge parent/clone sets in one or split them up.......but that's a different story.

3300

clrmame Discussion / Re: Help!

« on: 09 January 2010, 20:59 »

The official way of storing chds was always rompath\setname\chdfilename. Besides of that, MAME's official storing method for any file was always rompath\setname\file 1... file n....for decompressed sets which simply becomes rompath\setname.zip for compressed sets (file 1...file n is then inside the archive).

Back in the past due to a MAME bug it was possible to store them in a rompath root.
After the big CHD update in MAME .130 (oh yes, all chds need to be updated via chdman), Devs decided to re-allow the rompath at root level storage (which is still weird since you won't see to which set it belongs...since usually chdfilenames don't match a setname anymore but are chosen by the original hd/cd/whatever device).

If you want to use chds on rompath root, you need to tell cmpro so. Scanner Advanced->Allow CHDS in rompath root.

A set is a collection of roms and/or samples and/or chds. There are CHD-only sets, there are rom only sets and other combinations. Easiest is to see a set as the archive (.zip) which holds the single roms for example. A set + name check checks the name of the zip while a rom + name check checks the romfiles inside the archive.

>Why does Fishermans Bait want to rename 889ua.chd to *two* others - 889ja.chd *and* 889aa.chd?

Because the name check is set based and depending on the set it tries to find a best fitting name. And depending on your disk tag merge settings it decides which to use. Another reason to keep chds in the offical subfolder way.


So to sum it up: clrmamepro handles chds absolutely correctly in both storing modes, but you need to tell cmpro which one to use...(and the majority of users prefers the chd in subfolder mode).