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.

3241

clrmame Discussion / Re: Some CHDs treated differently?

« on: 27 April 2009, 06:26 »

A missing set isn't a missing chd. clrmamepro is correct in showing you the missing set since you actually miss it
There are chd-only sets which consist only of a chd definition, no roms, no samples (and maybe biosroms which are usually separated). If you scan for missing 'sets' and don't have the chd, the 'set' is listed as missing. If you also enable the missing 'chd' check, you will additionally see 'missing chd' messages.
Since disabling the 'Sets' check is not recommended, you can fool cmpro by simply adding an empty rompath subfolder for the chd in question as you did for the other chds. Then the missing set message won't appear anymore (however a missing chd one will appear if 'chd' is enabled).

3242

clrmame Discussion / Re: Skip confirmation only for certain fix options?

« on: 26 April 2009, 12:56 »

Unless I'm missing something, it seems like the confirmation prompts issued by ClrMame when fixing a set are either all on or all off.

Each type of fix got its own confirmation. When a 'wrong name' prompt appears and you click "yes to all" this will only set 'yes' to all 'wrong name' messages. As soon as a different message appears (e.g. 'unneeded file'), a prompt for this is shown.

So you are asked for each group separately. The 'ask before fixing' option however is a general one which enables/disables the prompting.

3243

clrmame Discussion / Re: Some CHDs treated differently?

« on: 26 April 2009, 12:53 »

Hello

With CHDs scanning disabled (I have none), some CHDs sets are still detected as missing (fe. 700a04.chd or psyvaria.chd).
How to disable displaying them as missing?

TIA

Actually this shouldn't happen. Are you sure they are listed as "missing chd" and not by a different thing like "missing set"?

3244

clrmame Discussion / cmpro 3.126a released

« on: 23 April 2009, 20:01 »

3.126a

added: 3 state button bar file
misc:  scanner popupmenu move/copy to operations remember last used path
fixed: bios assignment can fail on rather identical sets (naomigd/naomi MAME .131 issue)

3245

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 22 April 2009, 07:29 »

well...7z support is not priority as you might know. Solid archives are always a problem since there are a lot operations in cmpro which are file based (i.e. adding one file to an existing archive). For 7z this would mean that it has to recompress the full file over and over again each time a new file is added. It's a pain. Besides of that, as soon as you got one of the 'deeper' checksum checks (like full archive test, sha1, checksum analysis) enabled, it will decompress files into memory...and again....file by file...for solid archives this would mean it skips 99% of the time

3246

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 21 April 2009, 11:28 »

I understand the options I just didn't understand the reasoning. I figured that if you weren't planning on fixing anything there would be no reason to perform checksum analysis, etc. I rebuilt the affected files so I cannot check the behavior. Did it show in the status window which files/sets were fixable? If that's the case, I understand... Because even if I didn't want to fix the problems, it would come in handy to know which were fixable if I did choose to fix them.

First, please differ between checksum analysis and the standard checkum checks.
A checksum check can be e.g. crc32 which can be rather quick for archived files since the checksum check will simply compare the stored information with the database. A checksum check can be more time-consuming when it has to decompress the file to check the sha1 for example.

This is all 'checking'. 'Checking' also includes (if enabled, default is disabled) the checksum analysis. This checks are run when a wrong checksum was found. Then it checks if byte order changes or fills with patterns can create a valid checksum.

Fixing can be enabled by the belonging standard fix options or -for checksum analysis- with the 'fix file (if possible)' option which corresponds to the standard fix operations.


So, by default all fix options are disabled. So actually you don't have to change anything to do what you wanted to do.

3247

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 21 April 2009, 08:22 »

so the options are clear now?

3248

clrmame Discussion / Re: clrmamepro auto-minimizing problem

« on: 20 April 2009, 21:39 »

ah...I should read more carefully....XP....and cmpro is filled.

again: cmpro is being created if you run cmpro for the first time and quit cmpro. Actually it always writes cmpro.ini on closing the program. So if you run it for the first time, you won't see a cmpro until you close it.

The scan went fine...it used the default values during that one.

