Using `len(self.slots)+1` to arrive at a slot number for new saves has a flaw

[JSearUK]

Which is that players can delete slots, creating a gap - possibly several, of various sizes - in the series of occupied slotnumbers:

• player makes new playthrough
• player makes first three saves, slots 1, 2, 3
• player deletes 2 (possibly by removing it as a diskfile from both save locations - we're catering to devs as well as players)
• player tries to make new save:
• len is now two;
• slot 3 gets overwritten.

[JSearUK]

When I was cramming data into filenames - which we may still have to resort to doing - I didn't want the filename getting too long and potentially running into OS filename-length issues; I reckoned Win/linux systems would cope, but I wasn't too sure about MacOs/Android. So I limited the field lengths -

My input screens were ported and tweaked from another project of mine, so the 35 character limit for player names was already present in the code. That seemed a reasonable length to permit flexibility, while still being manageable at a sensible font size, so I left it. But 70+ characters was already making me nervous. I reasoned that no player would need more than 10000 saves in one playthrough (my Skyrim/Fallout playthroughs typically run to 1600 saves), so I allowed 5 characters (which should have been 4...) and zero-padded it so that max() and .sort() would perform correctly. So far, so good -

Then I considered that slot numbers would only ever go up. It was conceivable (if highly unlikely) that a player could hit the cap, have deleted all saves except number 9999 - and be unable to save any more. Therefore, saving in lower slots needed to be a thing... which led to sorting by Slot Number (not just Most Recent), so that people could see said slots, and then the ability to choose a slot to save in (given the range of a series of empty slots). And it all worked rather well :P

However! Now that we have infinite slotnumbers, most of those concerns have gone away. If we choose not to implement this behaviour in the rewrite, there may no longer be much point to the sorting options. slot_num could become an integer for real, thus dodging a lot of try/except's

[JSearUK]

Either way around, the + New Save + button that saves to the slot that is +1 higher than the current highest slot number - or the new Most Recent - needs to be at the top of the slots list, so that the player doesn't have to do any scrolling to find it. Right-click to open Save screen, click once on + New Save + and done.

I have moved the + New Save + button to the top, but made no other changes; it still prompts for a name, etc.