page  <- 1234567891011121314 -> <- 1 .. 3 .. 14 ->
--
--
List results:
Search options:
Use \ before commas in usernames
3) Since we're still on the subject of free saving penalty, I'd like to point out that the current penalty often gives especially to the new runners the feeling that using free saving is more frowned upon than it really is. This often results in less segments used than would be appropriate to handle the situation as well as possible. There also seems to be confusion with what is meant by free saving. Maybe phrasing it differently would do the trick?

This, of course, doesn't bother the ones who've been here longer in the least, since they know the spirit of the rules and know exactly what they're working on.
Quote from 65:
3) Since we're still on the subject of free saving penalty, I'd like to point out that the current penalty often gives especially to the new runners the feeling that using free saving is more frowned upon than it really is. This often results in less segments used than would be appropriate to handle the situation as well as possible. There also seems to be confusion with what is meant by free saving. Maybe phrasing it differently would do the trick?


Yeah, I can see that the term 'penalty' implies saving is an 'offence' of some kind. Can you think of a better word?
Quote from ExplodingCabbage:
Thus for competition (and verification) to be fair we need an objective rule (or at least a well-understood guideline) for balancing a lightly segmented run against a heavily segmented run that is a few seconds faster and deciding which has better 'quality'.

I think it should be quite possible to make an algorithm that takes time and number of segment to give a fair "quality grade". That's about as objective as it gets, but obviously the result would still need to be evaluated by the verifiers.

Quote from ExplodingCabbage:
Quote from 65:
3) Since we're still on the subject of free saving penalty, I'd like to point out that the current penalty often gives especially to the new runners the feeling that using free saving is more frowned upon than it really is. This often results in less segments used than would be appropriate to handle the situation as well as possible. There also seems to be confusion with what is meant by free saving. Maybe phrasing it differently would do the trick?

Yeah, I can see that the term 'penalty' implies saving is an 'offence' of some kind. Can you think of a better word?

First time I got here I immediately read the rules and yes, it felt like saving was something that was frowned upon. I'd say this part of the rules needs rewording. Maybe change it to something like:
For games that let you save anywhere (i.e. without save points), we'll add half a second for each save to the time, to minimize the advantages gained by using huge numbers of segments.

Also, the bit in the rules about death warping, namely "This is referred to as death abuse. Radix never liked this either and used to impose small but inconsistent penalties when it was used. Death abuse is usually encouraged to avoid backtracking." seems a bit contradictory as newcomers don't have a clue who Radix is and therefor don't know that a lot of his ideas have been thrown overboard. I suggest leaving out the Radix bit.
Quote from Scepheo:
Quote from ExplodingCabbage:
Thus for competition (and verification) to be fair we need an objective rule (or at least a well-understood guideline) for balancing a lightly segmented run against a heavily segmented run that is a few seconds faster and deciding which has better 'quality'.

I think it should be quite possible to make an algorithm that takes time and number of segment to give a fair "quality grade". That's about as objective as it gets, but obviously the result would still need to be evaluated by the verifiers.


Agreed, this is basically what we want, and indeed is what we have at present, although it's a simple algorithm that consists of 'add on half a second to the time per save'. I can't conceive how any other form of algorithm could work, though, whilst remaining fair, acheiving the desired result (whatever that may be) for all games (given that games vary enormously in length, difficulty, the complexity of tricks, the existence of exploits revolving around saving, etc.), and not requiring runners to solve complex maths problems to determine the optimum number of segments to use.
Quote from Scepheo:
I think it should be quite possible to make an algorithm that takes time and number of segment to give a fair "quality grade". That's about as objective as it gets, but obviously the result would still need to be evaluated by the verifiers.

Crazy, I was just thinking of that while you were posting. I'm no math genius, but this was my idea:

S: arbitrary segmenting score
10: doesn't need any extra segmenting
20: might need a segment or two more
30: the run would be better with some more well-placed segments
40: the run needs more many more segments than most
50: this run needs a ton of segmenting

n: actual number of segments used

Base segments = ceiling((run in minutes / 5) * log(S)) = B

penalty in seconds = (n - B) * 5^(n - B)

I used five minutes as the duration for a segment, but I know that can be a really long time. This is just an example. I also picked five seconds as a base in the penalty section out of thin air. Surely there's a more elegant algorithm, but the parts I like are the community determining the arbitrary segmenting score on a game-by-game basis and the penalties increasing for each added segment. This would make using a time saver you've found still doable for the first couple segments in excess of the community-agreed amount, but will eventually stop a "segment anywhere" mentality.
najzere:
There are several features of your algorithm that I see as problems:

* The community know less about the game than the runner, especially before the runner embarks upon the run. As such they'll almost always get S wrong. Also, who chooses S? What standard do they judge it against? Do we change S if major new tricks are found for a game, and is that fair on people whose runs are already up?
* If the community sets S too high, there's zero deterrant against extra segmenting, which is worse than the current system.
* If the community sets S too low, the punishment for using more than B segments is incredibly harsh. One segment over incurs a 5 seconds penalty, two seconds incurs a 50 seconds penalty and 3 segments over incurs an enormous penalty of over 6 minutes. That doesn't look like it's 'eventually' stopping segmenting to me. Tongue

The last two points could be mitigated by not having a base number of segments and starting imposing the penalty from the first segment, taking a number only slightly above 1 to the power of n-B instead of 5 (possibly determined by S), and perhaps multiplying the result by some function of S, but the issue will still remain that punishment for a needless extra segment in a run with few segments will be low and punishment with many segments will be exponentially larger. I'm not sure this is fair or that it helps acheive the result we want; a constant penalty per segment seems better for consistently deterring unnecessary segmenting (i.e. not letting people get away with it if S is set too high) whilst not preventing legitimate segmenting if S is set too low.

Meaning no disrespect, I think that - if the idea of using some algorithm other than a constant penalty is a good idea at all, which I'm very sceptical about but haven't totally dismissed as madness yet - it would be much more productive to discuss properties we want that algorithm to have, or even more fundamentally the goals we want it to acheive, and only once that is done to start coming up with actual variables and functions.
Back in the game!
Quote from mikwuyma:
UltimateDarius: Do those games even let you save anywhere with all of your progress saved in the same spot? If not, then you're missing the point.


Well, crap.  Wind Waker does not.  But the Pokemon games do.  But then again, that is already covered by the in-game timer continuing to tick away.
Actually, I was talking of an algorithm for weighing the time-vs-segments of one run against the time-vs-segments of another one, to determine whether one should obsolete the other or the time improvement doesn't weigh up against the increased number of segments.
Quote from ExplodingCabbage:
There are several features of your algorithm that I see as problems:

I agree with all your reservations, actually. If the penalties seemed especially harsh in my formula, it's probably my bias against segmentation. Tongue

I do like the idea of exponentially increasing penalties, although perhaps not as acutely. The reason I don't like strictly linear penalties of one amount for all infractions, is that segmented runs are already in a separate category, so I don't see the need to penalize someone for the first couple (or more?) segments in their runs. I'm against mass-segmenting, so I like seeing it become increasingly difficult to justify more and more segments. The benefit of a standard penalty per segment is the runner can make a decision on a per trick basis instead of worrying about the overall time. I guess I'm just in that group of people that considers less segments = more skill.
Edit history:
mike89: 2009-06-15 12:39:55 pm
SEGA Junkie
1) I understand that it would be pretty unfair to remove a standing run that, at the time of it's creation, was fair by SDA rules but may no longer be. However, having said that, how do you expect a run outside SDA's ruleset to be obsoleted, especially if it's in a category that no longer exists? I would get in contact with runners who have runs affected, explain that SDA's rules no longer cover their run (with a certain amount of tact that I do not possess >_>) and give them the option of having it continue to stand (with the caveat that it no longer falls under SDA rules), or having it removed.

3) This one seems to be the most problematic. As a simple curiosity for me, though, I'd like to know why in console runs, more segments seem to be encouraged, while for PC runs they seem to be frowned upon. Whether or not they actually are is irrelevant, because they are (as previously mentioned, simply the concept of a save penalty is enough to ensure that).

Further to this point, I don't feel that the amount of segments used should affect the verification decision.

4) We are not TASvideos.

That should say it all, really. Why do PC runners get the aid of tools? And where do (or where can) you draw the line? I don't know much on the specifics of scripts to speak further (ie most PC runners consider weapon change scripts or something like that to be fair game) so I won't offer a judgment, rather just leave that as an observation.