Now that cmpro.ini is filled, you will find your entry in there....but not at top....it used it during start, plus default values for the rest...and when you quit, it wrote your setting + the used defaults (not necessarily in that order).

so...looks fine now

3249

clrmame Discussion / Re: clrmamepro auto-minimizing problem

« on: 20 April 2009, 21:30 »

Are you running Microsoft Vista?

Then be sure that you DON'T use a folder for cmpro which is monitored by UAC.

If you install cmpro to a protected folder like C:\program files\, you have to set the compatibility properties of cmpro.exe to 'run this program as administrator' to work correctly or you have to disable UAC. In other folders it should work fine without setting this property and without the need of disabling UAC.

3250

clrmame Discussion / Re: clrmamepro auto-minimizing problem

« on: 20 April 2009, 20:19 »

Okay, I'm looking in the program folder for clrmamepro, and I don't see any cmpro.ini. The only .ini files are stats.ini, urls.ini, and version.ini. I also tried uninstalling and reinstalling the program, with no difference.

It's being created after you successful started cmpro, used it for the first time and quit.
So since you don't have a cmpro.ini, you can't have illegal sizes for the window....which is a bit weird that the profile isn't shown for you. If you start cmpro for the first time (no cmpro.ini) you should even see a welcome prompt telling you what to do next. Maybe that window is behind of any other window of your desktop.

what you can also try is: before the start, add a "cmpro.ini" file into the cmpro root folder. The file should hold the following two lines:

[CMPRO SETTINGS]
Adv_HideWindow = off

3251

clrmame Discussion / Re: clrmamepro auto-minimizing problem

« on: 20 April 2009, 20:05 »

Hi. I am trying to run the latest version of clrmamepro, but every time I run it, the window comes up for about 1 second, then immediately minimizes to the bottom of the screen, and I can't restore it. I can't right-click it, and if I left-click it, nothing happens. All I can do is bring up the task manager and end the program. I've also tried it with older versions, and the same thing happens. This is the first time I've tried it on my new computer, and I've ran this before on my old computer with no problems. I am running Windows XP SP3 32bit. Anybody have any ideas what is happening?

Also, once I managed to click "options" before it minimized, and I thought it was ok, but then a couple seconds after the options window opened, the whole thing minimized again.

The normal behaviour is that the 6-button main window is hidden when scanner/profiler/merger/etc is opened. In this case however you will see scanner/profiler/etc instead. If you don't see such a window, the saved window positions may be corrupted. You can find them in cmpro.ini...for example:

Win_ProfilerDlgTop = 105
Win_ProfilerDlgBottom = 634
Win_ProfilerDlgLeft = 248
Win_ProfilerDlgRight = 1262


If the profiler window (usually the first window you see after start) is hidden to the bottm left, you should be able to bring it back to normal by clicking the normal windows restore button beside the [X].
If you stop cmpro, remove the upper mentioned lines from cmpro.ini and restart cmpro, the default values will be used again.

When running cmpro under MacOS/CrossOver it's recommended to set: Adv_HideWindow = off  in cmpro.ini


In general it sounds like your profile window settings are corrupted somehow....since that's the window which a) hides the 6 buttons one and is shown right after start.

3252

clrmame Discussion / Re: Updating CHD files

« on: 20 April 2009, 18:30 »

Will ClrMamePro support automatically upgrading the CHD files in the future?

No since there is no need. chdman does the job just fine and it's no big deal to write a batch file which automatically converts all chd files.

3253

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 20 April 2009, 12:09 »

I Then I scan. If it asks to add a missing file or remove an unneeded file, I want NO.

If no fix options are enabled, it won't ask and won't fix.

But apparently I also need to go into the "Advanced Scanner Options" and then over to the "Fix Missing Options and I need to make changes here.  (reminded that why should I need to make changed for Advanced Scanner Options for fixing misses)

No you don't have to do this.

SO, why are we bothering with the VERY SLOW Avanced Scanner Options if we have aldready disabled the associated fix checkbox.

Again, you don't have to do this. I only told you that if you got the checksum analysis in CHD&Hashes enabled, it will do the analysis which can take long in some case. This has nothing to do with the standard fix/check options.

