Deciding Standards/Rules

λ Half-Life
1

**There are several things that need to be resolved, I’ll write all of them here: **

  • Scripts / TAS scripts, what is the difference?
  • Segments; with unlimited it is possible to create one every .1 sec, essentially making TAS like strafes.
  • Should replicating mouse wheel scripts be allowed in no-scripts?
  • Deciding on a mod standard; This is subject to change if separating the render and physics FPS is plausible.
  • Creating a client/mod for Half-Life (and other expansions/mods?).

Deciding Standards/Rules
I am opening this as a partial response to SpiderWaffle’s recent thread but mostly to look at what categories exists and if any changes can be made or if they should be kept. A large portion of the community may already be aware of this, but I feel like there may still be quite a lot of confusion. Let me explain myself briefly, lately a lot of people have been moving to official versions of Half-Life, especially after PJC and I several months back started looking into HL21. We were both sort of assuming and arguing against people that claimed it wasn’t following legit rules. As you know, there’s a lot of people outside the speedrunning community that don’t exactly know much about it.

Why wouldn’t they be following the rules?
It didn’t exactly cross my mind at the time that there was a possibility that they weren’t. I believe PJC started arguing with rayvex which is one of the few within the community who was actually involved with HL21.Of course as it turned out, the “youtubers” were right, not because they knew what they were talking about, but by assuming it merely based on things like glitches and speed which of course wasn’t really the reason. Maybe you could argue it would have been called HL22 on official settings.

So why did this happen?
The two main Half-Life versions are WON and Steam. WON has no bunnyhop cap but is capped at 100FPS. Steam has a bunnyhop cap but its FPS is uncapped on the other hand. Playing with a bunnyhop cap is and was unacceptable for most people. Therefor an outdated WON client capped at 100 FPS is what most people would choose. Scripts do not run well at 100FPS however. For example, this forced Quadrazid on his earlier Opposing Force run to set his FPS to 83.33… There was also some drama lately over allowing an autojump command (frameperfect regardless of FPS) when on 100FPS. However I feel like this may not be legit or comparable.

Anyhow…
The crooks of the problem was the added bunnyhop cap that valve implemented, which was largely influenced by Counter-Strike. TFC and HL wasn’t exactly complaining. There are a lot of people who want to run on the official versions, and I’m not here to change that. What I would like to is to have globalized rules for a specific mod because I know that a large portion of the community is already running on one. Currently everyone is following the HL21 Hybrid settings by using bunnymod pro. The question I ask is, why?

**These are the settings HL21 used: **

  • steam ver. 1.1.2.0 (NGHL)
  • Gauss/grenade transition feature that never existed on any official version of Half-Life
  • Bunnyhop cap removed
  • Restored WON crowbar damage
  • Quickgauss glitch removed

These settings have been arbitrarily defined in favor of gameplay/entertainment value and planning. And as such I personally find HL21 as the best speedrun released to date. It is very very intricate and the level of detail and planning is astounding. It blows my mind every time I watch it, some 50+ times. <:

What I would like to propose are any of the following:
(Some changes are extremely minor.)

**1. No-Bunnyhop Cap (or WON FPS uncap?) **
Simply a removal of the cap on a steam version which was implemented thanks to CS, please remember to thank them. Gauss/Grenade transition isn’t a very big deal and while people may say that QuickGauss is rather extreme, the same was said about IHD. QG of course gets auto enabled by removing said feature.
WON crowbar damage barely makes a difference except for the two first windows in HL.

**2. Unified **
Collect every single glitch and traits from all versions, put them into one client. If valve updates, we may have issues however.

**3. A Modification decided by the community **
Essentially a mod that can add anything regardless of making sense, think of it as AG or some other multiplayer mod. The con here is that it feels like you’re not really following any rules. i.e you could just add a feature that enables you to cut down time. This is essentially what the HL21 settings are trying to be.
I believe there are numerous problems with this however. In a multiplayer the goal is to beat players, in a speedrun it is to beat the game. With option #1 and #2 you are following some type of static decision, with this you are not.

