Please login or register.

Login with username, password and session length
Advanced search  


The new forum is online, hope you enjoy it!

Show Posts

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.

Messages - Roman

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 158
clrmame Discussion / Re: ClrMame Tutorial
« on: 12 April 2022, 17:53 »
No...I only wanted to point out that it follows a general storing schema (and MAME follows it too).

Either you have your sets in archives (.zip or .7z) OR you keep them decompressed.

Of course 99.99999999999% use archives.

clrmame Discussion / Re: ClrMame Tutorial
« on: 12 April 2022, 17:42 »
You can convert your sets by using the rebuilder by the way......

(in case your sets are compressed as zip, you can disable "recompress" in the rebuilder options, so it should run rather fast (depending on your system))

The rebuilder takes everything from the source which matches entries in the loaded dat (match by hash) and creates all instances of that match in the destination. There it uses the correct name etc....

clrmame Discussion / Re: ClrMame Tutorial
« on: 12 April 2022, 17:23 »
Unmerged is not "stand alone"...simply due to the device references.
Modern Frontends should all handle split or full merged sets (this is nothing new...)
So there is really no real need to use unmerged (unless I add a real stand alone mode).
I'd say the most common is split....and of course there are some hd-space-gurus who have everything fully merged in solid 7z archives (hey wake up....it's 2022 and TB of HD space is cheap... ;-))

You can turn off Scanner->Advanced -> separate bios sets...in case each of your sets really contains the bios files for their own....(yikes)....

but really....believe me: noone (should) use unmerged sets :-)

clrmame Discussion / Re: ClrMame Tutorial
« on: 12 April 2022, 17:14 »
"I have a non-merged set for 0.241"

Then you're the only person on the planet who does that :) and actually I highly doubt that...it does not make sense to keep MAME roms unmerged since they are NOT stand alone. You still have device and bios relations (ok, the latter can be handle with turning off separate bios roms option, but you won't have luck with the device relation.

So....check again...sure that you're using unmerged sets...it's really really really uncommon. Use split instead ;)

clrmame Discussion / Re: ClrMame Tutorial
« on: 12 April 2022, 16:59 »
What you normally do:

1 ) Run clrmamepro, go to profiler, add one exe-based profile for *the current* MAME: Profiler -> create... -> filename: browser for your mame binary, description: MAME, Emulator MAME, hit create profile

2)  double click the profile, it will prompt that it runs mame etc....after confirming, it will import data. If a prompt asks you about importing Software lists, answer NO. Other prompts while importing can be answered with OK to all and yes to all.

