| 00:59.17 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 01:22.03 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:22.03 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 01:22.03 | *** mode/#bzflag [+v infobot] by ChanServ |
| 02:30.04 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 03:58.28 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 04:12.41 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 04:12.42 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 07:03.29 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 15:42.07 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-updkjpuqcxgvftno) |
| 17:58.24 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 17:58.24 | *** mode/#bzflag [+v spldart] by ChanServ |
| 19:07.04 | *** join/#bzflag joevano_ (~joevano@bzflag/developer/JoeVano) |
| 19:07.04 | *** mode/#bzflag [+v joevano_] by ChanServ |
| 21:13.38 | macsforme | it appears that the API cannot override a player's mute to send a message on their behalf (even by temporarily granting the TALK permission and revoking it after sending the message) |
| 21:14.09 | macsforme | it looks like the bz_sendTextMessage() functions just add the message to a vector called pendingChatMessages, and that gets processed sometime later |
| 21:15.37 | macsforme | what should the expected behavior be? should a message sent by the API bypass the mute and filter checks entirely, or should there be a special argument to disregard the checks, or something else? |
| 21:15.59 | blast007 | don't take away their talk permission. have the plugin make their messages go away. |
| 21:17.32 | allejo | ^ this. take over the message in the raw message event |
| 21:18.25 | macsforme | I think the assumption is that they didn't have the talk permission to begin with... since that could be the result of standard group permissions or set by another plugin (e.g., IPmute), I don't know how else to make it interoperable |
| 21:19.46 | macsforme | how would I identify the players that need to be muted, other than checking for the TALK permission? |
| 21:21.04 | blast007 | custom permission? |
| 21:21.16 | allejo | check if theyâre in a specified group? |
| 21:22.18 | macsforme | a group check won't help if another plugin (like IPmute) muted them, right? |
| 21:23.02 | macsforme | I guess a custom permission could work |
| 21:23.14 | blast007 | custom perm is easier since there's a function for that |
| 21:23.30 | blast007 | group check you'd have to fetch a player record and search through the groups list |
| 21:24.18 | blast007 | (plus, you may still need to have at least one permission associated with a group for it to either be a valid group file or for the group to actually be checked at the list) |
| 21:25.01 | blast007 | and IPMute would have to be modified to add that custom permission instead of taking away the talk permission |
| 21:26.53 | macsforme | wouldn't it be easier to modify the API to allow bypassing message filtering/ talk permission checks? |
| 21:27.30 | blast007 | no |
| 21:28.04 | blast007 | one line change to IPMute |
| 21:32.45 | macsforme | but then you have to re-implement the talk permission functionality from bzfs in your plugin, and you will require changes to the group permissions files of your users |
| 21:33.22 | blast007 | one line change to group file too |
| 21:33.34 | blast007 | heck, one *word* change to the group file |
| 21:33.38 | macsforme | TALK affects several things... chat, showing the motto, not sure what else |
| 21:33.49 | blast007 | hmm, true |
| 21:34.15 | blast007 | but it's for the league - doesn't the leagueOverseer already replace their motto with their team? |
| 21:34.39 | allejo | API canât forcefully set the motto with the talk perm either |
| 21:34.52 | allejo | without * |
| 21:35.09 | blast007 | but it also wouldn't let them change it, right? because of the overseer? |
| 21:35.41 | allejo | correct, the plugin sets or clears all mottos |
| 21:35.53 | blast007 | so that's a moot point there |
| 21:35.57 | allejo | but it canât set the motto if the player doesnât have TALK |
| 21:36.35 | blast007 | right, but we're talking about letting them retain the TALK permission and instead discarding messages in the new plugin |
| 21:36.41 | macsforme | so have players on LU.MUTE been going without a motto all this time? |
| 21:36.51 | allejo | yup |
| 21:36.57 | macsforme | ew |
| 21:37.33 | allejo | havenât gotten around to coming up with a workaround for that |
| 21:37.51 | blast007 | I've got one: just ban them instead ;) |
| 21:38.03 | allejo | you could grant TALK, send the message, and revoke TALK right after |
| 21:38.22 | macsforme | that doesn't work, as I stated above |
| 21:38.41 | macsforme | the message is queued for later, and by that time you've already revoked the perm |
| 21:39.16 | allejo | oh oops, I missed that |
| 21:39.34 | allejo | what if TALK is granted/revoked in the raw message event? |
| 21:40.09 | blast007 | you're making it more complicated than it needs to be |
| 21:40.21 | blast007 | just let them keep the talk permission |
| 21:42.13 | blast007 | register and handle the bz_eRawChatMessageEvent |
| 21:42.48 | blast007 | if they have the custom permission that is assigned to the mute group (and if it doesn't start with a /, perhaps), set the message to an empty string |
| 21:43.01 | blast007 | and if the message* |
| 21:43.29 | blast007 | bam, done - then all you need to do is handle the slash commands |
| 22:17.45 | macsforme | it looks like revoking TALK while processing the bz_eRawChatMessageEvent still revokes it too early... I guess I could revoke it during the next tick, but I don't want any other messages to get through during that window |
| 22:36.33 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 23:23.09 | *** join/#bzflag brad (~brad@stupid.h-o-s-t.name) |
| 23:23.09 | *** join/#bzflag brad (~brad@unaffiliated/brad) |