4. A Modification decided by the community based off of only existing features/glitches
Would be very similar to Unified, but basically allows pick and choosing. Maybe we don’t want QG? Maybe we want WON crowbar damage? etc

**5. Suggest more… **
I would personally prefer a logical system that isn’t arbitrarily defined nor has any “new” added features, which means #1 or #2. There has also never been a Basic-Script standard, I’m not sure how many would be interested in this but maybe it’s worth creating it.

**“Example category that could include certain scripts such as autojump; or alternatively set some sort of rule that limits wait commands to only be used within an alias, and all bundled/connected can only contain a total of say two.” **

Another probably smarter way would be to simply allow a shotgun spam script in the current no-script category. It is important to cut down the amount of categories if it is possible to settle on some sort of middle ground; especially if the script replicates exactly what a mouse wheel is already doing.

To get a clear picture of how this beautiful hierarchy of categories work together, have a look at this picture I made. Please have a thorough look at it to understand, the branches are logically placed and separated. Most are examples and they do not represent every single category ever used.

#2 Unified would be placed on the same branch as No-Bunnyhop Cap.
http://i.imgur.com/8vlmYcQ.png

Again, I’m merely saying the current mod ruleset is completely arbitrary, but it doesn’t have to be. Whatever you’re in favor of, Bunnymod Pro (or Bunnymod XT or a new client/mod) would still probably be used. However, remember that the point of this thread is the ruleset, not the clients or mods to be used but I do agree with the idea that there should just be one client/mod that contains everything necessary. This would mean all official versions and a mod version could be thrown into one single “program”.

2880×1400 374 KB

2

It’s very complex, but fortunately most of complication is of minor impact (little glitches, guass/nade charge, ect). I don’t pretend the optimal solution, but I do know we’re far from there, and these qualities should exist. Let me break it down:

An optimized solution should have:

1. Ease of Entry and Access
2. Ease of Hosting and Sharing
3. Least Complications and Confusion with Setting Up to be on Fair Playing Field
4. Adequate Scope of Categories
5. Non-Excessive or Redundant Categories
6. Assurance of Fairness (Protection Against Cheating)
7. Reasonably Seamless for Easy Creation, Timing and Comparing As Well As Sharing of Runs
**8. Allow For the Greatest Number of People with GoldSource Interest to Come Together and Syngerize the Growth of the Community At Large.
**9. Clearly Opaque to Players and Viewers What Category/Rule set/DLL is being used

Qualities 1-3: Can be accomplished with a robust mod or package, with multiple (2-4) DLLs, presets, or templates if you well that can hosted legally just about anywhere. Furthermore, it’d make sense to have default client settings those that most commonly used, things like brightness, gamma, truebright, shouldn’t be cryptic hidden commands needed to play in well light maps that new players have to ask and find out about later on their own.

Qualities 4-5: 2-4 Categories or Rules Schemes, with there own subsets such as SS, RTA segmented, no jump, ect. Should satisfy this. (deciding these is another matter, and prehapes the most challenging)

**Quality 6: **Built-in or compliant set of rubust cheat cheating tools can Massively help with this as well as some other minor measures. For example, tool that checks the known facts of a demo, such as frames on ground intebween jumps, if more much than 50% of the jumps are frameless there’s reason to suggest more than a mwheel or shotgun jump script was used. How much Yawspeeds are changing, if they’re not changing much or at all or in some predictable pattern simple scripts were likely used. For runs of record time to approved, a webcam video of sort should be required to prove a mwheel was used if the runner claiming so, and not a shotgun jump script. More Details to hatch out here.

Quality 7: Things like built in in-game timer are very logical, pre-made system (whether it’s just scripts) for making segmented runs, auto-record, ect.

