| 00:17.25 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 00:24.57 | Zehra | In the 'flag transferred' event, we are able to control what occurs, however there is one minor factor and that is other plug-ins using it to modify the event. |
| 00:27.48 | Zehra | Is there an easy way to know the 'final' state of the transfer event? |
| 00:30.05 | allejo | unlikely |
| 00:40.08 | blast007 | doesn't appear to be a notification event about the final outcome |
| 00:41.06 | blast007 | perhaps loading that plugin last would allow it to observe the final state |
| 00:41.40 | blast007 | or, you could share information between multiple plugins |
| 00:42.03 | blast007 | there's the various 'clip' functions for inter-plugin communication |
| 00:42.24 | allejo | modification events should really have a finalized state |
| 00:42.48 | blast007 | yeah, if we were doing the API over again, we'd have one event for modifying, and one for notifying |
| 00:43.29 | blast007 | we have that for some stuff, but it's not consistent |
| 00:44.18 | allejo | yea |
| 00:44.46 | allejo | possibly a weight/priority value for Register()? |
| 00:47.27 | blast007 | That still requires that plugins coordinate, essentially. |
| 00:48.01 | allejo | yea |
| 00:48.22 | allejo | what exactly are you doing or concerned about, zehra? |
| 00:48.31 | blast007 | a plugin author might also think that their plugin is more important and just put a big number, so then someone else has to use a *bigger* number for *their* plugin, and so on |
| 00:48.52 | blast007 | pretty soon, we'd be over 9000 |
| 00:49.05 | allejo | hehe |
| 00:50.46 | Zehra | allejo: Mostly flag tracking within the plug-in, drop and grab are easy, thief throws in a possible wildcard... |
| 00:52.01 | Zehra | I can easily keep tracks of the flags perfectly, but the implementations would unfortunately not be efficient. |
| 00:52.56 | Zehra | Or as I should say, less efficient than it could be. |
| 00:53.09 | allejo | why are you tracking flags? |
| 00:53.30 | blast007 | allejo: because the advertises demand data! |
| 00:53.44 | Zehra | XD |
| 00:53.47 | blast007 | advertisers* bleh, ruined the joke |
| 00:53.58 | allejo | lol |
| 00:55.53 | Zehra | Point manipulation is being done based on the flags... |
| 00:55.57 | blast007 | you could kinda fake it though, I think. Wouldn't be *100%* accurate, but close enough for a silly tank game. the flag grab and drop events both have the flagID, so you could see if the player with thief ends up with the same flagID as the one who was shot with thief, with the addition of a flag type check (since the transfer event doesn't have the flagID) or a flag lookup at transfer time. |
| 00:56.51 | blast007 | (and a time check, perhaps basing it on the time it takes for a flag to drop down after being dropped or spawning in) |
| 00:57.13 | blast007 | or, if it's a server you run, just add a notification event :) |
| 00:59.14 | Zehra | blast007: Thanks for the suggestion, the code will be both simple and efficient now. :) |
| 01:00.20 | allejo | are the drop and grab events called on transfer? |
| 01:00.29 | blast007 | allejo: no idea! |
| 01:00.45 | Zehra | The thief event would be.... since the thief drops... will have to check for that... |
| 01:00.49 | blast007 | so, yeah.. that'd need some testing |
| 01:01.32 | Zehra | Oops. Not thief event, drop event, when the thief flag drops on steal. :facepalm: |
| 01:05.50 | allejo | I see a zapFlag() call when a steal is canceled but i don't see it in the continue steal. is it triggered in your testing, zehra? |
| 01:07.26 | blast007 | zapFlag would be taking the thief away? |
| 01:08.21 | allejo | ohhh yea that's probably what's going on |
| 01:09.00 | Zehra | I haven't checked for that, nor completely written the plug-in yet and the thief event has not been added to the plug-in yet. |
| 01:12.51 | blast007 | might want to start with the thief issue since that affects the feasibility of the plugin |
| 01:16.51 | Zehra | Will be checking into it closely. Hopefully I'll be able to solve the potential bugs on my end. |
| 02:35.28 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 02:44.42 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo pushed 1 commit (06https://git.io/fjf6Z): |
| 02:44.43 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 149729e4: Split up Admin related slash commands to collection (06https://git.io/fjf6n) |
| 04:07.31 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo pushed 4 commits (06https://git.io/fjf67): |
| 04:07.32 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 147d4a88: Split up Server Owner related slash commands (06https://git.io/fjf65) |
| 04:07.33 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 14688554: Change FrontMatter 'title' to 'command' for /cmds (06https://git.io/fjf6d) |
| 04:07.34 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 14920edb: Add PageViews to display slash commands (06https://git.io/fjf6F) |
| 04:07.35 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 14a646a2: Update URLs in docs landing page (06https://git.io/fjf6b) |
| 04:14.52 | allejo | heeeeeeeee. i like how our search index is built off all our collections, so any new collection will be auto-included in our search index |
| 04:15.12 | allejo | like I just made that slash command collection and it's in the search index without me doing anything |
| 05:26.31 | *** join/#bzflag DTRemenak (~DTRemenak@2605:e000:141f:c002:3d1a:9fe6:ef88:9e58) |
| 05:26.31 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 05:26.31 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 06:30.05 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo pushed 1 commit (06https://git.io/fjfih): |
| 06:30.06 | BZNotify | 02feature/redesign/slash_commands @ bzflag.org: 03allejo 148423bd: Don't let content in sidebar layout overflow parent (06https://git.io/fjfij) |
| 06:37.45 | BZNotify | bzflag.org: 03allejo 11self-assigned pull request #24 "Move slash commands into own collection" (06https://git.io/fjfPt) |
| 06:37.46 | BZNotify | bzflag.org: 03allejo 11labeled pull request #24 as 11enhancement |
| 06:37.47 | BZNotify | bzflag.org: 03allejo 11labeled pull request #24 as 15documentation |
| 06:37.48 | BZNotify | bzflag.org: 03allejo review_requested pull request #24 |
| 06:38.29 | BZNotify | bzflag.org: 03allejo 11labeled pull request #24 "Move slash commands into own collection" as 15needs review (06https://git.io/fjfPt) |
| 12:21.42 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 21:12.33 | BZNotify | bzflag: 03atupone 11synchronized pull request #148 "Use of Vertex Buffer Objects instead of Client Arrays" (06https://git.io/vhCKr) |
| 23:40.29 | BZNotify | bzflag.org: 03tainn1 11synchronized pull request #23 "Analysis of tiny flag" (06https://git.io/fjfRi) |
| 23:41.16 | BZNotify | bzflag.org: 03tainn1 commented on pull request #23 "Analysis of tiny flag" (06https://git.io/fjfxo): Agreed with all and patch pushed; thanks for the feedback, @allejo! |