Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--prefer-region not yielding correct results #1341

Open
IDmedia opened this issue Sep 10, 2024 · 6 comments
Open

--prefer-region not yielding correct results #1341

IDmedia opened this issue Sep 10, 2024 · 6 comments
Assignees
Labels
potential-bug A potential issue that needs confirmation and/or triage

Comments

@IDmedia
Copy link

IDmedia commented Sep 10, 2024

Paste the command

igir.exe report -d "Nintendo - Nintendo 64 (BigEndian) (Parent-Clone) (20240809-203816).dat" --single --only-retail --no-unlicensed --no-bios --prefer-revision "newer" --prefer-region "USA,WORLD,EUR,JPN" --report-output report_n64.csv

Describe the bug

When trying to filter the Nintendo 64 dat file based on region, I notice that it for some reason prioritizes EUR over USA even though I specify the opposite. The issue seems to be consise, it's always prioritizing EUR.

007 - The World Is Not Enough (Europe) (En,Fr,De) MISSING
007 - The World Is Not Enough (USA) IGNORED
1080 Snowboarding (Europe) (En,Ja,Fr,De) MISSING
1080 Snowboarding (Japan, USA) (En,Ja) IGNORED
1080 Snowboarding (USA) (En,Ja) (LodgeNet) IGNORED

report_n64.csv
Nintendo - Nintendo 64 (BigEndian) (Parent-Clone) (20240809-203816).zip

Expected behavior

Igir should prioritize the region based on the provided list of regions

Debug logs

output_n64.txt

DAT(s) used

Nintendo - Nintendo 64 (BigEndian) (Parent-Clone) (20240809-203816).dat

igir version

3.0.0

Node.js version

N/A

Operating system

Windows 11 64-bit

Additional context

No response

@IDmedia IDmedia added the potential-bug A potential issue that needs confirmation and/or triage label Sep 10, 2024
@IDmedia IDmedia changed the title Region preferences not yielding correct results --prefer-region not yielding correct results Sep 10, 2024
@emmercm
Copy link
Owner

emmercm commented Sep 10, 2024

Does this happen when writing as well, or when only reporting?

@emmercm emmercm self-assigned this Sep 10, 2024
@IDmedia
Copy link
Author

IDmedia commented Sep 10, 2024

Does this happen when writing as well, or when only reporting?

I was too obsessed with the reporting that I took it for granted to check the actual files.... {facepalm}
It looks like it's only a problem when generating reports without writing files. It moves the correct files (with bold text).

@emmercm
Copy link
Owner

emmercm commented Sep 10, 2024

I think the "IGNORED" status is confusing. The results of 1G1R depend on the input files present, and since none are present here, we can't actually know which version should be chosen and which should be ignored. 1G1R choosing the European release could be valid depending on the input files.

I'll make an update so that when no matches are found for any clone they will all report as "MISSING".

@IDmedia
Copy link
Author

IDmedia commented Sep 11, 2024

I think the "IGNORED" status is confusing. The results of 1G1R depend on the input files present, and since none are present here, we can't actually know which version should be chosen and which should be ignored. 1G1R choosing the European release could be valid depending on the input files.

I'll make an update so that when no matches are found for any clone they will all report as "MISSING".

I'm not sure I understand what you mean by that. How come the input files determine the results of 1G1R? Isn't it just the dat-file and the "prefer"-arguments that determine the outcome? If the files present affects the outcome then I would love some kind of flag/option that could disable this function, if possible. I would rahter have Igir tell me that I'm missing an (USA) release instead of it picking the (Europe) or another undesired version just because that happens to be present on disk (if I prefer (USA) over (Europe)).

@emmercm
Copy link
Owner

emmercm commented Sep 13, 2024

Thinking about this more, I think you're right. That's the behavior that Retool, clrmamepro, RomCenters, and others have.

I wish I had made this change for v3.0.0 since it will be breaking behavior, but I'm ok with making the change in a minor update.

If you were to create an option for the current behavior, what would you call it? --single-any, --single-best-effort, --single-loose, or something like that?

@IDmedia
Copy link
Author

IDmedia commented Sep 13, 2024

I'm still trying to understand when the currect behaviour would be desired to be honest. Personally I would "trust" the DAT files and prioritize/pick roms how the user specifies. I see the DAT files as authoritative since it's the best source we currently have.

I'm not great at naming things and as mention struggle to see the usecase for the current behavior, but I would probably vote for "--single-best-effort" being the argument that makes the most sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential-bug A potential issue that needs confirmation and/or triage
Projects
None yet
Development

No branches or pull requests

2 participants