The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
damn you're savage. I want to be like you when I grow up
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logical and polite way to challenge somebody else's position...
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logic and polite way to challenge somebody else's position...
There's no challenge. The goals of the TASVideos community and the SM64 community are not compatible. I agree with the position; SM64 speedrunners should stop submitting movies to TASVideos and TASVideos should stop publishing them.
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logic and polite way to challenge somebody else's position...
There's no challenge. The goals of the TASVideos community and the SM64 community are not compatible. I agree with the position; SM64 speedrunners should stop submitting movies to TASVideos and TASVideos should stop publishing them.
May I remember the SM64 TAS Community, not just SM64 Community. A community that's apparently more interested in having a TAS done in emulator which emulates the game better than the emulator TASVideos.org has decided to choose. TASing is something with a very simple goal: finding out what's the fastest way to complete a game. And if that's being done in an emulator that can't even stay true to the original game, it doesn't make sense. It's completely nonsensical that the TASVideos community isn't capable of understanding that. There should not be any room for incompatibility, but still TASVideos finds it.
The solution is obvious. The "BizHawk or bust" rule is a failure, and people who actually TAS N64 games clearly dislike it. Allow Mupen (even if BizHawk is still preferred), or risk not getting new N64 runs on your site. Easy.
Does that mean you'll go away forever? Because that sounds awesome!
What a very logic and polite way to challenge somebody else's position...
There's no challenge. The goals of the TASVideos community and the SM64 community are not compatible. I agree with the position; SM64 speedrunners should stop submitting movies to TASVideos and TASVideos should stop publishing them.
Aside from the not-so-mature comment, I totally agree with your last thoughts about this situation. Sorry for the troublesome conversation =)
TASvideos has been actiing very authoritarian about many things imo. A lot of the rules just seem unnecessary over what's supposed to be a hobby for fun. If any separate tas community can afford to leave tasvideos, it's the sm64 tas community.
DeRockProject: the Life-changing Project
(TAS is perfection in this imperfect world. TAS is the answer to the longest math problems we have, called video games. TAS perfects worlds. TAS is god. TAS is the future. TAS needs us. Let it govern us. All hail TAS.)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
As usual this topic has turned into a mess of personal attacks. What else is new?
I wanted to look into a compromise for the different parties involved here, but I (as TASVideos administration) am really just stuck between a rock and a hard place here.
It's clear that BizHawk's N64 emulation has issues with timing severe enough that Mupen actually looks like a preferable solution. This is a very poor situation in itself, but it's also not easy to change. N64 emulation in general is just in a very poor state and there are barely any decent options.
On the other hand, Mupen has plenty of encodingissues which makes them a very large pain to publish. This was also one of the main reasons that Mupen was blocked to begin with. Publishers simply do not want to touch Mupen because of how horrible it is to encode Mupen, and Aktan is also just one person.
With Mupen blocked, SM64 TASers clearly don't want to submit. With Mupen unblocked, publishers won't want to publish. With better N64 timing in BizHawk, this problem could be sidestepped, but who would or could make that happen? And how?
How do you come up with a reasonable solution for each of these parties (that isn't just splitting both communities into going their own way)? I honestly have no idea at this point.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
How do you come up with a reasonable solution for each of these parties (that isn't just splitting both communities into going their own way)? I honestly have no idea at this point.
Joined: 12/28/2013
Posts: 396
Location: Rio de Janeiro, Brasil
An exception has just been opened for a non-SM64 TAS which was made in Mupen and published here. So there is a pretty simple solution - while there is an actual reason to use Mupen instead of Bizhawk, just let them submit Mupen movies. SM64 TASes are always a 'big deal' in the site, pretty sure some publisher will be up for encoding it.
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Ethan White wrote:
Mothrayas wrote:
How do you come up with a reasonable solution for each of these parties (that isn't just splitting both communities into going their own way)? I honestly have no idea at this point.
Allow Mupen. (:
I like how simple you make it look, but entirely ignoring half of the argument does not really make a solution. There are reasons I'm not just immediately going there and those reasons need to be addressed properly.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
I like how simple you make it look, but entirely ignoring half of the argument does not really make a solution. There are reasons I'm not just immediately going there and those reasons need to be addressed properly.
The TASers can encode it if the publisher doesn't want to
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Ethan White wrote:
Mothrayas wrote:
I like how simple you make it look, but entirely ignoring half of the argument does not really make a solution. There are reasons I'm not just immediately going there and those reasons need to be addressed properly.
The TASers can encode it if the publisher doesn't want to
Do you think they can reliably follow TASVideos' encoding standards?
Keep in mind this is more than just throwing a high-res dump on YouTube, it's also things like 10-bit 4:4:4 downloadable MKV files, subtitle placement, logos, optimal size to quality ratios for downloadables, and so on.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 12/28/2013
Posts: 396
Location: Rio de Janeiro, Brasil
Honestly, the site would lose more from not having SM64 runs than from having a encode whose MKV files aren't 10-bit 4:4:4.
That issue probably wouldn't even happen though. Somebody would surely be willing to correctly publish a SM64 TAS made in Mupen. Maybe it's not a bad idea to allow this emulator for the N64 games that work more accurately on it than on Bizhawk.
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
Plush wrote:
What was not fine in the encoding of the 120 star TAS, for example?
You mean the one by our publishers, or something else? Did anyone else make downloadable encodes for that TAS?
If the former, nothing wrong with it - just that it took a month or two of a publisher's time. If the latter, what are you referring to exactly?
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
What was not fine in the encoding of the 120 star TAS, for example?
You mean the one by our publishers, or something else? Did anyone else make downloadable encodes for that TAS?
If the former, nothing wrong with it - just that it took a month or two of a publisher's time. If the latter, what are you referring to exactly?
On the other hand, Mupen has plenty of encodingissues which makes them a very large pain to publish.
I looked at some of those encoding issues:
"Consistency is optional: Playbacks fail to sync or sync differently on different playthroughs for no apparent reason." Mupen basically never desyncs like that. It only desyncs if you load state or save state or something stupid on the first frame of the TAS.
"fails if monitor goes into powersaving mode" this only happens if aero is turned on. Just turn it off.
"captures parts of windows and menus in front of the capture window" that's annoying but can be avoided by not putting anything in front of the Mupen window.
"no 2GB split" There is an AVI-splitting version of Mupen. It Only splits 26 times (which is annoying), but it works.
I'm just popping in to point out that completely ignoring the part where it took a long time is actually a bit disrespectful to the person who did the encodes. Their time is also donated to the site, and they tend to get fewer accolades than the runners, but tend to spend as long, if not longer, contributing to the site overall.
I've been a reasonably minor figure on both sides of the player/publisher divide, and I can assure you that encoding with Mupen has been a pain that I've had the displeasure of experiencing. Please don't minimize the actual problems that it represents.
And, I understand that you think you've rhetorically outwitted Mothrayas here. But as far as I have seen in this thread, he's been as or more polite to you than anyone else. Please return that courtesy. We all have similar goals here.
natt is in the thread, why not open a dialog and try to help him, if he's willing? If emulator accuracy is the problem for you accepting BizHawk, wouldn't that be the most reasonable thing to do? I'm sure you have more than a few test cases that might be useful. It might not be as easy as trying to bully staff into accepting an improvement, but I think we both can agree it's more useful and sustainable.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
I'm just popping in to point out that completely ignoring the part where it took a long time is actually a bit disrespectful to the person who did the encodes. Their time is also donated to the site, and they tend to get fewer accolades than the runners, but tend to spend as long, if not longer, contributing to the site overall.
I've been a reasonably minor figure on both sides of the player/publisher divide, and I can assure you that encoding with Mupen has been a pain that I've had the displeasure of experiencing. Please don't minimize the actual problems that it represents.
And, I understand that you think you've rhetorically outwitted Mothrayas here. But as far as I have seen in this thread, he's been as or more polite to you than anyone else. Please return that courtesy. We all have similar goals here.
natt is in the thread, why not open a dialog and try to help him, if he's willing? If emulator accuracy is the problem for you accepting BizHawk, wouldn't that be the most reasonable thing to do? I'm sure you have more than a few test cases that might be useful. It might not be as easy as trying to bully staff into accepting an improvement, but I think we both can agree it's more useful and sustainable.
Legit sorry if that sounded disrespectful. I said that simply because I had nothing else to say: I realize how tough it must be to encode with Mupen so I'd just say it's better not to publish at all (which is the thing I've been saying the whole time)
Joined: 8/14/2009
Posts: 4089
Location: The Netherlands
adelikat proposed an alternative compromise: the movie is still submitted as a BK2 file, but the displayed time will be changed to reflect that of the equivalent M64 file.
Would this work for you? This would solve the SM64 community's gripe with the BK2 reporting an off time, while publishers can still encode and publish in BizHawk.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Joined: 7/16/2017
Posts: 1
Location: A pale blue dot in a sea of black
andypanther wrote:
One community is stubborn, so what? Not getting new SM64 TASes for a while is an acceptable price to pay to make the site better for everyone else.
The reason people are being stubborn is because they believe there are unresolved issues with the current system in this context. Ignoring these issues & just letting the SM64 community leave TASVideos behind risks missing out on a real issue, and making your site worse. It's better to resolve the issue than ignore it & hope you're the one in the right.
[Edit] The issue looks like it might be pretty much solved.
adelikat proposed an alternative compromise: the movie is still submitted as a BK2 file, but the displayed time will be changed to reflect that of the equivalent M64 file.
Would this work for you? This would solve the SM64 community's gripe with the BK2 reporting an off time, while publishers can still encode and publish in BizHawk.
That's fine by me. Please don't get me involved with having to do stuff like writing for publication etc