6) I think the runners themselves answer this question, just by asking themselves "is it really worth my time to do this category?". Using the specific example of Banjo-Kazooie, the 100% run is the default (because it's so close to any% anyway). From there, one would have to work backwards to plan an any% (by deciding which six Jiggies and 90 notes to omit from the route) and the time spent planning that by a runner may not be worth the separate category... they could've spent that time trying to beat the 100% instead (as many have already). Especially if as much of the run is similar as it would be in B-K (certainly none of the means of collecting Jiggies change...).

7) This is the one issue raised that I have a firm stance on. In-game time where possible. This means everyone knows where they stand and runs can be timed consistently.

The only reason I would stray from in-game time is if that last point is not enforced - ie. it doesn't consistently time runs. Metroid 2 is the obvious example, where the timer can be gamed, as it drops seconds upon saving. Even then it's a borderline case as you can't save anywhere, but it does raise the possibility that a run would exist solely to minimise the in-game timer, which would consist of killing all Metroids near a save point in their own segment. Not my idea of a "speedrun" in the true sense of the word.

(Er, I should clarify this. While the timer can be gamed that in itself is not the issue; what is the issue is that a worse run, or a run with a worse route or something, could appear better by the in-game clock, substantially so if their saves were planned to be x:59 into a segment and the better run gave no consideration to such things and played for real time.)

Where no in-game time exists, runs should be timed such that they are consistent and do not disadvantage any player attempting to beat the standing run - in other words, loading time should not be counted, console or PC. I have no idea why this isn't the case in the first place, and it may already be, but earlier comments in the topic make me think otherwise.
I love YaBB 1G - SP1!
What about the proponents of segment penalty agree on what's correct with test cases, I always do a big table of test cases when I have to balance stuff, usually for games, people have liked the results so far. ie. A 30 minute run in 2 segments versus a 28 minute run in 50 segments. Are 48 extra segments okay to use for 2 minute improvement in this case? No? How much should have been gained for it to be okay with you?. Answer the question before reading more.



To me the minimum should have been 5 minutes. And now I do the math thats equal to 6.25 seconds per segment, which is close to what I thought a good penalty should be (5 seconds) so I'm happy so far Tongue (Please remember I dont want these penalties affecting the final time I just want them for competition purposes. So the penalty being equal to the expected gain is good) Now it would need a big ass table full of tests and see what values come up.

Another kind of penalty could be a % penalty, ie 1% time penalty per segment, maybe add in incremental penalties, each extra segment costing .1% more, same could do with absolute time penalties of course. Now those values I just said any number, let's see how they run in ths case...:

Absolute: n*p
Absolute incremental: n*p*(1+i*(n-1)/2)
%: t*n*p
% Incremental: t*n*(p+i*(n-1)/2)

For:
t = length of run
p = base penalty
i = penalty increment per extra segment
n = number of segments


Now to get the 5 minutes I originally wanted the values should have been around (tried to round to easier to read numbers):
Absolute: p = 6.25s
Absolute incremental: p = 1.7s, i = 0.1s
%: p = 0.4%
% Incremental: p = 0.15%, i = 0.01%

____

But anyway, there's SS and segmented, as much as I read the admins feel records shouldn't be the goal (odd), I view SDA as a site for time records, as such SS is supposed to be the speed record of a human playing a game in one attempt, segmented is supposed to be the speed record within human capabilities (without being TAS). As such, within that description, segmented shouldn't have penalties at all, you did it faster? then it's better, I don't care if you saved every frame. You don't want to do so? then don't mind your run being obsoleted if ever or do a SS or IL. Your segmented is not supposed to show skill, its supposed to show fastest completion within the rules of the game.

I like the idea that for games where IL as defined is not applicable it could be a segmented run per levels. Again they would have no penalty since the places where it MUST be segmented are clear, hopefully.
Waiting hurts my soul...
Quote from mike89:
Where no in-game time exists, runs should be timed such that they are consistent and do not disadvantage any player attempting to beat the standing run - in other words, loading time should not be counted, console or PC. I have no idea why this isn't the case in the first place, and it may already be, but earlier comments in the topic make me think otherwise.

This is done for PC because hardware can vary quite a bit and loading times are affected.  Consoles are considered to be fairly set hardware; however, I think it may need to be asked if changing this wouldn't be best, as I'm sure running a PS1 game loads quicker on PS3 than on the original hardware.  Also, installing 360 or PS3 games to the HD lowers load times as well, and that probably shouldn't be counted against time.  Of course, such a change would increase the amount of work to time these games.
boss
Quote from ExplodingCabbage:
Quote:
This takes looking at it more than one segment at a time imo. If you segment one part in order to pull off a 20-second timesaver, with 4 more parts that were simply segmented for better optimization your timesaver is already nullified with a 4 second penalty on EACH segment.

