Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
12 ->
--
--
List results:
Search options:
Use \ before commas in usernames
Edit history:
moooh: 2013-07-09 06:33:52 pm
moooh: 2013-07-09 04:18:44 pm
moooh: 2013-07-09 04:16:19 pm
moooh: 2013-07-09 04:11:56 pm
INTJ
Original first post:
Quote from oasiz:
Frame rate, maybe have a simple flag for games that have major game breaking differences with a high FPS (Like where physics change completely, HL1/quake is still tame compared to some of the stuff you can get) See point *

Frame rate capping, mostly for older games where you can "uncap" the framerate and it will execute at a faster speed than it's supposed to be at. Mostly just applies to old IBM PC games that assumed a fixed MHz speed. For speed I'd allow "fastest possible" that still uses frame caps (C&C series, GTA1/2 etc..) Should be pretty obvious that the game must not run too fast.

What key binds are allowed -> as in, can you call console commands straight with a single key or just limited to what menu offers, allows stuff like "start vote to restart the game".

Can you bind two actions to the same key in series (not parallel). Some games like Duke3D allow you to do stuff like binding "W" to "move forwards" AND "use medkit", this is generally acceptable and does not require any console commands since the setup allows you to bind a single key to multiple actions (People always did this with deathmatch games) but would be cool to have a more clear ruling if this falls with scripts or not. Two categories for this too, the ones that require console commands to accomplish and the ones that simply fire multiple action straight away. NOT like typical scripts that do multiple actions after each other, more like gluing two keys/gamepad buttons together with a wooden stick (shitty analogy).

* Due to small differences with speed, re-releases, versions, etc.. I'd rely more on the verifiers actually knowing their game, if a ruling gets decided then why not add it to the KB? I'd say.. Just generic notes on what the game ended up using or if any issues got brought up and solved during verification should make things a lot easier for the next time and for potential new runners too.




Quote:
What key binds are allowed -> as in, can you call console commands straight with a single key or just limited to what menu offers, allows stuff like "start vote to restart the game".


Tacking onto that: What is the stance of SDA about using different keybinds from the standard in less sophisticated games, such as flash games, where you can not normally rebinds keys? A lot of people like using gamepads with Joy2Key or something similar to play those. Is that allowed? If yes, what about simply rebinding keys to a different layout in general (A lot of games use Arrow-Keys + ZXC, but I prefer for example Arrow-Keys + Num1-3)?
Thread title:  
Iha paska
I would limit that to what you can do ingame. Hooking a individual gamepad button to a single keyboard key should be allowed but anything that allows more than one action per button press (in cases where a menu does not let you do that) should be disallowed.
Turbo is out of the question as well.

Keyboard is so abstract to begin with, you could just make your own device in the end that is a keyboard with just the keys you'd need.
Quote from oasiz:
Turbo is out of the question as well.

A frictionless mousewheel is practically turbo and it really gives an advantage in a lot of games. So it is allowed if you can bind it in the ingame menu. But is it allowed if you
- use the console (like some Portal players do)
- use config files (like Mass Effect players do)
- use programs like the mouse driver
?
What about binding multiple keys to one action through these 3 means? If you have enough buttons, you practically have turbo again.
I asked this before, but got no definite answer. Maybe the roundtable can discuss it?
Edit history:
oasiz: 2013-07-09 06:52:44 am
oasiz: 2013-07-09 06:51:50 am
Iha paska
turbo with multiple keys? You can just do that with a mouse for example, just get a good button with a keyboard or mouse and slam it like it's 1799 !
And frictionless mousewheel, I've had mouses that have buttons instead of a wheel a few times already, laptops have free two finger scroll etc.. I think that is a thing you can't limit. There is no definite "right way" to do scrollwheel I'd say.