3) after the main window appears, go to settings, top left drop down box should show ROM-Paths. Now you can add your rompaths here (either drag'n drop or use the Add... button). Same can be done (if needed) for sample paths (if you switch the drop down box accordingly)

4) Go to scanner, select your prefered merge mode (most likely it's split or merged sets) and that's basically it (maybe disable samples if you don't use them). If you now hit "new scan" your rompaths are scanned. Nothing is touched since you didn't enable the check options yet.
Everything which now appears in the scan results window is bad.

Now what does BAD mean:
You can examine the output (expand/collapse) to see what is wrong with the mentioned set.
If you think that can't be right, then maybe your setup is not ok.
For example: You're checking a collection which does not belong to the loaded database or your rompath setup is bad. If you have your roms in e.g. e:\temp\test\neogeo_roms\mslug.zip and f:\other\pacman.zip, then e:\temp\test and f:\other should be setup as rompaths. Or your chosen merge mode does not match the one of your collection.

Enabling the fix options and running another scan will actually FIX the problems (if possible).

This is one standard scan (+ fix)....after that the scan result should either be empty (no problems) or you might miss files (e.g. when a new MAME is out and new stuff was added). There are various ways of adding missing files, one is the rebuilder (rebuilder destination should point to your rompath).

When a new MAME is out, you don't have to repeat all of the above. You simply replace your MAME binary and when you load your old profile, cmpro sees and asks you to update its database. And of course you don't have to resetup your rompaths again or your scanner options.

So basically it's:
- load profiler, run a full scan with all fix options, use the rebuilder to add missing stuff (there are some nice scanner context menu options for drag'n drop which automatically run another scan after a rebuild etc....)

"Tons of errors" is not normal. As mentioned, you either use a wrong database, didn't setup the rompaths correctly or used a different merge mode.

Maybe some additions:

You should store sets like this (and setup your rompaths accordingly)
rompath\setname.zip (.7z/.rar) for compressed set
rompath\setname\file 1... file n for decompressed sets

so e.g. c:\temp\test\puckman.zip (with puckman.zip holding the puckman roms and c:\temp\test is your rompath)
or c:\temp\test\puckman\pm1_chg1.5e (and so on) (with c:\temp\test is your rompath, puckman is the setname which is a folder then and the single files like pm1_chg1.5e inside that folder

The merge modes:
- full merged (sometime also simply called "merged"): Only parent sets exist but the sets include the clone set files, too
- split merged (simetimes simply called "split"): Each set exists but the clone sets only hold the files which are unique and aren't shared with the parent set
- unmerged (not merged): forget that mode...it's not really used, each set exist and even clone sets have the shared parent files in them...a waste of diskspace and not even a real standalone since today a set has other dependencies as well (bios / devices).

clrmame Discussion / Re: Different dat with the same name
« on: 09 April 2022, 08:11 »
The detection mechanism works by looking at the name element inside the dat file. So filenames don't play a role. If you're not the author of the dats, you will run into the same problem with the next update....so I guess you either convince the authors of changing the name somehow or be aware when loading the dat that you select a different option and not click on update ;-)

It's not really planned to add work in cmpro to change this behaviour at this point in time.

You don't need to copy it back since in 242 it doesn't exist anymore. As I said...it doesn't have any roms on its own but only device references now.

Don't worry about the resize. That's the normal behaviour when it sees that the file is there (identical name) but size is not correct.

Resize tries different things, not only cut down but also fill up with 0x00 / 0xff or double the rom to match the checksum.

So...ignore the message, the real problem was that when it adds the found missing rom, the existing one wasn't copied to backup.

in 242, pcmx2 does not have any roms. It only consists of device references....
in 241, it contained some roms which are now devices.

So it's ok that it was removed for 242....however it shouldn't be listed as missing. Most likely another full scan fixes that.

I was able to reproduce it with your files. Will check what is different

clrmame Discussion / clrmamepro 4.044c released
« on: 30 March 2022, 18:25 »
fixed: Scanner fix missing, backup fails when replacing a file in an archive and file is replaced silently

found the problem...fix is coming soon

The problem was that when the found missing file is added to the archive (where the same name exists), backup'ing the existing one failed due to a typo....this is fixed now. For the scenario it however means, that after scanning/fixing, you will still need to readd one file from backup via a rebuild operation (since it ends in an archive where fix missing does not look into...).

thanks for sending the files....I will have a look at it pretty soon.

I can't repeat that...

I get:
Set:   Tokyo Joshikosei Sailor-fuku Nyumon Dai-2-kan
Name:   tokyojn2
File:   E:\Temp\test2\tokyojn2\tokyo joshikosei sailor-fuku nyumon dai3kan.d88
Do you want to remove the file?

Set:   Tokyo Joshikosei Sailor-fuku Nyumon Dai-3-kan
Name:   tokyojn3
File:   E:\Temp\test2\tokyojn3\tokyo joshikosei sailor-fuku nyumon dai3kan.d88
Do you want to add the missing ROM?

Set:   Tokyo Joshikosei Sailor-fuku Nyumon Dai-3-kan
Name:   tokyojn3
File:   E:\Temp\test2\tokyojn3\tokyo joshikosei sailor-fuku nyumon dai2kan.d88
Do you want to remove the file?

And yes, after that one 1 file is missing, but everything is in backup and can be rebuilt from there.

Can you send me your *.cmp setting for your profile (cmpro's settings folder) and your cmpro.ini.

The rebuilder works fine, no ROM is lost.

Scenario: 241 dat, rebuild your roms, you end up with the 2 sets., Scan them, all fine.
Switch to 242 dat, scan with all fix options are enabled, yes, it seems that after that you're missing things, but in fact you will find 2 sets in the backup folder. Using the rebuilder to readd them works fine. Why scanner's fix missing does not automatically pick them up from backup..ok..that's a point to check though.

I don't see any "resize" attemp. The scanner reports missing and unneeded files to me.

You're using the latest cmpro version?

clrmame Discussion / Re: 1G1R Priority
« on: 28 March 2022, 06:12 »
No. The algorithm (which was done by Logiqx over a decade ago) does not take anything from the name/description into account. It's purely based on region/language attribute settings. However, you can modify the order of region/language in Settings and this increases/decreases priority (move up/move down). There you can also enable/disable regions/languages.

"Available Sets" is just a one time action. So it looks in your rompaths for matching setnames and enbles the found ones. The others are disabled....
So...it won't help you. "Initial invert" simply means that your selection from "Select sets" is inverted on program start (so you don't need to click invert on every start). But you can also simply keep "select sets" empty, hit available sets once and then tick the checkboxes before the setname to enable/disable them.

So....to enable/disable sets you can:

- pick them yourself (Avail/Select all/select none/ single tick the checkboxes before the setnames)
- use a setname list from a file
- use select sets input field (which offers all kind of variables, regex, etc) + apply

"On my little mame collection i have a lot (about 6 o 7 files) need the .chd files."
......or you modify the datfile and remove the disk entries...or you untick the chd option in the scanner...etc...etc....

Again...mtchxl5k, mtchxl5ko, mtchxl5ko2 etc are sets, not roms...

so simply go to scanner->scan results -> set information

Enter "mtchxl5k;mtchxl5ko;....." (semicolon separated) in Select Sets
hit Apply
hit Invert
and tick "initial invert"

You only need to modify the dat if you want to exclude ROMS, not SETS.

No, sorry.
If you got a collection where 1 set contains just one rom, you need to keep them archived or you need to modify the datfile (instead of having n sets with 1 rom each, have one set with n roms).

By the way...if I'm not mistaken MAME removed the "keep chd on rompath root" option...so actually this option became useless over time :)

you're talking about sets, not roms.
Sets can be enabled/disabled in Scanner->Scan Results->Set Information (button bottom left)

Single roms of a set can only be removed on datfile level.

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 158

Page created in 0.545 seconds with 21 queries.