EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

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 ... 106 107 108 109 110 [111] 112 113 114 115 116 ... 165
2201
clrmame Discussion / Re: Understand batchrun options
« on: 14 January 2013, 08:34 »
Generally, the Rebuilder got 1 destination folder or -when configured correctly- can use system default paths. You can do some more tricks with using rebuilder advanced -> destination prestring.
But still: These settings are per-profile settings.

The batchmode only allows some general overwrite of the destination (and this means 1 general destination). If disabled , the per-profile settings are used.
Yes, it's questionable if you ever need the destination overwrite because you're limited to 1 folder, usually overwriting the source is more needed.

2202
Well, if 7z creates an error during adding a file, tough luck...could be everything. The prompt is shown when an add operation failed, i.e. the commandline 7z returned an error.
As I said...with 7z it could be everything ...Out of memory (7z is a memory eating snake with 12312312 heads...) and latest alpha and betas of 7z are pretty unreliable.

We can discuss about showing the prompt of simply skip it....that's on my list for ages...but did not have time yet to implement it.

2203
1) forcing split merge mode will be a general setting, not a 1-set-selection.
2) for MAME itself, software lists don't really make sense since they mostly mirror the existing sets. In case of neogeo, you will need to have the files twice then...one times for standard MAME and the second time for the software list.

2204
There is not a single parent/clone relationship in your dat example.
I don't see any "cloneof" element

2205
The problem is more in the hands of 7z and solid archives and no good sdk out there...
Using zip with no recompression will be way faster ...and in times of cheap multi terabyte hds I really wonder why people still care about some 7z over zip space gain....

but no, no progress since real life takes all my time. I got some nice ideas but I doubt it will be added into the old core at all. And the new core does not exist yet at all :) But the ideas are on my list

2206
"cmpro keeps randomly complaining about issues", please be more specific. I need more details.

2207
clrmame Discussion / Re: Understand batchrun options
« on: 13 January 2013, 21:48 »
erm...don't fully get it but the rebuilder batch overwrite: "Use destination folder -> "D:/MESS/software" will place all found and matched files in *THAT* path...I don't think you want a colorful mixture of files of all 'batched' profiles in that one folder....

2208
1) if cmpro removes a parent clone relationship it simply interprets the sets in question as standalone ones. So you can't run into any overwrites (identical names while the hashes differ) when doing a full merge. You will need some files multiple times then, the ones which get merged in the normal case...but again...that's really no real problem. And this is only applied to the set(s) which cause possible merge issues, not the whole dat/sets.

2) It first informs you that software lists were detected and if you want to import them. Afterwards you have the options (and a list) which you want to include.
Pro/Cons Softwarelists...well...a lot of people like to keep them separated in single profiles (cmpro can simply read standalone MESS softwarelist files). The direct import is more for people who want to scan everything with one scan....personal taste...and yes in case of direct import cmpro needs to handle equally named sets within different software lists....it tries to do its best...but can't say that it's 100% ok, especially if some software lists even share identical roms (I remember at least one case for Atari files...)

2209
If you're able to run it manually, cmpro should also be able to import it directly...(cmpro does nothing else but calling the exe with the correct parameter (-listxml for MAME and -listinfo for old MAME)....it exports it to its temp folder...so maybe clean it up and retry....

but yes, you can still use the manually redirected one....or a 3rd party one

2210
merge options are enabled by default. They only get disabled if:
- your dat (no matter if xml or deprecated format) does not use any parent/clone relationships
- your dat (no matter if xml or deprecated format) uses a header entry to force a merge mode

2211
clrmame Discussion / Re: cmpro 4.09 released
« on: 13 January 2013, 21:33 »
well....sort of...as I said...it's your personal taste...while the defaults are my personal taste....but yes, the full/split merge difference make sense for the merge tags option, too.

2212
mame does not really care about naming. It looks in any defined rompath (mame.ini) and checks also the parent/clone sets for a checksum match to load the files...no matter how the files themselves are named within the zip....

your proposed diff method is not commonly used or requested. If there are uses who use such old mame versions, they keep the differences in separated rompaths and use separated profiles. There are "rollback" datfiles floating around for nearly each and any mame release.

