Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
<- 12
--
--
List results:
Search options:
Use \ before commas in usernames
Professional Second Banana
Quote from Essentia:
What about games that use the in-game timer for SDA timing? I ask because I can think of one place in FF6 where resetting could be useful, but there could be about 10 seconds of playing that wouldn't count on the timer if I end up resetting.

The 2 options I see would be to keep using the game timer and manually add any time from resets that wouldn't be counted on the in-game time, or drop the game timer and just use real time for the entire run.  I could see it going either way depending on how much reset time there is relative to the total length of the run - IMO in an FF6 run only resetting for inescapable battles on the Veldt would be the former, but something like (theoretically) resetting to shorten every encounter on the world map would be the latter.

In any case, we are going to need to amend the official rules for SDA run categories based on this decision, and any timing differences between SS and SS w/resets (unless they're game-specific) should be clarified there.
dabes
Interesting.
A very good reason not to use the ingame timer with resets is Pokemon Gold. Train your pokemon to level 100, do the clone glitch, timer is were it was before the training.
Claimh Happy
Here's my opinion on FF6 resetting:

1) Even if this is purely luck-reliant, this still seems to break SDA's rule from the previous topic that resets cannot be used to reverse a mistake. That said, I disagree with that rule anyways because some tricks are worth resetting for tens of times and really aren't going to happen on the first one.

2) If the in-game timer will no longer be accurate after resetting, than your run is no longer Single-Segment by the in-game timer. It is segmented. The run must be timed externally.
Edit history:
RoboSparkle: 2012-10-03 01:12:49 pm
RoboSparkle: 2012-10-03 01:12:10 pm
Magical. Flying. Bathtub
I would have thought the obvious solution for stuff like this is if it takes you 3 minutes to do the reset and the ingame timer is out by three minutes due to this then do the same as you would for a segmented run or an RPG where you don't see the ingame timer at the end.  i.e. SDA time = ingame timer + time spent playing not accounted for by the timer.

S3&K is a good example of this in Hydrocity 2 where you need to die to enable a zip to the end of the level.  In game timer is used but, pulling random numbers out the air, the time would be counted as 1:35 (game time at the end of the level) + 0:07 (excess game time due to death and returning to the star post) = 1:42 (SDA time for the level)
Claimh Happy
Or if we measured externally we could just have a time. And that's it. Plus external timing accounts for lag, which is something the player has some control over.

If we aren't going to allow (most) games to have SS obsoleted by SS w/ Resets, there's absolutely no need for the method of timing to be identical.
Not a walrus
This is one of those cases where trying to apply the same rule globally is probably going to run into a lot of exceptions.
People have already been penalized for pausing during a run (I remember a run of one of the Sonic Genesis games that got penalised around 50 frames for using pauses to help line things up).

The basic idea of "single segment + resets" is that it's like a segmented run except failed segments count against your time. As such, just take the game timer, and manually add on the length of each failed segment (if the game doesn't do it for you).
Claimh Happy
Quote from ais523:
The basic idea of "single segment + resets" is that it's like a segmented run except failed segments count against your time. As such, just take the game timer, and manually add on the length of each failed segment (if the game doesn't do it for you).


That's not the point of SSw/Resets at all. This category exists because resetting actually changes things in many games. In most zelda games, it spawns you in a different location than where you reset. In some games it interrupts a cutscene or outright skips it. In others it can corrupt your save and give you items or abilities you didn't have before. SSw/Resets is meant to give a home to these tricks without requiring the run to just be segmented (especially important recently as the standard for segmented runs has increased dramatically).
Fucking Weeaboo
Quote from Blubbler:
A very good reason not to use the ingame timer with resets is Pokemon Gold. Train your pokemon to level 100, do the clone glitch, timer is were it was before the training.


In a case like that the in-game timer would be thrown out, resets or not, since it's untrustworthy. See TMNT IV, who's in-game timer is very bad and is not used at all.
Caution: This user contains Kana ^_^
I would have thought the Pkmn gold timer to be accurate, but just not to register, because the time wasn't saved to cartridge. So it's more a kind of manually time the bit in-between and add that, isn't it? Well, whatever. Hope this at least settles most/all discussions we had in the other thread ^^
1-Up!
Mike or IsraeliRD can better comment on timing, but my impression is that in-game timers won't be used for SS w/ Resets. More like manually timed from player control to loss of control. I could be wrong on this, though.
Thats how you comin' bruh?
This should greatly increase a runner's time.
Obscure games ftw
Quote from Somsai:
This should greatly increase a runner's time.

