DFWC2014 general discussion

[nLxajA]

I think its better have one thread for all questions about DFWC than many theads for each question.
____________________________________________________
Anyone feeling generous is welcome to:

You can also view the list of donators to the link above.

[dqopb]

How about making an out-of-competition table for any demos that are worth attention but fail validation?

As an example, khetti's demo on dfwc04-4. A few people people said it is a TAS, but still a worth watching one.

Another example is Arcaon's dfwc2012-3 rejected demo. Technically it violated the rules, but watching it is mandatory for everyone.

Bot/script competitors (if any) can go to this table too.
I assume there will be a few strafe-only maps, as usually on dfwc's, so perhaps at least strafebot jumpers will show some stuff. If there are no competitors in scripts, I would be interested even in these strafebot demos.

[dqopb]

Since this is the general discussion thread,
and the rules page gives no description to the relatively unknown client dfengine108m, I'll put such a description here.

It is based on dfengine1.08, and it has:
-> snaphud embedded (same as there in iodfe, but the related cvars begin with scr_hud_snap_*)
-> fast startup time, same as there in iodfe
-> automatic map downloading from ws.q3df.org (doesn't go to the old address by default).

This is pretty much the change list. No more ioquake3 stuff here.
Source code is available as well.

source code

[sjuk]

rltnhtc0.jpg

DeFrag as a virtual universe (with concomitant maps' objects as teleporters, velocity pads, electroshaders) represents congruent planet of Solar system

ltovt80i.jpg

The cup's site banner at 2012 was stodgy (UT guised as ZERG prefers), and preliminary 2014 year's is feebly for now. Please don't count it as meticulous remarks-hunting, little changes will adduct to a much more pleasant presentable look. So, DeFrag's distinct style should be restrained

USB 3.0 cable 04.jpg

Site's current background bubbly image (by "twitter solutions") suits to Uran character by color gradient, but not by shape

fsyusquc.jpg

Pierce lines coming between C and 2 at banner and secant SignUp pieces are closer examples of what will fit. But again, not sairax'ed overweighted letters.

Thorium.jpg

[-av1spa-]

rltnhtc0.jpg

DeFrag as a virtual universe (with concomitant maps' objects as teleporters, velocity pads, electroshaders) represents congruent planet of Solar system

ltovt80i.jpg

The cup's site banner at 2012 was stodgy (UT guised as ZERG prefers), and preliminary 2014 year's is feebly for now. Please don't count it as meticulous remarks-hunting, little changes will adduct to a much more pleasant presentable look. So, DeFrag's distinct style should be restrained

USB 3.0 cable 04.jpg

Site's current background bubbly image (by "twitter solutions") suits to Uran character by color gradient, but not by shape

fsyusquc.jpg

Pierce lines coming between C and 2 at banner and secant SignUp pieces are closer examples of what will fit. But again, not sairax'ed overweighted letters.

Thorium.jpg

[sjuk]

Felicitous designers for enhancement:
gnj - for his traditional austere grey minimalism in levelshot patterns
Morbus - for virile monumentalism

vtsps78e.jpg

Сооружения ещё не здания но строения.jpg

[khetti]

I disagree strongly with both the letter and the spirit of many of the rules.

The "Random OB" section prohibits many totally consistent ob methods.
Don't ask for infinite examples, just consider the intent of such a rule: valuing skill over luck.

Hint: If you can describe how to consistently reproduce an OB it probably isn't random.
No matter if the description includes some numbers, DeFRaG provides for them.
If the result is a faster time than without, even if there are many steps, the advantage is earned.

Also, this

v. If a player gets a random OB that is hard or impossible to react to, for example while performing a groundboost, the demo will probably NOT be rejected. We highly suggest submitting multiple demos in any case.

is a contradiction.
You say you probably permit demos with accidental advantages.
Why would I send a slower demo alongside one that apparently doesn't break any rule?

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.

Are you going to change your imprecise definition at your convenience?
Are we supposed to continually check the rules throughout the competition in case someone told you about a trick that scares you?
Should we expect players to read the collective mind of the demo validators?
Should we teach the referees how to play the game?
If your response is "The vagueness of our rules is the problem of the player" you deserve whatever fiasco you get.

You might as well title the page "Random Rules for Random Reasons", add a disclaimer "Don't bother looking for interesting routes",
or even list tricks we are allowed to use

Btw, why require that everyone agree to the rules before signing up?
Maybe there are other far more hazardous oversights, but you'd probably reply "Too bad, I have ### people who implicitly agreed with me" if anyone cared enough to point them out.
After all, it is your substitute for justifying anything.

[TittenIgnition]

In a tournament as small as this, there's no point in trying to exploit "vague" terms in the rules. We all know and most of us agree on what would be crossing the line: wallbugs are bullshit, gbs/obs are not. Stop nitpicking about something that will almost definitely not come into play anyway. If you feel that the demo validators have flagged your demo wrongly, it's not like there will be thousands of demos: any dispute will be easy to solve.

Again: there's no need to pick out tiny discrepancies in the rules for a tournament in which less than 100 people will participate, and less than 50 will even be relevant.

[dqopb]

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

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

[gnj]

I disagree strongly with both the letter and the spirit of many of the rules.

The "Random OB" section prohibits many totally consistent ob methods.
Don't ask for infinite examples, just consider the intent of such a rule: valuing skill over luck.

I appreciate your input but can you be a little more specific?
We still have time to change the stuff BEFORE the competition starts.
(The ruleset will not change afterwards)
So if you can do better, your very welcome to help us fix any remaining issues.

If a player gets a random OB that is hard or impossible to react to, for example while performing a groundboost, the demo will probably NOT be rejected. We highly suggest submitting multiple demos in any case.

Gotta agree here, this rule is somewhat flawed.

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.

Are you going to change your imprecise definition at your convenience?
Are we supposed to continually check the rules throughout the competition in case someone told you about a trick that scares you?

No, this is absolutely not the intention. 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").