Btw, I'm honestly interested in knowing your (plural) opinion
Would you generally forbid resetting the game to save warp?
I'm assuming that no, you wouldn't.
So resetting after saving is fine, right?
By resetting during saving, you can't modify the data to your own will. It's still the game that modifies the data. You just tell it to stop in the process of it. By neither using an external device, nor by modifying the console. You are merely pressing a button.
The game code does not react to that button, the hardware does, so yes, you have a point. There is a difference. That's why there are distinct categories for these runs.
But is it different from save warping? Why would pressing the reset button be regarded as any different just because it happens during the process of saving?
Also, consider this: When booting up again, the game reads data that has only been modified by its own code. You've just told it when to stop. It would have the means of checking if it has loading valid data, but most games don't use check sums to do this. So isn't it an intentional oversight? Similar to pressing left+right? "Well, hardly anyone will ever do that, so let's not care about what happens if they do." That fits the definition of a glitch, doesn't it?
So imo, save file corruption is basically just severe glitching that is impossible to follow without any kind of debugging tool, plus resetting the game combined. Whether resetting should be allowed is debatable. Whether severe glitching should be allowed also is. Both at once is twice the trouble. They take away entertainment in one way, but also add entertainment in another.
It is different from modifying a game's memory at will though. It is also different from modifying the hardware. But it's also different from playing through the game in normal TAS manner, so you have a point. Luckily, there already exist different categories for these types of runs though, so there's no need to worry. ;)
The only way to push concepts like this through is starting a run yourself and prove the results are entertaining to a broad audience. If it works out well, you might even win an award with it at the end of the year. ;p
Some suggestions:
Insert a big headline that says something like "Welcome to TASVideos" above where it says "TASVideos is a community for creating and publishing Tool-Assisted Speedrun (TAS) videos of classic and modern video games." now.
The TASVideos news thing should definitely stay, imo.
Change "Most recent additions:
2010-02-19 [1465] GB Avenging Spirit (USA) by Mukki in 08:29.18 (vbm,mp4)"
To "Most recent additions:
2010-02-19: GB Avenging Spirit (USA) by Mukki in 08:29.18"
(Why would users care for the run's unique number and the format it was endoded in at this point?)
Remove (Old was ....) and the submission date everywhere except for at the most recent additions. They are really not necessary here.
For recommended movies, divide them in categories. Then make up a symbol for any of these categories. Display them randomly, as now, but with the category symbol in front of them. The symbol should give the viewer an idea of why this movie is recommended to be watched. (f.e. the run looks particularly speedy, has a very high technical level, is very glitchy, is very hilarious, etc)
One run could fit into several categories. A legend explaining these symbols would have to be displayed somewhere.
The point "Newest submissions" needs to be explained.
Newbies won't just know that we actually have a voting process going on they can participate in.
What's the difference between movies an submissions? Right now, this point is just confusing.
Well yea, I've treated this as a more generic question about how to find the first possible frame for a certain key press in difficult cases. (even though the topic title suggests otherwise >_>) I didn't even read the Sega Saturn part. Gens counts and displays the number of frames where the game didn't accept input. Obviously, watching that number helps a lot.
Get the number of the current frame displayed and you won't need to do any counting.
You should first have an approximate idea on when the first frame is where input get excepted.
This is what I do then (while already recording):
1) Make a savestate that's sure to be before the first frame when input gets accepted.
2) Pause the game.
3) Load save state 1.
4) Advance a certain number of frames.
5) Pause the game again.
6) Make another savestate on a different slot.
7) Press the button (f.e. start) using frame advance.
8) Unpause and maybe fast forward to check if the input got accepted.
9a) If it didn't: Pause the game, load save state 2 and continue at step 4.
9b) If it did: Pause the game and load save state 1 and continue at step 4, but only advance half the number of frames this time. The next time you get to 9a, you'll also half down the number of frames you'll advance in 4.
I hope this is comprehensible. x_x
What you're really doing is playing that game where the emulator thinks of a random number and you go asking "Is it bigger than 50? Yes. Bigger than 100? No. Is it bigger than 75? No. Than 62? No. Than 56? Yes."
Well, at this point you could just load that last save state a couple of times, and advance 1 frame, try if it accepts the input.
Then reload, but advance 1 additional frame this time for each time you've already reloaded.
You'll eventually find it. If you do some smart guessing and modify the process a bit, it doesn't take long at all.
For humans with godlike abilities, it should be possible to alternate between pressing left and right so fast that the system would register both as being pressed down simultaneously in any frame anyway. (unless the system checks whether right is pressed down an whether left is pressed down at exactly the same time. i don't think any system would do that.)
No, sorry, it seems you were right for some reason I can't comprehend yet. It really takes 8 shuffles. o_o
I was (mistakingly) assuming you agreed that it'd take 50 shuffles because of these two quotes:
arflech wrote:
the so-called "in-shuffle" in which the top card of the bottom half ends up on top requires 52 iterations to get to the original order!
arflech wrote:
the out-shuffle on a deck is equivalent to the in-shuffle on a deck with 2 fewer cards
I assumed that an in-shuffle with 50 cards would take 50 iterations, that's the same error in reasoning that let me come to my initial wrong result in the first place.
Edit: I'll now take a deck of cards and analyze what really happens until I fully understand it (or until I give up) as my punishment. :(
At least my formula was right. (I hope) :(
I hate those occasions where I'm so confident I'm right, but turn out to be wrong anyway in the end. Argh..
How come it takes 50 shuffles and not 8 then?
Wouldn't the lowest common multiple of all different orbit sizes determine the number of required iterations?
You're probably making a mistake when switching between the halves of the deck in your simulation.
Edit: It seems you were right for some reason I can't comprehend yet. XD
No, it didn't. He insisted on out-shuffle instead of in-shuffle, which requires an additional thinking step.
Sorry to tell you that there are no orbits of 8, not sure how you came to that conclusion. How can there be orbits of 8, when there are obviously also orbits of 50? An orbit of 50 requires 50 different positions (if the shuffling process always stays the same, which it does), an orbit of 8 would already occupy 8 positions.
Besides, 50 isn't even divisable by 8. -.-
The thing you looked up at MathWorld makes the cards move exactly as in my formula. lol
Edit: My original argument is flawed, though, as well. I'll see if I can fix it.
Edit 2: I tried my best, but am not satisfied with the result.
My approach to all of these problems is to brute force them with educated guesses btw. Logic isn't one of my strenghts, but I can get it down when it comes to it. :p
I'll completely disregard the top card and the bottom card, as they never change positions at all. For the remaining 50, you can also completely disregard the exact path they'll take through the deck.
It's only important to note that the only thing, that determines the position in the deck each card will arrive at, is their position in the deck before each shuffle. And that they all arrive at unique positions, obviously. To arrive back home again after the first shuffle, a card first has to reach the position the card that now has taken its original place had before the first shuffle. And to reach that position...
Edit: (I inserted this paragraph by editing after arflech pointed out that my argument was flawed. Unfortunately, this makes it sound way too complicated though)
The number of cards has been arbitrarily selected, so the whole thing would work with 48 cards as well - as well as with any number of cards divisable by 2. So, at this point it could either require "number of cards" steps, "number of cards/2" steps or exactly 2 steps, or it wouldn't work in all cases. By imagining the shuffling process (following only one card), it becomes obvious that it can't be only 2 steps. If you simulate the whole process with 2 cards (4 in total counting top and bottom cards), it takes 2 steps, so it's "number of cards" steps.
So, in the process, each card will have taken each of all possible 50 positions once.
That makes it 50 shuffles.
Btw, the path they take is "new position=(position*2)%(number of cards+1)". (Only counting (among) the moving cards and starting to count at 1!)
Truncated wrote:
For simplicity, let's say the top card of the top half is first, so it always stays on top.
Ironically, this makes the problem harder to solve. ;)
Good point. For example, I wonder what would happen if a team of say 3 TASers was working on a certain run, and then I'd put a bounty of 100$ on it... Doesn't the concept of bounties discourage team TASing as a whole? If there was a bounty for the first one to go sub-something on a certain game, wouldn't it harm the community? People would then keep new tricks secret and totally hide their progress, I guess.
Maybe you should only be allowed to put bounties on unpopular games or when proposing unconventional run concepts?
Bezman, you might want to read the second paragraph of [URL=http://alt-usage-english.org/excerpts/fxlessvs.html]this[/URL] article. It's debatable whether it's a mistake and recent tendencies go towards giving up the strict distinction, making "less" usable in all cases. (no source, too lazy to google for it)
Hm, there doesn't seem to be a way to make youtube videos stop buffering without clearing the data so far. Wouldn't a feature like that save youtube money? Strange.
Wow, I'll give this a yes vote. Of course, I fast forwarded through most of it, partly because I'm not so familiar with the game. But with so much effort put into the run and so good results, it'd be a bit cruel not to let it be published imo. Unless the author agrees with it.
And in this case, to me, it seems apparent that super should be regarded as the highest difficulty, as according to Obob, the differences in AI are very minor.
- Wow, this guy is really good! I bet he's been playing that same game for ages!
- It's a T.A.S.
- What?
- A tool assisted speed... no... tool... assisted superrun... speedplay, speedrun, whatever.
- Uhuh?
- Well, there is this one site.. Oh, just watch it!
- ...
Kuwaga has earned 43 "unfunny points". 3 more to go for a level up!
I'd say make a bounty run section or something like that where users can publiclicly place bounties on their desired runs. No matter if the run is also publishworthy among the ones on the 'main site', if the bounty has been paid out, the run would then be published in the bounty run section. Just a random idea to think about.
It makes more sense to only set bounties on runs that would also be publishable, but on the other hand it doesn't make a lot of sense to make up restrictions on what people should be allowed to pay other people money for.