Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
boct1584 wrote:
The short version is that it just says you have to give credit where you used the other persons' work.
So, it looks like the license doesn't contain an answer to the question of this topic.
The question is: if the majority of original movie was copied (no matter how), should the original author be considered a co-author or not?
boct1584 wrote:
There was a LOT of brouhaha about whether copying strategies is the same as copying input when [1860] GBC Pokémon: Yellow Version "save glitch" by p4wn3r in 01:09.63 was submitted, because it was a direct re-creation of a movie by gia, but he (gia) never submitted it or released the VBM, so p4wn3r was basically recreating it from scratch. I believe the final consensus was was summed up in the analogy "the strategies are like a recipe, the final input is like a cake. TASVideos accepts cakes, not recipes."
I think it's not even a question, of course copying strategies is perfectly fine.
I was mostly saying that copying input is also fine. We just need to figure out the best way to attribute authorship.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
Given that the keypress files are published under a certain publication license (hidden somewhere in the innards of the website), said license already stipulates how the original authors have to be credited.
The link to the licence is right above, in RachelB post. However, I don't see an exact wording how the original author shall be credited. If you see it, please quote the text.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
RachelB wrote:
As long as credit is given, there's nothing ethically wrong with copying someone's input, because they've already given permission for anyone to do so.
Yes, but the credit can be given in various ways: either just mentioning the old author in submission text, or adding their name as a co-author, or not mentioning the name at all (since the name is already mentioned in current publication, which is going to be obsoleted and thus linked back). Currently, the chosen way of giving the credit depends completely on the new author's attitude. Perhaps we could elaborate some general rules (when it's better to add a co-author and when there's no need).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
creaothceann wrote:
Hex editing is a valid tool though.
And that's why it's incorrect to draw the line between "copying input" and "reproducing the same input by hand". You have no way to tell which method was used, and both are valid options if the result is going to be the same.
I think I know why many people tend to draw the line here. With old tools there was physical delimitation between using rerecords for testing alternative approaches (actual TASing) and using an external hexeditor for splicing/copypasting (resyncing).
But since the progress doesn't stand still, you have to account the fact that it's perfectly possible to do both activities at the same time (e.g. in TAS Editor), so a quick copypasting + semiautomatic resyncing becomes as natural and trivial as using Frame Advance. Both activities (TASing and resyncing) blend together seamlessly - a moment ago you were experimenting with the first pipe in SMB, and in the next second you're splicing HappyLee's version of running to the end of 1-1. Of course you could record your own playthrough for the level ending segment (and maybe later you will rewrite it just for the sake of owning the entire input), but doing it mid-TASing would be inefficient, because you only want to quickly resync the level to the end, to see if your improvement doesn't break the flagpole glitch. Most likely it does, so the improvement fails, and you are going to lose a lot of time if you're afraid of copy/paste tool.
Copying input is similar to using third-party code in programming. Many people like to create their own bicycles, but emotions aside it's usually more efficient to use known frameworks/libraries/implementations. Especially when prototyping/experimenting, where big investments are undesirable.
Software developers kind of solved the ethical question - the code is distributed under many different licences. I guess we need some similar instrument of regulation, but taking into account the nature of TASing. Just please don't go for any naive restrictive approaches, which would be counterproductive.
For example, if you're going to play the "common sense" card saying that an honestly reproduced strategy usually contains slightly different input, then it's not going to work. Once you start detecting "copypasted parts" by comparing input logs, people will start adding semi-random noise (e.g. holding jump button when in air, or holding Start button longer, etc), and FYI this is incredibly easy to do in an Input Editor with Auto-restoring feature (basically, you select a segment you want to obfuscate, then start adding/removing buttonpresses while watching the constantly updated results of emulation and undoing any radical changes).
---------------------------------------------
TL;DR: Hexediting has nothing to do with ethics. It's just a tool. And the question of ethics should be solved by introducing various co-authorship models instead of the single existing model ("the last author gets everything").
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
xloctis wrote:
Вопрос интересует. Есть ли здесь люди с DesMuMe разбирающиеся? Имею 14260 фреймов ран на N+ NDS. Спросить просто сейчас хочу на ранней стадии пока это все.
Людей нет, первым будешь. Но всё равно спрашивай.
xloctis wrote:
а вообще как ломать игры? я в плане того что "corrupts savedata/game" и получать от этого профиты на что смотреть надо?
Нужно сразу понять, что чудес не бывает, и все удивительные вещи достигаются банальным трудом. Вот тут один товарищ случайно наткнулся на странный глюк, другой смог повторить его на запись, а потом я взял этот мувик и изучил происходящее в дебаггере. Убил считай целый день (пусть даже несколько часов, но всё равно же потом больше ничего уже делать не хочется), а в результате этот глюк для пользы дела толком и не использовать никак, потому что возможности коррапта памяти этим глюком очень ограничены - только Zero Page и только прибавление единицы, а не запись любого желаемого числа. Короче, не повезло с глюком.
Ну, это чтобы не было иллюзий, будто с любой игрой можно сделать что угодно. Не так уж много ТАСов корраптят память, большинство всё-таки не выходит за рамки геймплея (но всё равно доставляет удовольствие при просмотре).
Заметь, пока что все игры с "corrupts RAM" были на NES/SNES/GB.
Игры для этих платформ люди писали на чистом ассемблере и дебажили с помощью неудобных хардварных дебаггеров - естественно, им было легко ошибиться. Да и никаких фреймворков тогда не было, разработчикам приходилось писать даже функции BIOS'а для своей игры, не говоря уж о функциях операционной системы (менеджменте памяти). Обработки исключений не было и в помине. ООП практически не было (хотя были самопальные велосипеды на тему осмысленной группировки данных), MVC и всяких шаблонов, позволяющих упорядочить код (хотя бы корректно отделить системную логику от геймплейной) - тоже не было. Короче, хаос был.
А на NDS люди уже писали под современные компиляторы C++, с использованием динамического выделения памяти (а некоторые, я слыхал, вообще использовали всякие смарт-поинтеры и даже какие-то местные реализации Garbage Collector) - то есть менеджмент памяти там уже реализован специально обученными людьми и не лежит на плечах разработчика игры, так что сделать какую-нибудь фатальную ошибку (как в Battletoads) на DS было намного труднее. Как подтверждение - пока нет ни одного ТАСа для NDS, который бы реально корраптил ОЗУ (глюк с SRAM в Chinatown Wars не в счёт, там, как я понял, используется ошибка в скриптинге/игровой логике). И я сомневаюсь, что в такой простой игре, как N+, можно обнаружить какую-нибудь серьёзную уязвимость. Советую просто сделать скоростной пробег всех уровней - мне бы, например, было интересно его увидеть.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
AndiHoffi wrote:
Before diving into the details, I would be interested in knowing who in this thread did actually know A*-search before reading this topic.
I used A* for pathfinding in an unfinished prototype of a 2D-maze-like game. Actually, at first I used a simple Dijkstra algorithm and all was well, but then I started overenginneering for no reason (hence "unfinished") and added simple heuristics formula (distance to the end tile). Can't say the performance was noticeably better (on some convoluted maps the simpler algorithm was even faster, while A* was better on empty fields with a few obstacles), but at least it worked. In a static map. Then I added moving obstacles and it became apparent that units have to recalculate their path every frame from scratch, because the map already changed since previous calculation. Well, of course in real development they use various tricks to minimize this problem (while also reducing the quality of pathfinding, which isn't noticeable when playing in realtime), but I don't think those tricks are applicable when we want perfection. So I started trying to make the evaluation formula more complex (take into account the nature of moving obstacles, like preiodic movements, etc). At the same time I noted the apparent need to simplify the game rules in order to make the heuristics more adequate to the complexity of the game.
AndiHoffi wrote:
If you do find a good evaluation-function for the state of the game, the algorithm works very efficiently and is NOT a brute-force-approach, but an informed search-algorithm that has to be tailored for each game it should be applied to.
I think, finding a good evaluation-function is the lesser problem, and the real problem is finding a good way to represent the game as a graph. The more gameplay nuances you omit, the less nodes your graph will have (thus also skipping some nodes that could lead to a shortcut).
AndiHoffi wrote:
Thus: As long as the game does not have many of these obstacles that slow down the progress, it should be very efficient to solve.
Yes, so everything depends on how you define obstacles. If your definition doesn't represent the real picture, the solution will be far from perfect, even though the searching algorithm will honestly produce the best result within the given framework.
AndiHoffi wrote:
1.) Detection of duplicate states
Many button-combinations lead to an equal state of the game.
If you're going to compare hashes of entire RAM, you likely won't ever get a two duplicate states, because the input often affects various irrelevant things.
So, to get anywhere, you'll have to filter out irrelevant variables (or at least those that you think are irrelevant), and this is the point where you build a simplified model of the game, thus risking to produce a solution that is only perfect in terms of your model.
By the way, have you checked this? http://tasvideos.org/forum/viewtopic.php?t=13996 The guy there found an interesting way to turn videogames into formalized tasks. Of course his way produces extremely simplified models ("make numbers go up", huh), and the results are, naturally, rather pale, but it's already something (out of almost nothing).
AndiHoffi wrote:
2.) Detection of inefficient states
Here the evaluation-function comes into play: Each state is rated by adding the amount of frames needed to get there and the (estimated) least amount of frames needed to complete the level (e.g. until after the fireworks have ended). Then the state with the smallest sum will be evaluated.
OK, this evaluation-function is pretty generic, so it will likely work, as in, produce the generic "run right for justice" movie.
AndiHoffi wrote:
* At the start of each level, turn around, jump, and then start moving forwards
This should IMO be easily found since AFAIK it pays off after a few seconds only.
Yes, but the algorithm won't even attempt to check those alternative actions, unless there's an obstacle that can't be walked around in less number of seconds. So, to ensure the perfection, you'd need to have some huge obstacle at the end of the level, one that would force the algorithm to try different routes, starting from the very beginning of the level. Needless to say, this would create a huge problem with performance.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Ohh, so roots of TASing are once again found in Japan. Great finding, feos.
It seems the device already allowed to save input log to audio tape (like Excitebike and Family Basic did), so at least in theory someone in mid-80s could load the data from the tape, edit it in a hexeditor and record back, then load to the Game Repeater. Man, this is exciting to know.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
thelegendarymudkip wrote:
is there a TAS-editor that doesn't strech lag-input out
Everything is there, in the Manual.
www.fceux.com/web/help/taseditor/index.html?ProgramCustomization.html#AutoAdjustInputAccordingtoLag
thelegendarymudkip wrote:
or will I just have to not use TAS-editor? (The mentioned stretching is the ones that comes with FCEUX 2.2.1)
As it is now, TAS Editor is not meant to be used for multigame TASing, so you may want to switch to traditional method (the one Angerfist uses). I imagine having 6 TAS Editors on desktop would be kinda scary.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
AndiHoffi wrote:
{19278BFA-FEA2-4A51-867F-26DA4B7430F2}.htm
Actual link is: http://www.fceux.com/web/help/fceux.html?ExternalInput.html
I hope zeromus or adelikat can answer your question, but I want to ask you, how did you get to this old Help? I thought I've changed all links to point to the new Help, but people still keep finding the old one (which is outdated and should probably be deleted) - can you tell me which link brought you there?
AndiHoffi wrote:
My goal is to get a reliable interface to control FCEUX from my own code.
Well, Lua is pretty reliable. Why do you think everyone uses it?
But, if you want high speed (for bruteforcing), the only way to go is modifying the sources, everything else will be as slow as Lua, if not slower.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
From my past experience of making DualTASes, the only reason for desyncs is holding Frame Advance key for more than half a second - this starts "key retriggering" feature, which has different speed on different instances, and thus some emulators will advance more frames than others - it's easy to overlook this and keep TASing, while the movie is already desyncing.
So you should never hold Frame Advance even for a moment, instead you must tap it, even when you're entering a long sequence of the same buttonpresses (e.g. when you need to walk right for some time - do not just hold Right and Frame Advance, instead you should hold Right and carefully tap Frame Advance as many times as you need to record the walking).
Actually, wait, isn't there just the right new option in FCEUX 2.2.1?
NES->Emulation Speed->Set frameAdvance Delay
Set this to 9999, so you can be sure you won't retrigger Frame Advance even by holding the key whole minute.
MESHUGGAH wrote:
edit: and it would be still better if you would contact AnS about the possibility to link multiple instances to 1 TASEditor (some functions should be removed for efficiency)
I don't know an easy way to do it. Do you imagine what would it look like? At the very least it would need 9 Greenzones and a lot of hacks, which I hesitate to do in such a well balanced system as it is now.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Tub wrote:
AnS wrote:
But what is actually inherent to TASing? I say, only the fact of editing the replay data.
Indeed. The fact that the input is not generated by holding a controller and playing the game, but by artificially constructing the best possible input one can imagine using any tools available.
I was stressing the fact that the data is being modified (instead of live performance, which also generates/constructs the data, but does it on the fly).
The point is that in TASing the input is being constructed incrementally, by polishing previous attempts and being able to compare/revert to old progress (unlike in live speedruns where, if you managed to pull off a trick, you can't be sure you'll repeat it in another situation). The gamepad with replays reflects this point very clearly, so I think it would be immensely useful.
Tub wrote:
Which is why I dislike the idea of a replay-controller for the AGDQ presentation: it limits the input generation to holding a controller and playing the game.
I don't think anyone is going to assume this is how TASes are actually made, since emulation is well-known concept, while the gamepad will be presented as a novel concept. So no need to worry about the possible misconception. Conceptually.
Tub wrote:
Sure, none of the tools I mentioned are required to make a good TAS. There are other tools I didn't list. But holding a controller is probably the worst tool we have, it's absolutely insufficient in terms of precision and efficiency when aiming for perfection, and I disagree that there should be much focus on this way of TASing.
The focus should be put on replays, not on tools. Tools come up as a natural step towards comfort and efficiency.
Tub wrote:
Remember that the timeslot during AGDQ is somewhat limited, so it's important to bring the point across as quickly as possible. That leaves more time to show off our best TASes :)
But it's very important to show the inherent legitimacy and naturalness of TASing, since a lot of people still consider it somewhat farfetched (if not plain cheating).
What they don't realize, is that any recorded data (both input and output/AVI) may have been edited after it was created and before it was seen. The only way to be sure of the "live performance" is to actually be somehow involved in the process of generating the input (e.g. to make a random request to the player and receive certain feedback). Whenever the probing is impossible, you can only believe that the recorded replay wasn't edited. Probably. Most likely.
Well, there's always some probability of cheating involved in regular speedrunning, but it is neglected because it's rather small. While in TASing there's basically zero cheating, since the title says clearly: the replay data was edited. And provides an insight on how exactly it was edited, how many times, etc. Basically, in the whole world of gaming, TASing is the closest analogy to Open Source paradigm. It's literally the opposite of cheating.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Tub wrote:
But I doubt it's the right tool to explain to others what a TAS is. Unless that controller can do savestates, slowdown, memory watch and LUA scripting. ;)
The things you mentioned (savestates, etc) are only representing the current phase of TASVideos history. They don't tell us what a TAS is, because they are not inherent to TASing:
1) they are often used for other purposes outside TASing
2) TASes can be created without them, for example, this TAS was made entirely in a text editor, and this one was solved by a bot without using emulator.
But what is actually inherent to TASing? I say, only the fact of editing the replay data. That is essentially what a "rerecording" is - a rerecord happens not when you load a savestate, but when you overwrite old logged buttonpresses with new buttonpresses.
Of course, savestates help to quickly navigate backwards in the movie (in order to edit previous buttonpresses), but they are not necessary (if you don't have savestates, you can just replay the movie from the beginning - sure it's time consuming, but then, if we're talking about comfort, even our conventional savestate slots aren't the best way to navigate the movie, and everyone still uses them, so I guess it's just a matter of habit, and not something truly fundamental).
So yes, this kind of gamepad functionality is the right tool to explain what a TAS is. Unless you also want to explain which emulators and tools are popular at TASVideos today.
Derakon wrote:
It'd be totally useless for conveying what making a TAS is like, but that's fine.
What do you mean useless? It does convey the idea how you can make a TAS without an emulator: first you record an imperfect playthrough, then you transfer the input log to an editing environment (e.g. Notepad), there you change some buttons and then upload the file back into the gamepad, replay it and see the changes, then make some conclusions and repeat the process until you're satisfied.
Of course, this process would take hundreds of years to produce a publish-worthy TAS, but the supposed "gods" have infinite time, so the workflow is perfectly legitimate.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
I don't care about the single submission, as long as it doesn't create a precedent.
But if it's going to be percieved as a precedent, I vote No.
creaothceann wrote:
I see games as a labyrinth designed by the developers, with the ending in the middle.
That's a very limited model. And it brings us back to the discussion about whether we should perceive videogames the way they were planned or the way they were implemented (e.g. game designer planned a labyrinth with an ending in the middle, but programmers shifted the ending to the right and also left a few unintended shortcuts or even alternative ending points).
creaothceann wrote:
The TAS spending the least of the viewer's time doing that wins.
Are you talking about the Vault here? Because I thought the Vault doesn't have to strive for maximum viewer's pleasure, but for maximum effectiveness of the solution.
creaothceann wrote:
note that the viewer wouldn't even see a difference if the emulator wouldn't announce the input file's end.
A casual viewer does not notice the majority of stuff that happens during TAS, so that's not a point.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
Extra bonus if it could be used as a regular gamepad as well (perhaps there could be a switch to select which mode it is in.)
Indeed, it would be a great feature which could make the device look more credible in the eyes of casual gamers.
Actually, it would be even more awesome if the gamepad could also log the buttons while in the "normal gamepad" mode, and then replay these while in the "TAS replay" mode (mode 3?). This would introduce even the most ignorant people to the concept of logging and replaying input (without needlessly bringing the next, complicated step: tools like savestates, etc). And no problem if these replays are going to be desync-prone - even a single successfull public attempt to replay World 1-1 of SMB should be enough to get the idea.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
AnS wrote:
Warp wrote:
Is that really so? Because if it is, I would have to raise an objection. It would be like saying that Vault doesn't allow 100% completions (if any% is faster.)
But this is not 100%, it's "uses suboptimal character" category.
Yes, and? What's the rationale in accepting one goal but not the other?
As you know, there are two main goals of TASing: to find the theoretical limit of the game and to provide entertainment. If a movie doesn't provide entertainment, it should at least show the limit.
When we're imposing additional constraints, it becomes possible that we will find a limit of a different game (rules of the original game + additional rules).
Personally, I would only accept "any%" runs to the Vault. But at least with the "100%" category the imposed constraints (and thus the additional rules) are suggested by the game developer, while e.g. "Pacifist" category is completely made-up (in order to add entertainment). "Suboptimal character" is something in between.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
Is that really so? Because if it is, I would have to raise an objection. It would be like saying that Vault doesn't allow 100% completions (if any% is faster.)
But this is not 100%, it's "uses suboptimal character" category.
Warp wrote:
Just because Vault is a collection of speed records doesn't mean that there can't be alternative goals or limitations imposed in the run (within rational limits, of course) IMO.
What would be the reason to impose those limitations, if the result is not entertaining?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Ti_ wrote:
По идее уже есть трик.
ASM6 научился генерировать .NL файлы которые fceux кушает.
Ух ты, не знал! Почему эта версия ASM6 ещё не выложена на romhacking.net? Там какие-нибудь баги есть? Вообще, запиши видео или текстовую инструкцию для народа - я думаю, это всё будет очень полезно.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
FatRatKnight wrote:
Anyway, initial reaction is over, it's time we make a thorough analysis.
If you're going to use FCEUX debugging tools, I suggest downloading the latest revision, since there are a few improvements. For example, the "Highlight Activity" feature of Hex Editor:
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
FatRatKnight wrote:
If there's an overall strong desire to shift the standards around, this would be a decent start.
Yeah, now an idea for a decent end. Behold the Final Solution: automatically close the emulator when the movie ends!
This way the length of the input log will be equal to the amount of frames that can be seen. So TASers would have to add blank frames until the moment where they consider the game to be completely finished - e.g. publishers stop AVI dumping where the final music loops. Of course some RAM values (and CPU registers) still keep oscillating with different intervals, producing unique states of the game. Too bad these states won't be seen by movie watchers (because emulator quits), even though they are a part of the ending. But anyway, no one will ever want to experience them all (who ever watches TASes with RAM Watch open?). People just choose a random reference point, at which they consider the game completed. This point belongs to the interval from the earliest frame where the input changes could be stopped to +∞.
FatRatKnight wrote:
There are still a few cases where even when the game won't accept further input that the ending can be extended or reduced a little. Super Mario World comes to mind: Mario and the princess needs to go next to each other before the rest of the ending plays, and this would have different times depending on Mario's position when you defeat Bowser.
Why have you chosen the point where Mario and the princess meet? What if some other point (after this point) will be delayed because of different Mario position when you defeat Bowser?
I think, this method of choosing a reference point is unreliable. Sure, regular players will be satisfied with any plausible point, but we know too much to be satisfied with a random (e.g. plot-based) point.
For example, think about what happens at SDA maraphons, namely speed challenges between two players. Let's say, the 1st player killed the last boss slightly faster than the 2nd one did it, but he's got more points, so the score tally took longer and the 2nd player reached the "CONGRATULATIONS" message slightly earlier, but then the 1st player got better subpixels and met some princess placeholder earlier, but the 2nd player got less lag and his screen faded a bit faster, but the 1st player got shorter credits, but because of longer credits the 2nd got overall shorter music (less loops) on "THE END" screen, but the 1st got better RNG thus the "falling stars" particles on his screen degraded into an infinite loop earlier, but the 2nd got better modulo of GlobalTimer (ingame frame counter in RAM), so the hidden game clock stopped earlier, but the 1st got better overall value of another oscillators, allowing them to form a stable loop in the nearest billion of years instead of the nearest trillion. Anyway, who has won the SDA race?
I'd say, the one who was able to free his hands from the controller and hit the button on the chess clock, or just shout to the guy with timer. Everything else will happen eventually (something within seconds, something within years), but the player is already free to move to the next game (if it would be this kind of maraphon).
So, for example, given the interval of frame points [200; +99999999999] we may choose any frame inbetween, but the only consistent choice is to either always take the leftmost value, or always take the rightmost. Since the right value is usually unreasonable (it's the number of frames needed to degrade the game ending output into a loop, sometimes it's actually infinity), we choose the left value.
FatRatKnight wrote:
Why is locking a controller in an unchanging state a special method that doesn't need to be counted as part of the movie's time?
Because this method exists in hardware and is used by regular players. I'm talking about the "make all buttons forever released" method.
FatRatKnight wrote:
Why is leaving it in a final state a desirable thing, when further changes can reach the credits faster?
Because credits are not the ending, but a random reference point which became popular. Some games don't even have credits at the end.
FatRatKnight wrote:
Is it because the input movie length is shorter?
No, it is because the earliest point seems like the most objective reference point.
At least it looks so from the purely technical side, which is what TASvideos is good at.
FatRatKnight wrote:
If one is looking to find a game completed as fast as possible (as currently known), the default input where further changes could do it faster denies such fastest completion.
If one is looking to find a video that shows credits (or some other point of the ending) as fast as possible, he'd better search Youtube.
Even if your movie reaches one point faster then ever, you still can't claim that the same movie actually reaches another points (of the ending) as fast as possible. Of course, most players imagine that there's linear progression, which would mean that the earlier you reach one point, the earlier you'll reach the next one, but it's not so simple (in the general case).
FatRatKnight wrote:
I consider all frames (aside from the user idly messing with the keyboard) after your input list to be a part of any run, just as much as if you had actually padded your movie file with them.
Up to which frame should we pad the movie?
FatRatKnight wrote:
Just because there is unchanging input after the end of my input doesn't mean that this unchanging input isn't part of the resulting movie. After all, people are going to watch it.
You never know up to which point people are going to watch it.
OK, the unchanging input is part of the movie, but so is the input produced by dropped controllers after the end of an SDA race. The TV may be already switched off, but controllers keep producing null input, and the game keeps updating. Should they also include the input to the timer value?
FatRatKnight wrote:
I don't hate the current method of stopping input short, but I prefer the fastest end rather than the shortest input. I don't expect standards to change that easy, as people are used to it and seem to really hate when something changes. But it's a good test for the runners that, with my preference, want the fastest end.
So you want to cater to casual viewers who have a simplified understanding of what is the end. Well, I also think the main goal of TASing is to provide entertainment, and not just find the limit of games. So I agree that Moons can have both types of movies: those that entertain people (by giving them an ending they like) and those that find the limit of the game. But when we're talking about Vault runs, I think the latter goal is more important, since their entertainment value is negligible.
£e Nécroyeur wrote:
no matter how many Frames I spend trying, my movies will *never* be entertaining.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
CoolKirby wrote:
Blank frames should definitely be removed after the movie though. There's no reason for them to be there.
Well, there would be a reason, if we didn't assume that movie watchers never press any button while watching the movie (even after seeing the "Movie finished." message). If they were less reliable, TASes would have to keep producing null input until the very end of credits, or else some movie watcher may press a button and thus skip or alter the ending.
TASing relies on many assumptions (like any other activity does certain assumptions, for example, in the 100 meter sprint you can run more efficiently if you assume that after you reach the finish line you can relax and fall into friendly hands, while in real life you would probably run so fast only because of being in a hostile environment, which requires further actions after running). Here we assume that the game is played inside a safe sandbox, which provides a consistent initiial state of the game and a reliable conditions after the movie ends. Without these things it would be impossible to ensure determinism.
If we modify our emulators to make them immediately start generating random input every time a movie ends, most of existing TASes will desync, because some of those random inputs will either pause the game a moment before ending, or reset the console, or skip ending and go to title screen, etc. This would actually be a new reliable way to automate movie length calculations, since all TASes from now on will need to have many blank frames at the end (to ensure that movie watchers will see the ending until the very last frame that matters). This "random input noise" would be just another assumption (replacing the current one), and it'd probably be closer to real life, but less convenient for TASers. But at least the site will be able to know the ending frame for sure.
FatRatKnight wrote:
This does imply that my April Fools' TAS is indeed just a little over 3 seconds long, as I do specify a final state other than empty where the controller no longer changes.
The problem is, your chosen final state makes additional assumptions (without even replacing the existing one) that are not a part of TASVideos traditional set of assumptions. And I'd say, the less assumptions we make, the better.
It's similar to using dirty SRAM - in that case we assume that the initial state of the game is different from the usual state, while in your case we assume that game controller can keep the last state of buttons (should it be a new category "Uses modified controller"? or "Leaves dirty input footprint" - since after watching the movie the emulator will be oblidged to keep repeating the last state of buttons while ignoring user's actions).
TASes using dirty SRAM aren't very frequent, since they give you an advantage that has to be justified by providing huge entertainment to the viewers. Needless to say, leaving dirty input is also very uncommon (because it doesn't match the default state of controllers seen in real life: all buttons are released) - it makes additional assumptions that reduce the percieved value of a TAS.
FatRatKnight wrote:
For this line of thought, now I'm curious what you think of my April Fools' TAS. With the information we're discussing now, should it be published for the concept of finishing a game with a really short input file?
I liked it very much and answered Yes to the question of entertainment. If the site ever adds a Demo tier, the movie should definitely be published there, along with all TASes starting with dirty SRAM.
Actually, if the movie were better recognized, say, less repetitive and even more dramatic than it is, I would suggest to publish it in Stars (the tier is so high that it's probably above rules of the site), and volunteer to modify FCEUX to make the final auto-hold put less overhead (the final state of buttons should be stored in the movie file, so that movie watchers don't have to bother with settings).
As a concept of finishing a game with a really short input log, this run is nothing special. I've seen some games that allow you to set password to appear right before the very ending (see, for example, Blackthorne for SNES) - those runs would probably be even shorter. But it doesn't look like anything wonderful, so I don't think you should promote your TAS from the point of shortest input. Instead I find it more amazing that your TAS was the only TAS that made me worry about the fate of the protagonist. You know, when we're spoiled with so many TASes that play with death, we become sceptical, because we know it's just TAS and not a live stream of someone playing right now, so everything is going to be good, unless a desync happens. When watching your TAS I also knew that the input won't change, so I was able to quickly predict that at current pace the player is surely going to die, unless some miracle happens. I guess if I wasn't familiar with the game, I wouldn't be so sure.
FatRatKnight wrote:
Mainly, I asked about a controller with no buttons pressed primarily because that is used as a standard here for ending a movie, by my impression.
It's more like a standard used everywhere. It's a default resting state of hardware, after all. Most games expect you to not press anything on the ending screen, or else the ending may be skipped. So this standard has gameplay-related roots, and is not arbitrarily chosen. Even more realistic standard would be the aforementioned "random input noise" instead of blank input, but IMO it doesn't worth the trouble.
FatRatKnight wrote:
Technically, many movies published here can be "improved" by doing everything up to the last frame, then have the following frames hold the non-null default state in order to complete the movie
That would be like improving a normal TAS with a TAS starting from dirty SRAM.
FatRatKnight wrote:
I can always modify my argument to instead pick unchanging input rather than blank input, if you prefer. I'm sure you know where I'm going by now.
I'm not sure I do, so I would like to hear the modified version.
Patashu wrote:
Another thought: If 'TAS timing ends as you can put the controller down' implicitly removes all blank frames after the last frame of actual input for the purposes of timing, why not remove all blank frames before the first frame too?
That sounds a lot like SDA timing to start counting. Can't really say anything against it, except that maybe the Power switch command is also a part of the movie.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Maybe a more proper name for the topic would be "Input time vs Output time". Because AVI time depends on the publisher logo and the time he decides to spend on the ending screen.
FatRatKnight wrote:
I will ask one thing: Why is a controller with no buttons pressed a special state that doesn't need to be counted as part of the movie time?
Actual state does not matter. The thing that matters is that the state is final and does not change anymore, but the game still finishes on its own.
Some may remember that FCM movies store joypad events instead of a simple log of button states. The size of FCM files is much less than the size of binary FM2 files after conversion. You could call this a kind of lossless compression, because FCM files remove redundancy and only store the necessary data - the actual essence of a TAS movie.
FatRatKnight wrote:
Rather, it's about the fact that ending a movie short is relying on some default controller state to finish the game
No-no-no, ending a movie early is relying on the fact that the game can be finished without any further interaction.
FatRatKnight wrote:
Why is leaving buttons unpressed a desirable thing, when further input can reach the credits faster?
Clarifying: leaving buttons unchanged is a desirable thing, while further modifications of the controller state are optional.
Dropping the controller is an amusing thing that has something to do with data redundancy, entropy, chaos theory and other poetic matters. It's very TAS-tastic.
Further input changes give you more advantages, so it's not as interesting and definitely less challenging. We may as well use lots of coins in arcade games, just because we can. But last I checked, TASVideos enforces 1-coin TASes, because they look more cool. Ending input early is also cool, because it's often impossible to do without tools.
FatRatKnight wrote:
Is it because the input movie length is shorter? While we may feed a shorter list of input to the emulator, the game's completion is delayed.
Well, since I like playarounds more than pure speedruns, and I often support speed-entertainment tradeoffs, therefore I don't see any problem in delaying the game completion for the sake of showing some neat trick.
Honestly, the game completion is kind of rudimentary feature of TASing. Sure, we need it to invoke the feeling of closure, but the content of TAS is more important than AVI time (when it's reasonable).
I often enjoy reading detailed submission texts more than watching the actual movie, because I wonder which creative solutions the TASer invented being under pressure of certain restrictions (either game-related, or self-imposed, or community-imposed). The need to stop input as early as possible (because previous TASes of the game decided it) is one of such creativity-boosting restrictions - it's clear, reasonable and gameplay-related (which makes it fun).
Output-based definitions are better suited for SDA, not TASVideos.
FatRatKnight wrote:
I consider blank frames after your input list to be part of any run, just as much as if you had actually padded your movie file with them.
Sure, feel free to consider those blank frames to be part of the input log.
Meanwhile, I only consider those frames until the last change of buttons state. So, for example, if there are actual empty frames at the end of the movie file, I only consider the very first of them to be a part of the run, because after the frame the controller state doesn't change (not while the movie is still playing and not after it stops).
MESHUGGAH wrote:
The main goal of a TAS is to complete the game as fast as possible. This means that the TAS has enough button presses to make the game reach it's credits.
Uh, it works both ways:
"The goal of a speedrun is to complete the game as fast as possible. This means the run must reach credits in the lowest amount of frames."
MESHUGGAH wrote:
For vault, I would say shortest input should be used and other tiered TASes should aim for the more entertaining version
Indeed, Moons/Stars are out of question, but the nature of the Vault just asks for some strict rule.
