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] 2 3 4 5 6 ... 133
1
I haven't looked into the actual score but I could imagine that both USA sets (the demo and the normal one) might get the same score value and then maybe the last one is prefered for no real reason. I guess the algorithm was more for a scenario where you only got distinct regions within one parent/clone relationship.

2
I've checked that 'tutorial' and I don't see a problem with it. I used their description on the Nintendo datfile (used their region ordering USA/CAN/AUS/EUR....) and I still get Mario Kart listed. With the USA regio as highest prio, the algorithm picks Mario Kart DS (USA) (Demo) (Kiosk).nds / eb26155d as 'the chosen' set for that parent/clone relationship.

If people say "may game xxx is not appearing at all" then normally 3 cases might happen:
1) the game belongs to a region which is not enabled and so the set is filtered out
2) due to the scoring mechanism and the arrangement in the dat, a different clone/parent is picked as you might expect (see above Mario Kart DS example, I personally would have picked the "Mario Kart DS (USA)" set and not the "Mario Kart DS (USA) (Demo) (Kiosk)"....but of course scoring algorithms aren't perfect and depending on the datfile it picks what scores best and not what you think is the best guess ;-)...in such a case you might better filter out demo/kiosk versions before.
3) your xxx clone is actually used but gets a different naming due to the definitions in the datfile

So again....the scoring algorithm was designed by Logiqx and is used in several rom managing tools and runs for a decade now....every now and then users come up and are not satisfied with what the algorithm picks...but that's the way it was designed. Surely you can write your own routine...but you cannot compare it to what is used in various rom managing tools.

3
So I made a quick test....downloaded the Nintendo - Nintendo DS (Decrypted) (Parent-Clone) (20200126-032320).dat with that DAT-o-matic, loaded it in cmpro, enabled the 1G1R option, enabled EUR as region and I get Mario Kart DS (Europe) (En,Fr,De,Es,It) listed (see screenshot)
When I select region USA I get the mario usa set with checksum eb26155d...

So everything works fine here and I don't see any bug.

As mentioned before, Logiqx' 1G1R algorithm (which uses a scoring algorithm) is unchanged for over a decade and the results highly depend on a) your enabled regions/languages, plus b) the order of the enabled regions/languages, c) the original datfile and its "release" elements....and sometimes users simply have a totally different understanding what 1G1R is all about (how the setnaming and set selection works).

In your Python code I don't see Logiqx' algorithm implemented but surely you can point me to it in your code....
I guess part of Logiqx' code can be found on old forum posts like https://forum.no-intro.org/viewtopic.php?f=2&t=544

4
The 1G1R algorithm hasn't changed since 2009.

If you face issues with the selection it's usually simply based on the used datfile or a misunderstanding what 1G1R actually does.
So if you're sure that Mario Kart DS should be selected, send the datfile and your settings and I'm pretty sure I can tell you what is wrong on your side or in the dat.

5
you mean for example a51mxr3k for area51mx? a51mxr3k is a clone of area51mx which uses the same chd (but different roms).

6
Using sysdefpaths is only possible if you split your sets by (bios/software lists) systems (e.g. neogeo, naomi, etc).
Having a chd folder means that you have a rompath setup which uses the chd folder ("one folder") for multiple systems, so sysdefpaths won't work.
But of course your idea of keeping chds in one folder is fully valid.
So actually (as long as you don't use software lists), you should turn off the sysdefpath usage. This can be done by accessing the sysdefpaths (via "systems") and remove (unbind) all.

After that you should run a full scan again to see if this already resolves your rename issues, too. If not, you should send me your cmpro.ini, the *.cmp file from the cmpro settings folder so I can try to rebuild your scenario.

7
clrmame Discussion / Re: dir2dat and CHDs in 4.036a
« on: 04 January 2020, 17:32 »
well.....yes, currently you are stuck ;-)
Since only *.chd files (if they are valid ones) are added as disks, you could rename .chd files in e.g. .cchd and use dir2dat and manually change the ending afterwards....but yeah sure it's not really an option.

Rebuilding chds is not that far away I guess......if I only would find some time

8
clrmame Discussion / Re: cache
« on: 01 January 2020, 20:00 »
You need to add datfiles only via drag'n drop or the add button. Copying it to the datfolder would require a refresh button click, the other methods don't.

9
clrmame Discussion / Re: dir2dat and CHDs in 4.036a
« on: 31 December 2019, 12:44 »
I will check this in 2020  :)

10
clrmame Discussion / Re: characters
« on: 22 December 2019, 17:22 »
Again....

