| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 01:11 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 01:30 | |
| *** FastLizard4 is back | 01:46 | |
| *** FastLizard4 is now away: AWAY from keyboard | 02:10 | |
| *** FastLizard4 is back | 02:42 | |
| *** yuitimothy is back | 02:47 | |
| *** FastLizard4 is now away: AWAY from keyboard | 04:33 | |
| *** FastLizard4 is back | 04:40 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 260 seconds) | 04:45 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Leaving) | 05:33 | |
| *** FastLizard4 is now away: AWAY from keyboard | 06:12 | |
| *** FastLizard4 is back | 08:09 | |
| *** FastLizard4 is now away: AWAY from keyboard | 08:21 | |
| *** FastLizard4 is back | 08:57 | |
| *** FastLizard4 is now away: AWAY from keyboard | 10:30 | |
| *** FastLizard4 is back | 11:22 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 11:22 | |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC (Ping timeout: 268 seconds) | 11:57 | |
| *** Juest <Juest!~Juest@user/Juest> has joined #bzflag | 12:21 | |
| *** FastLizard4 is now away: AWAY from keyboard | 12:21 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:33 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:35 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 264 seconds) | 12:38 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 12:47 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has quit IRC (Quit: Leaving) | 14:38 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has joined #bzflag | 16:49 | |
| bz-next | one general thing I've noticed while fiddling with cached resource fetching: the system seems to only really support textures in the current codebase. There's a "resource getter" with cURLManager, but it doesn't integrate with the cache. It is nominally used by the client, but not for anything as far as I can tell. It is used to download to the media directory, which is odd to me considering that a cache exists | 17:02 |
|---|---|---|
| bz-next | I'd rather there be a CachedResource or something that wraps cURLManager and eventually have Downloads use that, since all the cache management logic is in Downloads rn | 17:03 |
| bz-next | Really, imo, Downloads should be TextureDownloader or something, since I don't think having a central class to handle all downloads is a good pattern if the app becomes more dynamic and needs to occasionally fetch stuff from places. It ties resource fetching to initialization of global state, and that's a bit brittle | 17:06 |
| bz-next | If there's just a generic CachedResource, then anything that needs to fetch stuff can just use the cache, a request will be fired off if needed, and you can just check to see if it's ready and grab the data. If you want to manage a bunch of downloads then you can just manage a collection of CachedResources. If you want to pop a UI element with some remote data in it, then the UI element can just spawn its own CachedResource and fetch the data that way | 17:10 |
| bz-next | without relying on some global manager being done | 17:10 |
| blast007 | where is the code that would download resources to the media directory? | 17:15 |
| blast007 | the media directory isn't going to be writable in 99.9% of cases, since that's the data/ directory | 17:16 |
| bz-next | cURLManager ResourceGetter instantiated in playing.cxx as resourceDownloader, line 1938-ish, on MsgFetchResources it builds a path to the media directory and adds stuff to fetch | 17:17 |
| bz-next | maybe a defunct remote resource fetching idea? | 17:17 |
| bz-next | from the code it looks like it was intended to be used for custom sounds. But it doesn't use the cache | 17:23 |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC () | 17:29 | |
| blast007 | maybe that's why it would crash clients :P | 17:33 |
| blast007 | custom sounds, that is | 17:33 |
| bz-next | lol oh no | 17:33 |
| bz-next | yeah reading through the code for all that, it is full of dangers. Like, what if the sound tries to play before the resource is done downloading, even if it is able to write it out? | 17:35 |
| blast007 | BZFlag Codebase: Full of Dangers Edition | 17:35 |
| bz-next | It'd be a massive refactor to solve that kinda issue in general I think. You'd need an abstract resource class of some sort, that understands if it's being sourced from a file or a URL and engages the cache manager if so. Since bugs come about from not manually checking the cache manager for isCacheFileType() when loading... anything | 17:40 |
| bz-next | it's probably easiest to just add the cache check logic into the various things that use game resources, like sounds, in the same style as what's done with the texture manager | 17:42 |
| bz-next | isCacheFileType(filepath) then getLocalName(filepath) if so. Even that relies on the downloads being ready for access, which is unfortunate, but what can you do, really | 17:43 |
| bz-next | Really, considering that all these managers are singletons, the big bad download manager should just be global and able to be queried to see if it's done its work. Maybe? Or maybe just accepting that some init has to be done before you can trust any later code to work | 17:45 |
| bz-next | currently downloads are handled between joinInternetGame and joinInternetGame2 or something like that, so it's just in lockstep with initializing the connection to the server | 17:46 |
| bz-next | that could be fine so long as everything that needs to be downloaded for the map / game connection actually happens in the download manager and isn't done by some other mechanism | 17:47 |
| blast007 | I did want to revamp the game joining process. I wanted their to be better feedback between the client and server about what is happening, and also be able to specify resources to download beyond just textures. | 17:47 |
| bz-next | I think generalizing the Downloads class a bit and plugging it into MsgFetchResources would be 80% of the work to make that possible | 17:48 |
| blast007 | At one point I had looked at fixing up the custom sounds handling, but the scope of things I needed to change kept growing :P | 17:49 |
| bz-next | yeah... if resource fetches are specified via specific server messages, when do they even happen? Does all client code then need to check if the resource is available yet? | 17:49 |
| bz-next | Given the current structure of things, resource fetch stuff should be specified along with the initial connection, or baked into the map file or something | 17:50 |
| bz-next | Having it not in sync with loading the world is just... overly ambitious given how the code expects stuff to be there when it needs it | 17:50 |
| blast007 | bz_sentFetchResMessage is an API function that a plugin would call to tell a client to download something | 17:51 |
| blast007 | and it's probably one of those things that was only ever tested from someone's home directory, so it didn't have issues writing to the data/ directory | 17:51 |
| bz-next | lol yeah | 17:52 |
| bz-next | that makes a lot of sense | 17:52 |
| bz-next | I think the big question is: should resources manage their own "isReady" state? Or should all code that uses resources fail gracefully (with retry) if the file isn't available? But then what happens if it never downloads at all, does it try to open the file and fail every time? | 17:55 |
| blast007 | https://github.com/valyala/ybc "This library implements fast in-process blob cache with persistence support." | 17:55 |
| blast007 | there's probably other similar libraries as well | 17:56 |
| bz-next | I think the cache itself works OK but a problem is that the cached objects aren't really cached objects. They're just strings that are re-written to point to files in the cache directory | 17:56 |
| bz-next | So any asynchronicity issues aren't really handled | 17:57 |
| blast007 | yeah | 17:57 |
| blast007 | if resources had to be fetched as part of the join process, there would be fewer issues | 17:57 |
| bz-next | I think async is too ambitious to support, yeah, exactly | 17:57 |
| blast007 | that was what I was trying to do in a previous attempt at fixing the custom sounds | 17:58 |
| bz-next | Can a plugin tell a client stuff during the connection process? | 17:58 |
| blast007 | a plugin could register custom resources during the Init() | 17:58 |
| blast007 | and then we'd just have to decide how to handle a plugin being loaded later via /loadplugin | 17:59 |
| bz-next | lol just prevent it | 17:59 |
| blast007 | easy fix for that would just be to remove /[un]loadplugin | 17:59 |
| bz-next | at some point bzfs just becomes unix, as all complex enough systems do | 18:00 |
| blast007 | https://static.bzexcess.com/bzflag_design_diagram.jpg | 18:01 |
| bz-next | lmao | 18:01 |
| bz-next | clearly that's UML | 18:02 |
| bz-next | I do think the idea of loading a shared object at runtime as a plugin and letting it be loaded and unloaded is already an impressive level of playing with fire | 18:03 |
| bz-next | at least for a small program like bzfs | 18:03 |
| blast007 | especially because on Linux (and macOS?) we're not preventing a plugin from calling internal bzfs functions/methods | 18:03 |
| blast007 | (and yes, some plugins DO that) | 18:04 |
| blast007 | I had tried enabling the gcc visibility flags before, but that didn't seem to have any effect | 18:04 |
| bz-next | you can't prevent the people from getting what they want | 18:05 |
| blast007 | sure I can :) | 18:05 |
| blast007 | *removes plugin system* | 18:05 |
| bz-next | imo plugins would ideally be lua or python or something and the API in that case would be pretty airtight, and it'd be easier to write them | 18:06 |
| bz-next | but given that there's a critical mass of essential plugins, probably, the .so plugin thing will never go away | 18:06 |
| blast007 | we had lua in 2.99.x, but it was a custom fork of Lua that change some floats to doubles or something like that | 18:06 |
| bz-next | what makes me sad about C++ plugins is not only the difficulty of building them for plugin makers, but also how hard string manipulation is, given that it's usually the bulk of what they want to do | 18:07 |
| blast007 | tupone has worked on a Python implementation, and we also at one point had a python plugin for our C++ plugin API that could load Python code as plugins. | 18:07 |
| bz-next | "quick lemme unload and reload the pythonplugin.so since something went weird, one sec" | 18:08 |
| blast007 | I don't recall how that one even worked. I never tried it. | 18:08 |
| blast007 | one part of Lua I hate is that the arrays are 1-based instead of 0-based | 18:09 |
| bz-next | from what I've seen of Lua I don't like it at all but I do think it'd be more accessible at least. I do like python | 18:09 |
| bz-next | and lua has luajit which is nice | 18:09 |
| bz-next | I do think that plugins are so essential rn to the game that disrupting the plugin ecosystem would be disasterous though | 18:11 |
| bz-next | so pluginception is probably the way to support something accessible, lol | 18:11 |
| blast007 | plenty of other scripting languages to pick from too: http://www.squirrel-lang.org/ https://www.angelcode.com/angelscript/ https://chaiscript.com/ https://wren.io/ | 18:16 |
| bz-next | I unironically think BASIC wouldn't be so bad | 18:19 |
| blast007 | but specifically TI-BASIC from the TRS-80 ROM | 18:19 |
| bz-next | yes you gotta pick your flavor | 18:20 |
| blast007 | https://static.bzexcess.com/this_is_the_script_that_never_ends.mp4 | 18:21 |
| bz-next | think of all the apps that could be ported into plugins! | 18:22 |
| blast007 | bzfs -loadbasicplugin gorilla.bas | 18:22 |
| blast007 | https://www.howtogeek.com/779956/gorilla.bas-how-to-play-the-secret-ms-dos-game-from-your-childhood/ good times | 18:24 |
| blast007 | pretty sure I first ran that on a system with monochrome graphics, so I didn't know it had color until later | 18:24 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 18:39 | |
| bz-next | lol this debug output: | 18:50 |
| bz-next | Accept: */* | 18:50 |
| bz-next | If-Modified-Since: Thu, 01 Feb 4461534 12:34:56 GMT | 18:50 |
| bz-next | in a few million years it'll work... | 18:50 |
| blast007 | what request generated that? | 18:57 |
| *** Juest <Juest!~Juest@user/Juest> has joined #bzflag | 18:59 | |
| bz-next | I was trying to use cache manager to check for a new file, from scratch | 18:59 |
| bz-next | and accidentally sent an uninitialized time into cURLManager | 18:59 |
| blast007 | ah, I was gonna say, sounded like it grabbed some random memory :) | 19:00 |
| bz-next | I can load some html into an imgui window now on demand, so that's most of the work done for a map archive | 19:00 |
| bz-next | just need to integrate some yaml parser or something and make a map index | 19:01 |
| blast007 | JSON might be better for the data | 19:01 |
| bz-next | yeah perhaps. also the advantage that I've used json before, and never used yaml... | 19:01 |
| blast007 | YAML is better as a hand-written configuration or data file | 19:02 |
| bz-next | but yeah you could probably use this code to load and cache RmlUI stuff in the future | 19:02 |
| bz-next | You just make CachedResource("url string"), then call resource.fetch(), resource.is[Complete/InProgress/Error]() and getData() | 19:04 |
| bz-next | so it's a lot easier to fetch stuff | 19:04 |
| bz-next | And you can just be lazy and embed a CachedResource anywhere in the code | 19:05 |
| bz-next | and CacheManager supports https now :) | 19:06 |
| blast007 | looks like BZFlag since 2.4.10 will follow redirects (and since 2.4.4 we supported HTTPS with cURL), so I suppose I could forward the http:// URLs on images.bzflag.org to https:// | 19:16 |
| bz-next | currently I'm just having the texture downloader rewrite http URLs to https on emscripten only | 19:17 |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC (Ping timeout: 252 seconds) | 19:17 | |
| *** Juest <Juest!~Juest@user/Juest> has joined #bzflag | 19:25 | |
| bz-next | the ifdef HAVE_STD__ISNAN that redefines the string "isnan" to "std::isnan" and results in a bunch of errors for "std::std::isnan" depending on the order you include files... | 19:52 |
| bz-next | imo it's got to go | 19:53 |
| bz-next | with requiring a newer C++ standard it probably guarantees these things exist anyway | 19:54 |
| blast007 | yeah, we only check that in autoconf systems, so it's probably some holdover from compiliers on IRIX or Solaris, or other old gcc instances | 20:04 |
| blast007 | cleanup for that probably wouldn't happen in 2.4 though | 20:06 |
| bz-next | https://i.imgur.com/QnrMq5P.png this is probably good enough for a map archive, at least for now | 20:56 |
| bz-next | It reads JSON and it'll just fetch the map on click | 20:57 |
| bz-next | but it is hilariously ugly, so probably gonna try to clean it up a bit more | 21:00 |
| blast007 | "hilariously ugly" so it fits right in with ImGui? | 21:38 |
| * blast007 ducks | 21:38 | |
| bz-next | lmao | 21:49 |
| bz-next | honestly yes | 21:49 |
| bz-next | the code is equally ugly, just slinging weird callbacks around | 21:50 |
| bz-next | because who cares... it's an imgui widget :) | 21:51 |
| bz-next | but I did show a couple friends the UI, and the response is always that it's mildly confusing, I guess that's imgui for you | 21:52 |
| bz-next | developers: "WOW a GUI!!! that's so much better than nothing!" regular people: "what even am I supposed to do" | 21:53 |
| bz-next | well, you see, you click load and then browse to the file, then click open, then open the editor under the view menu, then click "update 3d view" duh | 21:55 |
| bz-next | at some point it's just easier to write a manual than it is to figure out a UI that people will actually find intuitive... | 21:58 |
| bz-next | Well you can now try it in browser at https://bz-next.github.io/mapviewer4/mapviewer.html | 22:21 |
| bz-next | once more maps are added I'll probably have to make the archive browser thing a bit nicer, but for now it works | 22:21 |
| *** FastLizard4 is back | 22:28 | |
| BulletCatcher | I approve of "Full of Dangers" as the release name for 2.4.28. | 23:46 |
| blast007 | lol | 23:48 |
| bz-next | it's actually a great name | 23:52 |
| blast007 | yeah | 23:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