Quality 8: However the solution helps this will be a major plus, things like linking and showing members currently running and their steams, social media integration, common forum links, links to tutorials, ect.

Quality 9: This keeps things open and honest, without false or misleading representation, and prevents questioning and repeated need to explain and justify. Also Adds Creditably and Trust to The Community, making the scene more elegant and attractive to all.

Currently, there’s no solution available or in use that accomplishes any of these innate universal qualities.

3

So myself, treetoon, ovvy, Kess and WindedCone just finished having a several hour conversation on Mumble about a rather large and ambitious concept that could actually be beneficial for not only the HL community, but every part of the GoldSRC and Source communities. It takes inspiration from many other communities; KZ (Xtreme-Jumps), Defrag, Quake, even SDA at points. Something like this will most likely take a very long time and a large amount of effort from many people to put out, but it will be worthwhile for the future. I believe this is really what SpiderWaffle was aiming to achieve with his original thread in the first place but there has been some misunderstandings in the process.

Who and how this will be made a reality is another topic, for now thoughts and ideas need to be collected. Obviously not all of this may be possible for the time being if at all, but if we collect everything that is on demand here we can try to implement as much as possible and try to discover alternative solutions for the parts that aren’t viable.

I wrote some notes into a text file whilst we talked and I’ll try to elaborate on them as much as possible here as well as adding in some of my own ideas:

Game

A client/mod/something equivalent to JoeQuake that is easy to download and install. Much like JQ, ideally it would serve the entire community and be agreed on to be used as a standard for all runs, no matter what category/ruleset/whatever specifics.

[ul][li]Two presets - WON and Pre-SteamPipe (for realtime runs), labelled something like ‘Old Engine vs New Engine’ much like Half-Life 2 to keep things simple instead of having confusing names. How these presets will be laid out (commands/shortcuts/packages etc) needs to be discussed. WON (OE) preset’s FPS dependency (the effects) will not surpass 100, however you will be able to use more than 100fps simply for the visual aspect (basically catering to higher rate monitors which is forward thinking).

Pre-SteamPipe (NE) preset’s FPS Dependency will be able to reach 1000fps without needing good hardware. This would essentially be splitting the fps_max command into two parts, one for in-game exploits and one for the visual aspect. This means keeping the game’s fundamentals legitimate whilst dealing with non-advantageous annoyances. I’ve heard this is something very similar to what the Quake 3 community has with CPMA and Defrag.[/li][/ul]

[ul][li]Creating fair, optional alternatives to the mouse wheel - more of a preference-based feature so it is arguably not necessary, however there are a handful of players that would like it and would be more willing to follow a standard if it was implemented. Me and treetoon briefly played around with the ‘decentjump/shotgun jump script’ with 3-4 jump/wait loops and whilst the effect is similar to a mouse wheel, we cannot be sure how similar it is without proper testing and analysis.

Yes, there is obviously a stigma around the word ‘script’ generally in the more competitive categories such as SS and RTA, however think of it like this - if you implement alternatives that are on the same playing field as the mouse wheel (if there are suitable ones) as actual features of the game (accessible via the in-game menu without having to manually paste or write in configs), you will no longer need a separation between the scriptless and scripted categories and **all **advantageous scripts can therefore be banned completely from all competitive categories as a standard, leaving the automation and arbitrariness out and bringing the human element back in for everyone.[/li][/ul]

[ul][li]Implement useful scripts for demo recording and other purposes as features available through the menu or a console command.[/li][/ul]

[ul][li]In-game timer - This has been desired for a long time now, the fact is that loading times **do **matter in competitive GoldSource running and cutting them out manually via post-editing is not only tedious but inaccurate also, so being able to get the without loads time instantly would be very useful for competition. Could also include the ability to auto split via external timer like LiveSplit/WSplit, this has already been demonstrated via nd3644’s AutoSplit mod which is based off of YaLTeR’s Bunnymod Pro. Fatalis has also said he’s planning on making a GoldSrc equivalent to his SourceSplit component.[/li][/ul]

