I love the category and would normally be in full support of this being published as a Moon, but the fact that it contains extraneous rupee collection because a different run's input was used when it was still considered a test makes me hesitate.
It's kind of a crappy situation, because I empathize with Sam completely and wouldn't ask em to do it over, but I'm still not sure we should be publishing runs that have entire unnecessary sections.
I'm sad that it doesn't have enough support for it to be very likely that it gets remade, but, eh, that's life. And I hope someone proves me wrong :)
A warb degombs the brangy. Your gitch zanks and leils the warb.
Nercroposting can create a lot of confusion when people see old threads, not realizing they're old, and start responding to things that are no longer relevant.
Yeah, I think this is the main reason for rules in other forums. If all the posts on the front page are new except #4, which is 6 years old, only has a few posts, and has a title like "Contest Submissions Due Tomorrow!", bad things can happen.
"ais523 wrote:
I'm disappointed that this isn't a bump to a years-old thread :( Someone go bump it in 2018.
And yes, if you have something new to say and there's an appropriate thread to say it in, the age of the thread doesn't matter. Multiple threads on the same topic just makes it harder to find information.
I resolved to come back and do this as soon as I saw the title ^_^
I have seen some pretty epic thread necros here, I think there was like an 8 year one a while ago? I'm way too lazy to try to find it though.
A warb degombs the brangy. Your gitch zanks and leils the warb.
fwiw, I agree with you completely, and empathize thoroughly with your desire to leave. No one should have to put up with that crap when they are trying to bring real value to a new community, and it's extremely ungrateful of us to tell you to just deal with it.
I personally hope that you and True can find a (possibly moderator-mediated?) solution that lets you feel comfortable sticking around, because I think you would be a great asset to our community and find value here yourself, but I can't fault you in any way for wanting to remove yourself from a hostile situation.
True, I don't know you or your intentions or your culture. I'm not going to judge you to be a bad person or a troll. But it would be super cool if for the sake of TASVideos you could find it in yourself to respect Sonny_Jim's wishes, and either moderate your tone or refrain from talking to him at all.
A warb degombs the brangy. Your gitch zanks and leils the warb.
While I agree that it techincally makes sense to treat any variable that affects sync as input in the movie file (i.e. the movie + emulator should completely specify the system), I think an arbitrary limit must be placed at some point. As Derakon mentioned, we can make exactly the same argument with regards to cosmic ray bit-flips as for initial ram state: Cosmic rays can flip any bit at any time, and arrive completely randomly (but rarely). If the emulator were to emulate this, then it would sacrifice sync-robustness. One can either arbitrarily choose a fixed cosmic ray pattern (such as no rays), or let the user specify them in the movie. But in the latter case, the TASer would be able to manipulate any ram value at will (i.e. as if he had a game genie or similar). That case is more extreme than the one we're talking about now, but they are otherwise very similar.
This is a nice argument, but I think you are overlooking a fatal flaw: it's not about what actually might happen during real use at all. If that were the case, we would be discussing allowing emulation of things like the half-inserted cartridges that resulted in Geddan. What we care about is the specification. The state of RAM during play is fully specified by the NES hardware design. The state of RAM at power-on is specified to be undefined - this is a common concept in both hardware and software programming; C compilers for instance rely heavily on specified undefined behavior to optimize code.
In light of this, I actually think it's pretty silly to go by "most likely hardware configuration", since that is a) going to vary by model and even individual device to drastic degrees (it was unspecified and thus not a target of factory testing), and b) going to result in some games randomly getting advantages and others not, in a very unsatisfying way.
I know it's not a very intuitive result, and thus unpalatable to many people, but I think that full control of power-on ram (unless there ARE specifications I'm unaware of that declare certain states impossible) should be the default. I don't think TOO many movies will be affected by this, and we can always have a "doesn't initialize RAM" branch for those that are.
A warb degombs the brangy. Your gitch zanks and leils the warb.
While I'm generally in favor of allowing this stuff, because insisting on a single arbitrarily-chosen-by-emulator-developers state is really dumb, there is another possibility (though maybe not a very realistic one):
We could demand that every movie sync against *every* possible initial state.
This is obviously impractical to test exhaustively, but the rule could just be that movies obsolete other movies that can be shown to sync for fewer initial states.
A warb degombs the brangy. Your gitch zanks and leils the warb.
How about we do something like this, and do it many times and create a heat map?
we could take a hex grid of data and represent it by a pixel per value and create an image. The color of that pixel will be hotter based on the number of times it was "on"
If the heat map was essentially evenly colored, we could conclude that essentially any ram combination is theoretically possible. However if the image was "clumpy" then we know we need to be more skeptical of what's possible.
Yes please. Not only is this a great idea, I suspect that the resulting images will be very pretty ^_^
A warb degombs the brangy. Your gitch zanks and leils the warb.
It does skip more than half of the game at once. It in no way near the any% concept either. The game itself is just fucked up, so you don't even need to corrupt memory to break it to death and abuse.
This is the most ridiculous thing I've ever heard. By this logic, the mario64 0-star run isn't an any% run. There are plenty of Vault examples too; that rpg that wins on the first frame comes to mind.
The entire point of any% is to complete the game as fast as possible. If we can skip 99% of the game, we absolutely should. Trying to separate it from memory corruption is one thing (that I personally don't agree with, and which certainly doesn't apply here), but trying to define a percentage of the intended game that must be completed is just crazy.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Haven't watched since there's no encode yet, but I'm enjoying the submission text.
Can you explain how
* Enemies don't "exist" offscreen
and
* I use a fully charge bubble to damage the purple jellyfish 3 times quickly. I believe it has something to do with it being offscreen affecting it's invulnerabilty period, but I'm not certain.
are consistent? If it doesn't exist offscreen, how is it taking damage?
A warb degombs the brangy. Your gitch zanks and leils the warb.
I believe the periods of movies in which version improvements don't count that the rule is trying to define are times when:
- the player does not have control (inputs have no effect on RAM? or something, I'm sure there are cases where that's not quite right)
- the game is in the same (up to translation) state before and after
e.g. I believe that it is uncontroversial that a movie that skips a cutscene entirely DOES count as faster than one which does not; the rule is intended only to ignore situations in which the semantically "same" cutscene is faster for cosmetic reasons.
For most of what's skipped, the player DOES have control, so the improvement should be obvious; I assume there are level transitions or something in which the player does not, but those should also count as improvement, since this movie never enters their entry states at all.
It's not like player could not skip the first 4 levels after selecting the shorter version
I don't think this argument is relevant - imagine a v1.1 of SMB1 in which you start one block further to the right, and there is one fewer column on the left edge of the level. It's not as though a run on the v1.1 ROM could NOT gain those few frames, but it would still uncontroversially be accepted as the shorter movie, no?
A warb degombs the brangy. Your gitch zanks and leils the warb.
This argument was pretty fun to read at first, but then Adelikat came back with better proof than could possibly have been expected and then it still went on for two pages :/
In a no-doubt vain attempt to end it, I will offer a perspective on the save-state issue that has not yet been explicitly proposed (though Radiant's argument is in a similar, if less theoretical vein).
A savestate is a state that can be brought about deterministically by the same player we imagine to be performing the TAS at hand.
This is something else entirely.
The idea of a NESBot script that powercycles until it reaches the right state muddies the issue, but doesn't change anything - such a loop is not, in fact, guaranteed to terminate, and definitely does not bring the state about in a deterministic amount of time, or with a deterministic number of instructions.
So, what are we doing when we choose a register state? We are definitely not TASing the game. I am here to argue that what we are doing can best be thought of as selecting the game.
TASes have no room for true randomness. Without an environment in which the state is always the same after the same inputs, no run would ever sync. Therefore, hardware randomness like this can never be part of the TASVideos definition of a "game". Therefore, I propose that what we have in Cheetahmen II is a 64-game cartridge - 63 of them happen to be identical, and one of them is the game TASed by this submission.
Perhaps this idea will be more palatable if we call them "versions" instead, and treat them the same way we treat [U] and [J] versions of a game, or 1.0 and 1.1 releases - this is functionally equivalent (ie, we still have to make a choice beforehand of which ROM we will be TASing) but it gives us a more comfortable framework for managing them.
The movie acceptance rules say:
Keep in mind that time gained solely through basic ROM differences will be discounted for the purpose of comparison. This includes:
- time gained through shorter cutscene text and speech boxes due to Japanese writing being more compact;
- differences in title screen, cutscenes, and menus (unless menus are the game's main control interface).
Only actual gameplay improvements will be considered.
Given all of this, I propose that this run be accepted, with the register state listed as the version, and that it obsolete any run which uses a different version, for the reason that it contains actual gameplay improvements over them (skipping the first four levels).
A warb degombs the brangy. Your gitch zanks and leils the warb.
:(
If you read this, Sonny_Jim, I beg you not to judge the character of the community as a whole by the words of one person.
And True, I wasn't there, so I have no idea if the side of the story presented here is reasonable, but in general, I would urge you (and everyone) to err on the side of kindness when interacting with strangers on the internet, especially those who, like Sonny_Jim, are less technically experienced in a particular area than you, and have come to our community for support.
We lost a lot of potential value here, not to mention turning a person off of the site who might have gone on to derive a lot of enjoyment from it themselves.
A warb degombs the brangy. Your gitch zanks and leils the warb.
It's getting to be an old post, but did this ever happen? HappyLee's comment left me intrigued. AndiHoffi recent post just reminded me of it.
Sorry that I haven't told you that the author has found some improvements in the previous worlds (which seem amazing) and been remaking it from the begining with a new team. Unfortunatelly the process became very slow. They has just finished world 2 a month ago, and I can't imagine when they are going to finish 4-1 and 4-2, but since it's a really huge project and the authors are working hard on it, I think what we can do is just to wait... Meanwhile Mars and I are working on SMB warpless walkathon, which is also a huge project, but we've already saved lots of frames in 1-3, 1-4 and 2-1 using new routes and technologies. We'll send a WIP after another breakthrough. :)
I've been checking this thread at least every couple months since that tease was posted in hopes of some more news, so I'm very happy to hear this :D I have been patient this long - I can continue to be patient! But the knowledge that it's being actively worked on is very nice.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I'm strongly in favor of shortest input.
As a viewer, I MUCH prefer to see clever use of the environment/physics/items to set up an input-less boss kill than just more standard play - bosses in TASes tend to be pretty boring anyway. It adds a neat, TAS-only goal that increases the feeling of having total control over the game, even in the future :)
I do see some merit in FatRatKnight's point that all buttons unpressed isn't that special of a controller state. The reason we find it to be special is that it just so happens that all default controllers for all major consoles have this as their resting state, but there's no real reason why that has to be the case.
Therefore, I can see an argument for "shortest time to no required input change". This would usually be the same, but would sometimes allow for neat things where you hold right and A or whatever for a while, and do things on "autopilot" for a bit at the end of the run without it counting towards the time.
However, this would probably be way too counterintuitive and weird for most people, so I think we should probably just stick with the current definition of shortest input :)
A warb degombs the brangy. Your gitch zanks and leils the warb.
I'll throw in another vote for "completionist".
If things like this start happening a lot, we might consider a branch title (or even publication tier?) specifically for "vanity" runs - runs that impress everyone and are technically impressive in completing the goals they set for themselves, but which for whatever reason can't be usefully compared to other runs of the same game, or which we don't want to accept as precedent for category definitions.
The fundamental tension here is that this run exists, and is amazing, and TASvideos seems like the only logical home for it, but it just doesn't fit into the framework we've established. TASvideos has a long and illustrious history of exceptions to the rules, and there's nothing particularly wrong with that - we've more or less "solved" the problem here by just giving it a random branch title and publishing it anyway. But if we do start to see a lot more submissions like this, things could get messy, and it might be worth formalizing what we want to do with them.
A warb degombs the brangy. Your gitch zanks and leils the warb.
There is a Facebook page, and it used to announce submissions and acceptances, but it hasn't been updated since October 2012. I'm not sure if announcing every submission is the right role for that page even if it does come back - maybe less frequent announcements of major runs and other site news might be more appropriate - but either way it would be nice if it came back.
Having a web IRC client link on the homepage would be great. Tons of sites do it very successfully, and it lowers the barrier to entry a lot. That said, perhaps it should default to, say, #tasvideos-homepage or something; a huge flood of uninformed users might not be what the #tasvideos community is looking for :)
One thing that might get TASVideos some more awareness and respect would be TASers contributing their knowledge the new SDA knowledgebase/wiki, and noting which strats are TAS only, perhaps with links to gifs/timestamps in official encodes. Even if you are not a TASer, moving our GameResources content over there and cleaning it up could be useful.
I'm not actually sure what their policies are on TAS-only content. There seems to be limited (but not zero) inclusion at the moment. We definitely don't want to be seen as invaders, but I think everyone in both communities is pretty aware by now that we are not enemies, and that shared knowledge has improved TASes and RTAs alike, so I would hope we can find a home there. If it eventually completely replaces our GameResources pages, I for one would see that as a massive improvement.
A warb degombs the brangy. Your gitch zanks and leils the warb.
All glitches are basically discovered on accident.
I would argue that at least some glitches have been found by examining the game's machine code.
And lots more are found on purpose by methodical searching or logical reasoning about how systems might interact in unusual circumstances. Saying all glitches are discovered by accident is not just untrue, it kinda pointlessly undercuts all the hard work that people put into glitch hunting.
A warb degombs the brangy. Your gitch zanks and leils the warb.
What an awful game ^_^
That one bit where you got your head kinda stuck in the ceiling and broke a bunch of blocks quickly was neat. And the ending text is hilarious.
Run looks good, easy yes vote.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Also, you never know what unintended items that might be discovered in the future. And if that were to happen, should old runs not be considered 100% anymore? How would you compare old runs with newer runs?
This problem isn't unique to glitched objects. There's a very real possibility that a game will be TASed before every legitimate secret added by the developer has been found - or imagine a case where the game presents a choice between two things, but it turns out it's possible to collect them both, and it's not obvious whether the developers knew.
Therefore, I don't really think this is a good argument against including glitched objects in 100% runs when it makes sense (ie, there are a finite number of them). It's okay for definitions to evolve.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I just saw this video, and it got me all excited about the possibilities for TAS tools and techniques in a more aesthetics-focused context that we're used to around here.
Would love to hear other people's reactions, links to anything else similar, or thoughts about what tools and experience the existing TAS community might be able to bring to bear on future projects like this.
----
Mod edit: Merged topic from Tool-assisted laboratory forum.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Can we implement a new site-wide rule against arguing about 100% definitions in submission threads?
If you care about these things, speak up in the game's thread /before/ the run is made. No one is going to redo a multi-hour run (e.g. the hotly disputed ChronoTrigger 100% that was recently published under a different name..) because you decided to chime in /after/ they put in months or years of work and had some problem with it.
100% definitions are inherently arbitrary, and each game's community needs to define what they care about on their own time, before work on runs is started. If you think you have some really compelling argument for why the consensus is wrong, bring it up in the game thread, and convince the people working on the next version of the run. In the mean time, be a little more gracious to the people putting in hundreds of hours to make high quality runs for your enjoyment, even if you can't figure out exactly why they made all the choices they made. They've probably thought about it more than you have.
A warb degombs the brangy. Your gitch zanks and leils the warb.
I know absolutely nothing about this game, so I can't say whether it was optimized at all. I can say that I was pretty amused throughout.
That axe is really silly.
A warb degombs the brangy. Your gitch zanks and leils the warb.
