Canceling and resubmitting is not necessary to update the movie file. Instead, simply ask a judge to replace the movie file for you. Please keep this in mind for the future.
Site:https://tasd.io/
JS/TypeScript and Rust parsers should be available soon. Go, C, and Python parsers are likely to happen in the future.
The site cannot be reached at the moment.
Hmm you're the only one who I've heard that can't access it. I've tried several different VPN locations too, and the site itself is actually github, so not sure why you wouldn't be able to access the site. You can download it though, either as a text file or HTML https://github.com/tasd-org/tasd-spec/releases/tag/v1 Dimon12321 wrote:
Why specifically these languages? Why not Java, for example?
Those are the languages people have told me they are either working on parsers for (or would like to soon). There's no reason a parser couldn't be made for Java, I just don't know of anyone who's planning to do that.
I am proud to announce, Version 1 of the Tool Assisted Speedrun Dump (TASD) format specification has officially released!Site:https://tasd.io/Github:https://github.com/tasd-org/tasd-spec
Feel free to ask questions here or message me in Discord.
TAS Replay Refresher
In order to properly replay a TAS movie on real hardware, we need a sequence of controller inputs to feed to the console. However, due to how most emulators are designed, the input values a TASer sets in their movie does not necessarily represent what a real controller is doing.
For example, most cores in BizHawk represent each row in TAStudio as a single input for an entire frame. However, in reality, the console may be reading inputs from the controller multiple times, or even zero times, during each frame. In order to rectify this inconsistency, scripts are used to "dump" the inputs into a new format that contains sufficient information to replay the TAS.
History
Previously, dump formats were designed to be "good enough" for the immediate use-case of the person replaying the TASes. After I had started console verifying TASes, I quickly began noticing the severe limitations of those old formats (e.g. no reset support, different interpretations of the data, no way to identify which ROM to use.) So I felt there needed to be a new format; ideally something that would work regardless of which console or replay device was being used.
ViGrey and I started this project back in 2021 after we both shared interest into creating a new format. Vi has been a massive help, writing up the bulk of the specification document and working with me to form the core layout and structure of the format. Progress has been especially slow the last few years; I hadn't worked on it at all during 2024. Slowly but surely though, work has progressed and here we are.
Feature Highlights
TASD is designed to be as hardware and software agnostic as reasonably possible. Both the creation and parsing of the format should be doable on most architectures, even microcontrollers, and with (practically) all programming languages. While intended as a file format, it can also be used to stream input and configuration data (no reliance on pointers to other files or other segments of data).
The format itself explicitly supports the NES, SNES, N64, GameCube, Game Boy / Color / Advance, Sega Genesis, and Atari 2600. Adding additional systems is relatively simple and won't break backwards or forwards compatibility. Though, software will still need to be written to handle these systems appropriately.
Other metadata is supported too. Such as attributions (for several different roles), ROM identification, verified status, game-genie codes, memory initialization, and more!
Check out the specification for all the details. A word of caution though: it's very dry reading! There may still be some ambiguities or wording issues that I've missed, so let me know if something doesn't sound right.
Dump Scripts and Parsers
Nothing at the moment... Getting the specification out first was higher priority.
JS/TypeScript and Rust parsers should be available soon. Go, C, and Python parsers are likely to happen in the future. I have an outdated Lua serializer that I'll either update or rewrite eventually.
You're not wrong. Although, those submissions also included completing the game as a goal. The first chose to complete the game in addition to the primary artistic goal. While the second was to minimize the number of A presses needed to complete the game.
feos wrote:
Bigbass wrote:
Game completion solely for the sake of game completion doesn't add any artistic value in my opinion. Especially for this game, simply completing the game isn't special or unique (and thus doesn't contribute toward entertainment or artistic values.) Perhaps if the completion was performed in an uncommon way, like how "game end glitch" movies complete a game through unconventional means, then it could further an artistic goal, but still not the artistic goal of this movie.
MovieRules wrote:
For non-standard goals, in addition to any of the above, the movie can also be ended at some logical or artistic stopping point that makes sense.
If the artistic intention of the non-standard goal is to grab all trees in the game, then it makes sense to me that the artistic stopping point is whenever that goal is complete.
IMO you're reading that rule backwards. Its point is not to allow game completion as an option if it makes sense as a part of the main goal. Its point is to require some closure, most traditionally game completion, but there are other options if their reasoning can be articulated and agreed upon.
Nothing in the way the rule is written indicates to me that its purpose is to require closure (game completion) beyond the non-standard goal(s) of the movie. Maybe the rule's wording needs some improvement to clarify its intent.
Right now, it reads to me like as long as the goal is non-standard (grab all trees), then it's allowed to end based on something logical or artistic (grab final tree). I'm curious how others interpret this rule, especially non-staff or people reading our rules for the first time.
feos wrote:
It's already optional in Playground, which is fine for all kinds of wild experiments. The only problem with it is that it never got as much promotion on the site as regular publications, but every time I try to dedicate time to that, other site duties take over (or burnout). Even then it doesn't mean that PG should fully merge with Alt, because there are still technical rules that make publication problematic.
Apologies if there was some confusion on my part. Originally it sounded to me as though you were saying the movie was invalid because it chose to end the TAS early; sorry if I misunderstood. I'm not arguing towards any particular publication class, I leave that up to the judges. Rather I'm voicing my opinion that it appears to be a sensible artistic choice to end the TAS when the goal is completed.
At the first glance, I don't see why ending input mid-game is an essential (logical or artistic) part of the "all trees" goal and why game completion would make it worse in any way.
Personally, I feel that given the goal of the TAS is to grab all trees, going out of their way to do something that doesn't further that goal in any way is entirely unnecessary. The stated goal is to "grab all 87 trees in the game in record time," not to "grab all 87 trees, and beat the final boss, in record time."
Would game completion make it worse? Perhaps. It would certainly lengthen the TAS, which hurts the "record time." The extra time needed to complete the game isn't related to grabbing trees, yet it would still become part of the TAS.
Game completion solely for the sake of game completion doesn't add any artistic value in my opinion. Especially for this game, simply completing the game isn't special or unique (and thus doesn't contribute toward entertainment or artistic values.) Perhaps if the completion was performed in an uncommon way, like how "game end glitch" movies complete a game through unconventional means, then it could further an artistic goal, but still not the artistic goal of this movie.
MovieRules wrote:
For non-standard goals, in addition to any of the above, the movie can also be ended at some logical or artistic stopping point that makes sense.
If the artistic intention of the non-standard goal is to grab all trees in the game, then it makes sense to me that the artistic stopping point is whenever that goal is complete.
1. I understand that it's not a requirement, but I am so used to movies beginning with the bios sound. Also, the audio on LSnes doesn't seem to be as good as that on BizHawk.
lsnes is clearly defined as one of the preferred and accepted emulators for GB movie submissions. Additionally, the desired goal of this TAS was clearly achievable using lsnes despite any emulation differences that may exist. As such, implying that Bizhawk is a better option or that lsnes shouldn't be used, isn't warranted. You personally may not like lsnes being used for submissions, but people are completely allowed to use it if they wish to.
DJ_Incendration wrote:
2. I get that it's easier for them to understand, but it's a lot harder for us.
I doubt the language of the text matters given the goal of this submission. Regardless, I'd much rather the person putting in all the work to create the TAS be able to understand what the game is doing, than for the convenience of being able to read the text myself. In any case, the site's movie rules explain that "regional differences such as text and cutscene length are not counted as improvements or time losses." So no, the region choice will not be considered.
I haven't had much luck with Mario 3 rom hacks so far.
Coincidentally I just attempted SMB3Mix and SMB3 Ridley X Hack 6 earlier today. Both desynced after several minutes. Think the former reached about 8 minutes in.
I've always had trouble with SMB3 and I think the cause may be an inaccuracy in FCEUX's PPU emulation. In some games it seems like there's just enough timing inaccuracy that a "lag" frame happens when it shouldn't. You can sometimes see it if you switch between Old and New PPU modes. Though I think the New PPU mode also has problems. It's something ViGrey and I discussed some years ago, as he noticed something similar too.
There have been SMB3 runs verified that used FCEUX, but very few, and some were via resyncs to bizhawk. The recording for [2835] NES Super Mario Bros. 3 "all levels" by Lord_Tom & Tompa in 1:04:36.90 even notes that sometimes the replay desyncs. So I'm inclined to believe it's an emulation issue.
Hi guys. I'm new here. I study some things about TAS, but I never make a movie. I want to make a TAS of Human Cannonball (Atari 2600) and I'm looking for some trips. I already have a source code in lua with a test version. The last input occur in frame 1946 and I don't know to improve this. I don't know how to use TAStudio. I always use Lua Console.
Using Lua in this way is a highly inefficient way of making a TAS and isn't something I'd recommend. It'll be a whole lot harder to make changes and step backwards/forwards through a game, than it would be if you were using TAStudio.
For learning how to TAS and how to use TAStudio check out our Wiki: TasingGuide page and this playlist by The8bitbeast.
Updated console verification using #638750777182992609:Link to videoEdit: Note this is outdated again. I'll see about getting a new one recorded soonTM. (don't delay publication)
If you look at the workbench, there are numerous TASes that have been submitted earlier than yours that have also not started being judged yet. There are not enough staff to take on every submission immediately.
I'm not saying that I'm suffering the worse fate. I can only speak for my self, and for this submission alone.
For comparison, most of the other submissions you've mentioned are less popular games, not a Star movie on this site.
Judges may be more inclined to process submissions for games or platforms they personally enjoy or understand more than others. But otherwise, the fact the current publication is a Star movie doesn't affect the speed at which judges are obligated attend to improvement submissions. There's no practical reason why an improvement must be judged sooner than other submissions.
HappyLee wrote:
Bigbass wrote:
Your attitude isn't appreciated nor welcome on this site. If it takes 3 months, then it takes 3 months, there's no harm in that. Please be patient, working through the submission queue takes time.
No harm? No harm to delay a submission for months, whether on purpose or not on purpose?
For comparison, Bernka's submission in 2012 took only 4 days. Maybe learn a thing or two from that? Maybe try improving yourselves before criticising my attitude?
I'd say TASVideos has improved quite a lot since 2012, and I'm confident that many others in this community would agree with me. The fact we have so many more submissions from so many different authors is evidence of that. We've been able to publish TASes that would have never been permitted back then.
As a result of the increased submission rate, the submission queue can understandably take longer to process. Submissions may reside in the queue for awhile longer than they used to, but again, I see no harm in that for the authors. Of course, we don't want the queue to grow faster than we can process submissions, but there's only so much we can do with the resources we have. Judges are volunteers. Volunteers who have lives and responsibilities outside of TASVideos.
We're also always looking to grow the team of judges as well as reduce their workload. Which is precisely why we've taken steps to implement Reviewers and Sync Verification.
Taking all of that into consideration, please try to be patient. Being adversarial will not speed up the process.
It's been 20 days since our TAS was submitted. It's still "new", no one's judging it.
Since this is an improvement over a Star TAS on this site, it should be an easy decision to me.
There are 15 other "new" submissions in the queue that are older than this one, and many more that are currently being reviewed by judges. Furthermore, 20 days is not that long of a wait, regardless of how "easy" it might be to make a decision. Also keep in mind that once a judge has claimed a submission, the judgement process is more involved than just seeing the author state there's been an improvement and pressing the accept button.
HappyLee wrote:
I'd hate to wait for 3 months to see this published. Hopefully TASVideos's better than that.
Your attitude isn't appreciated nor welcome on this site. If it takes 3 months, then it takes 3 months, there's no harm in that. Please be patient, working through the submission queue takes time.
We will not rush judges or push them to take on more work than they are willing to handle. We will also not give special priority to you just because you want the process to go faster.
* The game itself is just a clone of an already existing game, meaning there's no reason to not TAS the original, unless this version had substantial changes, which it doesn't (this is the biggest problem in my opinion).
Geometry Dash does not have a native linux release. Unless there's some other way to TAS it that's acceptable by this site, going with a TASable demake seems reasonable to me.
Mikewillplays wrote:
* Remember how I said there were only two elements with optimization. Well, one of those elements isn't even optimized! There was no consideration for what stage should be played last in order to end inputs as fast as possible, which I wouldn't care about if it wasn't one of the only two things you could optimize.
I don't think it's fair to so harshly judge past submissions for improvements that weren't discovered until later. You didn't provide this feedback on the previous submission, and the judge didn't think of it either.
Thanks for elaborating. In the future, I'd strongly encourage you to provide more detailed feedback upfront, instead of bluntly saying something is "the worst TAS" ever. If you believe there are improvements that can be made to a submission, please offer them constructively.
since I think the original publication is the worst TAS to ever be published.
That is a rather strong opinion with no backing evidence or reasoning. Since you didn't comment (or vote or review) the previous TAS, could you elaborate why you feel this way? How does this improvement change that opinion?
I looked at a trace log, and it looks like the primary issue is that the game polls for input constantly. Most games poll input during or immediately after vblank, but apparently polling for input is this game's version of a busy loop. This means both emulation timing (in the case where a latch happens to fall near an NMI), and how / when the emulator handles input, are both factors for sync.
Additionally, I just discovered that the quickerNES core doesn't support Lua memory callbacks. So even if the accuracy was there, I'm not sure how anyone would reliably dump the inputs.
Definite yes vote on entertainment! Seeing 3, 4, 5, if not all the balls, sunk in a single shot is a wonderful sight.
Unfortunately, I wasn't able to console verify it. The TAS consistently desynced at the start of the first stage. Didn't investigate any further, but it seemed like the game ate the input(s) to aim and/or fire the first shot.
Welcome to TASVideos starleaf!
Submitting a TAS on this site means that you intend for it to be published (if accepted). A publication gets a high quality encode uploaded to the site's youtube account, and a dedicated publication page. As part of the curation process, submissions must follow a set of rules. However, as others have noted, this TAS is rather unoptimized and slower than the current record for this category.
If you only wanted feedback instead of publication, then please upload to the site's Userfiles. From there, you can share your userfile and request feedback on either the forums or our Discord server (#tas-feedback).
In the future, please also review the submission instructionsbefore submitting a movie. On the "Submit Movie" page, you should have seen a large box at the top that included a link to these instructions.
Not sure about the emulators, but no one has console verified any TASes for this game yet. I have yet to try the newest "no abilities" one (which uses Bizhawk 2.8).
I have however tried [3318] NES Kirby's Adventure "game end glitch" by TASeditor, MESHUGGAH, CoolKirby, Masterjun, MUGG & illayaya in 00:35.76 quite a few times on hardware. From what I recall, Kirby would always end up doing something differently than what the TAS expected. Like not jumping at the exact right moment. I've never tested with RAM initialization though (don't have the hardware for that), so maybe that would make a difference.
I have 0 idea what to make of a movie that console verifies on a practice ROM, yet doesn't on the original (unless I interpret it wrong.) Is it possible to extract the inputs from the macro to work on a non practice ROM? I'm very curious.
I'd be quite surprised if this TAS worked on the original game ROM. Even if the game was more reliable, like Super Mario 64 is in regards to input handling, the practice ROM clearly modifies the behavior of the game in several ways. As outlined in ch4 and ch5 of the practice ROM's manual. Maybe the modifications don't affect the game/system behavior enough to matter? That certainly doesn't seem to be true to me, but I guess it's possible.
The ability to successfully replay the TAS's inputs using the practice ROM, only proves that the TAS verifies on the practice ROM (i.e. a modified version of OoT). The practice ROM is effectively no different than a ROM hack, in my opinion. The gameplay may be very similar, but it definitely appears that they are still two different "versions" of the game.
Moreover, because of the modifications to the game, I personally feel that this run is specifically a TAS of the OoT Practice ROM. Not a TAS of the original OoT. I'm not saying the run is invalid or anything like that, rather just that the distinction should be clearly stated where applicable.
When a submitter or author cancels a submission, it means that they do not wish for the submitted work to be judged.
The whole premise was based on the fact that its not the case, its more of a way to save time and efforts on both ends.
Its not something I would sometime do and sometime not, all my cancels are based on that premise.
Now im not saying that to have a discusion about the rules themselves, just that "they do not wish to be judged" doesnt match whats really going on, in some cases.
Inactive authors are just inactive, so theres no way either they would just magically uncancel their stuff because you deemed thats how it has to be done.
Cancellations can happen for other reasons on a case-by-case basis. For example, an author might ask for a delay, and then disappear. A judge will likely cancel the run on behalf of the author. One way or another, cancellations effectively mean that we cannot proceed with judging until the author(s) choose to uncancel (or make a new submission).
I cannot comment on what may or may not have been said to you in the past regarding the movies in question, as I wasn't active during that time. But regardless what the motivations were, it was still cancelled.
Every run I did cancel (and not just me I think) was because I was told it was gonna be rejected, so to save time or efforts on both ends.
If uncancel is not a thing done by the site, most of the cancels for that reason will not be uncancel, either ppl are not active anymore or god knows what other reasons.
Authors are allowed to uncancel previously canceled submissions if they wish (and if they were the submitter). The site's movie rules have had significant changes in recent years, greatly expanding what kinds of movies are accepted for publication. If after reviewing the rules, and/or discussing with a judge whether old submissions might now be acceptable, you now feel like uncancelling a submission or submitting new work, you may certainly do so.
arukAdo wrote:
I dont exactly see the problem since the credits are respected even while uncanceling.
When a submitter or author cancels a submission, it means that they do not wish for the submitted work to be judged. It wouldn't be right for us to process (and potentially publish) work without consent of the author(s). If the author later wishes to proceed with the judgement process, then as noted above, they can freely do so.
That all said, this thread is specifically for suggesting and documenting rejected submissions that might now be acceptable due to a rule change. Not to discuss the rules themselves or any other site policies.