Uh, so then you'd segment before the trick and nowhere else, allowing you to do all the tricks but not just segment needlessly to optimise running around. Which is exactly the result I'd want to see.

Right now, not even the HL run does that, so I'm not too sure how you can't see that already. Having a half second penalty already eliminates all the half second saving tricks that need a separate segment. Upping the penalty would scrap out some tricks that save a bit more time. Even little tricks like that add to entertainment.

Quote from ExplodingCabbage:
Quote:
Quote:
As for the save penalty, pretty much any game with saving anywhere has warping upon saving and loading

When it's really obvious, then it gets a penalty.

That's not really a penalty, you're just adding in the time for the missing frames. That doesn't provide a deterrant.

It's a bit ironic since the point of the rule was also to make up for the missing frames at the start of segments. No matter what word I use - the point stands. So once the gap is filled, why punish a run even more?

Quote from ExplodingCabbage:
Removing the segmentation penalty would stop me from contributing because what's the point in submitting a segmented run where you've not put in lots of unnecessary segments if someone can just double the segment count, copy the run and beat it by a few seconds through extra optimisation, and that will obsolete mine?

Nobody would bother. Remember that we're not TG. We're not keeping track of world records so why would anyone even think about basically duplicating a run with the goal of finishing only a few seconds faster.

Quote from 65:
I've always considered this site to be primarily about skill, entertainment is something that you can have unless it restricts speed or skill. If I want to watch something that's made primarily entertainment in mind, I go to TASvideos.

No matter how much people desperately try to oppose the fact that tasvideos and sda are the same thing saying how they differ, for me as a viewer and a runner, they both achieve the same exact goal, on purpose or not.

Quote from mikwuyma:
Groobo: Runs with scripts are a very small % of the site, and outside of a few communities (Half-life and Portal), not many people use them. The issue of scripts always brings up a lot contention and arguments, which is why it's being discussed whether it's worth allowing more runs with scripts. That and scripts are paradoxical to the other rules we have on the site.

It's funny how other runners that aren't even slightly affected by the grandfathered rule are the ones constantly attacking it, saying how the site should treat all games the same, but then you have the exact same people saying that we need to allow more game specific rules.

Seriously, we'll have people going against quake basically having its own site at some point.
Invisible avatar
I'm surprised to find Spider's opinion on the save penalty as such :). About the additional category (segment at the start of levels) suggestion, I feel it's a bit too redundant and too arbitrary, but it is something to be thought about. The current segmentation system is good, but I feel a little more deterrence from heavy segmentation is needed. 1 second penalty per save should do well, now that I think of it. I wouldn't mind seeing 2 seconds myself, but this indeed punishes the runner a little too much. 1 second is sensible. Of course, like I said already, old runs need not be re-timed; it is simply not necessary. Also, about the algorithm suggestions... there might be complicated systems that MAYBE will accomplish a minimally better job at deterring segmentation while being a little less punishing on the runner. However, simplicity is an important thing. Save penalty is pretty simple - only applies to saves you make yourself in games with a save anywhere option. It's predictable (always the same amount of time), and easy to be counted by the runner. It would suck to segment where you need it, then find out at the end of the running process that the run won't be accepted due to how the algorithm is used; whereas with the save penalty, if you consider adding a segment somewhere, you always know what the consequence will be. That's why I think the linear system is the way to go.

Also agreed that the save penalty section will need to be rewritten; I like the "For games that let you save anywhere (i.e. without save points), we'll add half a second for each save to the time, to minimize the advantages gained by using huge numbers of segments." suggestion, with the additional time reflecting whatever the new penalty will be (if it will be changed). Sounds way less like some kind of punishment this way.

And I feel any save penalty is a must - the talks about whether segmented runs need any skill happen often, and indeed, maximizing the time saved while avoiding using too many segments is pretty much the only thing that adds some necessary skill into the mix. There were already many people who thought the HL run was 'over the edge' on the matter. Removing the minimal deterrent from going even further seems counter-productive to me - after all, runs are meant to attract watchers here, and many will skip a run that uses a segment every 3 seconds. Also, save penalty serves a dual purpose - in many, if not most 'save anywhere' games there's a period of time during the loading where movement is processed, but not shown on the screen. Without save penalty I could probably create a 2 minute long Deus Ex run. Except nobody would watch me being in the menu 99% of the time. As such, I think the removal of the save penalty altogether would be a mistake.