EDIT: Oh yeah, I have sprint bound to both mouse4 and shift already, if I get tired then I switch to the other one on the fly..
Wiiaboo
oasiz, the issue is that no conventional button mashing can really compare to freewheel mouse scrolling. You basically get an input for every frame. And, without any kind of scripting or rebinding outside of the game, the scroll wheel will only ever send two keys: Scroll Up, and Scroll Down (which are just events like any other keyboard or mouse button). The game may or may not have key rebinding as an option, and it may or may not support those events. The issue, then, is whether it should be allowed to rebind those outside of the game (like, with AutoHotkey) if the game itself doesn't normally let you use Scroll Up and Scroll Down.

Rebinding and scripts are generally a no-no. However, it's true that you can get mouses that let you rebind to other keys (even keyboard keys), with the mouse driver or even on the mouse itself. There's probably at least one out there with a freewheel.
Iha paska
But the issue is here that locking wheel is just one type, will the rule be that everyone MUST use a lockwheel mouse. Even when considering that my first "scrollwheel" mouse back in the 90s was actually with buttons instead of a locking wheel?

What about touchpads and their drivers ?
Two finger scroll is pretty damn free and some even have hacks in the drivers (default settings) to leave some scrolling momentum.

There are too many different rats out there to really limit this.

IMO, the difference is so small and most PC games don't even need turbo, even source runners who do ABH'ing with the scrollwheel have a locking mouse and it works just fine.

If someone really modifies his mouse to get free movement or just shorting pins then I would already consider that pretty lame and enough to note during verification.

IMO as long as it's unmodified and requires that the runner inputs it (not just letting it roll freely without interaction) it should be ok. And button mouses shouldn't automatically trigger the action when holding the button down.

I think that would actually be a good outline.. every action that the mouse outputs should come from the user input instead of leftover momentum on the wheel or holding a single button down to trigger actions automatically.
Edit history:
moooh: 2013-07-09 04:15:22 pm
Exoray
Apologies for the semi-mess. This was the best I could do without merging oasiz's entire post from the roundtable thread (which contained some other things related to that as well).
Edit history:
moooh: 2013-07-09 04:31:45 pm
Exoray
Alright so to answer some of the things brought up.
Frame rate: Sounds like you say, very much depends on the game and we'll have to look at it on a case by case basis.

Frame capping: It's been ruled in the past that if the game speed is actually affected by higher fps (some games run faster on 200 fps for example) then changing the fps above 100% speed is not allowed.

What keybinds are allowed: We generally say that you should only bind things through the menu and use the same limit as the menu offers. This ensures a fair playing field for each game. If a game allows you to bind two keys to the same action through the menu, then you are allowed to do this. If it does not, then you should not try to circumvent this by use of 3rd party programs or overriding it with config files.

Generally we say that you should only tweak the things that the in game menu offers. This is also to ensure a fair playing field since there would be so many combinations of different console commands that one could otherwise use that might be difficult to notice and thus make it impossible to compare a run with another. This also helps making the run verifyable.
There are a few exceptions to this that come by a game by game basis. Usually it entails allowing to change the FoV, change mouse acceleration or to change resolutions.

Scroll wheels: It's been brought up several times in the past and the ruling is that you are allowed to bind things to the scroll wheel, if you can do so from the in-game menu.
If people can properly handle a free scroll wheel, they should get the right to use it imo. Those things are damn hard to control plus from my experience they don't even work properly for most games.

What about the following case:

You can bind keys via the menu, and there's 2 button slots available for one action. (So you could bind Sprint to both Shift and Mouse Button 4 for example).

However, with the use of the ingame console (by presing ~) you can bind this action to a third key (or as many as you want). I recall having +use bound to at least 11 different keys back in the day (I didn't use any of those 11, but they made for good testing).

(I'm not gonna mention that using the console to bind stuff is not only easier, but also faster (Don't have to get lost in a friggin menu looking for the control settings, 6 clicks away, only to spend 30 seconds looking for the specific action you want to bind, when you can just push "~bind key action" in mere seconds.))

IMO this should just be allowed.

