I'd like to make this thread today to see what the staff currently would feel about a hypothetical hack that requires MSU-1 being hosted in the hack section, given these specific points in mind:
1. No .pcm files for now, just the .msu file alongside the .bps file.
2. The submitted zip file of said hack conforms to the current 10mb limit, as every other hack does.
3. The hack itself may provide diagnostic info in the event it cannot detect the .msu file to improve the user experience (elaborated below).
4. This setup is insanely niche and I would be surprised to see even a handful of hacks resort to this for extra space.
All common methods of playing hacks (snes9x core, bsnes core, fxpak pro, mesen, reportedly snes classic) support msu-1 out of the box without required setup from the user. The only additional requirement compared to a normal hack is requiring the .msu file to be in the same folder as the patched .smc file, and to share the same filename (ignoring extension). The submission ideally has this setup as-is so that patching to the same folder would work immediately, though it's likely someone will want to move the file. A readme file included can provide help information about how the required file is to be used (matching folder + filename + .msu extension) to help in this situation. If the user ignores this, the same info can be displayed upon startup - with additional notes about possible incompatibility (e.g. canoe or other niche emulators) if everything is setup otherwise, or that the hack was incorrectly distributed if no .msu file was provided.
Image sample for when S-MSU1 string not detected:
Image sample for when the data file is not validated (an incorrect file is named myhack.msu through some means):
However if the above hypothetical situations seem still less than desirable for the section, then I can understand being firm about forbidding this use of msu-1. but I'd like to see how many others feel and get additional perspectives.
Tangential follow-up question: These are even more niche and maybe it's even silly to ask, or maybe it'd be better to judge when we cross this bridge - but there are other expansion chips that require the user to provide a BIOS file to play such as DSP or CX4, for certain SNES games. The emulator will always prompt the user to provide it one for the given game. It's theoretically possible to modify SMW such that it uses one of those chips. Would it be considered acceptable to submit to the hack section if it requires this? A disclaimer and similar in-game diagnostic help as the msu proposal could be provided for better UX.
▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
―••~asuka over rei every day~••―
90% of teens smoke weed. if you're
part of the 10% put this in your sig
▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
1. No .pcm files for now, just the .msu file alongside the .bps file.
2. The submitted zip file of said hack conforms to the current 10mb limit, as every other hack does.
3. The hack itself may provide diagnostic info in the event it cannot detect the .msu file to improve the user experience (elaborated below).
4. This setup is insanely niche and I would be surprised to see even a handful of hacks resort to this for extra space.
All common methods of playing hacks (snes9x core, bsnes core, fxpak pro, mesen, reportedly snes classic) support msu-1 out of the box without required setup from the user. The only additional requirement compared to a normal hack is requiring the .msu file to be in the same folder as the patched .smc file, and to share the same filename (ignoring extension). The submission ideally has this setup as-is so that patching to the same folder would work immediately, though it's likely someone will want to move the file. A readme file included can provide help information about how the required file is to be used (matching folder + filename + .msu extension) to help in this situation. If the user ignores this, the same info can be displayed upon startup - with additional notes about possible incompatibility (e.g. canoe or other niche emulators) if everything is setup otherwise, or that the hack was incorrectly distributed if no .msu file was provided.
Image sample for when S-MSU1 string not detected:
Image sample for when the data file is not validated (an incorrect file is named myhack.msu through some means):
However if the above hypothetical situations seem still less than desirable for the section, then I can understand being firm about forbidding this use of msu-1. but I'd like to see how many others feel and get additional perspectives.
Tangential follow-up question: These are even more niche and maybe it's even silly to ask, or maybe it'd be better to judge when we cross this bridge - but there are other expansion chips that require the user to provide a BIOS file to play such as DSP or CX4, for certain SNES games. The emulator will always prompt the user to provide it one for the given game. It's theoretically possible to modify SMW such that it uses one of those chips. Would it be considered acceptable to submit to the hack section if it requires this? A disclaimer and similar in-game diagnostic help as the msu proposal could be provided for better UX.
▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
―••~asuka over rei every day~••―
90% of teens smoke weed. if you're
part of the 10% put this in your sig
▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