-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core/Commands [Implement kickdelay command] #14250
Conversation
Should I ignore that codefactor issue ? https://www.codefactor.io/repository/github/azerothcore/azerothcore-wotlk/pull/14250 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from that I still don't see the point of delayed commands, here are some things to improve.
Yes, you can ignore CodeFactor
Thanks fo the PR.
Removed min_time and max_time, in my opinion this is uselles to pick random time, just delay it with one value. |
@frytik can you update the the how to test portion. I may know someone who may be interested in testing this out. |
So I have just to remove notification from player, and we are good to go? |
In terms of features, that's my only request. I'll leave the actual code to the other devs. |
Changed. |
|
||
LoginDatabase.CommitTransaction(trans); | ||
|
||
if (sWorld->getBoolConfig(CONFIG_SHOW_BAN_IN_WORLD)) | ||
if (sWorld->getBoolConfig(CONFIG_SHOW_BAN_IN_WORLD) && !delay) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are excluding delayed banns? Add another config for it instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we shouldn't show ban reason in chat for delayed ban, because kick is comming after certain time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still say add a config for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need config for that ? You have to skip this message if you are doing bandelay, cause this message is handled in bandelay function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you keep this option with config, banned player will see reason in chat before kick out of game.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, keep the config default off. Perhaps someone would like the message to show, and therefore should have the option for it
kickReasonStr = std::string{ *reason }; | ||
} | ||
|
||
targetPlayer->KickPlayer(kickReasonStr, Seconds(Acore::StringTo<int32>(delay_time).value_or(0))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not the best when it comes to CommandHandler, but cant we pass the delay_time argument directly as Chrono by just needing the user to specify ms/s/d when using the command, to avoid the 3 way conversion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly I don't know. Every other command parsing it same way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok just checking
Core/Commands [Requested changes]
Reworked whole announce system for kick/ban, now everything is in separate function, so should be better readable |
Ill give this a test run the next 48hrs when i got a opening in my schedule |
Save you some time :D Video2.mp4 |
Thanks for the video! |
.bandelay account $acc_name $bantime $reason $delay_time That number five at end of command means delay time |
applying run-build label to see if workflow passes. failure not related to pr. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with 2 char and work fine for the two commands. Thanks |
One question and a comment if I may, just went over the PR list and read it out of curiosity.
|
PR Abandoned. If you want to continue work on this address the comment above. Open a new PR or reopen this |
Changes Proposed:
Issues Addressed:
Tests Performed:
How to Test the Changes:
Example commands:
.kickdelay test Cheating 10 <- 10 means seconds
.bandelay ip 147.232.22.53 1d Cheating 10
.bandelay account test 1d Cheating 10
Known Issues and TODO List:
How to Test AzerothCore PRs
When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].
You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:
http://www.azerothcore.org/wiki/How-to-test-a-PR
REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).
For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.