Warning: a wall of text incoming, however it illustrates an important point I want to make, so just bear with me. There's also a tl;dr if you can't be bothered to read it all.

Well, that's all well and good, but the real reason I'm posting is known to most people who saw me rambling about on IRC. Some people are advocates of allowing all scripts on all games, but I am very much opposed to that idea. I was intrigued by the suggestion of EC:
Quote:
4) Hard one, this. I think I'm against allowing scripts altogether, but then I don't really understand what they are capable of since I've never used them. Theoretically, couldn't you effectively TAS a game with scripts my creating a massive mega-script that when executed runs the whole level automatically? Or am I totally overestimating what it's possible to do?

Obviously, the answer is 'theoretically, yes'. However, theory and practice often don't go hand in hand. Therefore, I decided to make a special run of 100m, to prove theory might be incredibly close to practice in this case. What's 100m? A custom map in Quake, which is exactly what it says on the box: a straight, 100m course, without any monsters or secrets. We use it to evaluate our Quake bunny-hopping abilities [for the uninformed on the subject, bunny-hopping is using Quake physics in order to gain speed well past the intended maximum speed without any boosts, named such because it involves constantly doing curvejumps through the air]. You can see the current table of bunny-hopping comparison in 100m here. Now, note, the 'crème de la crème' of the bunny-hopping community is capable of 10.5 and lower runthroughs. My result is currently third (10.10), second is the bunnyhopping legend Kay Berntsen, and the first is a relative newcomer Jason Hochreiter, who has uncanny bunnyhopping abilities. It's a map practically every Quake runner knows, practically every Quake runner ran, and practically every runner worked hard to achieve their result on. It's not an uncontested map!

So, how does this relate to this topic? Well, I decided to try to see how far I could take scripting. I decided to see if I could manage to get to the aforementioned 'crème de la crème' by writing a string of commands and executing them, without any human input during the entire run. I wanted to do that to illustrate a point, but also to have some fun in checking what the script engine can do. As such, my attempt is a very crude and unoptimised script.

