mirror of
https://github.com/SabreTools/MPF.git
synced 2026-02-08 05:37:45 +00:00
[Request] Allow Check to ingest data and place it into !submissionInfo.txt #625
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @acridAxid on GitHub (Oct 10, 2023).
Originally assigned to: @mnadareski on GitHub.
Is your feature request related to a problem? Please describe.
I hate having to manually type disc metadata into the generated
!submissionInfo.txtwith a text editor; it is not user-friendly or ergonomic.Describe the solution you'd like
From earlier discussion, I understand MPF.Check will never have an interactive mode where users can enter text into it. Instead, I'd like to ask if MPF.Check (and maybe the standard UI, if that would be helpful to others even if the workflow doesn't necessarily exist yet) to ingest some serialized data (JSON, TOML or whatever works for you as long as there are widely-available standard libs to handle it) and then place that information into
!submissionInfo.txt.Describe alternatives you've considered
I was considering writing a simple wrapper script that collects my information, then parse the current form of generated
!submissionInfo.txt, remove the filler text and insert the collected metadata. That seems messy and could easily break if the format of the!submissionInfo.txtdocument is ever changed or added to.Additional context
I have RSI which makes certain hand movements (like reaching back and forth between the alphanumerics and arrow keys or for the mouse) painful; this would allow me to get back to entering metadata one-handed like I was able to do in the past.
@mnadareski commented on GitHub (Oct 10, 2023):
https://github.com/SabreTools/MPF/issues/466
Edit: Since this was misconstrued when I originally posted, I was linking this to the other item as a way of giving more of a reason why the Check UI would be beneficial. I was not saying that this did not have a use case nor am I saying that it was a duplicate. If something is a duplicate, I will say as such and mark and close accordingly.
@acridAxid commented on GitHub (Oct 10, 2023):
Understood.
@mnadareski commented on GitHub (Oct 10, 2023):
It sounds like you're asking to ingest an existing submission info JSON to fill from. If this is the case, I will need to put some thought and consideration into this so that people don't just take submission info from another disc they dumped or from a random log online to fill out theirs.
In theory, deserializing from a standard submission info JSON is simple, with the caveat that anything pulled from the logs will overwrite whatever is being read in from the file. To start, I may have to limit which fields can even be imported. For example, limiting it to physical disc info (ringcodes, etc.), comments, and contents.
@acridAxid commented on GitHub (Oct 10, 2023):
Does tamper detection exist for other ingestion vectors like MPF's text input fields accepting paste from clipboard, manually or programmatically edited
!submissionInfo.txt, or Redump's New Disc form? If these methods are already not concerning to Redump maintainers, I don't understand why this method is uniquely concerning to you.Completely agree that fields that MPF programmatically detects should be trusted over user-provided data; the whole purpose of using Check is to reduce user error with its detection and log parsing logic. To be clear, I believe that users should not be required to manually edit a number of
!submissionInfo.txtfields greater than zero after import.@mnadareski commented on GitHub (Oct 10, 2023):
Okay. Here we go. This is a unique situation where information is being automatically pulled from a source, more similar to pulling from Redump than it is data entry into the disc info window, editing the file directly, or filling the new disc form. Ingesting submission info in this way is new for MPF and therefore needs the same thought put in as pulling direct from Redump.This is why it is concerning to me.
Due to the same above concerns, balanced with the needs of the moderators, I need to be aware ahead of time what data imported in such a manner needs to be omitted. Omitted data means that there is a guarantee that those fields are more likely to be direct from the logs and media, which can be validated from the logs. If this happens to leave fields needing manual editing, those can be addressed separately.