|
|
|
Member 1435 posts
Registered: Jan 2006
There's a new f_ruleset check format implemented in development (2.0 alpha) branch of ezQuake. Here's the preview: What you can see is three players on the server already supporting it. Some points: - replies are padded with spaces so that they start in the same column - better readibility - both players are using smackdown ruleset (pretty obvious) - both players passed the f_modified check as denoted by "m" flag in the "-" group - player "JohnNy_cz" is using movement scripts - "s" in the "+" group - both players are not using enemy skin forcing - "f" in the "-" group - both players are using ezQuake 2.0 alpha client - no need for f_version (unless you want to perform CRC check) - there are also f_server replies of both players included - player "JohnNy_cz" doesn't have any additional features enabled as all the flags are in the "-" group What else is there to take in count: - there is now no way to check if a player is using independet physics - this was part of the f_ruleset reply before, but I think time has shown it it not necessary anymore - packet delay is not reported anymore! - it used to be there but again time has shown it's not necessary; of course other restrictions on this feature still remain If you have some spare time, please test this stuff. If the community wants, this can be back-ported to 1.9 branch and can be contained in 1.9.3 version. But I'm rather against it as there hasn't been any proper testing of this. (Not like it's a big or complicated change, but still.) If you have any opinion on how to improve this even more, write them right here! Thanks.
Member 386 posts
Registered: Apr 2006
The f_checks were rarely done, and done properly even less. This looks like a great idea for making the whole process easier.
Moderator 1329 posts
Registered: Apr 2006
If you have any opinion on how to improve this even more, write them right here!Thanks. What if you take a screenshot that doesn't make everyone puke bE
Member 312 posts
Registered: Feb 2006
If you have any opinion on how to improve this even more, write them right here!Thanks. What if you take a screenshot that doesn't make everyone puke bE 5) Before you post please ask yourself "am I contributing something worthwhile to this thread?". If the answer is no, please do not post. And as for the new f_ruleset, very nice indeed! I'd like to see it implemented to an official release as soon as possible. But if the developers are worried of its liability, there is no need to carelessly add things that might be exploitable
Member 130 posts
Registered: Jan 2006
From my point of view I want the following things: 1) Same accepted rules on client settings for all tournaments (EQL, QWDL, etc.) I think this one is true already. 2) ONE setting that enforces those rules 3) Enforced rules by default, so if you want to use features not allowed by the rules you need to manually enable them It's not the end of the world if this is not true, but it is certainly weird and leads to people cheating without even knowing they are doing it. 4) Test that gives yes/no answer to whether player follows the rules I don't want 10 different values of things he uses or doesn't use. I want to know whether he follows the accepted rules or not. 5) Automatic test and a warning at game start "Warning: Player X has enabled non-tournament settings" Well, have to come up with better term than "non-tournament settings"
Member 1435 posts
Registered: Jan 2006
Mipa: There is a difference between thrashtalk towards anyone random and making a joke at someone you know and talk to every day. Take that in count and consider better what your write on this forum. This is the last time I am bothering to explain basics of polite behavior on this forum.
Member 271 posts
Registered: Feb 2006
if you're concerned about people never doing f_ruleset checks, the best thing to do is to allow the user to violate it _until_ checked. There is no dishonesty in doing so, and the only time the players are not on an equal footing are the times when they know that they are not. Imho, allowing ruleset violations when not checked is more honest than allowing them unless someone checks.
packing everything into a single query is a good thing, imho. Perhaps a misnomer though.
So long as it doesn't exceed 38 characters (320/8 - 2). An IP can be 21 chars, excluding whitespace. A player name can be 15(16-1 according to the scoreboard at least).
Imho, keep f_ruleset <= 38 chars, and add a new 'f_check' of <= 76 chars which contains everything as in your screenshot. But put IP first (padded to 21 chars), as this keeps alignment if people use 320*200 still (sw).
Member 485 posts
Registered: Feb 2006
It's not obvious which color means on/off and passed/not passed.
Administrator 2058 posts
Registered: Jan 2006
Agree with Kalma. Red/green?
Member 1435 posts
Registered: Jan 2006
packing everything into a single query is a good thing add a new 'f_check' So keep one or make two? What'd be in first and what'd be in the second one? What's the point of one being <= 38 and second not being <= 38?
Member 173 posts
Registered: Jun 2008
2) ONE setting that enforces those rules 3) Enforced rules by default, so if you want to use features not allowed by the rules you need to manually enable them 4) Test that gives yes/no answer to whether player follows the rules 5) Automatic test and a warning at game start That would be very cool. ATM, players need to do various things at different times - it would be great if it was all done by default. Maybe this is something that could be scripted tho (rather than JohnNy having to do even more work ;-)).
News Writer 169 posts
Registered: Dec 2007
I talked some to spike in #fte today so while it may not be enough of an answer to johnnys questions, perhaps its worth some atleast: 21:51:17 Spoike: my compaints about their layout 1: f_ruleset isn't really the right name, f_checks is more apropriate. their line is longer than will fit at 320 conwidth 21:55:47 Spoike: tbh, I wonder exactly why there's no crc in there...
Also, modf rjsc skif doesn't make a lot of sense
Member 271 posts
Registered: Feb 2006
regarding modf rjsc skif etc, imho readability isn't too important so long as people can see at a glance if others are playing by different rules. and seeing it at a glance means it needs to fit most common resolutions.
'name: ' + (15-strlen(name))*' ' + serverip + (21-strlen(serverip))*' ' + ' ' + clientandversion + (16-strlen(clientandversion))*' ' + ' ' + rulesetfor21chars
if the ruleset is built of individual rule flags, in the same order, consistent between clients, each one of a single letter, showing up only when things are blocked. eg: s: 'smackdown' rules u: using Unmodified models/sounds r: Rocketjump scripts blocked m: Movement scripts prohibited etc. so a fresh install of quake would give ' u ', while a client with everything locked down for tournaments would give the full 'surm'
why the layout given above? name+server gives a break at the right place at 320, giving name+server on the top line, and client+rules on the second, with server+rules aligned in one column and name+clientver in the other, alternating server/rules. while at 640 you have name+server+clientver+rules, giving two aligned columns that can be scanned quickly.
why flags instead of abbreviated rule names? its about as readable! its faster to scan, as its more compact. it provides future extension without creating even more response lines. f_ruleset can be used for a more verbose description of the rules anyway. (or a spammy 'rules' command could print u = unmodified, etc) presence/nonpresence is easier to scan with a glance, assuming they mostly match (which they mostly will in any tournament). presence/nonpresence means there is no need for client-specific colour markup (even {white stuff} is client specific).
issues: ipv6 addresses can be much longer than 21 chars. It is strange to name a discontinued tournament within the rules of all current tournaments. I would be much happier if 'smackdown' were broken into its constituent parts, at least for the print Alignment depends upon fixed-width fonts.
This is my opinion, but if your original version is the one that makes release in ezquake, FTE will follow suit. At some point. Its still better than the original.
Member 1435 posts
Registered: Jan 2006
Aligning IP is nice idea, aligning ruleset name too (21 chars is too much though, I'd go for 9, smackdown being the longest). I'm against colors too, white is not that harmfull.
What I'm against though is breaking up smackdown ruleset into particular features - that's against attempts to unify stuff, as you can find out in the manual, there are way too many features that are blocked in there. Smackdown is rather a trademark for "official competition" where "somebody cares". It's a leftover, yeah, but people are just used to it.
Also I find attempts to try to align the line specifically for 320 and 640 a little weird, for instance I have conwidth 400...
Well I have other comments for details too, I think it'd be better to discuss it in private. I do want to unify this thing across clients, I'm glad FTE is interested too.
Member 174 posts
Registered: Nov 2006
Personally I am just hoping that Ezquake and FTE would get out new versions (stable) which could be used in tournaments asap, ofc with the new f_ruleset. Since it's so much easier to just do that one f_ruleset instead of 10 I am quite sure people will start to check it too, hopefully force people to fix their configs/settings too. If not I guess it would require admins of the current leagues to put on some pressure and maybe come up with new rules about this But when these stables are out I guess we will start quite fast to disallow some old clients and moving on to only using the newest ones. Gotta say, if I understood right what Spirit said about the colors: SD:Greenboxhere RJ:Redbox -> should be changed MD:Greenbox etcetc.. Those sd/rj/md on the same line with just colors would be really easy and fast to read thrue just before a game starts.
Member 1435 posts
Registered: Jan 2006
Updated my first post with the current state of the reply. From the commit log: new format better wraps on small console resolutions, additional features are denoted by flags, explanation is available via /f_ruleset; performing the check via /f_ruleset check; format of the reply was discussed with and proposed by Spike from FTEQW, both clients should soon reply with the same format Colors is a no-no.
|
|
|
|