DFWC2014 general discussion

[dqopb]

Also, khetti, I can agree with most of what you expressed above.
But competitions are a special case where we can't allow too much randomness. Especially on dfwc.

What for random obs, many places were covered with SURF_NOOB anyway. I mean places where there were no intended OB by the mapper. So the ob-related rules are mostly for safety.

Same with the sticky ob on gazboosts - it should not happen thanks to SURF_NOOB. But in case if someone gets some advantage in a place where there was no SURF_NOOB added,,, that should be considered the mapper's flaw, not the player's fault. I still hope/expect it won't happen after thorough testing that took place.

[khetti]

In a tournament as small as this, there's no point in trying to exploit "vague" terms in the rules.

Finding loopholes is required of serious competitors.
No reasonable person can trust their adversary to infer common limits to the meaning of these unclear terms.

Thanks TittenIgniton. I wish all the players were as conscious as you.

It is not an ethics violation to choose the most advantageous of many possible definitions, at least in arbitrary competition.

I appreciate your input but can you be a little more specific?

Specific how? There are obs which are consistent that the rules disallow. How many or how severe should not concern you.
Listing them all is unfeasible, and arguing which example is or isn't random is the exact type of thinking I want you to avoid.
Begin by learning what Random means, not by writing down every simplest-case OB you can think of and categorizing them without considering what emerges from their combination with other actions.

You of all people should know how complex and explotable this game is and how challenging it is to create a perfect ruleset. This is merely a safety net in case someone comes up with something BLATANTLY unfair which wasnt covered in the rules (hence the phrasing "common sense of fair play").

The game is built around unintuitive exploits, everything else is a patience test.
None are "unfair," unless you define fair play as "only whats obvious after years of brainless repetition."
If you want a safety net against cleverness and rigor, talk to your mappers.
You can exclude a technique through geometry easier than by convincing everyone that the undefinable-except-by-authoritah-after-the-fact "common sense of fair play" prohibits it.
A players task is to find the best route and execute it, not to anticipate the motions of a blind god.

[gnj]

Specific how? There are obs which are consistent that the rules disallow. How many or how severe should not concern you.

Specific like: give us an example. Pick a rule (or the whole random OB section for that matter) and tell us how it SHOULD have been phrased.

We are not interested in theory lessons at this point in time, we want to get stuff fixed.

Begin by learning what Random means...

But maybe you dont really wanna contribute, but just tell us how stupid we all are?

[khetti]

I gave you a negative definition:

If you can describe how to consistently reproduce an OB it probably isn't random.

It covers every case, I think.
You're free to point out exceptions.

We are not interested in theory lessons

You can't act responsibly without a theory, but ok, I'm not your tutor.

But maybe you dont really wanna contribute, but just tell us how stupid we all are?

An invitation to read a base definition before building on it isn't an insult.
Breaking the conversation to look for occasions to be offended isn't productive.
I've contributed some criticisms, you can address them or point out where I've been unclear.

[Arcaon]

I gave you a negative definition:

If you can describe how to consistently reproduce an OB it probably isn't random.

It covers every case, I think.
You're free to point out exceptions.

Give an example of a consistently reproducable OB that breaks the current ruleset, and I promise you the current ruleset will be changed. Aloha!

[gnj]

We are not interested in theory lessons

You can't act responsibly without a theory, but ok, I'm not your tutor.

Why do you quote me like that? I said we dont need theory lessons AT THIS POINT IN TIME (since the schedule is tight and theres other stuff to do).

And that it would be better if you stepped in directly (while a specific example/phrasing that we can just put inside the damn ruleset - since you seemed to have the solution already), instead of going back and forth and wasting time.

Whatever, this doesnt lead to anything and im really not in the mood of continuing this argument.

Maybe hk, dqopb, arca will proceed with you on the issue.

[oranje]

I'll play along

i. It is not allowed to utilize OBs, that were created by using a weapon in places where the OB detector doesn't show a possible weapon OB. When an overbounce is created by weapon usage, the player has to reach the maximum height possible with one contact shot from the used weapon. This rule does not apply to sticky OBs.

There are other ways of getting OBs that are not random, such as:

ii. It is not allowed to utilize OBs on slopes, or OBs created by jumping from a slope onto a level surface (the slope being the origin of the jump).

Not random.

141025.oj.csu1_a.slope-ob.dm_68

iii. It is not allowed to utilize OBs that occur hitting ceilings of any shape (straight, slanted, curve).

Not random.

141025.oj.csu1_a.ceiling-ob.dm_68

iv. It is not allowed to utilize OBs that may randomly appear after triggering jumppads and jumppad-like triggers

Not random.

141025.oj.csu1_a.pad-ob.dm_68

I understand that the rules are up to the people who are hosting the competition and they can enforce as many restrictions as they please, but these are not random OBs.

Keep in mind: Demo validators have the right to reject demos with engine/physics/map exploits not listed in these rules, if they violate the common sense of fair play. It is the responsibility of the validators to judge that. If you find a trick / bug / map exploit that you are unsure about, it is highly recommended to contact one of our validators or admins to confirm its usage.

This basically says that if you don't play the map the way the mapper intended it to be played, your rec doesn't count. Isn't the whole point of defrag to find new routes and tricks? Might as well have strafe pads or a 2x rocket room as a dfwc map.

Since when did the df community become so afraid of its own tricks?

[TittenIgnition]

This basically says that if you don't play the map the way the mapper intended it to be played, your rec doesn't count. Isn't the whole point of defrag to find new routes and tricks? Might as well have strafe pads or a 2x rocket room as a dfwc map.