[ul][li]Auto-updater - Pretty self-explanatory, would allow features to be added in progressively and not making users download a new version all the time. An alternative could just be some sort of alert that occurs when an update is available.[/li][/ul]
Webpage

A central hub page for GoldSRC running, something similar to SDA’s Quake site. There is already a base for this in the form of the SR Wiki with many of the features already being in place, however this will need heavy reworking mainly in the design and layout/format. The centralized hub page will have sections for player profiles, demos, guides, rules, FAQs etc. This would be suitable for all games, not just HL. We will need to give well-respected, experienced, knowledgeable and reliable players their own roles in forms of editors, verifiers, general admins, reliable contacts etc. Perhaps two main sections could be made, one for Source, one for GoldSRC, then have hub pages for each game with their respective sections.

[ul][li]Roles - Have some sort of proper “hierarchy”, as in giving established/experienced/knowledgeable/willing members their own roles. GoldSRC is currently lacking on this compared to Source. We could discuss each role, have applications/submissions for them and allow people to discuss and say their vote etc. There could also be a limited amount of each role, so that inactive players could pass over their roles to more active ones instead of being labelled as something when they’re not doing their job, allowing them to step down etc.[/li][/ul]

[ul][li]Player profiles - Info/interview page, statistics, contest participations, runs contributed to/performed, etc.[/li][/ul]

[ul][li]Links to leaderboards (speedrun.com/hl1, speedrun.com/op4, speedrun.com/bshift, speedrun.com/decay, speedrun.com/gmc etc)[/li][/ul]

[ul][li][/li][/ul]
Demo tools
Alot of features are already available via HLAE, however we need something to check and analyse demos for cheating. The KZ community has their own tools for this and whilst they do work for one-map demos in HL, we need something that is able to provide more detail and do more as a whole. There isn’t really a concern for cheating at the moment but if the community becomes much larger with this project there surely will be.

[ul][li]Display inputs, FPS changes etc[/li][/ul]

[ul][li][/li][/ul]
Tutorials
A series of tutorials for each aspect of running, available via a single YouTube channel and capable of being embedded into appropriate webpage/s.
[ul][li]Basic & advanced movement - bhop, duckroll, ducktap, countjump, jumpbug, edgebug, w-strafe, crouch brake, +use brake, avoiding speedcap etc.[/li]
[li]Boosting - damage, object, weapon-exclusive etc[/li]
[li]Game commands/settings[/li]
[li]Scripting/TASing[/li]
[li][/li][/ul]
Want to get involved with on-the-fly discussion? Read here:

Details for Mumble and IRC rooms to discuss stuff (try to keep all agreed/good points noted and elaborate/discuss here):

Mumble Server:

Address - chumtoad.net
Port - 64739
Password - calhoun

IRC Channel:

irc2.speedrunslive.com:6667
#goldsrc

4

Borderless windowed Support please, similar to newer source games where you can just select a res and hit borderless windowed.

Something displaying that the user is using sv_cheats 1 in demos/in game like in the top left window a little box that says “Cheats on”

Same as the Cheat in top left idea, tell the category the player is running. Like Scripted/no Scripts SS/RTA Hard/Easy.

Add your own little game mode shits, like Crowbar only, no jump, Unlimited FPS and Uncapped Bhop ect. ect.

As for tutorials are we going to have a full game run tutorial along side it? or maybe section tutorials you could load up in the menu.

max fps mode or something along the lines of that. Strip the game of all the graphics possible so older computers can compete while streaming or something like that.

I kind of visioned something like this while ago, and some of these ideas are coming back to me.

5

Please note that the Half-Life engine is closed-source so any engine-related feature like separating the rendering FPS from the physics FPS would take a big amount of research and lots of time.

6