Did I manage to make the script get under 10.50 (a huge achievement, seeing as Jozsef, one of the best runners and hoppers ever, has 10.52. Also, many very competent runners will never achieve this threshold)? Yes, I did. And that was after about an hour of writing the script - a crude, 'alpha' version of the script. So, I decided to go further. I wanted to beat myself by using a script, surely a good illustration of how allowing all scripts could potentially lead to things one could only describe as TASing (not that I have anything against TASes, I love them, but this site's goals are slightly different).

And beat myself, I did. By that time I had about one and a half hour of additional tweaking that went into the making of the script. So, I managed to beat the result I had to retry for about a week in total with a script that I wrote in less than 3 hours. I managed to beat the result I achieved after having almost half a year of bunny-hopping experience - and believe me, I trained my bunny-hopping a lot.

But that wasn't enough, I saw many flaws in the script, I rewrote a few things, all with a single goal in mind: to achieve the fastest full-speed 100m run anyone has ever seen.

And yes, I did manage. The top time by Jason was 9.86. My script achieved a 9.79. And it's very crude, with a LOT of flaws and a lot of tweaking still possible. In total it took me about 5 hours to be faster than anyone from the expert bunny-hopping community ever was. Of course, my words would not carry much weight without any proof, so, for the types with Quake installed (actually even a shareware version will be able to run 100m): .dz file

(I couldn't resist changing the modify date with this time. Actually, I have a fully scripted 9.77 recorded but I just wanted to make this lame gag. Sorry :()

For the people without Quake installed, I've made a HQ video: MP4 video

Finally, the crude script file [you can see I was having fun]:
Code:
// Generated by Ben Johnson (for real)
// disqualified for scriptozolol abuse
// weee
_cl_name "recordbot"
// wait aliases
alias w "wait"
alias w2 "w; w"
alias w4 "w2; w2"
alias w8 "w4; w4"
alias w16 "w8; w8"
alias w32 "w16; w16"

// clear all movement alias
alias number_16_bus_shelter "-forward; -moveleft; -moveright; -back; -left; -right; say resistance is futile"

// align and acceljump
alias drifblim "cl_yawspeed 150; +right; +forward; w4; +moveright; cl_yawspeed 190; w4; w2; cl_yawspeed 230; w4; cl_yawspeed 170; -moveright; w4; cl_yawspeed 100; +moveleft; w2; -right; +left; w2; cl_yawspeed 160; w2; cl_yawspeed 220; w16; w2"
alias thi4f "+jump; w; -jump; -forward; cl_yawspeed 160; w2; cl_yawspeed 120; w4; cl_yawspeed 60; -left; -moveleft; +moveright; +right; w; cl_yawspeed 100; w2; cl_yawspeed 130; w2; cl_yawspeed 160; w8; w4; w; cl_yawspeed 130; w4; cl_yawspeed 100; w2; cl_yawspeed 60; w2; -right; -moveright; +moveleft; +left; w; cl_yawspeed 120; w2; cl_yawspeed 160; w4; w; cl_yawspeed 160; w4; w2" 

// double twist 1
alias accidental_babies "+moveleft; +left; cl_yawspeed 175; w; +forward; +jump; w; -jump; -forward; -moveleft; -left; cl_yawspeed 80; +right; +moveright; w2; cl_yawspeed 100; w4; w2; cl_yawspeed 140; w4; w; cl_yawspeed 120; w4; w2; cl_yawspeed 70; w4; -moveright; -right"
alias mrufkojat "+left; +moveleft; w4; cl_yawspeed 100; w4; cl_yawspeed 123; w8; w; cl_yawspeed 100; w4; w2; cl_yawspeed 70; -left"
alias buttface "accidental_babies; mrufkojat"

// double twist 2
alias luxury "cl_yawspeed 180; +moveleft; +left; +forward; +jump; w2; -jump; -forward; -moveleft; -left; cl_yawspeed 70; +right; +moveright; w4; cl_yawspeed 99; w4; w2; cl_yawspeed 140; w4; w; cl_yawspeed 120; w4; w4; cl_yawspeed 70; -moveright; -right"
alias yacht "+left; +moveleft; w4; w; cl_yawspeed 95; w4; w2; cl_yawspeed 120; w4; w2; w; cl_yawspeed 95; w4; w; cl_yawspeed 70; -left"
alias raymond "luxury; yacht"

// finishing
alias duct_tape "w4"
alias swiss_army_knife "cl_yawspeed 200; +moveleft; +left; +forward; +jump; w2; -jump; -forward; -moveleft; -left; cl_yawspeed 100; +right; +moveright; duct_tape; cl_yawspeed 145; duct_tape"
alias paperclip "cl_yawspeed 70; duct_tape; cl_yawspeed 30; -moveright; -right"
alias macgyver "swiss_army_knife; paperclip"

// all twists
alias blatherskite "buttface; raymond; raymond; raymond; raymond; raymond; raymond; raymond; raymond; raymond; macgyver"

// woot
bind SPACE "record 100m_script 100m; duct_tape; +speed; drifblim; thi4f; blatherskite; number_16_bus_shelter; -speed"


I assure this script will run perfectly, as long as you have stable 72 frames per second when the script is being executed. The time might vary from 9.77 to 9.80, but that's because Quake's timer starts at different points depending on how the loading goes. It ain't a huge difference usually, but it can throw the results about a few centiseconds. Also, turn "Always Run" off in the options. Otherwise it WILL desynch. Finally, LLCoolDave got 9.73 running the exact same script, so it is fairly dependant on some other settings, but I'm not sure what those settings are. Cheesy

This script will achieve a speed of roughly 670-680 units. 650 is already an exceptional speed, especially if you're doing 'straight path' bunnying.

As you can see, the movement is fairly robotic and the scripting is easy to spot. It's pretty much impossible to avoid the robotic movements. However, I just wanted to make a point that allowing all scripts for all games is a bad idea. I also am not FULLY against scripts; as I already said, I consider weapon change scripts harmless, and also pretty much undetectable anyway, so it doesn't make sense to ban them. I feel the line should be drawn at movement scripts and things that allow superhuman manipulation of the game, however. Those things are easily detectable. If this line isn't drawn, this script would, according to rules, obsolete the work by the human runners. This script, written in just a handful of hours. And it would obsolete the week of work I put into my time; it would obsolete the effort Kay put to learn and enhance what is likely the best bunnyhopping technique; and it would obsolete the result by Jason, who I know spent a lot of time making his exceptional 9.86.

Thankfully, a 'no overboard/movement scripts' rule is already enforced on /quake/, and so it won't be obsoleting anything. However, I feel the need for such a rule on the main site, as well.

Note, this ain't an attack on anyone's opinion, I'm just trying to illustrate my point better.

tl;dr: In a few hours I made a script that beat an entire Quake map by itself and got the best full-speed time on that map in SDAQuake's history so far.
Quote from groobo:
Quote from 65:
I've always considered this site to be primarily about skill, entertainment is something that you can have unless it restricts speed or skill. If I want to watch something that's made primarily entertainment in mind, I go to TASvideos.

No matter how much people desperately try to oppose the fact that tasvideos and sda are the same thing saying how they differ, for me as a viewer and a runner, they both achieve the same exact goal, on purpose or not.


I'd prefer if you didn't present your personal opinions & beliefs as facts, thank you very much. Entertainment is entertainment is entertainment; a play can entertain as much as a movie; are they the same thing? Just because the sites happen to achieve the same goal for some people, does it mean that the sites themselves strive for those specific goals? No.

TASvideos and SDA are indeed similar in many regards, but they are not the same thing. It makes me a bit sad if you do think the other way around is the truth as anyone should perceive it.
sda loyalist
A couple of people mentioned I should post my thoughts on segmentation in this thread, despite their, well, extremism. I have a few varying views on this and I haven't decided which one I prefer more.

  • Segmentation shouldn't be a separate category - this is the least popular one. basically, less segments beats more segments, no matter what the time is. of course, the current verification process will weed out 'newer techniques but worse execution' so that's not an issue. i guess the main issue people have with this is that some games really aren't suited to single-segment running. i don't care, personally; make a segmented run then - there's no penalty, after all. alternatively, one might think that this promotes 'beating the previous run by one segment' but i don't have an issue with that either. they've probably gained some time by not saving, unless it's one of those weird PC games that lets you save anywhere, doesn't add the time to save onto the game timer and maintains velocity across saves, in which case their continued nerve is to be rewarded anyway because such games usually have taxing movement techniques like bunnyhopping
  • Segmentation should be restricted to specific areas - dex touched upon this, suggesting 'at the start of the map'. technically this is the segmentation style that projects like Quake done Quick use because loading in the middle of a map has traditionally been considered cheating. of course this raises the whole 'arbitrary' thing up, another thing i see as a non-issue. without rules given as gospel by those on high i don't think there's much challenge to it if you make up your own category, rules and segmentation plan


Also dex, Roll Eyes
Fucking Weeaboo
Quote:
Segmentation shouldn't be a separate category


I'm sorry, but I severely disagree with this.  Both single-session and segmented provide different challenges.  Segmentation allows the runner to be more precise and be able to take the chance to execute more difficult tricks that could ruin a single-session run a hour or two in (and they wouldn't want to do that).  Single-Session is challenging in that you have to perform at your best for a long session.  You may not be able to do all of the outrageous tricks a segmented run can do, but that doesn't mean you can just be sloppy either.

Plus some people I think segment TOO much.  That's one of the big reasons why I don't like watching PC runs.  It's partially because I don't do much PC gaming, partially because of all the load times, and partially because everybody segments every 0.523 seconds.  I have nothing against segmenting...I mean, if that's what it takes to get the job done perfectly, then fine.  But it's a bit hard to watch.
boss
Quote from 65:
Entertainment is entertainment is entertainment; a play can entertain as much as a movie; are they the same thing?

They both can entertain, no? Hence in a way they're the same.

Quote from 65:
Just because the sites happen to achieve the same goal for some people, does it mean that the sites themselves strive for those specific goals? No.

But that's what I said.

Dex: Unexpected. I'm thinking nobody would go that far with scripting in a run (and it surely wouldn't make it through verification, even with the current rules) and it's still very different from what we've seen in the hl runs. It's a good idea, even though practically this would change nothing - only the FAQ page.
berserker status
Quote from groobo:
Quote from 65:
Entertainment is entertainment is entertainment; a play can entertain as much as a movie; are they the same thing?