Note that the ampersand (&) and less-than (<) characters are not permitted in XML attribute values.
Cmpro uses the the xml/html entity references for such chars, e.g. by using: <rom name="this_is_an_&amp;_test" ......

If you got xml datfiles where & is only listed as &, then the datfile is not ok and should be fixed in the dat.

I don't see anything wrong from cmpro's point of view.

11
clrmame Discussion / Re: characters
« on: 22 December 2019, 13:33 »
cmpro's dir2dat creates a fully valid xml datfile where some characters use their official html entity. So an ampersand & character is listed in the xml as &amp;
cmpro reads the dats correctly and shows the names correctly, also scanning is done correctly.

if "someone" or "another romtool" can't manage that....well, then "someone" or "another romtool" does not parse XML correctly. If "someone" or "another romtool" should support it, go and ask them.

12
clrmame Discussion / Re: Romset upgrade, missing some sets
« on: 17 December 2019, 12:36 »
1) Profiler, load a profile or create one based on the mame binary
2) Settings, setup rom (and samplepaths)
3) Scanner, hit scan
4) look at the scanresults tree output...if you're happy stop, if not, find missing stuff and repeat with 3)

That's it. If you want that things get automatically fixed, enable the fixoptions in 3)

13
Is the "hyperspin xml" a valid datfile? If so then you simply scan with that one loaded in cmpro and everything not listed in there becomes unneeded and will be removed.
If it's not a valid datfile for clrmamepro, find one and use it ;-)

14
clrmame Discussion / Re: Romset upgrade, missing some sets
« on: 15 December 2019, 17:12 »
Then your internet is wrong.
2spicy is a set belonging to the lindbergh system and consists of a 2 chd files (where actually one of it is flagged as nodump).

So...let's sum it up: You miss a lot of chd files which represent several sets. Go find them. All sets in MAME are available "in the internet".

15
clrmame Discussion / Re: Romset upgrade, missing some sets
« on: 15 December 2019, 13:54 »
well, looks like you're missing a lot of chd files then....

16
clrmame Discussion / clrmamepro 4.036a released
« on: 14 December 2019, 20:16 »
4.036a
fixed: broken rar support in 64bit version (64bit conflict of rar and sha1 class), updated rar dll to 5.8

added: automatic 32k path length support, no more need to use \\?\ prefixes (*)
fixed: miss-list listed some sample-only-sets where the parent is autogenerated (e.g. fantasy_sound, nes_jf13, etc)
fixed: wrong software list rom size for roms which imply an offset of 0x00000000 as default
fixed: remembering window positions on multiple / virtual screens fails
fixed: rebuilder match count for files with identical crc32 but different sha1
fixed: rebuilder removal of rebuilt files for files with identical crc32 but different sha1
fixed: detect chd clone to clone moves (aka MAME 206 vs4e to vs4eo rename)
fixed: rom count for fully missing sets included bios roms even when the bios set is available
fixed: select sets options like initial invert / incl. clones/devices etc should only be activate when select sets or from file is specified
misc: rebuilder log adds software list information to file name
misc: dir2dat writes chd files as disk
misc: added cmpro.ini option Adv_WindowToFront = on (on / off) to handle the automatic bring window to front functionality
misc: profiler cache which reduces rescanning datfiles/settings on each profiler visit, should speed up profiler for users which have lots and lots of dats. Delete/Add/Move operations will force a refresh at the moment though
misc: limit extension removal to a max of 3 characters and no space after the .
misc: updated zip, rar and 7z dlls (4.6.7, 5.71, 1900)
misc: updated sha1 c++ class implementation to 2.1
misc: switched to Visual Studio 2019

17
clrmame Discussion / Re: Cmp 4.036 issue
« on: 14 December 2019, 18:01 »
fixed

18
clrmame Discussion / Re: Cmp 4.036 issue
« on: 14 December 2019, 14:50 »
Seems to be an exception in the used unrar64.dll (or unrar.dll if you use 32bit).
So most likely you only have to use the old dll
I will double check the latest available one later today.

19
clrmame Discussion / Re: Romset upgrade, missing some sets
« on: 14 December 2019, 13:42 »
Find the missing sets...they should be listed in detail in the scan tree window

20
well...hard to say...the external 7z compression task failed. Does the 7z file already exist? Do you rebuild it to a place where the 7z is already present? Or does the rebuilder try to add it to a new archive?
What are your 7z settings?
If there's a chance can you provide me the datfile and an example file?

Pages: [1] 2 3 4 5 6 ... 133

Page created in 0.097 seconds with 19 queries.

anything