3254

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 20 April 2009, 08:56 »

crap, yeah I forgot the "Checksums" box... but I still don't understand why any additional scanning would be triggered if the fix options are disabled? There are no checksums in the dat file besides the CRC32. We are talking the difference between HOURS and seconds.

There is no additional scanning. The "run analysis" is the part which can take long. In case of a wrong checksum for example it decompresses the file and does the analysis (like applying byte order changes to see if this solves the checksum issue etc.). The 'fix file (if possible)' writes back the file if the analysis shows that it's fixable.

3255

clrmame Discussion / Re: Move all sets remembering last paths?

« on: 20 April 2009, 06:59 »

Could you please change the move (and I would guess all the other options) unfixed, etc. so that they remember the last few paths chosen? Or at least the last chosen directory?

I put it on my list

3256

clrmame Discussion / Re: Checksum analysis ignoring fix options

« on: 20 April 2009, 06:58 »

Time depends a little bit on check-options not only fix options. E.g. if you scan for sha1 hashes (Scanner->Hash & CHD), it will decompress the archived file to memory and calculates the sha1 checksum...

For checksum analysis it will do similar if you have the "Run Analysis" option enabled. Is that disabled in your scan?

3257

clrmame Discussion / Re: Updating CHD files

« on: 19 April 2009, 18:51 »

I might have misunderstood something, but is it possible for ClrMamePro to automatically update the CHD files when it finds that it is of the wrong version?

No. It only detects the different versions and tells you if you have to update or downgrade. In any way you have to use chdman.exe to update your chds.

3258

clrmame Discussion / I'm not an artist....

« on: 15 April 2009, 22:11 »

...but I quickly made this:

http://mamedev.emulab.it/clrmamepro/images/new_style.bmp

...you might want to download it and load it in About->(PopupMenu)->Change Buttons.....

3259

clrmame Discussion / #0016 - double roms

« on: 15 April 2009, 18:26 »

MAME tries to name the files after their name and location of the original PCB. This can result in different filenames for identical files in different sets. If they don't share a parent/clone relationship this doesn't play a role. Now what happens when this happens within a parent/clone relationship.

By default, clrmamepro acts like this: different names - different roms.

So if you have something like:

pacman\rom1.bin      crc 0x12345678
pucmanjp\rom1jp.bin crc 0x12345678

within a parent clone relationship and you fully merge the sets you will have 2 files in there which are byte-wise identical.

A waste of disc space? Well...since MAME loads by crc/sha1, you don't actually need the files twice...MAME doesn't care about naming anyway....clrmame does. clrmame is strict. In days of terabyte HDs it's questionable if you really have to care about some bytes..

MAME itself added something to define that the files are identical. These are the so called merge-tags and they tell clrmamepro which 'alternative' name is also allowed:

rom name="mds-te_2b_a.bin" merge="mds-te.2b"

When clrmamepro uses this information it's not that strict anymore and detects if double roms can be avoided. By default usage of this tags is disabled. The reason for this is: I personally like the strict way better since each rom listed in the datfile can be found with the correct name in the sets and in the past merge tags were buggy in MAME's xml output.

You can enable the usage of the rom merge tags in profiler->options->Parse rom 'merge' tags.

By the way, disks (chds) also have merge tags...and surprisingly this option is enabled by default (otherwise you'd need some of the beatmania chds twice or even more...this *IS* a waste )

3260

clrmame Discussion / #0015 - chds in rompath root

« on: 15 April 2009, 18:14 »

An - imo - ugly way to store chds is to keep the chd files themselves in a rompath root. Why ugly?

1) it's against the general MAME loading scheme of rompath\setname\file 1... n (rompath\setname.zip for compressed sets)

2) you don't have any connection to the set itself. In case the name matches the setname like area51.chd it's ok....but you normally don't know directly to which game 765uab02.chd belongs.

Some years back MAME allowed chds on root level...then it was fixed (it was defined as a bug). When MAME introduced the new chd 4 format lately, this storing method was reenabled.

In case you're using this (which I personally don't recommend) you have to tell clrmamepro so. In Scanner Advanced you will find an option to allow chds on rompath root level.