They both can entertain, no? Hence in a way they're the same.


In a way, yes.  Are they the same?  No, absolutely not.  This is a pretty ludicrous claim in my opinion.  You're right, the primary goal is to be entertaining and strive for the fastest time possible but the MEANS of doing so are practically polar opposites.  The point is, at TASVIDEOS you can achieve a ridiculous time through inhuman means (i.e. chrono trigger, case closed) while at SDA it stresses SKILL and LEGITIMACY.  Similar, yes.  The same thing?  Not by a long shot.
Quote from groobo:
Quote from 65:
Entertainment is entertainment is entertainment; a play can entertain as much as a movie; are they the same thing?

They both can entertain, no? Hence in a way they're the same.


In a way, yes. However, while the other might entertain a certain audience the other one might not. Thus, they do not share completely same characteristics; they're merely similar. As you've surely noticed, not all people like/dislike both speed runs and TASes, so the same logic applies here, too. Also, what RiskBreaker Y said.

If we were to think that, since both can entertain, they're the same, wouldn't that make your original statement fairly ridiculous? "A show of skill, or entertainment? TBH it's balanced right now and what you're trying to do is to hurt one side in the other's desperate favour." Since a show of skill can entertain, it IS entertainment and whether it's balanced in one way or the other doesn't make any difference as they indeed are, in a way, the same.
Groobo, a quick response to your points:

* My issue with segment-break warping isn't the effect on the final time (though obviously that needs to be added back in in any case), it's the fact that it looks shit and spoils the entertainment value of a run. Adding the dropped time back in has no bearing on this.

* Many of your arguments seem to revolve around the idea that 'nobody would bother / be dickish enough to obsolete this by doing X lame thing'. And yeah, you're probably right, and I've probably skirted around my real feelings on the issue by using the unfair obsoletion argument. Really my issue is more that I don't want to do things that will make my run less optimal for purely subjective reasons (like avoiding segmentation even though there's no penalty). And when watching a run I look for all the little timesavers that are used and all the little mistakes made - as you said, even half second tricks add to entertainment. If there's no segmentation penalty, any time lost due to not segmenting as much as possible is an unambiguously bad thing and makes the run worse by the standards we judge them on. As such I'll just be seeing avoidable imperfections everywhere and thinking that the runner could've avoided them with some more 2-second segments, and that'll spoil my appreciation of segmented runs tbh.
Quote from groobo:
Dex: Unexpected. I'm thinking nobody would go that far with scripting in a run (and it surely wouldn't make it through verification, even with the current rules) and it's still very different from what we've seen in the hl runs. It's a good idea, even though practically this would change nothing - only the FAQ page.


Actually, the point he makes is that there is no objective reason to reject this run according to the current SDA ruleset (not the Quake ruleset, but, as has been pointed out several times, the quake section is not considered to be part of SDA and does its own thing.), as it explictely allows scripting like that (read it if you don't believe me). The reason this would be rejected is thus entirely subjective, because the verifiers have a personal issue with a scripted run like that, which in turn means that you expect there to be some ideological common ground amount viewers/verifiers that would be used to reject this run. I don't see a reason not to anchor that apparent ideology in the rules.
sda loyalist
Quote from Lord_VG:
You may not be able to do all of the outrageous tricks a segmented run can do

There's nothing stopping you except your own skill and nerves. Which is exactly how I want it. People pulling off insane stuff three hours in, simply because they had the balls to go ahead and do it even though it might kill the run. That's speedrunning.
Quote from lag:
Quote from Lord_VG:
You may not be able to do all of the outrageous tricks a segmented run can do

There's nothing stopping you except your own skill and nerves. Which is exactly how I want it. People pulling off insane stuff three hours in, simply because they had the balls to go ahead and do it even though it might kill the run. That's speedrunning.


lag, there are some tricks whose odds are simply too low for this to be viable. If a run has 5 complicated physics tricks or tricks requiring frame-perfect timing each with a 1 in 100 chance of success, that's nothing in a segmented run, but the odds of successfully executing all five in SS would be 1 in 10 billion. SS runners ALREADY put in hundreds or thousands of tries and cram in all the tricks they can without making the run inviable to execute without it taking up an unreasonably long portion of their lives.
IMO, a large save penalty doesn't make any sense. A 5 second penalty would mean that on a 20 segment hour and a half run, you'd gain a minute and forty seconds, which is quite a considerable increase, especially on an oft-run game. Which would mean that once the run is optimized to within a couple seconds, less segments with more mistakes would win out. It defeats the point of segmented runs, in that it's supposed to be very optimized by the fact that they save time since they can save often. The current penalty is enough to deter save abuse, without a major change in the resultant time of non-abused run.

For game time vs real time, people have been saying to use game time as long as it's accurate. Being accurate isn't necessary. It should be used as long as it's consistent. A game timer that runs fast is consistent, but not accurate, and is certainly acceptable.