2213
well...your MAME exe created no or an incomplete output...blame MAME...or your OS which might not be able to run DOS programs anymore....
you could run a mame -listinfo manually and redirect the output in a file and load that (most likely it's incomplete)....

again...there is no reason to use 15 year old MAME versions....
anyway...there were old versions of MAME which simply fail to create a -listinfo output....live with it...

2214
ah now I see what you're trying to do...you want one basic install (.34) and then diff updates....

First of all....I personally don't see any sense in keeping old MAME versions or even each and any version....but anyway...

You want to keep diffs, then you need to handle them in separate profiles and in different rompaths.

You got one profile for .34 and one profile per diff-dat you've created. In each you point to 1 rompath holding just the roms from the used diff dat.

Again...your basic idea of keeping a base version and then diff updates is very unsual....

2215
clrmame Discussion / Re: cmpro 4.09 released
« on: 10 January 2013, 18:59 »
did a test with and without the profiler options.....no issues here. Follow the storing method for the files which I've posted and everything should work right (cache clear / new scan).

2216
clrmame Discussion / Re: cmpro 4.09 released
« on: 10 January 2013, 09:15 »
ehe...I knew that somebody will ask this...

well...yes, you can enable it too if you like....a new scan will then list a lot of unneeded files for you. The reason why it's not enabled by default is that the rom merge information was too often too wrong in MAME's past. (However cmpro tried to fix this automatically).

The whole story is about differently named files within a parent clone relationship which are physically identical. Usually there is a reason for the diffent name (to match the real IC name on the boards), so for cmpro it means: different names = different roms...your somehow turn this off when enabling rom merge tag parsing. If you currently have a differently named but identical rom in a clone, it will be removed if you got a copy of it already in the parent (with a different name).

In times of multi-terabyte hds and maniacs who collect a full mame set, noone should really care about the saved disk space when enabling it...but anyway...it's your personal taste...



actually when I do some brainstorming about a rewrite of cmpro I think of removing all special rules.....it will end in something like:
- only xml datfiles (MAME dtd)
- other (xml) formats need to do a xslt transformation
- trust in the given xml, i.e. always use merge tags, don't care possible issues during fullmerging based on different roms with identical names (the scanner/rebuilder should handle that) etc..etc...
- no more support for old style rules (like old bad_dump handling via ~crc32)

etc etc...should make life much more easy...at least for the developer ;)

...but hey...not a single line is written yet....

2217
clrmame Discussion / Re: cmpro 4.09 released
« on: 10 January 2013, 08:11 »
yes it should be enabled. Otherwise you need several identical chds twice...which is a waste of diskspace...on the other hand, even with this option disabled, you shouldn't run in that fixing loop...I did not test it yet with this option disabled....I will tonight.

2218
clrmame Discussion / Re: cmpro 4.09 released
« on: 09 January 2013, 19:15 »
For a full merged p911 set your rompath should contain:

p911.zip with the files: a00uad_nvram.u39, a00eaa_nvram.u39, a00jaa_nvram.u39 and a00kac_nvram.u39
kviper.zip with 941a01.u25, 941b01.u25 and ds2430.u3
and a subfolder named p911 with the chds:
a00eaa02.chd, a00jac02.chd, a00kac02.chd, a00uac02.chd and a00uad02.chd



2219
clrmame Discussion / Re: cmpro 4.09 released
« on: 09 January 2013, 08:13 »
I can have a look at it later tonight...but generally:

- check if you got profiler->options->Parse Disk Merge tags enabled
- keep "Allow CHDs in ROMPath Root" disabled if you store chds in subfolders (which is the common way)
- clone chds need to be stored in their parent set's folder

2220
clrmame Discussion / Re: Different folder for bios and software
« on: 03 January 2013, 11:49 »
well...if you did not import software lists...why do you want to split them up?
Clean the profiler cache and reget the data if you need another chance to import them....or think about separated software lists where you simply drop the MESS software list xml files into the profiler and handle them as individual profiles...

Pages: 1 ... 106 107 108 109 110 [111] 112 113 114 115 116 ... 165

Page created in 0.292 seconds with 20 queries.

anything