I know this is standard for most if not all other speedrunning communities, PC games or not, but in the context of GoldSrc/Source games I couldn’t reconcile this requirement with the objective of eliminating unfairness due to hardware differences. The 100fps cap is introduced so that people with outdated hardware can compete in SS/RTA, and yet loading times matter? Someone with an SSD and a top end CPU will consistently have shorter loading times compared to another guy with legacy hardware. The advantage of newer hardware is even more pronounced on Source games.

I suspect everyone just implicitly decided to factor the loading time in simply because this is the more convenient thing to do (when streaming, for example), and not because it is the “correct” way.

Do you then use ultrasound to locate yourself in-game, now that you can’t see anything without the graphics?

7

I think he meant that this is why an in-game timer is needed.

8

Tryedz has made a pretty good full-game tutorial that is only missing a few strats.

Yep, that’s exactly what I meant. I was saying that they matter in that they cost varied amounts of time depending on hardware, not that they matter in that they should be kept.

9

As a side note this means that you could run the game at say 1FPS but have it be butter smooth. So maybe this should only apply for 100+ FPS. Or alternatively some arbitrary value such as 30?

The fact that SW got banned for merely proposing ideas and arguments I find quite disgraceful.

10

Yes, your client will have to be running greater or equal to 100. Otherwise ticks will be skipped.

11

Do you then use ultrasound to locate yourself in-game, now that you can’t see anything without the graphics?
[/quote]

I seriously hope youre sarcastic

12

Strip the graphics? Older computers? You’d need a Pentium from the 90’s to not be able to play HL, if the textures were any lower quality you’d be looking at 8bit graphics or even solid color textures, and nobody would want to watch a stream with graphics like that. My $250 netbook with integrated graphics runs HL at 60fps easy, anything slower than that wouldn’t be worth owning.

13

A Eee PC is struggling with keeping up 10 fps, but uh, I don’t think anything would really help in this case.

14

Let us consider the following.

Category A: no-script ± replicating scripts without advantage
Category B: current scripted
Category TAS: host_framerate

Now we could scrap #B, this would however alienate the segmented runners. Most of which want to use autojump, OB, gauss and duckroll scripts etc. and of course bringing said into #A is out of the question.
The main point of this is that the line between TAS and #B is very thin and mostly relies on HFR. What you would most optimally want is to leave any type of automation to TAS and let #B only contain most common scripts, even trigger delaying.
To achieve this, we might need very specific rules that should not rely on arbitrary decisions like “this and that script is fine but not this”. If possible, ban and limit certain commands?

Currently the way it sits you could create a TAS with specific commands, then convert these into a regular HL script, run it without HFR, possibly create very short segments to minimize error by unstable FPS. And all of a sudden, technically you have a “scripted” HL run and not a TAS.

15

There’s multiple popular TF2/QL streams that have configs for extremely bottom line graphics? I don’t think graphics would change people mind about watching an old ass game being speedran.

Edit: 60fps is putting you at a disadvantage for running the game anyway :P.

16

The “lingering matter” of Scripts and TAS-Scripts

Here is an example of a TAS script Yalter created for agtricks in 14,578 seconds (100aa):
http://pastebin.com/WNKx6ZaT

There are roughly 100 lines of built in TAS commands + the wait table. It can later be converted into regular Half-Life commands, the result in this case is 17 000+ lines of commands:
https://mega.co.nz/#!ZYZFFJ5A!9N4ebVT9JuU7hcOFkU0bzDczaz5tGk9yK6UN-GYlvLU

To me it seems that the main problem is the inhuman movement seen in TAS’s. Here’s an example:

[sup];cl_yawspeed -1507.87346354;+moveleft;-moveright;wait[/sup]
[sup];cl_yawspeed 1518.85979114;-moveleft;+moveright;wait[/sup]
[sup];cl_yawspeed -1507.87346354;+moveleft;-moveright;wait[/sup]
[sup];cl_yawspeed 1518.85979114;-moveleft;+moveright;wait[/sup]
[sup];cl_yawspeed -1507.87346354;+moveleft;-moveright;wait[/sup]