There's no real way of telling what buttons I press to begin with and any selfrespecting gamer should know how to use a simple ingame console for their game.
HELLO!
The problem is I remember back in the Quake days that you could bind whole macros to a single key in the console... and that's clearly not allowed.
.
That's scripting, and that has been banned for years now.
Well yeah, but what about just binding a single action to more than 2 keys?
Iha paska
Thanks for the clarifications, And I have to agree with S's points. Binding multiple keys for a single action should be allowed.

The game & community around it usually has a mutual understanding on what FPS is considered cheating and what is not. Some games break but verifiers should be able to point it to a different category at that point if the game totally breaks with FPS changes and makes an entertaining run while at it. KB could be the place to give pointers to new runners on agreed norms unless exceptions arise. Like compare running HL1 with 100fps instead of say.. 60fps. It changes the physics but it is a accepted norm with HL1 runners.

What about two actions with one key like the Duke3D example?  As in, binding W to both "forwards" and "use medkit" which is acceptable in deathmatch for example (and something that everyone should do). This is something that the setup.exe lets you do out of the box without additional. I know you kind of answered this with "What menu lets you do" but I'd love a clear lining on this Smiley
Most games don't let you do this normally so usually it's out of the question anyway..
Exoray
Like said, if the in-game controls menu allows for binding primary and secondary keys and allow binding them to the same key then that's perfectly fine do to so from that menu.
If the menu allows you to bind move forward and use medkit to the same key in Duke3D, then go right ahead!

The use of the console is simply disallowed because there's so many different things you can potentially do with the console that it becomes impossible to make general policies around it.

Quote:
(I'm not gonna mention that using the console to bind stuff is not only easier, but also faster (Don't have to get lost in a friggin menu looking for the control settings, 6 clicks away, only to spend 30 seconds looking for the specific action you want to bind, when you can just push "~bind key action" in mere seconds.))

Unless you re-configure all your keys something like once every 2 minutes I don't really see why this would be a relevant argument Smiley

No one is really going to hunt you down if you bind duck to both ctrl and c out of pure convenience. However if the game only allows one key-bind from the menu and a multiple bind like that would be able to affect the gameplay then it becomes far more quiestionable.
Just pasting this from a PM with moooh a while back. Could you add all the PC rules when they're done?

Quote:
We've come to the conclusion that altering FPS for a game is fine as long as it doesn't affect the game speed.
A segment or IL run should be recorded with the same FPS throughout the entire segment. Whether this is accomplished by tuning the FPS using a console command before starting the run or by starting up resource heavy programs to affect things is not something we are going to govern.

The minimum recommended FPS to record in is 30. Anything below 20 would quite likely be outright rejected due to too poor video quality.


Quote:
The use of the console is simply disallowed because there's so many different things you can potentially do with the console that it becomes impossible to make general policies around it.


Actually this is not what you have said before. You said console commands were looked at case-by-case depending on the game. When we used the console to bind the voting option in L4D it was fine.
Exoray
Obviously there are exceptions, like I mentioned in my first reply above. These exceptions are naturally on a case-by-case basis depending on the game. They are still exceptions, to the general rule of not using the console at all.

So what I said as a general policy is still true. And we're not inflexible enough that we can't make exceptions where exceptions are needed Smiley
Are these ruling open to discussion? Because you're invalidating several runs already on the site and they seem overly strict to me (ban of console/config binds, ban of on the fly fps change and ban of <20 fps).
Edit history:
moooh: 2013-07-10 08:42:04 am
moooh: 2013-07-10 08:41:51 am
Exoray
Low fps depends on the video quality. If the video quality is accepted I'm sure you can get away with occasional 15 fps. If the entire video is going to be a stuttering mess then you can probably expect it to not be Smiley
Oh and I should mention that some communities don't consider low fps glitches to be an acceptable thing at all. For instance the super meat boy running community disapproves of the wall clips that 2 fps runs could potentially pull off.

