Append "Output Filename" to "!SubmissionInfo.txt" -> "!SubmissionInfo_[Output Filename.txt]" #475

Closed
opened 2026-01-29 16:17:02 +00:00 by claunia · 10 comments
Owner

Originally created by @7Seventy7 on GitHub (Nov 18, 2022).

Originally assigned to: @mnadareski on GitHub.

Case Use 1) A friend of mine who is a beta collector mention he plans to dump hundreds of beta discs into a single directory with MPF/dic. He brought up a good point that "!SubmissionInfo.txt" is a generic naming system and the file will be overwritten constantly.

Case Use 2) I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task. This makes it easy to confuse which game's !SubmissionInfo.txt is open at times and can lead to a mixup. Having the Output Filename field autopopulate to the end of the the SubmissionText file will help add an additional layer of clarity.

Originally created by @7Seventy7 on GitHub (Nov 18, 2022). Originally assigned to: @mnadareski on GitHub. Case Use 1) A friend of mine who is a beta collector mention he plans to dump hundreds of beta discs into a single directory with MPF/dic. He brought up a good point that "!SubmissionInfo.txt" is a generic naming system and the file will be overwritten constantly. Case Use 2) I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task. This makes it easy to confuse which game's !SubmissionInfo.txt is open at times and can lead to a mixup. Having the Output Filename field autopopulate to the end of the the SubmissionText file will help add an additional layer of clarity.
claunia added the enhancement label 2026-01-29 16:17:02 +00:00
Author
Owner

@FoxhackDN commented on GitHub (Nov 18, 2022):

By default, the programs will use the volume label as a specific folder name, and as the file name.

If the discs have no volume label, OR if several discs have the same volume label, they will be file name collisions when trying to save them to a single folder. DIC will also choke if it finds that files with that name already exist.

It is NOT a good idea to dump everything into the same folder. You have to hit the start button in MPF anyway, just, type in a folder name before dumping, it's better to keep things separate to avoid problems.

@FoxhackDN commented on GitHub (Nov 18, 2022): By default, the programs will use the volume label as a specific folder name, and as the file name. If the discs have no volume label, OR if several discs have the same volume label, they will be file name collisions when trying to save them to a single folder. DIC will also choke if it finds that files with that name already exist. It is NOT a good idea to dump everything into the same folder. You have to hit the start button in MPF anyway, just, type in a folder name before dumping, it's better to keep things separate to avoid problems.
Author
Owner

@mnadareski commented on GitHub (Nov 18, 2022):

If there is a need to dump that many discs with either the same or similar titles, I'd recommend not even using the MPF UI. A script that includes a loop that creates numbered directories and then invokes MPF.Check on the results would be far more useful and fitting this use case.

@mnadareski commented on GitHub (Nov 18, 2022): If there is a need to dump that many discs with either the same or similar titles, I'd recommend not even using the MPF UI. A script that includes a loop that creates numbered directories and then invokes MPF.Check on the results would be far more useful and fitting this use case.
Author
Owner

@7Seventy7 commented on GitHub (Nov 18, 2022):

I see what you guys are saying and good info in there. Still I don't see a downside to appending the !SubmissionInfo filename.

@7Seventy7 commented on GitHub (Nov 18, 2022): I see what you guys are saying and good info in there. Still I don't see a downside to appending the !SubmissionInfo filename.
Author
Owner

@mnadareski commented on GitHub (Nov 18, 2022):

As Fox mentioned above, that would do very little because that name would be the same as the default folder, both of which would be derived from the volume label, if possible. If they're going to the same folder, they would most likely have the same volume label.

@mnadareski commented on GitHub (Nov 18, 2022): As Fox mentioned above, that would do very little because that name would be the same as the default folder, both of which would be derived from the volume label, if possible. If they're going to the same folder, they would most likely have the same volume label.
Author
Owner

@7Seventy7 commented on GitHub (Nov 18, 2022):