Since when did the df community become so afraid of its own tricks?

You people who combat these rules so heavily do so only because you read and interpret literally everything that is said, but don't see the reason they're there: we want every run to be reproducible, and purely about skill. A good example of a random OB that's unfair is w3sp's run on chronos_cpmrun3. It's a pretty big OB off of a ramp-jump, and this type of thing cannot be controlled by a human. That's what we want to avoid, which is why these physic-related rules really ought to be more like guidelines. Strict guidelines, but not rules that cannot be broken or else ban. These things should be up to the demo validators: if there's an OB that goes against these rules, but it can be easily reproduced, it should be allowed. If it's completely random (CPM ramp-jumping into an angled - or even flat - ceiling and getting a huge OB off of it is random), it should be disallowed.

In summation: stop nitpicking, the demo validators will hopefully not be so picky as to disqualify legitimate runs, but also should not allow completely random occurrences such as random OBs.

Nobody wants to lessen the amount of work, practice, dedication, thinking, pathfinding, ..., that goes into getting a perfect run, but we do want to eliminate that run which relies on a random OB in order to get a good time.

Not sure if I can make it more clear than that... There's no doubt in my mind that those who wrote the rules were thinking exactly what I am.

[TittenIgnition]

141025.oj.csu1_a.slope-ob.dm_68

This ought not be against the rules, but I don't see many places where this would actually gain any time, except at the beginning of a run. If an OB like this, if executed partway through a run were able to skip a large section of the map and actually save time, then it was simply a mistake by the mapper (no mapper is going to make their maps such that they adhere specifically to these rules, and any exploit that they see is disregarded because it would be "breaking the rules"). That type of OB should not be disallowed IMO.

141025.oj.csu1_a.ceiling-ob.dm_68

This is not random, and should not be disallowed. I'm totally fine with this exact type, but what if it were an RJ off of a ramp, mid-strafe? There's no way to control exactly what follows, and if the OB would ever happen again. Flat-ground, flat-ceiling, totally fine IMO.

141025.oj.csu1_a.pad-ob.dm_68

This also isn't random and should be allowed. I dunno why it wouldn't be - maybe because there are some maps that can be completely circumvented (30-second run turning into 1-second run) by bouncing multiple times on a jump-pad? One situation in which it would be "random" would be if the trigger were activated from the side, but it's so marginal and precise... it would never happen, will probably not matter, and launcher-OBs ought to be allowed. After all, of all the OBs argued here, this is the easiest to reproduce, and the most consistent. Unless the trigger is angled and activated not from a standing position (think q3ctf4 style 1?)... it would have the same issues as the standing slope OB.

[khetti]

Give an example of a consistently reproducable OB that breaks the current ruleset, and I promise you the current ruleset will be changed. Aloha!

The entire point of not giving examples is to point out that creating allowances or disallowances for every possible trick and variation isn't feasible and would inevitably result in omissions of both kinds.
I can't believe I have to restate this.

Why do you quote me like that? I said we dont need theory lessons AT THIS POINT IN TIME (since the schedule is tight and theres other stuff to do).

When should you learn, if not before acting?
You'd prefer to learn how to referee a competition as you go?
What an insult to the participants and other contributors.

Like the website said, I can't sign up until I agree with the rules.
I'm sorry if you're busy, but the dialogue could only take place after I'd seen them.

And that it would be better if you stepped in directly (while a specific example/phrasing that we can just put inside the damn ruleset - since you seemed to have the solution already), instead of going back and forth and wasting time.

Simpler is better:

Overbounces which cannot be reproduced consistently are forbidden. OBs resulting from unpredictable or inaccurate processes, or requiring manually unachievable preconditions, must not be used.

Do not create a fragmented patchwork of contradictory subrules.

Regarding the "tricks we haven't thought of but might or might not reject based on our personal tolerance to ownage" section, delete it.
The "Map Exploits" section, too.

Is that clear enough?

Since when did the df community become so afraid of its own tricks?

It's always been this way. Every single new trick is protested to death, all the way back to bunnyhopping.
Thanks for trying to help, but you also appear to have missed my point about examples. Providing them will only result in more convoluted rules.

You people who combat these rules so heavily do so only because you read and interpret literally everything that is said, but don't see the reason they're there: we want every run to be reproducible, and purely about skill.

Interpreting what is said is a fault, instead we're expected to dowse incoherence for the writers unexpressed meaning.
This is your honest opinion?
You're referred to my previous statement where I told you that literal parsing of rules is required of serious competitors.
A player who ignores loopholes will be beaten by one who finds utility in ambiguity.

A good example of a random OB that's unfair is w3sp's run on chronos_cpmrun3.

Cool, you know one when you see one. That was never the problem.

These things should be up to the demo validators: if there's an OB that goes against these rules, but it can be easily reproduced, it should be allowed.

No, the rules should be absolutely precise in their language.
A records validity should be determinable before it's submitted.
A runs validity should be determinable before it's completed.
A routes validity should be determinable before it's attempted.
Do you see the problem if they are not?

stop nitpicking

I'd rather the organizers stop putting nits everywhere, and you stop providing a nit breeding ground.
You'd not only expect that loopholes not be used to gain an advantage, you ask not to hear about them at all.
Just feel the intent of the rules. Join hands and meditate on fairness, everyone!

the demo validators will hopefully not be so picky as to disqualify legitimate runs, but also should not allow completely random occurrences such as random OBs.

Kill 'em all and let God sort them out?