| blast007 | custom sound files would only be downloaded once per file (unless the cache size limit is exceeded) | 00:03 |
|---|---|---|
| blast007 | once per URL* | 00:03 |
| SpringTank | right | 00:03 |
| BulletCatcher | Use of the spree*.wav files was added in 2005 commit 9966d2d8, disabled in a2fae9c2 ("may" be buggy), and removed ca3f2a8e. | 02:11 |
| BulletCatcher | Those .wav files were never used in a released version so no one should miss them if they go away now. | 02:11 |
| *** Gort[m] <Gort[m]!~M-gort-ma@2001:470:69fc:105::7ed> has joined #bzflag | 02:29 | |
| SpringTank | ^ use one of them, but if blast is adding/fixing custom sounds for 2.6 then it doesn't matter. | 03:02 |
| SpringTank | I* use one of them | 03:02 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 06:40 | |
| *** Sgeo_ <Sgeo_!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 07:41 | |
| *** blast007[m] <blast007[m]!~blast007m@2001:470:69fc:105::7ec> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 11:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 13:58 | |
| *** Harlin <Harlin!~DonQixote@75-163-188-12.clsp.qwest.net> has joined #bzflag | 14:58 | |
| *** DTRemenak <DTRemenak!~DTRemenak@2603-8001-3700-003f-9ca3-b955-530f-8f95.res6.spectrum.com> has quit IRC (Quit: ChatZilla 0.9.97 [SeaMonkey 2.53.8.1/20210717164911]) | 16:44 | |
| *** Harlin <Harlin!~DonQixote@75-163-188-12.clsp.qwest.net> has quit IRC (Remote host closed the connection) | 19:53 | |
| *** Harlin <Harlin!~DonQixote@75-163-188-12.clsp.qwest.net> has joined #bzflag | 21:30 | |
| SpringTank | what's left to do on 2.6? Maybe I can help? | 21:38 |
| *** blast007[m] <blast007[m]!~blast007m@2001:470:69fc:105::7ec> has joined #bzflag | 21:38 | |
| blast007 | I don't even recall what's been done to it :) | 21:44 |
| blast007 | also, there isn't a plan for what goes into it (yet) | 21:44 |
| SpringTank | well, don't want it to suffer from feature creep again that's for sure... | 21:45 |
| SpringTank | I have a plan if you want to hear it | 21:45 |
| SpringTank | take what works in 2.6, and if it hasn't been done already, update the netcode to be easy to add features later on. Then release it as 2.6 | 21:52 |
| SpringTank | the server owner can have the option of telling the server to reject older clients if they are using newer features in their maps. | 21:54 |
| SpringTank | but if they are hosting an older map with older features then it doesn't matter. In this case a newer server version can support older clients and not kick them. | 21:55 |
| SpringTank | then with each minor release, concentrate on one single feature to add. | 21:55 |
| SpringTank | I think it's similar to what was already being done with 2.4 | 21:56 |
| SpringTank | and similar to what microsoft is doing with minecraft. | 21:56 |
| blast007 | nah, we're not gonna do that | 22:05 |
| SpringTank | so what's the plan? | 22:07 |
| blast007 | or at least probably not | 22:10 |
| SpringTank | it would get something out there... and for the next major change in protocol could be in 2.8 | 22:12 |
| SpringTank | i mean, it's similar to what was done to 2.4 wasn't it? | 22:13 |
| blast007 | no | 22:13 |
| blast007 | 2.4.0 could still connect to the latest 2.4 server | 22:14 |
| SpringTank | in 2.4, wasn't it fixed up enough to be released along with some backported features? | 22:14 |
| SpringTank | right | 22:14 |
| blast007 | 2.4 was us cancelling the 3.0 release, rolling back to the 2.0 code, backporting specific, low-risk changes from 3.0 and implementing some new stuff (or better versions of stuff from 3.0). It was also the most organized development cycle we had, as far as I know. | 22:16 |
| blast007 | one of the main things I'm slowly working towards for 2.6 is IPv6 support | 22:18 |
| blast007 | that requires changes to the websites, or authentication system, the client, and the server | 22:18 |
| SpringTank | We can build on top of that development cycle. My suggestion: make it so 2.6.0 can connect to a server that is say 2.6.2 unless the server owner chooses to use newer features and has a server option to reject older clients prompting the user to upgrade. | 22:19 |
| SpringTank | and IPv6 support sounds awsome. | 22:19 |
| blast007 | do you do any OpenGL coding? | 22:20 |
| SpringTank | i've tried and fell flight on my face. does that count? | 22:20 |
| SpringTank | flat* | 22:20 |
| blast007 | heh | 22:20 |
| SpringTank | yeah | 22:21 |
| SpringTank | agatha has been playing with openGL. she has something that works I think. | 22:21 |
| SpringTank | just some basic stuff | 22:21 |
| blast007 | I was interested in replacing our menu UI (and maybe other part of the UI) with either MyGUI or Crazy Eddie's GUI | 22:21 |
| SpringTank | never heard of those, looking at them now | 22:22 |
| Agatha | I kindof like the old menu system. It takes a bit of getting used to, but that's part of the charm, I think. | 22:25 |
| blast007 | Agatha: do you want to update it to support text fields that can scroll left-to-right? :) | 22:26 |
| blast007 | or add dropdowns, or checkboxes, or mouse/joystick support | 22:26 |
| blast007 | dropdowns and checkboxes would be nice to haves, but of course not required | 22:27 |
| blast007 | even a lot of commercial games don't do that. they just do left-right selection of on/off or the various options | 22:27 |
| SpringTank | I was, and this was just an idea I had, goning to play with what little mouse support bzflag has to try and get the mouse to work with the existing menu system. | 22:28 |
| SpringTank | although that wouldn't be flexible enough for future upgrades | 22:28 |
| blast007 | somewhere I do have some code that moves some of our menus layout code into the base class. right now each menu has custom code to handle how to scale/position everything, even though a lot of it could just be the same or a choose of 2 or 3 layouts | 22:29 |
| SpringTank | Might be easier to spin our own shiny new menu system with room for future upgrades. | 22:29 |
| blast007 | we don't *have* to code everything ourselves :) | 22:29 |
| SpringTank | true, i just hate using other people's libraries because more often then not it's like learning a whole new language. something I'm not very skilled at. | 22:33 |
| Agatha | I feel like most games probably have their on UI system, like what bz has. This is . . . fine, you ask me. Yes, there are deficiencies, but I think the menu system is functional. | 22:33 |
| Agatha | One of the reasons I'm . . . extremely reluctant to touch the bz source code myself, to the extent I'd even be able to help, is that it's so complicated and messy that no one really understands it. There are tons of grandfathered bugs, too. | 22:33 |
| Agatha | I know that this horse has been beaten to death, but I still maintain the system needs renovation. If rewrites from scratch haven't worked, then maybe take it more slowly. | 22:33 |
| SpringTank | more importantly, documenting what we do know and how it works. something that has been worked on a lot | 22:34 |
| SpringTank | block diagrams, etc. | 22:34 |
| SpringTank | you can't fix something if you don't know how it works | 22:34 |
| SpringTank | obvious answer is obvious | 22:35 |
| SpringTank | IMO the existing menu is charming in it's own way and I like it, but it needs mouse support and refactoring to make it more flexible for future additions. | 22:36 |
| SpringTank | is 2.6 code based on the current build of 2.4? | 22:37 |
| SpringTank | a basic in game windowing system might be usefull as well. | 22:39 |
| SpringTank | but not immediatly nessasary. | 22:39 |
| blast007 | "If rewrites from scratch haven't worked, then maybe take it more slowly." ... such as replacing custom code with wonkyness with mature, well tested libraries? ;) | 22:41 |
| blast007 | 2.6 should be pretty close to in-sync with all the 2.4 changes | 22:41 |
| blast007 | I merge from time to time | 22:42 |
| blast007 | (well, 2.5) | 22:42 |
| blast007 | 2.6 doesn't exist yet :) | 22:42 |
| Agatha | blast007 Yes, exactly! Someone who knows what they're doing needs to focus development there, IMO. | 22:42 |
| Agatha | What I see is an API / codebase with sketchy docs that are incorrect in various ways. For example, my own efforts at writing plugins are hobbled because I'll try to do something and there's nonsense data, or something causes a mysterious crash. So I have to come here and beg for people with experience in the codebase to tell me what's wrong! Parameters with weird names, stuff documented nowhere, random cargo cult copypasta that shouldn't work and sometimes | 22:42 |
| Agatha | doesn't. | 22:42 |
| Agatha | This kind of stuff eats up most of the time I have to do anything on the project! | 22:42 |
| Agatha | While I'm not at all deep in development here, I can't imagine people who know the codebase better are having an easier time maintaining, let alone improving, it. | 22:42 |
| Agatha | . . . | 22:42 |
| * Agatha sigh | 22:42 | |
| Agatha | But this is all just complaints—and not very useful ones at that. | 22:43 |
| Agatha | I have literally no idea what y'all are actually working on. What is this mystical 2.6? What's different to 2.4? What's blocking 2.6 from becoming the main one people use? | 22:43 |
| Agatha | Yes, I've written code before, and I've played with OpenGL . . . but I'm no software engineer, nor a maid. This project needs both, and at the same time :S | 22:44 |
| blast007 | heh | 22:44 |
| blast007 | yeah, my attempts to add IPv6 support get real complicated because we pass addresses around so many damn places | 22:45 |
| blast007 | and there's also some weird stuff randomly shoved into Address.h | 22:45 |
| blast007 | maybe I should start pushing partial changes to the fork on my account | 22:46 |
| SpringTank | sounds to me like the netcode needs refactoring. *easier said than done* | 22:47 |
| Agatha | So for the IP thing, may I suggest something like wrapping some small piece of the code that uses it in an IP class or whatever that abstracts the IPv4 vs. IPv6 distinction, and getting that working. Then gradually refactoring outward until everything is fixed—but with stuff in the meantime still functional. | 22:47 |
| SpringTank | ^ | 22:48 |
| SpringTank | yeah, one major thing at a time. | 22:48 |
| blast007 | I have some functions written to handle IPv4/IPv6 addresses, CIDRs, etc | 22:48 |
| Agatha | Well, less than one major thing at a time, really. You have to break the problem down, as with all problems. | 22:48 |
| blast007 | yeah, it's just that our address stuff is used all over the place | 22:49 |
| SpringTank | then I think the next major thing would be to strip that out and come up with a better netcode library. | 22:50 |
| Agatha | blast007 Sure. So fix it in some places, and get that working. Then fix it in more places and get that working. Etc., until you're done. Is what I'm saying. | 22:50 |
| SpringTank | reduce the spagettie code monster | 22:50 |
| SpringTank | draw it out on a whiteboard | 22:50 |
| SpringTank | lol | 22:50 |
| Agatha | 3rd party libraries are okay, I guess, but they are additional work to set up, and building bz is already pretty annoying for a noob like meee | 22:51 |
| Agatha | I have actual notes on how I succeeded the one time, hah | 22:51 |
| SpringTank | well, i meant come up with our own netcode library | 22:52 |
| SpringTank | something on the side that could then be used in bzflag | 22:52 |
| SpringTank | want me to give it w throw? | 22:52 |
| blast007 | 2.5 has some improvements to the netcode, IIRC | 22:52 |
| SpringTank | I'm nearing the end of this semester's flight courses, i think i can find some time for it. | 22:53 |
| blast007 | for instance, now the world gets sent a lot faster for players with higher lag | 22:53 |
| SpringTank | interesting | 22:53 |
| blast007 | don't need to use fastmap or an HTTP cache for the world file | 22:53 |
| SpringTank | sounds to me like bzflag's netcode is the next biggest monster to eat. | 22:54 |
| SpringTank | probably the most important | 22:54 |
| blast007 | I was recently trying to find some better way to post ideas and have a discussion around them, while still bewing tied in with Github's issues, PRs, etc. | 22:55 |
| blast007 | maybe just an issue for that is enough | 22:55 |
| SpringTank | lol | 22:55 |
| blast007 | I was hoping for something with a bit more project management features though, like dependent features | 22:55 |
| SpringTank | yeah | 22:56 |
| blast007 | here's an idea for improving the poll system by making it part of the network protocol, not just slash commands: https://gist.github.com/blast007/a85fef0bcdb327220b441663cdd8ab07 | 22:56 |
| blast007 | (with the idea being that there would be some sort of Poll UI, not slash commands) | 22:57 |
| SpringTank | i skimmed through it. sounds great | 22:58 |
| SpringTank | but doesn't this add more client/server messages? | 22:58 |
| blast007 | recent stuff I thought about for 2.6 features: https://gist.github.com/blast007/cc11096ee783e7e44c40ae76fd3be397 | 22:58 |
| blast007 | yeah | 22:58 |
| blast007 | our system supports up to 65535 (or 65536) different messages types - we might as well use more of them them ;) | 23:00 |
| SpringTank | falls back to bzflag's netcode, which is it's foundation | 23:01 |
| SpringTank | true | 23:02 |
| SpringTank | that's actualy preetty cool | 23:03 |
| SpringTank | so it doesn't need a total refactor like I thought it did. Just maybe needs to be organized and documented better. | 23:04 |
| SpringTank | how does the client handle undefined server messages? Does it just ignore them? | 23:04 |
| blast007 | I think, but that's a part of the code that's pretty easy to look at and follow | 23:09 |
| blast007 | playing.cxx handles much of that | 23:09 |
| blast007 | we have a big switch statement that covers the message types | 23:10 |
| SpringTank | that's how I thought it worked. | 23:12 |
| SpringTank | just had an idea. Is there a script or program that can parse C++ code into graphical block diagrams? | 23:22 |
| SpringTank | i played with IDA pro, maybe it will do it | 23:23 |
| SpringTank | but it's more of a dissassembler than anything | 23:24 |
| blast007 | https://static.bzexcess.com/bzflag_design_diagram.jpg | 23:27 |
| SpringTank | lmao | 23:35 |
| SpringTank | i found a neat little program called Sourcetrail | 23:35 |
| SpringTank | trying it now | 23:35 |
| SpringTank | lets see if it can handle bzflag. lol | 23:35 |
| SpringTank | https://en.wikipedia.org/wiki/Sourcetrail | 23:36 |
| SpringTank | https://en.wikipedia.org/wiki/Call_graph#Software | 23:36 |
| blast007 | it might end up with the same image as above ;) | 23:36 |
| SpringTank | "12 errors: 7 fatal" | 23:37 |
| SpringTank | so far... | 23:37 |
| SpringTank | but it's still going. | 23:37 |
| SpringTank | would be incredibly valuable to us if we could get a functional block diagram of the current system | 23:37 |
| SpringTank | especially to those of us like myself who are very visually based. | 23:39 |
| blast007 | pretty sure I've used this before | 23:49 |
| blast007 | I used bear to create a compiliation database and pointed to that | 23:50 |
| blast007 | I started with a clean source directory of master and did './autogen.sh && ./configure && bear -- make -j14' (adjust the 14 as needed depending on how many core you have) | 23:51 |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-71-182-231-53.pitbpa.fios.verizon.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 23:52 | |
| blast007 | cores/threads | 23:52 |
| SpringTank | interesting | 23:53 |
| SpringTank | well mine hit 50% | 23:53 |
| blast007 | mine finished with no errors | 23:53 |
| SpringTank | and it's just going by the raw source | 23:53 |
| SpringTank | I pointed mine to all files, so that's probably why I got errors | 23:53 |
| SpringTank | I just wanted to see what it would do | 23:54 |
| blast007 | I probably should have disabled plugins, cuz those are in here too now :) | 23:54 |
| SpringTank | lol | 23:56 |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-71-182-231-53.pitbpa.fios.verizon.net> has joined #bzflag | 23:56 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
