Oh wait yeah don’t worry I’m being dumb, we should categorize by version because of the large difference. WON/Easy/RTA, Steam/Easy/RTA and then WON/Hard/RTA for the people who don’t wanna switch.
Seems good to me. So what about Individual Chapters? Same thing here or would that clutter too much?
For ICs I guess we can start out with WON/Easy and Steam/Easy and if anybody gets any ideas we can implement them later?
By the way, should we add the ability for people to submit times with milliseconds? You can get frame perfect starts and stops in HL, OF and GMC so it would be accurate.
EDIT: I’ve implemented the current changes 
I don’t see why it should be called Easy/Hard. I think the current WON Hard should be called Legacy or WON Hard SS. For full game runs, Easy is obviously the fastest category but not for ICs. But I don’t think ICs will be popular enough so it needs seperate categories for difficulties. So give the runner the option to participate with whatever difficulty he wants and we could in the leaderboards display what difficulty the run was played on, like current “SS” and “NO SS” (both in ICs and full game runs).
Yes, milliseconds should be added, and for the map configs maybe add bxt_timer_reset and bxt_timer_start to make sure everything is exactly the same for everybody. I added this myself in the configs when I did runs.
“WON Hard SS” would be misleading since we removed the “no RTA tricks” rule globally.
Remember, the reason we didn’t merge difficulties is because there are many people still wanting to run on Hard, and if we allowed people to submit Easy runs on top of that they’d just get annoyed because of their runs being beaten in a “cheap” manner. We basically left the Hard category in place for legacy reasons.
For ICs though, I guess I could support the idea of adding a difficulty label instead of categories. We could also do this for OF, BS and GMC full-game due to the lack of Hard runs in those already.
I always thought that the point of the WON Hard category was to attempt for single segment runs as you and others thought that what I was doing was lame because it wasn’t considered as attempted SS runs (you’re right about that as all I ever did was practice runs). A run with RTA exclusive tricks are NOT SS attempts.
The rule itself, no RTA tricks, wasn’t lame. What was lame was that there were no category where you tried to complete the game as fast as possible within reasonable means. Now we have that, WON Easy, but nobody will run it because it will only be the top players who would be interested in doing that as it is only benefitial for them. This thinking is what made me want to have multi-skill allowed.
I’d like to see a category for WON multi-skill, Nyu says he is interested in running multi-skill and I’ll certainly be interested in running multi-skill when I get back to HL.
Edit: "and if we allowed people to submit Easy runs on top of that they’d just get annoyed because of their runs being beaten in a “cheap” manner. I don’t see how it would be in a “cheap manner”. I’m talking about having a “Half-Life any%” (no Easy/Hard). The WON Hard should be exactly like it has been but it should not allow any non SS runs at all but it should be renamed so it’s apparent that the category goes by different ruleset.
If it is true that RTA is faster in WON, then there is no point in doing SS runs unless you have some sort of conservative belief that RTA is bad for whatever reason, or if you want some sort of miscellaneous challenge. If RTA is faster, it’s not going to be much faster at all. For example, Cubeface used a RTA strat a long time ago and was able to beat kukkye’s SS run with it by 3 seconds. A category that’s 3 seconds slower than another category doesn’t need to exist.
I think the “no RTA tricks” rule is lame, the same way that most of the community do. Why? The first reason being what I mentioned above, the second reason being that it’s hard to even enforce when you have people accidentally doing RTA tricks like ammo duping without realising and then submitting their runs which is hard to spot even for a moderator. The third reason is that it fails to adapt to modern speedrunning standards, which is that every single sitting run is RTA by default unless there are no RTA-exclusive tricks (even then people just run RTA anyway because what’s the point in being elitist and saying “you can’t submit a run unless you don’t ever die”?). As I already mentioned, it was a rule invented on a whim because of controversy; the situation wasn’t thought out or dealt with properly at all.
Why would it only benefit top players? With RTA being 100% allowed, you can just quicksave before the rotor jump/slave boost and keep retrying it until you get it; even top players would likely be doing this every now and then. Besides, just because a category is hard, doesn’t mean you need to create a cop out category for beginners who can’t be bothered to play it properly, especially when there’s yet again barely any difference. As people have pointed out before, if there’s really a high demand for a multi-skill category then so be it, but I fail to see why there would be for the reasons I’ve said, not to mention the high “no” vote in the poll that was made.
“I always thought that the point of the WON Hard category was to attempt for single segment runs as you and others thought that what I was doing was lame because it wasn’t considered as attempted SS runs (you’re right about that as all I ever did was practice runs).”
I guess I’m wrong then about this. Well then, it’s good as it is currently after the changes, I suppose. I actually found a consistent way to do the vortiguant boost on Skill 1. I found a reference to which I time my jump, what I look at is the vortiguants hand during it’s attack animation. I might stream a run during the weekend with the shittiest stream quality and 80-100 fps and go for WR WON Easy Kappa. Laptop webcam? woop.
Ok, so what’s left to discuss about categories? ICs merged difficulties, seperate versions?
Where can we discuss allowed/disallowed commands etc? We need a list with all stuff that needs to be looked at as I have said before. I’ll plan to get such a list going but if someone can do that before me that would be cool.
In my opinion we should agree on a whitelist of commands/variables based on which ones we can justify, then say everything else is banned. If we miss anything out, we can just say somewhere something like “if you feel there’s something missing that you believe to be justifiable, please consult with the community etc etc”. Here’s some I can think of that I’d imagine would be on such list:
- default_fov - Doesn’t do any harm before the run, but perhaps should not be allowed mid-run? If not allowed mid-run, how would that be enforced?
- clockwindow - This should automatically be set to 0 in WON runs as it didn’t exist back then, but what about in Steam runs? Would hate this to not be allowed but can’t think of justification for it?
- cl_showfps - Doesn’t give any advantage as far as I’m aware?
- net_graph - Doesn’t give any advantage as far as I’m aware?
- +graph - Same as above
- fps_max - Very complicated, probably justifiable due to what I mentioned earlier about Blue Shift?
- r_drawviewmodel - Doesn’t give any advantage as far as I’m aware?
Currently allowed but up for discussion/should be banned(?):
- alias - Only use I found for this so far was toggling the flashlight by holding the key instead of pressing it, not advantageous as far as I know? Any other possible uses?
- wait - Can’t think of any justification for this, shouldn’t be allowed in my opinion
- weapon_ - Not sure what to say about this, it’s only bindable via menu in OF and GMC as far as I know. I’d hate to see this not be allowed but I can’t think of a justification as to why it should be other than avoiding confusion between games?
- cl_pitchdown - Can’t think of any justification for this, shouldn’t be allowed in my opinion * cl_pitchup - Can’t think of any justification for this, shouldn’t be allowed in my opinion * cl_pitchspeed - Can’t think of any justification for this, shouldn’t be allowed in my opinion * developer - Does this have any advantageous effects?
- r_drawentities - Maybe easier to hit enemies because hitboxes are visible? Dunno, but if not allowed how would that be enforced?
- s_show - Has been used for audio cues without having to listen to them, can’t think of any justification for allowing it, but if not allowed how would that be enforced?
There’s quite a few that wouldn’t be feasible to ban without forcing everyone to stream or have some sort of software that detects them via demos (is this even possible?), so maybe they should be allowed for that reason? Not sure.
I’m for all of them except cl_pitchdown and also unsure on alias and clockwindow as I don’t know how they affect.
The way I see it is that these commands don’t really alter the game as opposed to sv_ commands and all those.
I don’t consider “wait” as a command that alters the game and should be allowed in my opinion. It seems a bit sketchy but I think it’s right to have it allowed, and I like it.
default_fov mid run changing: It’s a bit sketchy but I think it should be allowed.
r_drawentities: Should be allowed as it doesn’t really give an advantage and it lets people reach higher fps (only other use I know is to help finding the medstation after getting captured).
Should r_refresh be allowed? Should “Play”, to play soundfiles be allowed?
fps_max should be an exception as it makes the run so much more interesting. The only way fps_max could stop being allowed in the default category would be if there was a new category implemented that didn’t allow it and it became the most popular.
So I’m for all commands that don’t change the game’s fundamental properties, if that makes sense. So no things making Gordon move faster, making him “notarget”-able, ie no modifications.
As far as I know, without scripting, alias just lets you toggle stuff by holding a key instead of pressing it.
clockwindow 0 removes the default “freeze” that occurs after every loading transition. This would of course affect your time. < Don’t need to worry about this anymore
I think r_norefresh should be allowed since all this is useful for is increasing your FPS (such as at IHD), so the more people that can get closer to 1000FPS the better I guess because it becomes more fair?
Does playing sound files show up in demos?
Makes sense, though even if ‘wait’ doesn’t make him move faster, it does directly affect the time. Tryedz said his current run is beatable without it and I spoke to Nico recently and she said her GMC run is likely beatable without it also. If we consider building a whitelist, I don’t really understand why it should be allowed.
So can we get a confirmation of general consensus on the console-exclusive commands/variables? Most people I’ve spoken to agree on disallowing everything by default and then adding necessary exceptions as we go along, so I guess I’m just asking if I should go ahead and implement it or not.
Main reasons I’m bringing it up again is because A. we had another discussion about it in the Skype group and B. as I mentioned in previous post, Tryedz said his HL run is beatable without ‘wait’, Nico said her GMC run is also, but these won’t be if we wait too long. Then there’s the GMC segmented run that’s coming close to a section where it would be useful, so I kinda feel like we need to make up our minds pretty quickly in order not to disrupt things.
EDIT: By the way, referring to previous post, quad pointed out that clockwindow doesn’t have any effect in latest Steam, so that’s something to cross off the list.
We need more people to participated in the thread.
The wait command does affect the time but it does so in a reasonable way imo. It only delays. It seems weird to me to disallow it (and the Skill command) when fps_max is allowed. Allow these and that would be it (there are no other reasonable commands of the same type, right?). But we’ve discussed this already :>.
If you mean to start over from the beginning and discuss if things like fps_max, and everything else, should be allowed (this would take lots of time)? Don’t you mean to have everything that is currently allowed (or stuff already used in verified runs) kept allowed and we should conclude whether each particular command should be kept being allowed?
We just need to get seperate discussions/votes about each mentioned command going and it would be a good idea to start with the Wait command.
fps_max has way too many complications for it not to be allowed in my view, so I think it’s a justifiable exception.
What I mean is that most people I spoke to seem to agree with the principle of “only use what is bindable through the menu with the exception of anything that is considered necessary/reasonable (such as fps_max)”. If this is actually the consensus, then I don’t see any excuse to arbitrarily allow wait, skill changing, rebinding binds, yawspeed changing etc.
Alright, makes sense. Not that I like it, but I agree. So, everyone should pretty much keep doing what they’re doing but forget about the wait command.
The only allowed console exclusive commands would be cl_showfps and fps_max.
Edit: So no speedometer
Speedometer is BXT stuff which is a whole different story (where you for example have to use console commands to start the timer).
The thing about the speedometer is that it gives an advantage and it is a console command (and also an external assistance/modification). If the thing PJC mentioned comes into affect then it would be stupid to make an exception for it. The goal, I think is to have as few exceptions as possible.
Timer start/stop doesn’t give an advantage so I don’t see your point. However, the timer itself gives an advantage so bxt_hud_timer 0, but that wouldn’t really be in our interests.
I forgot to mention weapon_ commands in my previous post but yeah, they shouldn’t be allowed. They don’t change the run enough for it to be worth making an exception for. I’m going after a category that is “right” without being too boring. Although, if we go through with any of the changes we’re talking about then it would already be too boring for me, but that’s just me.
We need to remember that we’re going after what most of us would find the most fun to run. But to know what most of us want, more people need to express their thoughts. And since this is not very likely then we have to either act by ourselves (we that do participate). I don’t like the idea of having people who don’t care or are too lazy impact (through votes/polls) the decisions being made.
So an idea I have is to make a category where no console exclusive commands are allowed except for fps_max and cl_showfps 1 and another category where all commands are allowed execpt for those that would obviously be considered cheating (notarget, sv_ commands and other serverside modification). This is a long-term solution. Inevitably we’ll see which category will end up being the most popular.
The categories can have small changes, like allowing weapon_ commands if there is interest but with bigger changes it should be considered to just make a new category.
Eh, this is kinda stupid as I’m probably the one who gets affected the most by these imminent/potential changes so coming up with solutions that would suit my interests is probably pretty pointless. Maybe we can add my idea of a category anyways and see if anyone will ever run it? ¯(ツ)/¯
I feel like we should do this for portal too. but thats just because i really want sv_autojump.
I agree about the speedometer; we could still say this kind of stuff is not allowed in principle and then proceed to try and find a way to enforce it I guess.
To be honest I don’t really have any good arguments for allowing weapon_ commands. My natural “the community’s reaction to this is going to be really bad” paranoia kicks in on this specifically though :-\
Elgu pointed out to me the other day that you could argue cl_showfps 1 is beneficial if you have a bunch of FPS binds and you find it hard to keep track of what your FPS is set to mid-run. Unless there’s a good counter-argument to that, I’m thinking that one shouldn’t be an exception.
Category-wise, as usual if there’s enough demand for a category like you suggested then I guess it should be set up, but personally I find it hard to justify considering how little of a difference it would likely make. What would the differences be even? One triggerdelay saving only a couple of seconds at most, scriptless 180 gaussboosts with yawspeed, possible but not confirmed small change in health/armor management?
What about default_fov? Does it actually provide any benefit if you only set it pre-run? Mid-run you could use it as a zoom feature so that probably shouldn’t be allowed, but considering the varying FOVs between runners based on preference I don’t see why it shouldn’t be allowed pre-run.
My thinking with cl_showfps 1 and default_fov (pre-run) is that it’s not too unusual seeing as lots of people who don’t speedrun use these commands (same with weapon binds though). I don’t think cl_showfps 1 would provide an advantage over someone not using it as you normally rely on your muscle memory to press the right button. As of now, the different fps_max values vary quite a bit and it’s quite noticeable when you run on the fps you didn’t intend to. And any default_fov should be allowed imo, as I have never seen at it like it’s providing an advantage, just personal preference.
The time difference might not be very big but the feel of the run changes a lot. This category would encourage people to experiment with what is acessible within the game client in order to gain whatever little advantage there is to get. The thing with the Wait command is that it’s not very explored and I think there is new stuff to find with it (new changelevel delay skips, NPC manipulation). I feel that this kind of ruleset is relevant for every goldsrc game.