While it's somewhat unlikely that someone would keep a collection of runs, preserving even obsoleted versions of the run, if someone does then the file names (for runs of the same game) would sort nicely by category rather than being randomly interspersed.
OTOH, this case is rather unusual, so I suppose it's not extremely important.
However, one could also make a cosmetic argument: It makes sense that the game name is succeeded by the category of the run because they are more or less related to each other. But as said, this is just cosmetic and there's no right or wrong opinion.
While I like the obsoletion chain idea in theory, that can be a bit hard to implement considering double obsoletions, and site administrators changing them on a whim. Just consider the recent suggestion to use a phantom movie to obsolete.
Given its shaky nature, I don't think it's a good idea to make use of it, and even then, it would be hard to always do right, and could mean renaming published movie files and forcing people to redownload torrents.
I see how it could, indeed, cause technical difficulties. It's a pitty because it would have been more descriptive.
adelikat wrote:
My proposal:
http://tasvideos.org/1279M.html
becomes:
doubledragon2-1279-adelikat.fm2
if a specific category is involved (such as if there was both a 1 player & 2 player versions of this game) then the category would be mentioned too:
doubledragon2-1279-2player-adelikat.fm2
What happens if two games for different systems have the same name? I think (hypothetical names) "nesdoubledragon2" and "genesisdoubledragon2" is a horrible naming scheme (if for nothing else, because it's confusing whether it's part of the game name or something else). Better to use something consistent, ie have the the system name in all the files rather than only in some of them.
The run category should be located before the id (or version) number and all file names should include this category (even if there's only one) so that the file names will be sorted by category and not get intermixed by order of publication.
Thus my suggestion would be:
nes-doubledragon2-any-1279-adelikat.fm2
nes-doubledragon2-2player-2345-adelikat.fm2
On that note, this submission & thread has served a point and reached a consensus. Therefore I am judging this "submission" as rejected by the people.
I don't think there has been such a consensus. If anything, I have seen more of a consensus that past runs which break the rules but have been published anyways ought to be removed. Also the opinion has been presented that if a speed-oriented run has been bested by a regular speedrun, and nobody is obsoleting it anytime soon, it could be put into a poll to see if it should be removed.
Personally I think it's a bit inconsistent that published runs get special treatment with regard to the rules of publication. New submissions will be rejected if they break the rules, but if some past submission got past the radar for whatever reason, then it's forever protected and the error cannot be fixed later.
About audio vs. subtitle commentaries, note that:
- Many people whose native language is not English can understand written English much better than spoken English, especially if the person speaking has a heavy accent (which is not uncommon, especially if the speaker is also not a native speaker).
- The same is true on the other direction as well. The author of the run is usually the person who is most suitable to making a commentary on it, but most people whose native language is not English are often more fluent at writing it than speaking it, so a written commentary would be much easier. (And even if someone would be fluent at speaking English, it might still be easier to just write a commentary rather than speak it.)
- If the commentary is in subtitle form, the video can be paused in order to read the text at one's own pace. This means more info can be included in short segments. This isn't so for audio commentaries.
Spaces in the filename still cause problems with *nix operating systems, and thus should be avoided. Use underscores instead?
Spaces in filenames cause problems basically only with badly-written shellscripts. Of course that doesn't mean it's not a good idea to avoid them anyways.
Nach wrote:
For both types of formats, we don't include system information, which also makes it hard to know which system the run is for.
That's actually a good point. I agree that the file names should contain the system name (nes, snes, genesis, etc). Else if we have the same game name with two different systems we end up with awkward hacks like "genesisgamename" and "snesgamename". Better to be consistent.
I don't think we need to add a publication date once we have the movie number in it.
I think I later redacted that suggestion in favor of the obsoletion chain version number.
I don't think the movie number should be the only thing distinguishing between different versions of the same run. Also author-specific version numbers won't cut either because they don't make the obsoletion chain clear at all. For example, if one movie is versioned as "someauthor-v3" and another as "anotherauthor-v1", which one obsoletes the other? It's impossible to say. (I also agree with the opinion that the author-specific version number is kind of obsolete information in the file name and doesn't really provide much useful information and could be left out completely.)
(One could argue that the movie number tells which movie obsoletes the other. But it tells that regardless of the author-specific version number, so it still remains kind of obsolete.)
The obsoletion chain number provides interesting information (for example it tells how many times the run has been obsoleted in total), so I think it should be included. The movie number is rather abstract and doesn't really tell much.
How about something like this:
system-gamename-category-version-author-movienumber.ext
For example:
psx-saga_frontier-any-v01-knbnitkr-1453.mp4
In many tabletop games where a d100 is required, it's a common trick to throw two (differently-colored) d10's instead, and use one of them multiplied by 10 and the other as is (because a physical d100 is very cumbersome and impractical to use). For example, if you throw a white d10 and a black d10, the white could be used as the tens, and the black one as the ones. The end result is the same as when throwing a d100: An even distribution. (Many die sets even contain a d10 with multiples of 10 instead of regular 0-9 numbers, for this exact purpose.)
However, suppose that you use a variant of this: Throw two d10's and then the larger result is always used as the tens, and the other as the ones. (So for example if you throw a 7 and a 2, then the result is 72, but if it had been a 2 and a 7, the result would still be 72.)
What is the probability distribution now?
The GameBoy Color has a vertical resolution of 144 pixels. What's the point in encoding it with a vertical resolution of 1080 pixels?
EDIT: Ah, I totally forgot about this.
How about this:
Any published run which meets these two criteria:
1) Has been published over a year ago, and
2) presents any of these problems:
- does not comply with the site rules,
- is speed-oriented, but there's a regular speedrun that is faster,
- would clearly not be accepted if submitted today (for some definition of "clearly")
will be included in (or nominated for) a yearly reconsideration poll.
Just an idea for more precise rules. Fine-tune as needed.
Sorry to barge in, but if I remember correctly, the run was known to be seriously suboptimal even before it was accepted for publication, but it was published anyways because people wanted an OoT run so badly. IIRC there was some controversy even back then. "Decent" might not be the best word for that.
I think that your suggestion for the naming and the ordering of the different fields in the name is quite sound.
One small thing, though: If we use obsoletion chain position as a version number, how many digits should be used? The problem arises if we want the file names to sort nicely. If we use "v1", "v2", ... "v10", "v11" and so on, that introduces the problem that most systems will then sort the files as:
somegame-category-v1-someauthor.ext
somegame-category-v10-someauthor.ext
somegame-category-v11-someauthor.ext
somegame-category-v2-someauthor.ext
somegame-category-v3-someauthor.ext
...
which always looks ugly.
Always using two digits solves that problem until some game gets obsoleted 100 times (yeah, not very likely to happen, but theoretically possible).
Now you're saying exactly what I just said.
"We have a process for publishing movies, what process would there be for unpublishing, that someone finds one frame where it can be improved?"
The sentence was somewhat confusing, and I apologize if I understood incorrectly what you were trying to say.
Notice, it's a question.
Also notice the bolded part, what system do we use? There has been no talk as of yet how it would work exactly. Now you mention voting and judging. Okay, does that mean each movie has to be periodically reviewed? What system do you propose?
Someone already suggested doing the same as with the submissions which were saved from the grue to be re-evaluated, but in this case it would be the reverse. That doesn't sound like a completely bad idea to me.
The point in the argument is that we have no quantification setup for this obsoletion idea.
Lots of things here can't be precisely quantified, but they don't need to. That's why we have a voting and a judging system: To overcome that problem. How do you quantify, for example, whether a submission is worthy of publication? You can't. That's why there's a voting and judging system in place. Just because you can't quantify it doesn't mean it can't or shouldn't be done.
We have a process for publishing movies, what process would there be for unpublishing, that someone finds one frame where it can be improved? We'd be effectively opening the door to flush every movie down the drain.
Yes, I can see how a movie being improvable by 1 hour is the exact same thing as a movie being improvable by 1 frame. Completely equivalent, and both should be retroactively rejected, yes.
Why does this same pattern of "logic" always ensue in this type of discussions? Someone makes a suggestion and then someone else will invariably and without fail present a completely ridiculous slippery slope argument to counter it.
The slippery slope argument is not valid, has never been valid and will never be valid. Especially when it's so over the top and exaggerated as this one. (The difference between 1 hour and 1 frame is something like 5 orders of magnitude, which could just as well be astronomical in this context.) Please stop using it. It just doesn't work.
I chose rerecord counts and movie length as such that they wouldn't mess with site statistics in any meaningful way.
The routine which generates the statistics tables considers 0 rerecords to mean "does not have a valid rerecord count, ignore this movie in the rerecord statistics".
Any editor can actually turn that feature on or off by editing the MovieStatistics page. It's specified with the "need=<column name>" specifier. I don't remember now, however, if this could also be turned on for the movie length as well (in other words, a length of 0 would be considered invalid and thus ignored). I wouldn't be surprised if it worked with that as well, but even if it doesn't it should be relatively easy to add.
That would be a much cleaner way than using some "average" values.
I'd say an RPG TAS is not boring to someone who has played the game (especially if he has played it recently, as he can then best see where the tool-assistance and luck manipulation is happening). On the contrary, it often makes a very interesting TAS. In fact, I recommend actually playing the RPG through before watching the TAS of the game.
A 10-hour chess game TAS would be boring even for a chess aficionado.
I wonder if a shortening convention could be used for cases where there are so many authors. An overly long file name can be inconvenient (and some file systems have a limit on file name length, most prominently some commonly used data CD/DVD file systems, IIRC).
Maybe something like "various authors", or the authors could agree on a representative author and have his name with something like "and others" attached to it.
