| *** bzfs-alchemy <bzfs-alchemy!~bzfs-alch@2607:fb90:79b3:9afc:ac39:be37:b2db:9373> has left #bzflag | 00:42 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@73.184.170.223> has joined #bzflag | 04:04 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 04:06 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 04:10 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@73.184.170.223> has quit IRC (Ping timeout: 268 seconds) | 04:13 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 04:15 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 04:18 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 04:36 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 04:38 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 272 seconds) | 05:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:33 | |
| BZNotify | bzflag: lars-vc synchronized pull request #340 "Lars addingsplit" (https://github.com/BZFlag-Dev/bzflag/pull/340) | 08:53 |
|---|---|---|
| *** FastLizard4 is back | 09:50 | |
| *** FastLizard4 is now away: AWAY from keyboard | 09:57 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has quit IRC (Quit: Leaving) | 11:41 | |
| *** bz-next <bz-next!~bz-next@user/bz-next> has joined #bzflag | 12:16 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:31 | |
| BZNotify | bzflag: lars-vc synchronized pull request #340 "Lars addingsplit" (https://github.com/BZFlag-Dev/bzflag/pull/340) | 13:13 |
| BZNotify | bzflag: bz-next commented on pull request #340 "Lars addingsplit" by lars-vc (https://github.com/BZFlag-Dev/bzflag/pull/340#issuecomment-1952433065): Is there some way to avoid having to call .val() on protected value... | 13:17 |
| bz-next | A general call to map makers: I'd like to make a repository of both classic and new maps, but some maps don't have license details included. If you have made BZFlag maps and are OK with maps being included, please respond here or at https://forums.bzflag.org/viewtopic.php?t=20737 | 13:28 |
| bz-next | Maps would be indexed and available via both the bz-next.github.io map viewer, as well as desktop builds of the bz-next project. | 13:29 |
| bz-next | License and attribution would be included for all maps. | 13:29 |
| blast007 | it'd be more useful if map authors went back to their old releases and included the license info there | 13:36 |
| blast007 | but a lot of them aren't active anymore | 13:36 |
| blast007 | also, as for that PR #340, that's not something that's gonna get merged | 13:37 |
| bz-next | anti-cheat with open source I think is just kinda hard | 13:40 |
| bz-next | One thing I was thinking would be some sort of reflective fingerprinting of clients, where a client computes the distance between some of its own symbols and stuff in the binary, and computes a hash or something. Then you could at least know if someone is running a dev client or modified client | 13:41 |
| bz-next | Could still be faked of course | 13:41 |
| blast007 | Their code is for protecting in-memory values. It's probably some academic project, and doing it on an open-source game lets them modify the code to test that method of proection. | 13:41 |
| *** L4m3r_ <L4m3r_!~L4m3r@user/L4m3r> has joined #bzflag | 13:42 | |
| bz-next | that makes sense. I guess someone could theoretically use one of those cheating apps to modify client variables | 13:42 |
| blast007 | the binary hash idea has been mentioned multiple times over the years, and it wouldn't work | 13:42 |
| blast007 | the client can just lie | 13:43 |
| bz-next | I guess anything that is done would just be kinda pointless obfuscation and make the code more complicated for little gain | 13:43 |
| blast007 | what needs to happen is for the server to have more knowledge and be cable of running the same calculations that the clients do, and be able to override the client's state | 13:44 |
| *** L4m3r <L4m3r!~L4m3r@user/L4m3r> has quit IRC (Ping timeout: 264 seconds) | 13:44 | |
| bz-next | What do you think of the idea of having servers collaborate to reduce lag by doing something peer-to-peer-y in the future? | 13:45 |
| bz-next | Do you think that would help all that much if it was possible? | 13:46 |
| blast007 | I don't think that would help except make things more complex | 13:46 |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (Ping timeout: 256 seconds) | 13:47 | |
| *** L4m3r_ <L4m3r_!~L4m3r@user/L4m3r> has quit IRC (Ping timeout: 260 seconds) | 13:48 | |
| bz-next | Maybe in a distant future where everyone has IPv6 and NAT isn't such an issue, clients could just have a peer to peer aspect to them, but that's just a dream rn | 13:49 |
| blast007 | instead of clients sending their position, velocity, and similar state, they could instead send their input states: https://www.gafferongames.com/post/deterministic_lockstep/ | 13:49 |
| blast007 | and then you'd have a shared library that the client and server use to calculate the state of the world based on those inputs | 13:49 |
| *** Agatha <Agatha!~agatha@user/agatha> has joined #bzflag | 13:50 | |
| blast007 | the game *used* to be partially peer-to-peer, but that also exposed everyone's IP, and then players were DoS'ed | 13:50 |
| bz-next | that is... ughh | 13:51 |
| blast007 | (I think the IP info was left in for a release of the game even after the peer-to-peer aspects were removed) | 13:51 |
| blast007 | major release* | 13:51 |
| *** TD-Linux <TD-Linux!~Thomas@user/td-linux> has quit IRC (Ping timeout: 246 seconds) | 13:52 | |
| *** ashvala <ashvala!~quassel@104.131.125.108> has quit IRC (Ping timeout: 260 seconds) | 13:52 | |
| *** ashvala <ashvala!~quassel@104.131.125.108> has joined #bzflag | 13:52 | |
| bz-next | having a shared physics between the game and the server sounds like it'd be a huge improvement in a lot of ways | 13:52 |
| blast007 | yeah | 13:53 |
| bz-next | it is a bit frustrating how little code the client and server share rn | 13:53 |
| blast007 | right now the server only keeps track of the last state and the current state it's comparing it against | 13:53 |
| bz-next | probably it'd go hand in hand with reducing the amount of global state | 13:53 |
| *** TD-Linux <TD-Linux!~Thomas@user/td-linux> has joined #bzflag | 13:53 | |
| blast007 | in 1.7, bzfs was mostly one big file | 13:53 |
| bz-next | A solid minimal refactor imo would take all the various managers and DBs and such and wrap them up in a game state class or something | 13:54 |
| bz-next | since it's non-trivial to manage the state of all those objects rn | 13:54 |
| *** dngor <dngor!abuse@104-136-128-209.biz.spectrum.com> has quit IRC (Ping timeout: 264 seconds) | 13:56 | |
| bz-next | there are already existing bugs during init of bzfs where NULL pointers to objects have member functions called on them during init | 13:56 |
| bz-next | because the state is just unweildly to manage | 13:56 |
| *** dngor <dngor!abuse@104-136-128-209.biz.spectrum.com> has joined #bzflag | 13:56 | |
| *** macsforme <macsforme!~macsforme@rahab.fairserve.net> has quit IRC (Ping timeout: 260 seconds) | 13:56 | |
| bz-next | I think after doing that it'd be a lot more manageable to rework state in general | 13:57 |
| *** Agatha_ <Agatha_!~agatha@50.109.254.246> has joined #bzflag | 13:58 | |
| *** macsforme <macsforme!~macsforme@rahab.fairserve.net> has joined #bzflag | 14:01 | |
| *** ChanServ sets mode: +v macsforme | 14:01 | |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (Ping timeout: 264 seconds) | 14:02 | |
| BZNotify | bzflag: lars-vc closed pull request #340 "Lars addingsplit" (https://github.com/BZFlag-Dev/bzflag/pull/340) | 14:31 |
| BZNotify | bzflag: lars-vc commented on pull request #340 (https://github.com/BZFlag-Dev/bzflag/pull/340#issuecomment-1952571076): Oh oops, I did not intend on this pr to be here. This was just for ... | 14:31 |
| *** FastLizard4 is back | 14:53 | |
| *** FastLizard4 is now away: AWAY from keyboard | 15:04 | |
| *** FastLizard4 is back | 15:11 | |
| bz-next | I am finding that building ImGui widgets that expose the state of the various resource managers in the game is really helpful for learning about how they work | 15:16 |
| bz-next | Eventually I'd like to use the ImGui docking branch and just make a nicer development UI with a default config that's not terrible | 15:18 |
| bz-next | Being able to see everything that's going on makes dev a lot easier | 15:18 |
| bz-next | I'd also like to render to a texture by default for everything, so that you can just have the 3D view be another window. There could be some cool stuff there, like being able to obs every player at once (panopticon mode) | 15:20 |
| bz-next | Because I envision deferred rendering as a necessary feature, it'd be necessary to do that kind of infrastructure anyway, and that could be really cool | 15:21 |
| bz-next | It could be a really cool admin client before it's even playable | 15:21 |
| *** FastLizard4 is now away: AWAY from keyboard | 15:31 | |
| *** L4m3r <L4m3r!~L4m3r@user/L4m3r> has joined #bzflag | 15:47 | |
| bz-next | There should be a BZDB editor / viewer too, that would be really handy | 16:10 |
| blast007 | bzadmin has one | 16:27 |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 16:30 | |
| bz-next | sweet, maybe that can be ripped | 16:32 |
| bz-next | I think a server message log in general could be useful too | 16:35 |
| bz-next | It'd be a good first step towards structuring messages a bit more in the code, have each message result in a message object and toss those into a notifier where a UI element can pick them up | 16:37 |
| bz-next | it could be done in parallel with the current stuff and then objects could be individually updated to use the notifier rather than being updated by the message parsing routine | 16:40 |
| bz-next | that way any new objects or UI would be able to be based on something more flexible, without breaking existing code | 16:41 |
| *** SpringTank <SpringTank!~quassel@99.65.58.146> has quit IRC (Ping timeout: 264 seconds) | 17:32 | |
| *** SpringTank <SpringTank!~quassel@99.65.58.146> has joined #bzflag | 17:32 | |
| Juest | nice | 18:09 |
| *** Agatha_ is now known as Agatha | 18:47 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 18:49 | |
| *** Juest <Juest!~Juest@user/Juest> has quit IRC (Ping timeout: 255 seconds) | 23:49 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!