Every line in this case (whenever there’s a wait) represents one frame, so at 1000FPS we’re talking about extreme strafe scripting. In order to preserve scripted runs, i.e not to make them completely pointless I am proposing some kind of solution/limitation.

I’ve looked at it for a while, my previous statement was that you could limit the amount of waits somehow. I could not find a proper ruling for this however, so I went on looking more into what makes a TAS a TAS; and for the most part it seems to me that it is the camera manipulation.

A great way of limiting this would be to set cl_yawspeed and cl_pitchspeed to zero, there are few cons here, the only being sequences that help by using +left/+right or +lookup/+lookdown. It would not affect the gauss script since it is dependent on abusing cl_pitchup/down rather.
Another solution is to ban +left/+right or set the yaw/pitchspeed cmd’s to only be changed once per second or similar.

I don’t think there is any magical solution but the no-script category did something of the same sort, i.e they banned the wait command. Sure, it’s associated with scripting but that does not mean it’s a script within itself.

If anyone has any thoughts or other/better suggestions I’d gladly hear them.

**Update: **
People usually ramble on about bhop scripts, but never in my life have I seen one. That is except autostrafe and autojumping in TAS’s.

Here is a shitty one made for 250fps just as an example:
[sup]
//bunnyhop script
alias +bhop “cl_yawspeed -1275;-forward;alias _special _bhop;_bhop”
alias _bhop “+jump;+right;-left;-moveleft;+moveright;wait;-jump;-right;+left;+moveleft;-moveright;wait;special”
alias -bhop “alias _special;-jump;-right;-left;-moveleft;-moveright”
bind “space” “+bhop”

[/sup]
Just hold forward, space and then steer, yawspeed could be changed with binds <:

17

One way I thought of distinguishing regular and TAS scripts, but didn’t post about for some reason, is that a regular script could be something which loops (like spamming jump) but a TAS script executes a single chain of actions. Of course that means that trigger delay is an issue, but I guess it is possible to have some sort of exception, or just not allow it, though that option seems like a shame because map overlaps are stupid and thus should be exploited.

There’s also treetoon’s suggestion of banning movement commands, but runs could still have other long-running scripts that just require mouse input.

On the other hand, it could be argued that we should move on from scripted runs and either do scriptless runs or TASes and nothing else, since using just some scripts but not all will always be arbitrary anyway, though I suppose there is some fun in trying to pull of tricks in real time that are too hard to do without scripts but still a challenge with scripts.

18