For most games it would increase the time.  But, this now allows savewarps and loadwarps in SS runs-the first example I can think of in Sly Cooper, as re-loading a file after an autosave can skip cutscenes and warp you to the start of the hub.
Not a walrus
Quote from Somsai:
This should greatly increase a runner's time.


Only if you're doing it wrong.
Willing to teach you the impossible
I grow to love you more and more every day UA.
Should the title of the old post be changed? It's locked but it still isn't obvious it's obsoleted.

https://forum.speeddemosarchive.com/post/single_segment_with_resets_now_accepted.html
Edit history:
moooh: 2013-11-09 09:33:20 am
Exoray
Added an edit to top of the first post to direct people here instead given the rare chance that someone would be reading that thread again.
Less confusing.
Edit history:
LotBlind: 2013-11-09 09:14:51 am
It's still stumble-able upon if you came through a Google search like me. But yeah.
Edit history:
Eternalspirit: 2013-11-10 08:18:58 pm
Quote from Marche_Fighter_Paladin:
1) Even if this is purely luck-reliant, this still seems to break SDA's rule from the previous topic that resets cannot be used to reverse a mistake. That said, I disagree with that rule anyways because some tricks are worth resetting for tens of times and really aren't going to happen on the first one.


Dark Souls Duke skip says hi. Smiley
Edit history:
Manocheese: 2013-11-10 10:25:57 pm
Yes, a cucco riding the ground.
I've been meaning to post about that rule. When someone asks if they can reset to get another try at a trick, the response is usually "if you fail a trick and have to reset, your run is probably too slow to be accepted." I've always thought this was a ridiculous argument. There are tons of mistakes you can make in a speed run: missing a jump, running out of health/ammo, failing a trick, etc. In all those cases, the verifiers are allowed to use their judgment to decide if the run is still acceptable. Yet this one specific type of mistake (failing a trick in an SS with resets run and having to reset in order to try again) somehow warrants an automatic rejection no matter how much time is lost. If it takes ten seconds to reset and try again in a five-hour run, is that too much to accept? What if the runner continues without doing the trick and loses a couple minutes; is that acceptable just because a reset wasn't used? Unless there's some reason for this rule that I'm not seeing, it seems nonsensical. In a category with resets, resets shouldn't be "sorta kinda half-allowed"; they should be allowed, period. If a runner makes a mistake, let the verifiers do their job of deciding whether to accept the run.
Quote from Manocheese:
I've been meaning to post about that rule. When someone asks if they can reset to get another try at a trick, the response is usually "if you fail a trick and have to reset, your run is probably too slow to be accepted." I've always thought this was a ridiculous argument. There are tons of mistakes you can make in a speed run: missing a jump, running out of health/ammo, failing a trick, etc. In all those cases, the verifiers are allowed to use their judgment to decide if the run is still acceptable. Yet this one specific type of mistake (failing a trick in an SS with resets run and having to reset in order to try again) somehow warrants an automatic rejection no matter how much time is lost. If it takes ten seconds to reset and try again in a five-hour run, is that too much to accept? What if the runner continues without doing the trick and loses a couple minutes; is that acceptable just because a reset wasn't used? Unless there's some reason for this rule that I'm not seeing, it seems nonsensical. In a category with resets, resets shouldn't be "sorta kinda half-allowed"; they should be allowed, period. If a runner makes a mistake, let the verifiers do their job of deciding whether to accept the run.


The rule was probably put in place because SS runs with resets weren't allowed before, or something along those lines. Now that SS runs with resets are allowed, I fully agree that resetting to undo a mistake should be perfectly acceptable. I think verifiers are intelligent enough to realize when this is used and warranted (the Dark Souls Duke skip, for example).
Not a walrus
That's pretty much exactly it. Unless the game has quicksaves then reloading to retry a trick will probably lose you a ton of time, but either way time losses from that should be treated just like any other time loss and not special just because it's a reload. So the statement is still somewhat true, but it's more that it's a sign you made a mistake rather than a mistake in and of itself.