Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=2549
http://svn.eathena.ws/bugs/changeset/13403/QUOTE("SketchyPhoenix")
Removed charcommand code while allowing atcommand code to support its functionality.
Charcommands still retain their '#' symbol but now looks for a character name as the first parameter instead of last.
Atcommand configs now support charcommand level configurations by comma seperation (e.g. 60,99)
As a result of this, all atcommands that don't affect multiple users already (@kickall, @doom, @mapexit) are capable of remote usage.
Problems I see in that change...
- change of file structure - forces people to re-do all their configs just like that
- backwards compatibility - I see you added code to handle the original file format.
CODE
- if( sscanf(line, "%1023[^:]:%1023s", w1, w2) != 2 )
+ if( (sscanf(line, "%1023[^:]:%1023[^,],%1023s", w1, w2, w3)) != 3
+ && ( sscanf(line, "%1023[^:]:%1023s", w1, w2) != 2 && strcmpi(w1, "import") != 0 ) )
...
+ p->level2 = atoi(w3);
+ p->level2 = cap_value(p->level2, 0, 100);
But there's a problem, you don't erase 'w3' when the old format is read. Thus the value becomes 0 (in case of initial junk), or the previously read value. Normally you'd erase w3, or use some if-else scheme. Anyways, with the old format the p->level2 value should be assigned the same value as p->level, yes? - @adjcmdlvl is unable to distinguish between the two level values and the user must have enough permissions to set both at once; this may prove restrictive if anyone beside administrators wants to use this command (not sure if such a thing is a good idea, though)
- in is_atcommand(), you recycled the atcmd_output[] and atcmd_temp[] buffers for temporary variable storage; use proper local variables instead.
- you messed up the indentation in atcommand_commands() (at the end of atcommand.c)
- atcommand_commands() might be returning messy output now, basically the same thing twice; maybe some delimiting lines to separate atcommands and charcommands in the output might help.
- you did not add a config setting to set the '#' charcommand symbol; also, read the documentation at the beginning of atcommand_athena.conf and see if anything's wrong with it.
- you introduced a new parameter, 'charname[24]' to the command processing, used only for logging purposes; I'd re-think the usefulness of this solution.
- now that the same code supports both at(@)-commands and char(#)-commands, should its name be left as 'at'(@)? 'gmcommand' is the original name I believe (but maybe changing the naming convention might upset a lot of people)
This post has been edited by theultramage: Dec 18 2008, 04:12 AM