I just created a TAS in the map bhop (1k FPS uncapped bunny) with a time of 5,292; It sets +left then changes the yawspeed for steering left/right. I wanted to find out if the dubious claim that without such heavy yaw changes, auto strafing would be so bad that it could not perform well enough to plausibly beat manual strafes.
In contrast to previous charts the results were rather surprising, by using both +left/+right instead of relying on negative and positive yawspeed values to set more specific and better strafes I was still able to come up with a good time of 5,94 (maptime). I’m still not quite sure what the non-TAS WR is but ovvy made a 6.22 run at 500FPS which is the fastest SS I know. (https://www.youtube.com/watch?v=bCu7Tjslv3Q)

It is important to realize that the script is merely functional, and I’m sure with heavy calculations more time could be cut down, not to mention I manually steered on my laptop trackpad due to not going in a straight line which could normally be fixed.
I set the yawspeed at the start of the map and yet again at the first frame of the first jump. This concludes the notion that somehow limiting yaw/pitch-speed is a viable restriction; the point still remains to set it/them to zero; nada; zilch, however.

I’ve never suggested banning movement commands; I’m specifically talking about camera commands.

Whether people like it or not, regular scripted runs will continue being made. I’d rather put whatever is being done on paper to define the differences between the two. We’ve sort of moved passed arbitrary things at this point I feel like, no-script has banned wait despite not being a script and merely a command. TAS’s are using host_framerate, a fundamental change that technically doesn’t do anything but replicate hardware but it still wouldn’t be considered legit in SS (or a clean install of HL, if you prefer).

The point is, let us create the arbitrary rule to set it apart; the only “true” way of running HL is to script (converted TAS script) the shit out of it, no restrictions as long as fundamental vars are followed (HFR is a fundamental). This is how valve created their game, they implemented a usable scripting system as a feature and for a reason.
They may have overlooked it.

19

A category is only created for the purpose of allowing comparison of runs within that category, ie competition on fair playing field. Which a lot of people want to do and generally has a positive effect for w/e gaming community it is. So I think for any sort of category to have a functioning place each individual user required be creating, modifying, perfecting scripts isn’t the way to go. This starts to bring you closer to a TAS, and requires players to spend inordinate amounts of time preparing scripts for their runs, rather than playing, and really is just undermining the initial point of establishing arena for human competition. This also is a major deterent for participation. I know after working on scripts for SS runs in 2001 and helping Quad with them to prepare for his easy run, it was a ton of work and not very enjoyable, I know Quad spent a ton time piecing out more things, after he was finally done and wanted to run OP4 he just did a scriptless run, not wanting to go through this drudge again and I would feel the same way. Only having the choice to script none or an extreme amount to stay competitive and not limit/hurt yourself.

So the regulations clearly have to really limit what is going to be possible to create and we need ways to prevent/check for cheating. What can work is to have set of already common scripts and nothing else, such as shotgun bhop, _special bhop, double duck, shotgun duck, _special duck, gauss, use boost, ARN jump, and maybe a few others. Basically what you’d typically expect to see in competitive multiplayer. With this I don’t see any problem preventing any yaw, or pitch changes, all the scripts can be made and run the best without any of these and this sort of adjustment is exact thing that starts to take away the GOOD PARTS of what is skillful human play, accurate smooth mouse control, and you’re becoming closer to TAS.

I could also maybe see allowing some scripts with no waits, limited commands, such and as fire and change weapon next frame, something quake players have long since used, in addition to the set of premade scripts.

Also the premade scripts could have easily built in GUI options for adjusting, such as what the final pitch is after finishing the guass script, or number of waits in the useboost.

A lot of this is going to depend how much can done on front of preventing/detecting scripts used beyond what’s allowed. It’s not good to ban something that can EASYLY be cheated, obviously best to prevent that from being possible, but if something really is just going to be too easy to cheat and too hard to prove legginess, allowing it can be a lesser of the evils depending on the situation.

20

Agreed that having the freedom to script anything without restrictions/limitations does not work for a competitive format which is why I’ve always felt scripted should not be considered a competitive category (one reason why if we had a leaderboard for it, currently it would go under the ‘misc category’ section because of the lack of rules/standards).

This also personally puts me off running scripted categories altogether due to the fact that right now I cannot be sure how much scripting is ‘too much’ and also that writing out long scripts is not really my cup of tea right now either; this may be the case for others and so having pre-made scripts that are set out on a page could be an idea, however I see a flaw in that people could easily add extra minor ‘upgrades’ or automations to these without it really being noticeable visibly and so you would need some sort of demo tool that checks every single command being executed. Then there’s the problem of not recording demos anyway; alot of SS/RTA runners nowadays are just streaming and saving their runs as a ‘highlight’ (Video On Demand) and so checking for cheating is already difficult enough, even impossible in some areas. Judging from this it seems that having a collection of permitted scripts could cause some pretty major complications; we already have a hard enough time checking for cheating in scriptless (though right now it is not really a concern).

Another argument about permitting only certain scripts is that they’re automations of a specific technique anyway just like any other script, so some might say there’s no real reason to allow automations of something that is already easily possible and viable via manual control other than it ‘looking good’ (which I guess I can understand for segmented runs, but not so much SS/RTA). To my mind in order to allow certain scripts you need to find something based off of the game that allows them to naturally be placed into a specific ‘group’, which with my rather minor knowledge of more advanced scripting I cannot think of, otherwise it’s just a case of ‘well what scripts do we like/not like?’ and to me that’s not a very good decision making progress for rule building in speedruns. It’s essentially the same as saying ‘well we don’t like this glitch/exploit/trick so we’re going to ban everyone from using it’ which some other communities have done and I don’t agree with.

I do think that with segmented runs (where scripts are most commonly used and are also most suited for) the banning of altered yaw/pitch speed as explained to me by treetoon could be a good option for limiting automated mouse movement which seems to be the most obvious and clear line thinner between scripted and TAS. Let’s be honest though, scripted-segmented runs are already “TAS-level”.

Even if you only allow certain scripts, with the game’s nature of allowing and not indicating against the use of unlimited segments (i.e HL’s continuous level format as opposed to Quake’s ‘Individual Level’ format) you are still able to perform every exploit in the game and therefore the only distinction between a scripted-segmented run and a TAS is robotic movement (which is already partially roboticized with bhop/duckroll scripting anyway) . In other games they just stopped making segmented runs altogether and worked on TASes instead, however in Half-Life (and other GoldSource/Source games for that matter) there is a certain appeal to the scripted-segmented category that will probably always be more popular than TASing. Mainly because A. alot of people will probably still prefer to watch human movement and B. alot of people will prefer to play the game instead of essentially ‘programming’ it (as in scripting the entire thing in a TAS). This is the unique niche that SourceRuns has compared to the majority of other communities where segmenting is no longer popular.

So we already know that when it comes to making the most optimal route possible it comes down to personal preference of whether you want to play the game or script it when executing that route because when it comes down to basics, scripted-segmented vs TAS is really no different. I’m not sure that I or others would appreciate arbitrary limiting the amount of segments you can use either since as I mentioned it’s the nature of the game to be able to play through it with no separations between levels/sections and being able to pause, save and load wherever you want. I understand the motivation behind SDA’s segmenting penalty because all they were really trying to do was discourage players from over-segmenting, however adding on extra time that doesn’t exist seems like a poor solution to me and going by what people here have said before you would not be able to get them on-board with that rule either (it’s even been removed from SDA’s rules now).

Sums it up pretty well. I hate to say it but if you really want a fair, competitive format then removing the ability of scripting may just be the (albeit unfavourable) solution. I believe (though correct me if I’m wrong) this is SDA’s motivation behind their decision, they probably could just not find any good solution. If there’s one thing that would create a larger distinction between segmented and TAS that’s probably it, but even then the line is still thin with the ability to use unlimited segments however. As for SourceRuns’ community comparison, both Portal 1 and 2 communities already don’t use scripts in their segmented runs afaik (though admittedly their circumstances are alot simpler) and I’m seeing a large growth of scriptless runners in the HL scene nowadays (though it could just be due to SS/RTA generally being alot more popular than segmented runs now because of the up-rise of streaming).

At the end of the day though there are still quite a few people out there that I can think of that will refuse to make scriptless-segmented runs regardless of the rules/standards and whether that’s fine or not I can’t say. Perhaps some of them would change their minds if there was solid, set in stone rules that became popular like in KZ, Defrag, Quake etc but I suppose there’s always going to be those out there that disagree and will play by their own rules anyway.

Sometimes I wonder what it would have been like if this situation was in reverse, as in if we had already banned scripts, didn’t have the availability of exclusive/combined feature modifications etc, essentially a more ‘raw’ standard. Would people have been dissatisfied with the standards/rules? Would people be opposed to bringing in stuff to make the game easier/faster than it already is? Point being that maybe the fact that we’ve allowed so much freedom already means no turning back for some people; a sort of ‘irreversible’ overkill.