It can be pretty easy to forget to refresh when batch redumping disc after disc, and it's rather inconsistent for only one file not to have the name on it. In other words, I can only see positives. But I've made my case so I'll rest it now.

@7Seventy7 commented on GitHub (Nov 18, 2022): It can be pretty easy to forget to refresh when batch redumping disc after disc, and it's rather inconsistent for only one file not to have the name on it. In other words, I can only see positives. But I've made my case so I'll rest it now.
Author
Owner

@mnadareski commented on GitHub (Nov 18, 2022):

All of the files that are correlated by name are output by the dumping program. Nearly all of the files output by MPF have a generic name for consistency.

@mnadareski commented on GitHub (Nov 18, 2022): All of the files that are correlated by name are output by the dumping program. Nearly all of the files output by MPF have a generic name for consistency.
Author
Owner

@tjanas commented on GitHub (Nov 18, 2022):

I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task.

That dramatically increases the odds of entering wrong ring code information. Take your time with dumping discs. It is not a race.

@tjanas commented on GitHub (Nov 18, 2022): > I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task. That dramatically increases the odds of entering wrong ring code information. Take your time with dumping discs. It is not a race.
Author
Owner

@7Seventy7 commented on GitHub (Nov 19, 2022):

I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task.

That dramatically increases the odds of entering wrong ring code information. Take your time with dumping discs. It is not a race.

This is not a logical statement. Whether the info is added into a SubmissionTxt or directly into redump, it is being entered in the same manner. And there is no point to enter ring codes twice, so it's better for me to just add directly into redump.

@7Seventy7 commented on GitHub (Nov 19, 2022): > > I do not fill out "SubmissionInfo.txt" when batch dumping a stack of discs because it's very inefficient to switch-task. > > That dramatically increases the odds of entering wrong ring code information. Take your time with dumping discs. It is not a race. This is not a logical statement. Whether the info is added into a SubmissionTxt or directly into redump, it is being entered in the same manner. And there is no point to enter ring codes twice, so it's better for me to just add directly into redump.
Author
Owner

@MrPinball64 commented on GitHub (Nov 19, 2022):

I dump all my discs into a single directory and named them by what's labeled on the disc, so the issue of identical filenames isn't a problem I have. I would like to be able to dump them all into a single directory and sort them out later, and not having the !SubmissionInfo.txt constantly overwritten would be very helpful so I didn't have to manually rename it.

@MrPinball64 commented on GitHub (Nov 19, 2022): I dump all my discs into a single directory and named them by what's labeled on the disc, so the issue of identical filenames isn't a problem I have. I would like to be able to dump them all into a single directory and sort them out later, and not having the !SubmissionInfo.txt constantly overwritten would be very helpful so I didn't have to manually rename it.
Author
Owner

@sadikyo commented on GitHub (Dec 16, 2022):

Maybe a compromise here would be to make this optional?

I actually do see the value in appending the filename to submissioninfo.txt. (maybe off by default).

I normally do dump everything to different folders, but in my case, I was trying to copy over several submissioninfo files to do some submissions - to a separate machine (due to reasons I don't need to go into here), and I had to go in and manually rename all of them. Just sharing another example as to where it could be useful.

I know we don't encourage people to dump into the same folder, for many reasons. But IF someone is going to do that for whatever reason, having this type of option would at least reduce the chance that data is overwritten.

@sadikyo commented on GitHub (Dec 16, 2022): Maybe a compromise here would be to make this optional? I actually do see the value in appending the filename to submissioninfo.txt. (maybe off by default). I normally do dump everything to different folders, but in my case, I was trying to copy over several submissioninfo files to do some submissions - to a separate machine (due to reasons I don't need to go into here), and I had to go in and manually rename all of them. Just sharing another example as to where it could be useful. I know we don't *encourage* people to dump into the same folder, for many reasons. But IF someone is going to do that for whatever reason, having this type of option would at least reduce the chance that data is overwritten.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SabreTools/MPF#475