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 ... 158
clrmame Discussion / Re: clrmamepro 4.045 released
« on: 22 June 2022, 08:02 »
ehe...no problem

clrmame Discussion / Re: clrmamepro 4.045 released
« on: 22 June 2022, 06:52 »
Dropping a file into the scan results window will run a rebuild operation (with the current rebuilder settings) with exactly the files/folders you've dropped. That hasn't changed for decades.
So....guess you need to be a bit more specific and give details what you want to achieve or you double check your rebuilder settings.
If manually opening the zip file works, it may be either structurally corrupt (not data corrupt) or it uses a compression which is not supported. So you can try to unzip the archive to a temporary place and rezip it and drop that newly created one for a test.

As mentioned before: mame -listxml has all information you need.

MAME exists since 1997, things changed over time, bios sets were introduced decades ago, devices decades later on. MAME and all frontends I know of work perfectly fine with split or full merged sets, so there is no real need to spend so much time on unmerged/standalone/whatever sets. The majority prefers a more compact representation. Why repeating thousands of bios and device roms over and over again.

It's not that hard to generate a standalone set.
Unmerged + disabled separate bios sets is a basis, then add the device roms manually.

And yes, there is a chance someday in the future that there might be something which resolves the deviceref dependencies.

I fully agree that the unmerged mode itself is totally useless, a standalone mode would make more sense.

dl-1425.bin is the qsound device rom so it belongs to the qsound set.
Don't compare MAME versions against other versions. Things do change frequently. Devices become separated which may be included in earlier versions. And again: non-merged is not standalone, devices are not included.

A MAME -listxml output gives you all information about all sets.

*Currently* there is no option to resolve the device ref dependencies, so devices would be needed as standalone sets. An option for now would be to use a modified dat where devicerefs are resolved.
The major reason why it's not optionally doable at the moment is that there is no real need for it. Frontends usually work perfectly fine with split or fully merged sets (and so with separated bios and device sets)...and the majority of users prefer it to save hd space ;-)

And yes, I've started this post with *currently*....and I have good reasons for it.

scanner -> scan results tree window ->  set-information (lower left button)

There you can limit your sets manually, by a file set list, by regular expressions / variables in select sets and so on....

well...depends on what you did...
"when I created the non-merged set"...can mean anything...

If such sets are part of the used dat not disabled...
...then you either scanned your sets... -> so they are either ok or are listed as missing/with errors
...or you rebuilt them...then -in case they were valid- are created in the rebuilder destination

From the "qsound_hle" set (which is a device set)

<machine name="qsound_hle" sourcefile="src/devices/sound/qsoundhle.cpp" isdevice="yes" runnable="no">
<description>QSound (HLE)</description>
<rom name="dl-1425.bin" size="24576" crc="d6cf5ef5" sha1="555f50fe5cdf127619da7d854c03f4a244a0c501" region="dsp" offset="0"/>
<sound channels="0"/>

So your prefered frontend shows clones and the parent set with one and the same name?
And it doesn't even use the full descriptive name which the MAME -listxml gives...well...go and send your complain to the frontend author :)
Nobody forces you to copy all clones over to your frontend machine....if you're happy with just 1 19xx set fine, copy that....but remember, the set requires the qsound_hle device to run correctly. So either integrate that in your 19xx set or keep it standalone (that standalone device won't make 19xx appear multiple times)

If you want standalone sets, you need the set and add the referenced device roms to it. At the moment you have to do this manually. Then you have 1 file with all required files.

"Which means in a front end like emulation station, you'll see the same game listed multiple times" ...well...that sounds weird since you only have 19xx and 1 separated device set (if not included)...so why should it list 19xx multiple times...sounds like a malfunction to me....

Normally frontends work fine with unmerged, fullmerged or split sets (the most common method to store MAME sets in my opinion), so there shouldn't be problem to have the devices in separate archives. But then again....why not keep BIOS sets also separated :-)....and finally...why not directly use split or full merged sets.

But don't mix: playability in an emulator, visibility in a frontend and set-audit results in a tool....3 different things.

I highly doubt that you get missing bios files messages with 19xx, since it does not use any bios at all. And the shown error does not refer to bios files.

Unmerged sets, even with turned off bios set separation does not create standalone sets. Why? Because there are also devices. Most sets use devices (besides possible existing bios and parent references), too.

For 19xx for example it's this:
      <device_ref name="m68000"/>
      <device_ref name="timer"/>
      <device_ref name="z80"/>
      <device_ref name="93c46_16"/>
      <device_ref name="screen"/>
      <device_ref name="gfxdecode"/>
      <device_ref name="palette"/>
      <device_ref name="speaker"/>
      <device_ref name="speaker"/>
      <device_ref name="qsound_hle"/>

where at least "qsound_hle" requires an additional rom.

So, your assumption is wrong that you can create/scan standalone sets (at the moment).

Simply delete kingyo.chd....since you already have it at the right place

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 19:36 »
Move them elsewhere and let the rebuilder readd them with recompression enabled.

clrmame Discussion / clrmamepro 4.045 released
« on: 06 June 2022, 15:52 »
misc: updated to ZipArchive 4.6.8, unrar, 7Zip SDK/DLL 21.07
fixed: rarely list a set as missing when it does not contain any files on its own
fixed: 4.044d misplaced a romset regression (full merged sets only)

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 12:14 »
no prob....and yes, keep your backups :)

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 11:19 »
ah ok....."full merged" ...that was the information which was missing....I'm able to repeat it....so assume it will be fixed soon

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 10:52 »
Do you use a MAME import with or without softwarelist import?
What's your settings (would be great to send over cmpro.ini and the profile's .cmp file from cmpro's settings folder).
And...do you have an actual nes.zip, sc3000.zip etc on your disk? And what does it contain?

clrmame Discussion / Re: loveber3cn Missing Set ARXMAX
« on: 06 June 2022, 10:43 »
Found your loveber3cn problem.
It normally doesn't pop up due to the unique chd for that clone. Since you're using a dat which does not use chds, a different issue is visible now.
It's gonna be fixed with the next release.

The reason...oh well....there's a flag which sees if a set does not need to exists (e.g. only devicerefs, only parent roms in a clone, only nodumps, etc) and that flag was set falsely in that case since loveber3cn references one bios file which its parent did not use at all...etc...blablab.... ;-)) Anyhow....it will be fixed.

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 09:00 »
You did read

didn't you?

4.044d  detects some unneeded sets which weren't detected before.

clrmame Discussion / Re: Cmpro "misplaced a romset" !?
« on: 06 June 2022, 08:16 »
Well yes, but they are not existing sets on their own. They are only referencing devices.
So if you got a nes.zip, genesis.zip etc on your disk, you don't need them and you can remove them.
That it shows "misplaced romset" instead of "unneeded" could be an indicator that you're using an additional softwarelist import instead of scanning software lists individually.

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

Page created in 0.109 seconds with 19 queries.