As with all the rules on SDA, they are always open to discussion and community input is a large factor. I've presented the current guidelines and the thoughts behind them. If anyone has other thoughts they want to argue for, feel free to continue doing so in this thread.

PC games are just one massive grey zone for the most part. Custom binds calling specific console commands could be considered similar to scripting, a thing massively debated in the past and disallowed on the site as a whole.
Okay, about console/config binds:
As I said some runs already use these and it would not be nice to invalidate them just for that considering that the verifiers seemed to have no issue with it.

about fps:
On a PC you rarely actually have a stable framerate, it usually just fluctuates around a value and then it can drop due to outside due to background activity. I know you don't mean to reject runs because the fps changes from 60 to 59 or because it changes from 60 to 13 for 2 seconds, but I wanted to mention it anyway.
Several Half-Life runs use on the fly changes. For example the healthdoor where it gets set to 1000 or NPC turns where it gets set very low (I don't know the exact number). These things have been discussed in the Half-Life threads before and nobody ever expected them to be banned.
What is occasional 15fps? If a trick requires low fps and takes 2s to perform and the fps drop only for that long is it allowed? What if it takes 5s, 10s, 10min? If Meat Boy runners have issues with this then low fps tricks can be another category or "major skips" or whatever.
As moooh said, I think the HL community already made their own rules before being involved with SDA and that these fps rules are accepted. You don't notice any difference when viewing anyway (since they are increasing fps, not decreasing) so I don't see any problem with it.

I would say that the minimum fps of a run should be 30 (unless the game runs slower naturally) and that all submitted videos that are CONSTANTLY below 30 (meaning not dipping below in just a few demanding sections) should just be rejected. This would also simplify the whole fps glitches question since you can't use that low fps anyway. Why I'm also saying this is because I recently watched the Crysis runs on here and it's a completely mess. Honestly it looks like a really cool run but when the fps drops down to 5 or so a lot of the time it's almost like you get sick watching it. There's also the Painkiller runs which are running at 25 fps but probably often below that, and they're a pain (yeah) to watch as well. I know Crysis was a demanding game at its time but if you don't have a strong enough PC to play and record at around 30 fps at the lowest graphical settings and in HQ res, then it's pointless to submit.
Quote from Freezard:
I know Crysis was a demanding game at its time but if you don't have a strong enough PC to play and record at around 30 fps at the lowest graphical settings and in HQ res, then it's pointless to submit.
Is that really fair to say, though? You can have a 25fps video that's still of acceptable quality. To outright say REJECT ALL THE RUNS instead of examining the acceptability on a case by case basis (like, plenty of indie platformers don't need 60 fps to look more than acceptable) is really unnecessary.
.
Generally we ask people to post a quality test in the tech support subforum if they're unsure whether the framerate meets our standards. I wouldn't worry about the specifics.
Iha paska
Onin, it was a case of 30fps instead of 60fps. Some games like GTA san andreas run at 25fps instead of the 30fps in GTA3 and VC
Personally I think that anything below 25-20fps is pretty awful to watch. Games are not movies where you compensate for choppy motion with excessive motion blur, either lower the graphics, buy more powerful hardware or just play it on a console.
So unless the game is forced to run at that rate, don't put it too low to unwatchable states.

HL runs are a bit different again since you can record demos with FPS changes BUT the engine will smooth them during demo playback.
Something I'd leave for the community / verifiers to decide, I'd still mention "Uses FPS bugs" or similar in the comments.
People have so many opinions on this depending on the game.
Gets the cake.
Back on the topic of freescroll wheels, they are really not as much of an advantage as everyone in the community thinks. If you get it spinning fast enough to be an "autospam", then it's doing an input every frame and the game will just see it as holding the key down. It's, imo, literally useless.
Yeah WHen I needed a new mouse I bought one with a freescroll wheel just so I could bhop easy.

I now use the wheel for everything BUT bhop.