| 00:02.34 | Okina | So quick thing with forums, should opening a new tab trigger logout? |
| 00:02.43 | Okina | Since it seems to do so in my case. |
| 00:03.16 | Okina | (Non-static IP if relevant and FireFox as preferred browser.) |
| 00:04.49 | blast007 | nope, shouldn't do that |
| 00:06.25 | blast007 | do you have some extension that messes with your user agent string? |
| 00:08.43 | Okina | Seems to happen more often on default configuration.(No extensions.) |
| 00:09.26 | Okina | And "uBlock" should not be messing with agent strings, as far as I can tell. |
| 00:09.55 | blast007 | I use Firefox here and I open forum links in new tabs all the time |
| 00:10.24 | blast007 | and by "uBlock" do you mean "uBlock Origin"? |
| 00:10.47 | Okina | Yes. |
| 00:11.35 | blast007 | is your IP drasticly changing? |
| 00:12.32 | Okina | I'm not certain, but it probably changes frequently, unless constantly connected. |
| 00:12.53 | Okina | (Either by download or IRC like connection.) |
| 00:37.28 | *** join/#bzflag Andradite (~Keiki_Han@unaffiliated/zehra) |
| 02:34.52 | brlcad | who |
| 04:36.21 | *** join/#bzflag infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 04:36.21 | *** topic/#bzflag is BZFlag Support and Development || Latest version: 2.4.20 || https://www.bzflag.org || https://www.bzflag.org/help/ || https://www.openhub.net/p/bzflag || https://logs.bzexcess.com/freenode/%23bzflag/ || New release! https://forums.bzflag.org/viewtopic.php?f=62&t=20395 |
| 04:36.21 | *** mode/#bzflag [+v infobot] by ChanServ |
| 09:13.19 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 09:13.19 | *** mode/#bzflag [+v spldart] by ChanServ |
| 09:31.07 | *** join/#bzflag _I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 09:32.44 | *** join/#bzflag FieldSobers (~User49@unaffiliated/user49) |
| 12:53.57 | *** join/#bzflag User49 (~User49@unaffiliated/user49) |
| 14:10.19 | *** join/#bzflag Sgeo (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 15:00.06 | *** join/#bzflag MarderIII (~MarderIII@enneman.demon.nl) |
| 15:48.05 | *** join/#bzflag FieldSobers (~User49@unaffiliated/user49) |
| 16:27.50 | *** join/#bzflag Agatha (180a9d90@c-24-10-157-144.hsd1.ut.comcast.net) |
| 16:29.49 | Agatha | Hi |
| 16:29.53 | Agatha | (This is not Agatha BTW. But I'm helping her with the C++ for her plugin.) |
| 16:30.00 | Agatha | On Thursday, she was advised that to delete a shot, one must bypass the official API and "send a raw endshot for that shot". |
| 16:30.15 | Agatha | So we're trying to do that. Here's our attempt: https://gist.github.com/agatha2/3305591e2282b8eb47fbc9742135b171 |
| 16:30.24 | Agatha | It doesn't work right (the client that fired still sees the bullet, though other clients, correctly, do not). |
| 16:30.31 | Agatha | It has lots of comments about what we think we're doing. |
| 16:30.41 | Agatha | Basically, I think we're not calculating the shot id to delete correctly. |
| 16:30.46 | Agatha | Any pointers? Thanks |
| 16:30.46 | CaptainRoberts[m | it's going to be super janky |
| 16:31.13 | CaptainRoberts[m | you sould probalby capture the ID when the shot is created |
| 16:31.24 | CaptainRoberts[m | this is outside of the normal API features, so it won't be easy |
| 16:39.43 | Agatha | Yes, exactly. So what do you suggest I do? The standard API doesn't expose the shot id (bz_ShotFiredEventData_V1's shotID member is bogus), and calculating it myself (as in the Github gist I linked) doesn't work correctly. I also notice there is a ShotCreated event callback in Shots::Manager, which I could set (but I think it would do the same |
| 16:39.44 | Agatha | thing). |
| 16:39.53 | CaptainRoberts[m | I also belive shot manager is rather untested |
| 16:40.24 | CaptainRoberts[m | best thing is to modify the API to send the shot ID |
| 16:40.35 | CaptainRoberts[m | you are allready out of the scope of normal API work |
| 16:41.09 | Agatha | Yes, I definitely understand that this is beyond the official API. |
| 16:41.30 | CaptainRoberts[m | Shot manager is trying to assign a global ID to shots, but shot IDs are actualy local to the player. so they are effectivly made up of two parts, the player ID, and the local shot ID |
| 16:41.55 | CaptainRoberts[m | and player local shot ids wrap around |
| 16:42.06 | CaptainRoberts[m | the server tells each client the max number of shots |
| 16:42.23 | CaptainRoberts[m | and the IDs go from 0 to max shots -1 |
| 16:42.36 | CaptainRoberts[m | so if a server is set to only allow 1 shot, the shot ID for a player is always 0 |
| 16:43.09 | CaptainRoberts[m | the server player is the only player that's allowed more shots than the shot limit, for world weapons |
| 16:44.00 | CaptainRoberts[m | so if you are just trying to kill the shot that was fired, use the shotID field form the fired event |
| 16:44.28 | blast007 | my suggestion is to not bypass the API since that will be blocked on some compilers already |
| 16:44.32 | CaptainRoberts[m | the "GUID" from shot manager isn't used in network transport |
| 16:44.56 | CaptainRoberts[m | yeah, only exported functions may be calllable by the plugins dynamic library |
| 16:44.58 | blast007 | extend the API, if you must, and then maintain your forked copy |
| 16:45.39 | CaptainRoberts[m | what you are doing is very fragile |
| 16:47.46 | CaptainRoberts[m | but your problem is the assumption that shot manager's GUID is the ID to send in transport. ShotManager has a FindShot method that takes a GUID and returns a ShotRef, the ShotRef has the shot, and the shot has the FiringInfo, and the FiringInfo has the ShotUpdate, and that has the local ID |
| 16:47.59 | CaptainRoberts[m | but you don't need shot manager at all |
| 16:51.46 | CaptainRoberts[m | but a simple compiler flag will break your code, when it blocks off access to non exported functions |
| 16:52.13 | CaptainRoberts[m | I'm surprised that flag hasn't been enabled by default in the project already. |
| 16:55.54 | blast007 | I tried with gcc, but it seemed to just export it all anyway |
| 16:56.05 | blast007 | I think clang might be hooked up to do it |
| 17:01.34 | *** join/#bzflag Agatha (180a9d90@c-24-10-157-144.hsd1.ut.comcast.net) |
| 17:01.50 | Agatha | Sorry! This IRC keeps disconnecting me for some reason? |
| 17:01.57 | Agatha | "use the shotID field form the fired event" <- Note: as I said, the shotID field is invalid in the fired event, so this doesn't work. |
| 17:02.01 | Agatha | The explanation above about the global ID vs. local ID was very helpful. |
| 17:02.07 | Agatha | Let me try the FindShot thing you described later. Again, the shot doesn't exist in it until after the event completes, but perhaps I can reference the shot later, and kill it in the tick event? Not ideal, but might work . . . |
| 17:09.10 | Agatha | And about forking the whole project and relying on compiler flags . . . look, the "right" solution might be to refactor the codebase, and also expose a lot of new stuff in the API. I am even willing to help with that, in the limited way to which I am able . . . but it's just not realistic for me, a relative outsider with little experience, to do |
| 17:09.11 | Agatha | that all by myself just for a one-off plugin. |
| 17:09.18 | Agatha | Yes, a brittle solution is clearly not ideal, but at the end of the day one just has to write something that works, even if it's hacky and bad. Maintaining a plugin is definitely also easier and smaller in scope. If the API improves in the future, I think we'll be happy to update it to the newer standard. :) |
| 17:09.32 | blast007 | this isn't something we'll add to the official game |
| 17:09.35 | CaptainRoberts[m | what makes you think the shot ID is invalid? |
| 17:09.59 | Agatha | blast: that's fine. I think it's probably a bad idea to add to the main game anyway. |
| 17:10.16 | blast007 | I'm talking about the API changes |
| 17:10.30 | blast007 | so, you're gonna have to have local modifications to the API, thus a fork |
| 17:10.43 | blast007 | the plugin will only work on your fork |
| 17:11.33 | Agatha | Roberts: see bzfs.cxx line 4192, and referenced constructor which initializes it to -1. This is then passed immediately into the event callback. |
| 17:16.24 | Agatha | blast007: Ah. No, I meant more, in some potential future where the external API or the internal bzfs code changes (both of which seem likely)ânot necessarily to specifically support these features, but, you know, changes *somehow*, then those changes are likely to affect the plugin. That's fine. We'll update the plugin. Please don't think we're |
| 17:16.25 | Agatha | trying to suggest that the API needs to be changed just for us. Our use-case might be a good motivation for changing it to consider, but CPI modifications should follow some overarching, coherent direction, and in any case be well thought-out. |
| 17:16.46 | Agatha | *but API modifications |
| 17:30.58 | blast007 | I just don't get what you're hoping to accomplish |
| 17:35.08 | Agatha | At a technical level? Delete shots in a plugin, potentially using undocumented, unofficial features, while accepting and understanding the risks that come with same. Or did you mean what's the point of the plugin? I can get Agatha to explain that one if you want, but basically it's just new weapon varieties, for fun. |
| 17:35.47 | blast007 | it's not going to work |
| 17:36.21 | blast007 | unless you're on LAN server with a world with no obstacles |
| 17:37.12 | blast007 | shot messages are UDP, so you can't guarantee that they arrive in order or at all |
| 17:37.31 | blast007 | and a slight amount of latency will make it wonky, not wacky |
| 17:37.53 | blast007 | and I don't know if you can even affect the client's own shots |
| 17:38.25 | CaptainRoberts[m | you can't |
| 17:38.31 | CaptainRoberts[m | not in 2.4 at least |
| 17:38.43 | CaptainRoberts[m | 2.6 had more code to do that kind of stuff |
| 17:39.10 | CaptainRoberts[m | you are trying to turn a car into an airplane, it's possible but it's going to be very hard |
| 17:39.14 | CaptainRoberts[m | and dangrous |
| 17:39.54 | CaptainRoberts[m | Fancy shots would be cool and all, unfortunately the BZFlag code-base is not at a place to do that right now. |
| 17:40.28 | blast007 | as I said to Agatha, that should be something coded client-side, not server-side |
| 17:47.09 | CaptainRoberts[m | the shot ID of -1 to the event is a bug and should be fixed |
| 17:53.49 | Agatha | Note: in allejo's plugin starter, it is documented as "// (int) shotID - (UNUSED) Value exists, however it is never set.", which made us think it was intentional. At any rate, the (server side) shot id is created by adding it to the shot manager, yet the event can cancel that from ever happening. So there's a circular dependency on |
| 17:53.50 | Agatha | setting it before the event fires. |
| 17:54.58 | Agatha | Well, deleting shots is important, but I guess not *critical* for this plugin. I'll have to talk with Agatha and see what she thinks. And maybe also look at the code some more myself. It feels like it should be possible. |
| 17:55.09 | CaptainRoberts[m | The documents are based on the code, the intent was to set the ID, it's a bug. The server side shot ID thing is new and like I said, mostly unused. It was added to help server side bots. The shot message from the client has the ID so it can be sent to the API. |
| 17:56.58 | CaptainRoberts[m | the API documents came after the API was initially written. The API is riddled with bugs. |
| 17:56.59 | Agatha | Yeah. Sounds good; was just FYI. |
| 18:01.08 | Agatha | I guess . . . big picture questionâwhat's the story here? What we gathered is that some kind of 3.0 release was planned, but it was too ambitious, so it partially merged back into the 2.* series? Looks like there's continual progress being made, but I can't quite tell what that means for the project. I guess 2.5 is next? |
| 18:02.55 | CaptainRoberts[m | that's pretty much it |
| 18:03.14 | CaptainRoberts[m | that situation has happened multiple times in the development history |
| 19:50.50 | CaptainRoberts[m | 2.6 would be the next version that breaks the network protocol and would be incompatible with older clients and servers. |
| 19:53.10 | Agatha | Is some kind of rough timeline for this available? |
| 19:53.50 | CaptainRoberts[m | Nope |
| 19:54.02 | CaptainRoberts[m | it's an open source project, people work on it when they want to |
| 19:57.59 | Agatha | Yeah I get that. That's why I specified rough: think more like "guess". Just looking at previous releases, it looks like a few months for 2.5. But perhaps a better estimate is possible. |
| 19:58.27 | CaptainRoberts[m | the 2.4 release has been going on for years and years |
| 19:58.44 | CaptainRoberts[m | people are STILL only working in 2.4 |
| 19:59.05 | CaptainRoberts[m | I would not expect a major release of bzflag for at least a year or two. |
| 19:59.20 | Agatha | okay thanks |
| 19:59.25 | CaptainRoberts[m | people won't let go of 2.4 |
| 20:00.27 | Agatha | Oh? There is some attachment to it? Existing plugins, perhaps? |
| 20:00.45 | CaptainRoberts[m | people fear change |
| 20:01.08 | CaptainRoberts[m | and it's hard to get people to test an incompatible version |
| 20:02.26 | CaptainRoberts[m | 2.4.0 was made 9 years ago |
| 20:30.51 | allejo | 2.6 requires effort |
| 20:31.05 | allejo | and who likes putting in effort into anything? |
| 21:40.33 | *** join/#bzflag Zehra (~Keiki_Han@unaffiliated/zehra) |
| 22:37.46 | Zehra | I noticed thread recently posted was moved to "Plug-in Releases", despite 1 out of a few plug-ins completed. |
| 22:38.19 | Zehra | Therefore while it is a completed plug-in, it is not the completed set of plug-ins, so therefore incomplete as a collection. |
| 22:39.16 | Zehra | (This may be considered partially "violation" of spirit of said rules.) |
| 22:39.48 | Zehra | However it would be fine, if it remains. (Since it anyways will be completed, just a bit earlier than expected.) |
| 22:40.02 | allejo | moved to plugin dev |
| 22:40.10 | Zehra | Thanks allejo. |
| 22:46.35 | *** join/#bzflag FieldSobers (~User49@unaffiliated/user49) |
| 22:55.56 | Zehra | Would anyone happen to recall of one server or mod of where game clients got differing "world" files? |
| 22:56.08 | Zehra | Or something similar to that manner. |
| 22:56.50 | blast007 | intentionally? |
| 22:56.57 | Zehra | Yes. |
| 22:57.13 | blast007 | there was a bug in some REALLY early version, but I don't see why you'd do that intentionally |
| 22:57.52 | blast007 | might have been a bug in a 1.7 development version as well |
| 22:59.15 | Zehra | Ah, okay, well mainly it would have been to provide differing material/object properties per team. |
| 22:59.32 | blast007 | Agatha: at this point, most of what is being done with 2.4 is just fixing SDL bugs and making the game better for first time players |
| 23:03.13 | blast007 | as for timeline, there's not really one, but a major goal for 2.6 is to have full IPv6 support, which also requires changes to the authentication system and the server list |
| 23:04.50 | BulletCatcher | Git commit f618a20c fixed a bug in doomed version 2.99 where a new random map was generated when the player in slot 0 left. The remaining players would be on the old map and newly joined players would be on the new map. Hillarity ensued. |
| 23:05.34 | blast007 | ah yeah, I knew that issue had returned somewhere :) |
| 23:18.16 | Zehra | players: "why is that tank up there, there isn't any objects", new player: "I see them and you can't??". (oO) |
| 23:18.51 | Zehra | In all seriousness, would it be alright for myself or anyone to provide guidance regarding code contributions? |
| 23:18.58 | Zehra | But not the actual code itself. |
| 23:19.16 | Zehra | "the effect may be achieved by changing line from so, to so"..etc |
| 23:19.19 | blast007 | what do you mean? |
| 23:20.55 | Zehra | Basically in other words, a template and instruction guide to achieve certain functionality. (Which could be given to anyone.) |
| 23:22.15 | Zehra | Similar to one of previous posts for "automatic respawns". |
| 23:24.20 | blast007 | certain functionality? |
| 23:25.35 | Zehra | Well, for instance, if a better version of the "2.6.x" planned branch of geno is provided as "instructions" or "guide"... |
| 23:26.20 | Zehra | if anyone takes it, provided it is properly licensed, could it be accepted as code contribution? |
| 23:27.33 | Zehra | so person provides guide under CC0, person2 uses guide to achieve mod, person2 submits "contribution" |
| 23:28.14 | blast007 | I don't know what you're talking about |
| 23:31.31 | Zehra | Would forwarded code contributions be accepted, person1 gives person2 rights to code contribution and person2 submits. |
| 23:31.40 | Zehra | In simplest essence. |
| 23:32.17 | blast007 | What are forwarded code contributions? |
| 23:33.11 | CaptainRoberts[m | He wants to be involved in other people's contributions, like an agent. |
| 23:33.20 | blast007 | and agent of confusion? |
| 23:33.25 | Zehra | Person1 implements code modification and tests it, waives all rights and grants them to person2, person2 is the one who "sends" it. :p |
| 23:33.46 | blast007 | Zehra: why would you want to do that? |
| 23:34.01 | blast007 | or are you person2 in this situation? |
| 23:34.11 | blast007 | gonna hire someone on Fiverr to be person1? |
| 23:34.26 | Zehra | person1 would be myself. |
| 23:34.41 | blast007 | so why wouldn't you just submit it yourself? |
| 23:35.25 | blast007 | the real name for the authors thing? |
| 23:35.48 | Zehra | Since I have not currently founded a corporation. (Yes.) |
| 23:37.05 | Zehra | If the guide is under Creative Commons Zero, there does not seem to be any issue. |
| 23:37.06 | Zehra | (And I'd certainly like to see 2.6. released.) |
| 23:37.14 | blast007 | a guide isn't code though |
| 23:37.39 | blast007 | and I'd like to see these 20 hotspots on the floor configure themselves |
| 23:39.23 | Zehra | That's the thing, if it is not code, there should not be any issues for whoever submits the code achieved by the guide. |
| 23:39.37 | *** join/#bzflag Andradite (~Keiki_Han@unaffiliated/zehra) |
| 23:40.08 | Andradite | "That's the thing" was my last post and last read on IRC. |
| 23:41.28 | Andradite | Also, person2 will learn and gain insights on the subject. |
| 23:41.55 | Andradite | (On my side, I get to see more possibilities with more stable code.) |
| 23:41.57 | CaptainRoberts[m | Does the guide tell you how to make a simple process overly complex? |
| 23:43.21 | Andradite | hehe, if it did, it certainly would not be accepted, now would it? |
| 23:43.39 | CaptainRoberts[m | then I think you've answered your own question |
| 23:44.49 | Andradite | I'll take that as a yes: https://forums.bzflag.org/viewtopic.php?f=78&t=20400 |
| 23:45.36 | CaptainRoberts[m | 𤦠|
| 23:46.34 | Agatha | Incidentally, the question has some bearing on me, too . . . the bug I found earlier, with the shot ID being -1? There's a one-line fix for that. I would like to delegate that as public domain. |
| 23:47.02 | CaptainRoberts[m | then just submit a pull request |
| 23:50.15 | allejo | yes, please just submit pull requests. it really makes our lives significantly easier |
| 23:50.58 | allejo | you don't see other projects saying, "we accept patches in these 20 different ways!" they'll always point you to the one source of truth. whether it's github or a mailing list |
| 23:51.06 | allejo | our source of truth is github |
| 23:51.24 | CaptainRoberts[m | that is literally what pull requests are for, to get community submissions |
| 23:52.21 | Agatha | Hmmm my friend tells me that's standard for open source projects, so okay. Give us a moment. |
| 23:58.42 | CaptainRoberts[m | yeah it's super standard. There is a developer agreement that you effectively agree to when you submit a pull request. You grant the rights for the maintainer to use the code etc... No need for public domainness. |