| 00:13.39 | *** join/#bzflag rob1n_ (~rob1n@unaffiliated/rob1n) |
| 00:41.16 | *** join/#bzflag noyb (~noyb@66.15.119.25) |
| 01:40.15 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 03:02.34 | *** join/#bzflag AnxiousGarlic (~Spider@130.225.244.206) |
| 03:02.35 | *** part/#bzflag AnxiousGarlic (~Spider@130.225.244.206) |
| 03:49.30 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 05:22.47 | *** join/#bzflag the (48d0b1c2@gateway/web/freenode/ip.72.208.177.194) |
| 05:24.15 | *** join/#bzflag the_map (48d0b1c2@gateway/web/freenode/ip.72.208.177.194) |
| 05:26.01 | *** part/#bzflag the_map (48d0b1c2@gateway/web/freenode/ip.72.208.177.194) |
| 05:26.45 | *** join/#bzflag the_map (48d0b1c2@gateway/web/freenode/ip.72.208.177.194) |
| 05:30.17 | *** part/#bzflag the_map (48d0b1c2@gateway/web/freenode/ip.72.208.177.194) |
| 05:30.48 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 05:49.52 | *** join/#bzflag asinck (~asinck@ip72-208-177-194.ph.ph.cox.net) |
| 05:50.25 | *** part/#bzflag asinck (~asinck@ip72-208-177-194.ph.ph.cox.net) |
| 08:12.56 | allejo | was the ability to overload built in slash commands purposely removed in 2.4 (as this was possible in 2.0) or was it a mistake? |
| 08:13.16 | allejo | i.e. via the plug-in API |
| 10:31.49 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:31.52 | *** join/#bzflag death__ (~I_Died_On@c-71-226-67-5.hsd1.ga.comcast.net) |
| 11:03.34 | *** join/#bzflag I_Died_Once (~I_Died_On@c-71-226-67-5.hsd1.ga.comcast.net) |
| 11:03.36 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 11:05.27 | Notify | 03BZFlag:173.192.81.187 * 8853 /World_units: |
| 11:10.58 | Notify | 03BZFlag:Blast * 0 /User:173.192.81.187: Spamming links to external sites |
| 11:11.16 | Notify | 03BZFlag:Blast * 8854 /World_units: Reverted edits by [[Special:Contributions/173.192.81.187|173.192.81.187]] ([[User talk:173.192.81.187|talk]]) to last revision by [[User:Yrogirg|Yrogirg]] |
| 14:41.04 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 15:42.37 | BulletCatcher | allejo, I see no obvious change in how parseServerCommand() works between v2.0.16 and 2.4. |
| 15:43.39 | BulletCatcher | bz_eSlashCommandEvent is still called before ServerCommand::execute(). |
| 15:46.46 | blast007 | how would you prevent the built-in command from executing? looks like it would still execute in both 2.0 and 2.4 |
| 15:47.49 | BulletCatcher | He did say "overload" and not "replace". |
| 15:48.28 | blast007 | generally when I think of "overload" I'd think of something where you wouldn't want both versions to still run, but instead run one with new options |
| 15:48.43 | blast007 | like a new /ban type |
| 15:49.14 | blast007 | (for instance, adding support for CIDR bans via a plugin while still using the normal /ban command) |
| 15:52.05 | BulletCatcher | Regardless of what it is called, it seems to me that the code works the same. |
| 15:52.13 | blast007 | yep |
| 15:52.58 | BulletCatcher | git diff v2.0.16 v2_4_x -- src/bzfs/commands.cxx |
| 15:53.26 | blast007 | anyone have any idea how difficult it would be to add grid layout support to our existing HUDui dialog system? |
| 15:54.41 | blast007 | tried creating an application from scratch using that Turbo Badger library, but that was a bit beyond my skill level.. some part of it don't yet have built-in implementation (like some function for handling timing) and thus their demo implements it with the help of GLFW |
| 15:55.00 | blast007 | there's also no documentation for Turbo Badger, and the API isn't yet stable |
| 15:55.19 | blast007 | thus, might be a bit early to use that.. |
| 15:56.12 | blast007 | (we'd probably have to maintain our own fork of it as well with the demo stuff ripped out) |
| 15:58.12 | BulletCatcher | It's easier to maintain a fork with Git than with Subversion, so that wouldn't be too awful if that's what we choose to do. |
| 15:58.25 | blast007 | yeah |
| 15:59.37 | BulletCatcher | If I understand what you mean, you would need a language for specifying grid coordinates, and some convention that accomodates different screen sizes. |
| 16:00.29 | BulletCatcher | It doesn't seem like it would be very hard to implement a specific design. |
| 16:02.02 | blast007 | this sort of thing: http://forums.bzflag.org/viewtopic.php?f=2&t=18957 |
| 16:06.53 | BulletCatcher | Yup. The hard part will be the design. |
| 16:06.54 | BulletCatcher | Are coordinates absolute or relative? Percentage of screen size or pixel counts? |
| 16:22.10 | blast007 | the hard part is the fact that we also need it to be flexible enough that we're not hard-coding the layout on the client but instead sending the layout from the server |
| 16:22.22 | blast007 | (or maybe I should say "the even harder part") ;) |
| 16:30.46 | blast007 | but as for the size, I dunno.. do we care about "HiDPI" screens? I'm thinking we should.. So scaling it to fill the screen well would be ideal. |
| 16:33.12 | blast007 | I'd want it to be a "flexible" grid of items that would adjust size and scale based on screen space and contents |
| 16:45.53 | BulletCatcher | There are already a variety of tools that manage rectangular windows on screens. |
| 16:45.55 | BulletCatcher | I recommend incorporating ideas from one or more of these so-called "window managers." |
| 16:47.01 | BulletCatcher | Furthermore, there is a well-established system for rendering text in rectangles. |
| 16:47.40 | BulletCatcher | That system even includes a client/server model. |
| 16:49.25 | BulletCatcher | Are we ready to include a web browser within BZFlag? |
| 16:51.11 | Patlabor221 | you don't mean browser, you mean HTML renderer |
| 16:51.18 | Patlabor221 | they are not the same thing |
| 16:51.19 | blast007 | I've considered it, but no, I think that's a bad idea |
| 16:51.36 | Patlabor221 | blast007: you should look into the concept of Anchors |
| 16:51.48 | blast007 | Patlabor221: it would be more than an HTML renderer - it would be a web browser engine |
| 16:51.51 | Patlabor221 | .net forms and Unity both use them, they work well for variable resolution displays |
| 16:52.02 | BulletCatcher | Once we have an HTML rendering system, it is only a small step to let it render arbitrary URLs. |
| 16:52.16 | Patlabor221 | at that point just redo the game in HTML5 |
| 16:52.23 | blast007 | and execute arbitrary code... |
| 16:52.41 | blast007 | there's enough of an attack surface in what we already have |
| 16:54.56 | BulletCatcher | It is a slippery slope from dialog boxes to web browser. |
| 16:54.57 | BulletCatcher | We'll have to be careful about not sliding too far. |
| 16:56.09 | blast007 | at this point I'd prefer it to be a game-protocol implementation since we're not even sure if we'll be keeping the HTTP API as it is right now |
| 16:58.13 | BulletCatcher | Using existing web browser technology would be a reason to keep and even enhance the HTTP API. |
| 16:59.35 | BulletCatcher | Or maybe we just rewrite bzfs as mod_bzfs for Apache. (only semi-kidding) |
| 17:04.27 | BulletCatcher | The only thing that is new about the dialog box idea is integrating it with BZFlag. |
| 17:04.28 | BulletCatcher | We might as well avoid reinventing too many wheels and reuse an existing framework for that. |
| 17:09.40 | blast007 | I'd still not want to integrate a web browser |
| 17:10.40 | blast007 | sounds great in theory, but I feel it wouldn't work as well as you're expecting in practice.. |
| 17:11.47 | blast007 | bugs like "The menu doesn't render correctly with the version of webkit in Debian X but looks right with the webkit in Debian Y" would probably be a thing :P |
| 17:12.29 | blast007 | and then there's no vertical centering in CSS unless you use tables |
| 17:12.48 | BulletCatcher | Yeah. |
| 17:12.50 | BulletCatcher | To avoid having to directly support HTML We could use BBcode as the markup language between server and client, for example. |
| 17:13.00 | blast007 | that's even worse... |
| 17:13.34 | BulletCatcher | There *will* be a markup language. |
| 17:13.43 | blast007 | not necessarily |
| 17:13.58 | blast007 | unless you count a binary interpretation as a markup language |
| 17:14.31 | BulletCatcher | A language implemented in binary is still a language. |
| 17:15.06 | blast007 | but not a markup language |
| 17:15.31 | BulletCatcher | I suppose not. |
| 17:15.51 | *** part/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-bagdfnjczrskpiow) |
| 17:16.14 | blast007 | I'd be fine with it being an object oriented system on both ends with layout and container classes |
| 17:17.55 | BulletCatcher | It just seems to me to be a lot of unnecessary work to invent our own text formatting language. |
| 17:18.31 | BulletCatcher | Unless, of course, that's the actual goal. |
| 17:21.18 | blast007 | I've had some experience with the web browser engine embedded in Valve games (specifically Left 4 Dead) and it wasn't all that plesent.. something as simple as this page wouldn't render right unless I initially hit content and then made it visible once the page loaded. http://bzexcess.com/l4d2_servermessage/ |
| 17:21.52 | blast007 | hid* |
| 17:22.06 | *** join/#bzflag the_map (~asinck@ip72-208-177-194.ph.ph.cox.net) |
| 17:22.51 | blast007 | a web engine bring far too much complexity and is a huge source of bugs and glitches, not to mention bloat |
| 17:25.49 | BulletCatcher | How much complexity do we need for BZFlag? |
| 17:25.50 | BulletCatcher | Is there an existing system that provides something close to that? |
| 17:26.22 | blast007 | Turbo Badger might be enough, really, but again, it's a new-ish library |
| 17:26.45 | blast007 | CEGUI is a dependency nightmare |
| 17:29.10 | blast007 | a lot of open source UI systems are pretty bad though |
| 17:30.00 | BulletCatcher | I suspect that ours would be no exception if we were to write it from scratch. :-) |
| 17:30.08 | blast007 | plus, our requirements are a bit higher than some games.. UTF-8 support, keyboard, mouse, and gamepad support (the latter of which we could probably emulate as keyboard if necessary), fancy layouts |
| 17:31.02 | blast007 | well, our UI system is already better for our use than some of the open source alternatives since it ties in with the game already ;) |
| 17:31.39 | BulletCatcher | Yeah, but now you want to enhance it. :-p |
| 17:33.09 | blast007 | CEGUI, for instance, does it's own resource management (iirc) and because of that has a lot of dependencies: https://bitbucket.org/cegui/cegui-dependencies/src/051a02c23494badfdf61ff02e3a694ac4e2fc1eb/src/?at=default |
| 17:33.12 | BulletCatcher | Having looked at https://github.com/fruxo/turbobadger now, I can see that it is, indeed, the sort of thing we might be interested in using. |
| 17:37.24 | *** join/#bzflag infobot (ibot@rikers.org) |
| 17:37.24 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/PI9KFD |
| 17:37.24 | *** mode/#bzflag [+v infobot] by ChanServ |
| 17:38.22 | blast007 | yeah, I think Turbo Badger might be worth giving a try. I started modifying the demo application this morning instead of trying to make an app from scratch. Going to see if I can replicate some of our menus and get them to be navigatable with the arrow keys (the normal navigation is more like desktop dialog systems where tab moves to the next item) |
| 17:40.16 | *** join/#bzflag infobot (ibot@rikers.org) |
| 17:40.16 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version http://goo.gl/PI9KFD |
| 17:40.17 | *** mode/#bzflag [+v infobot] by ChanServ |
| 17:41.38 | blast007 | another reason against a web browser engine based system is that I'd want the server to be able to easily push out changes to the dialolgs (such as pushing out current player counts on the team selection dialog) |
| 17:42.02 | blast007 | with web stuff you generally have the client poll periodically or do a long poll to emulate a push |
| 18:38.36 | *** join/#bzflag unclelightning (~chatzilla@pool-64-222-254-157.port.east.myfairpoint.net) |
| 18:39.44 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 20:10.00 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 20:26.53 | *** join/#bzflag timvisher (~tim.vishe@pool-72-92-23-217.phlapa.fios.verizon.net) |
| 20:34.11 | *** join/#bzflag timvisher (~tim.vishe@pool-72-92-23-217.phlapa.fios.verizon.net) |
| 20:39.49 | *** join/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-bagdfnjczrskpiow) |
| 20:39.49 | *** mode/#bzflag [+v Patlabor221] by ChanServ |
| 20:52.46 | *** join/#bzflag timvisher (~tim.vishe@pool-72-92-23-217.phlapa.fios.verizon.net) |
| 23:25.37 | allejo | BulletCatcher, hmmm... Did anything change is bz_CustomSlashCommandHandler? I remember before you could do what blast007 said and make a new command replace a built-in one |
| 23:26.32 | allejo | I think I remember seeing a plugin replace /register or /ghost (I think?) and this wasn't down through the command event iirc |
| 23:34.40 | blast007 | I didn't think that ever worked |
| 23:34.52 | blast007 | or at least it doesn't look like it could have in the latest 2.0 |
| 23:39.28 | allejo | hmm would it be accepted if that were implemented? |
| 23:39.56 | allejo | Imma try out 2.0. I swear I saw it working at one point :x |
| 23:40.13 | blast007 | it's something that would need more discussion |
| 23:41.30 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 23:44.04 | allejo | mkay |