Allow flags in reasons.yml
Opened this issue ยท 6 comments
I've tried using -p flags in the reasons.yml file, but those will only get output as text.
Is there a way to implement this feature or does it interfere with others?
Would be really useful for making warnings a lot easier and less to type for staff:
reason : Some reason -p 2
griefing: Random text -p 10
/tempwarn <player> <timeDiff> #reason
just outputs a warning with "Some reason -p 2" right now instead of "Some reason" and adding 2 points instead of 1.
EDIT: I figure allowing <timeDiff>
in the reasons.yml isn't possible, since the plugin checks for the correct syntax before it inserts the text defined in reasons.yml?
@EvilOlaf the CLI parsing is based on an external library. I didn't implement it myself, and I don't really want to either. This is Minecraft, not unix so I think it's acceptable to have this as a known caveat.
@xILukasIx Perhaps, that would be a good idea to prevent unexpected behaviour if this feature were to suddenly land. However, we're adding extra complexity for users. It would be better heading forwards if #
simply parsed flags as well. I'll need to think about how to implement it however, as it will require some refactoring.
So the issue here is that the flags are interpreted before pre-defined reasons. Your use case makes sense and I'd like to add this as an option, but it's not going to be a simple fix.
To explain, command arguments are first parsed for flags to allow them to be at any point within the command (in the middle of a reason, after the player argument and so on). After which, they're removed from the arguments and the command handler carries on as normal.
E.g. /warn -p 2 <player> <reason>
in this case, the first argument will be -p
and the second 2
, where as the command handler is expecting the first argument to be the player.
So it's the same problem as in the "EDIT" part of my post? Makes sense.
Maybe this would require a separate argument like ~reason, where it will check the ~reason for flags too before it carries on with the command?
E.g instead of using /warn confuser #reason -p 2
you'd use /warn confuser ~reason
where the flag is in the ~reason.
Hm a few Linux commands also work without space between parameter and argument, like -p3
.
So in this case the command as it is now would not detect 3
as argument. Though -pX
needs to be detected seperately, split into two variables and checked for numerical.
Just some stuff what was going in my mind currently...
One more thing I'd like to add, which it'll have to handle:
When you combine multiple #reasons and some of those have flags in them, it should add the values of the -p flags of course.
@confuser of course. I just wrote what was going though my mind while reading the issue report ;-)