DFWC2014 general discussion

[dqopb]

khetti, we see you have many things to fix in the rules. Maybe not in many words, but in quite meaningfull ideas.
You know the theory, you have the perfect juridical language.
Why not contribute to the rules directly? We spent several days working as a team and making that list of rules. Yet we are not sure that list is unexploitable, so we left the right to reject demos based on common sense etc. You dislike it, you say that's hole patching.
But as long as you don't provide your COMPLETE ruleset, your claims look like handwaving, don't get me wrong.
Feel free to create a google doc, maybe even based on the current one, and write down things (you have the knowledge and language, right?). Then we will join and examine your list with a fresh look. If your ruleset is better than the current one in all the aspects, I see no reason why we'd reject it.

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.

No, there have always been players who claimed their route was legit while others didn't agree. Even Arcaon had an OB originating from a slope jump on dfwc2012-3. Reproduceable? Yes. Legit? No, it was against the rules that had been published before. It is validators' work to decide on player's correct/wrong interpretation of the rules. And that's why we suggested contacting validators in arguable cases. You can suggest something better, but please let it be a complete list of rules.

[dqopb]

141025.oj.csu1_a.slope-ob.dm_68

Don't worry, slopes have been covered with SURF_NOOB anyway, so were surfaces to land from slopes too. That rule is there just in case, to make players not waste their time trying to exploit it. What you show is a special case of a stable slope ob. But slope obs aren't stable in the general case scenarios.

141025.oj.csu1_a.ceiling-ob.dm_68

Again, that is a special case. Ceiling obs are irregular in general cases. Sometimes you have to make a 390 RJ to hit the ceiling and get an ob. If you do a 360 RJ and hit the same ceiling, you don't get an ob in the same place. Or vice versa.

141025.oj.csu1_a.pad-ob.dm_68

I bet you skipped the word "randomly". If a jumppad gives a STABLE ob, the ob is not supposed to be random by definition. We all know dm6 jumppad obs, those are regular, stable. NOT random. If, on the other hand, you happen to fall onto jumppad / into velocity pad or any similar trigger FROM A SPECIFIC HEIGHT THAT GIVES YOU AN OB AFTER THAT TRIGGER, then THAT is supposed to be random. Like, if you fell from a slope or a low RJ into a jumppad trigger, and got an OB afterwards. That's not a stable OB like what you can get on any freestyle map.

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?

Why be so pessimistic? The current rules were designed FOR the players, including you, if you participate. And there's nothing told against finding tricks and routes! Mapper cannot anticipate all the routes on his map, as long as his map is not a simple box. And that's fine! You're right saying defrag is about finding routes and tricks. No worry, I assure you, there is plenty of space to find routes in these maps. Even though we deny random obs (shouldn't we deny them, after all?).

[Arcaon]

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.

Alright, I understand better what you mean now, and I do agree.

[dqopb]

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.

The thing is, if you don't give certain examples in the rules, but just give a very vague statement-to-cover-all-the-possible-cases instead, there will players come and ask "Is this legit?" or even send demos violating the rules, claiming the rules being unclear etc.

Like I said above, a huge map fixing work was done to prevent all the randomness described in the rules. Yet there is more than enough space for creativity. So I hope the random-related rules are even not required at all.

[oranje]

I bet you skipped the word "randomly".

I did, I thought that pretty much all OBs that aren't detectable with the chsinfo are banned. If that's not the case and the rules are merely stating that random OBs using jumppads/slopes are not allowed, then I have to agree with khetti on this:

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.

One can get random OBs from almost anything; slopes, jumppads, doors/buttons, bobbing/rotating/pendulum brushes, liquids. But there are situations where you can consistently get OBs from those things without fail; I know, I've mapped them.

Why be so pessimistic? The current rules were designed FOR the players, including you, if you participate. And there's nothing told against finding tricks and routes! Mapper cannot anticipate all the routes on his map, as long as his map is not a simple box. And that's fine! You're right saying defrag is about finding routes and tricks. No worry, I assure you, there is plenty of space to find routes in these maps. Even though we deny random obs (shouldn't we deny them, after all?).

I completely agree about banning random OBs. Finding new tricks and routes is the thing I enjoy most about defrag, but grinding them for hours on end is not. Landing random OBs involves EVEN MORE grinding, and luck instead of skill.

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.

Yeah, it's been this way since I can remember.

Kind of depressing...

[gnj]

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.

[...]

Is that clear enough?

YES! finally.. Thank you!

See, I understood what you were saying from the very start. My point was: Why would we with our limited knowledge try to phrase something (which would probably lead to new mistakes, which then again would have to be fixed etc etc. -> waste of time), when you have much more expertise on this field and are also a native english speaker?

Your proposal looks very good to me, we will try to find any loopholes. If not, this will probably go into the ruleset as is (replacing our previous rules).

Thanks again, i dont know why this had to be such a struggle... =/

[Arcaon]

I agree that the rule should be as general and all-encompassing as possible. I also believe that the rule should be made as clear, nonabstract and tangible as possible. I propose using the sentence khetti suggested, but with one example that covers the vast majority of random overbounces just for clarity.

Overbounces which cannot be reproduced consistently are forbidden (random OBs). OBs resulting from unpredictable or inaccurate processes, or that require manually unachievable preconditions, must not be used. A common example of this is any OB created through sudden and unpredictable contact with a sloped surface.

The benefits of the addition:
- This makes it extra clear what the previous sentences mean in practice (especially to non-native speakers). If it's not intuitively obvious what this rule means mid-run, we've failed in our communication.
- This clearly and explicitly rules out the vast majority of overbounces.
- The inclusion of "unpredictable" means that there's no possible way the overbounce could be reasonably considered legit anyway.

Opinions? i know i'm ryte ayy lmao

[pol]

That sentence is more complex and clearly tells what can we use.
Actually we dont really know if OBs listed in ruleset are forbidden, or only in case if they "resulting from unpredictable or inaccurate processes" just like headline says (in other words).
In previous editions OB restrictions wasnt clear and made ppl(people) confused, so would be nice to avoid it this year.
In my opinion it should be also included in ruleset.

[Arcaon]

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

Absolving oneself of all immunity in case of a competition-destroying loophole sounds like a... less-than-optimal idea. Every competition has a clause like this. Perhaps it should somehow be clarified that such decisions will be done after thorough deliberation, with the possibility for a player to appeal a decision, and that demo validators won't reject new gameplay techniques nilly-willy (which should be obvious if you dare give them some credence).

The "Map Exploits" section, too.

The wallbug rule stays. It has been made clear previously that there's a majority consensus opposed to its usage, even outside of competitions. And leaving the preventive responsibility completely to the map testing phase just opens up the possibility of exploits. If a better phrasing of the rule is provided, it will be rephrased at best.

It's best if the killbug rule is kept. It's statistically unlikely that there will be a map where killing yourself will be advantageous, but we don't want a ridiculous situation where killing yourself at the right time lets you spawn with haste and plasma (I'm looking at you, pht-slickrun2).

The timer reset rule can go. I'm pretty sure that the map testers have made sure that "wait -1" has been added to every target_startTimer anyway.

[TittenIgnition]

This thread is a great source of endless frustration >:(

I just don't like that these rules really need to be stated in general, though of course I agree that they're needed. Everyone knows what is and isn't acceptable, and the fact that so many people are arguing about the phrasing, all the while wholly agreeing with the mindset behind those rules just plain sucks.

IMO the rule should just state, "fuck random OBs", and that's that. Then we can all be friends again

...nilly-willy....

heh