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.

1

clrmame Discussion / Re: Latest Nightly Build

« on: Today at 07:10 »

The nightly build shows the same version number as the official one. The nightly build is: http://mamedev.emulab.it/clrmamepro/binaries/cmpro20191006.rar

(you need to manually unpack it and replace your exe/dll files).

2

clrmame Discussion / Re: scanner fix "unneeded" to immediately fix "missing"...?

« on: Today at 07:09 »

Scanner -> Scan Results (Tree Window) -> bottom left button

3

clrmame Discussion / Re: Latest Nightly Build

« on: Yesterday at 07:28 »

1st of all, it's normal that valid files can be placed in the backup folder.
This a) heavily depends on the used settings and b) damn normal.

let's start with b): If you e.g. have a file from pacman in a berzerk set it is of course unneeded for pacman and since pacman and berzerk don't share a parent/clone relationship, it is placed in the backup folder. Rebulding it from there will add it to the berzerk set

a) the settings, well, if you e.g. disabled some sets and handle them as unneeded, they are moved to the backup folder, if you then rebuild them with the same profile but changd set inclusions, they get readded. There are other settings which may affect such things.


Generelly I see a problem with your seutp since you already posted the weird behaviour with the 4x4 set which gets removed and readded which seem to be a similar effect as here.

So be sure: you really run the latest nightly build, cleaned the cache, and it would be interesting if you can send me:
- your cmpro.ini file
- the belonging *.cmp file for your used profile (cmpro's settings folder)

4

clrmame Discussion / Re: scanner fix "unneeded" to immediately fix "missing"...?

« on: Yesterday at 07:21 »

Open scanner -> set information and search in the set tree for the 4x4 set (parent and clone). click the clone and look at the list on the right. It should look like the attached scrrenshot, i.e. only one rom should be listed there. If you see 2 there then you are not using the nightly build ;-)

5

clrmame Discussion / Re: scanner fix "unneeded" to immediately fix "missing"...?

« on: 20 October 2019, 20:36 »

feedback?
with the nightly build you shouldn't run into this (you need to clean the cache though)

6

clrmame Discussion / Re: scanner fix "unneeded" to immediately fix "missing"...?

« on: 18 October 2019, 19:07 »

hmm...very interesting....when you single-load the msx1_cass.xml file in the profile, the set gets imported correctly (i.e. the clone set 4x4offrda only holds one unique rom, while the 2nd rom is part of the parent).
When you import the data via the -listsoftware mame run after receving data, the set is imported incorrectly (i.e. the 2nd rom is not part of the parent for whatever reason)

Have to check what is happening there.....the bad set definition causes the weird problem.


ah....the -listsoftware output kills the  offset="0" attribute


second "ah": since MAME .210 you need to use the cmpro nightly build to correctly support software lists where the offset attribute is removed

7

clrmame Discussion / Re: scanner fix "unneeded" to immediately fix "missing"...?

« on: 18 October 2019, 07:56 »

ehehe...never seen this before....guess I have to rebuild this scenario.

8

clrmame Discussion / Re: wrong SysDefPath error while Scanner, but it wasn't fixed...?

« on: 17 October 2019, 07:41 »

Actually I have to check if an automatic move from one sysdefpath to another is implemented or not ;-) Too long ago....it's not hard to implement (acutally I think it's in...) but maybe it fails for you because you already have a copy in the right folder, too.

9

clrmame Discussion / Re: wrong SysDefPath error while Scanner, but it wasn't fixed...?

« on: 16 October 2019, 20:12 »

- Standard folder holds a copy of "achase.zip" which is wrong. It's part of the a800 software list and should be placed in the assigned path (actually you do have a copy there, too)
- Standard folder holds a copy of "mf_achas.zip" which is wrong, too since it belongs to maxaflex bios set which is assigned to D:\games\mame\roms\maxaflex
With a clean setup profile cmpro warns me about the double set: "Set exists in various rompaths: ... " message....it does not do it with your profile though....have to check why....but generally your origiginal message is correct: wrong SysDefPath: achase [wrong: D:\games\mame\roms\standard\] [right: D:\games\mame\roms\a800\]
it found a dupe zip archive of achase there and this indeed needs to be in a800...

...and you got D:\games\mame\roms listed as a rompath, while all sets are in subpaths of that....so...this isn't a good idea either, you only need to list the real rompaths, not rompaths containing rompaths....

10

clrmame Discussion / Re: wrong SysDefPath error while Scanner, but it wasn't fixed...?

« on: 15 October 2019, 19:50 »

Hmm...I've tried to rebuild the scenario by using the MAME import and a800 as only softwarelist. Then the mentioned sets and did a scan...but no issues found. Either full or split merged. No problems here (using the latest nighly build)

So...can you provide me:

- your cmpro.ini
- your *.cmp file (cmpro's settings folder) for the used profile (I guess you're using a current official MAME binary as import)
- a pair of the archives in question (e.g. both bristles etc)...maybe the archive is special and causes a problem

11

clrmame Discussion / Re: wrong SysDefPath error while Scanner, but it wasn't fixed...?

« on: 15 October 2019, 07:07 »

The rom in question of the sets mf_achas and achase are identical

a800 software list:
rom name="astro chase (first star software)(1982).rom" size="16384" crc="18752991" sha1="f508b89d2251c53d017cff6cb23b8e9880a0cc0b"

standard mame:
rom name="ac.rom" size="16384" crc="18752991" sha1="f508b89d2251c53d017cff6cb23b8e9880a0cc0b" region="maincpu" offset="8000"

So most likely cmpro hits a false positive match when it tries to identify the sets.

If I remember correctly wrong system default path placements needs to be fixed manually, but in this case the original complaint about a wrong placed set is wrong...I will have a look at it later.

12

clrmame Discussion / Re: Latest Nightly Build

« on: 12 October 2019, 17:15 »

Not yet.
There are several points on my todo list which I want to include....problem is that I nearly have no time this year....what is the difference anyway in using an offical build and a nightly (which is also more a monthly or half-year) ;-)

13

clrmame Discussion / Re: clrmame option to "clear" clones

« on: 12 October 2019, 12:04 »

If you're familar with XSLT you might be able to quickly write a stylesheet which transforms MAME's -listinfo output in whatever you need. If not, then you either look around if some page provides a parent only dat, or you use the select sets method descibed in my first reply.

14

clrmame Discussion / Re: clrmame option to "clear" clones

« on: 11 October 2019, 07:07 »

First of all: Be aware that there are sets where only the clone does work flawlessly but not the parent.

You can disable clones from the set list by doing this:
Scanner->SetInformation->Select Sets: Enter %c=?*
Hit the "invert" button and check the "Initial Invert" checkbox
Then Scanner->Advanced -> check the checkbox "Mark disabled sets as unneeded"

or you simply take a datfile which only lists the sets you need.

15

clrmame Discussion / Re: Latest Nightly Build

« on: 10 October 2019, 06:21 »

Well, a corrupt archive is one of the more important issues so I thought a prompt is better than just a warning ;-) I will think about it.
No chd rebuild, yes...the update was just for 32k unc paths....

16

clrmame Discussion / Re: Scanning complains that there is no valid sets in rompath!!!

« on: 10 October 2019, 06:12 »

theoretically any involved driver or hardware...or even software (a virusscanner might block the access...but that should end in a missing or not accessible file rather than a bad hash)

17

clrmame Discussion / Re: Scanning complains that there is no valid sets in rompath!!!

« on: 08 October 2019, 06:00 »

better I run for cover..... ;-)

18

clrmame Discussion / Re: File skipped when making rollback rom

« on: 08 October 2019, 05:59 »

I've already told you.
You need the old sets/files.
There is no way to magically create files which aren't part of the 2019 MAME but are part of a 2003 MAME.
You need all the files which were replaced/removed in the given set(s) in the meantime.
The ones which did not change over time can be recreated of course, e.g. by using the rebuilder.

19

clrmame Discussion / Re: File skipped when making rollback rom

« on: 07 October 2019, 06:37 »

well...I'd say that's a pretty common behaviour.
Romsets change over time. Bad dumps will be replaced, missing dumps will be added, wrong named stuff gets renamed and so on.
Rolling back (there is actually no reason to do so) would mean that you need the old sets. clrmamepro can't create old stuff magically out of nothing.
If the set/files are skipped, it most likley does not match the checksum which is required by the old definition.

You try to switch back to a version which is 16 years old (again..there is NO reason)...you could imagine that things changed in the meantime.

20

clrmame Discussion / Re: Scanning complains that there is no valid sets in rompath!!!

« on: 07 October 2019, 06:18 »

Thanks for reporting and helping...

Well, about that "I want them all uncompressed in a folder" support.....you need to see how MAME originally works. A set usually contains more than one file (gfx roms, sound roms, dumps holding the code etc), so they got a container, a folder named after the set, holding these files. Using an archive (7z/rar/zip) is pretty the same - a container (again named after the set).

Scanning/Merging/Rebuilding is built around this.

I see your point when it comes to 1-file-per-set collections. Keeping them decompressed leads to the a bit obsolete storage method with the extra folder.

What you can do is to change the datfile definition to only define one set where all files are stored. This would allow to have all files in one folder (named after the setname defined in the dat). Cons: you loose additional information like a detailed description per set (however as you can see from these big filenames, they simply put all in there...) and you get the scan results after finisihing this one giant set.

Theoretically I can add an option which changes a loaded datfile into an one-set-billion-roms dat......time will tell