Documentation questions.

[PL1-Arcade]

1. Which is correct, 0.253 or 0.254?
   README.md says

This plugin is compatibile with:
- MAME 0.253 or newer

src/startplugin.lua says

 -- MAME 0.254 and newer compatibility check

2. README.md mentions that it is compatible with Arcade64, but does not mention MAMEUI.

This plugin is compatibile with:
- MAME 0.253 or newer
- Arcade64 0.253 or newer

I've tested it with MAME and MAMEUI.
Did someone already test it with Arcade64?
Any other forks we should test like HBMAME (may need to make a separate ssf.txt since the ROMlist is different) or NegaMAME?

3. Is the version in plugin.json supposed to be 1.0.0?

"version": "1.0.0",

4. Is there anywhere in the downloaded .ZIP file that shows what version files are enclosed?
   Might be good to have a file that identifies the version (and new features?) like version.txt, changelog.txt, or similar.

Scott

[Jakobud]

Yeah some clarification needs to happen and the comment in the code I think is incorrect.

The plugin.json version is the "version" of the plugin that MAME doesn't seem to really use for anything and I'm not keeping it in line with the actual release versions. Just leaving it 1.0.0 for simplicity until MAME does something about it.

I have tested with Arcade64 but still need to test with MAMEUI.

It sounds like the MAMEUI issues regarding the configuration are now working properly, correct?

[PL1-Arcade]

It sounds like the MAMEUI issues regarding the configuration are now working properly, correct?

I've spot checked all of the issues that have come up so far with the plugin -- AFAIK SSF plugin v2.1.0 is working correctly with MAMEUI.

The configuration process is a bit different than step 3 of the README for regular MAME. (no plugin.ini file, different menu, can't enable the plugin in game-specific .ini because MAMEUI always overwrites the whole file every time by default??!!??, etc.)

Anyone who is already familiar with MAMEUI and plugins will have no problem getting SSF up and running.

• Even as a MAMEUI noob, I managed to get two plugins working at the same time. (SSF + defenderlr)
• Eventually, we'll have to do a fresh install or two to confirm the procedures and maybe get some screenshots.

There are so many MAME forks that it might be better to put the install details for them in a separate file named MAME_Forks.md (?) so the main README.md doesn't get too bloated.

Scott

[PL1-Arcade]

Any other forks we should test like HBMAME (may need to make a separate ssf.txt since the ROMlist is different) or NegaMAME?

Good news: NegaMAME works just like mainline MAME with the SSF plugin. Spot checked for the various issues observed in mainline and everything's working the same.

Not-so-good news: HBMAME is incompatible with changes made starting in MAME 0.246.
Not sure if HBMAME's LUA plugin system code can be updated to include the v0.253 features that SSF uses, but I highly doubt it.

- The file rearrangement is incompatible with the design of HBMAME, so it will stay at the 0.245 base, and releases will have an extra digit on the end (currently 0.245.2)

https://www.1emulation.com/forums/topic/36739-compiling-has-changed-for-0246-onwards/

---

The plugin.json version is the "version" of the plugin that MAME doesn't seem to really use for anything and I'm not keeping it in line with the actual release versions. Just leaving it 1.0.0 for simplicity until MAME does something about it.

Even if MAME doesn't do anything with release version numbers, please include the release version somewhere in the release files.

I know that there are release notes are on GitHub, but there's no release version info in the .zip file.

It's going to take a long time for us to update all of the game settings so it would be good to include the release version so users don't have to guess about which version files they currently have installed.

Scott

[Jakobud]

That is a really good point about the release version. I will do so.

[PL1-Arcade]

That is a really good point about the release version. I will do so.

Did you forget to include this in v2.2.0 or am I missing it?

Whipped up a "whats_new.txt" that covers things through the current release and added it into the develop branch so we don't forget it for the next release.

Scott

[Jakobud]

Ah I did forget that. I will get it next update. The whats new looks good. Github has a way to automatically generate release notes. I might opt for that instead. But maybe not.

[PL1-Arcade]

Are there any repos that you know of that use those auto-generated release notes?

Might be good to see an example or two before deciding which approach you prefer, or if a hybrid approach with an auto-generated file with version/date and a manually edited "what's new" or "milestones" file is better in your opinion.

Seems like a possible downside to auto-generated release notes is if it includes every PR as a separate line item, important new features/improvements could be buried in a pile of "updates to ssf.txt" entries. If it appends to the beginning of an existing file, can we edit the file before either the current or the next release package is compiled?

On the other hand, we wouldn't have to always remember to edit the "what's new" or "milestones" file if a release notes file containing at least the release number/date is automatically included when you generate the package. 🤷‍♂️

However you want us to proceed is fine by me. 😄

Scott

[Jakobud]

Ya that's what I was thinking. If it's just a compiled list of commit messages it would be a bit of a mess.

[PL1-Arcade]

#35 (comment)

As you mentioned in that PR comment, a CHANGELOG.md file formatted like this example would be a good way to go.

https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md

Scott

[PL1-Arcade]

First draft CHANGELOG.md file uploaded.

b0889e6

Questions, suggestions, and some reference info concealed in the Markdown comments.

Scott