| allejo | how freqeuntly are lag stats updated in bzfs? | 01:12 |
|---|---|---|
| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has joined #bzflag | 01:13 | |
| blast007 | every 10 seconds or so | 01:23 |
| blast007 | src/game/LagInfo.cxx's getNextPingSeqno controls that | 01:24 |
| SpringTank | shouldn't lag stats be updated every time the server initiates a clock sync with the clients? | 01:28 |
| SpringTank | or does bzflag not have a master clock like that? | 01:29 |
| JeffM[m] | There is no clock sync like that | 01:29 |
| SpringTank | :/ | 01:31 |
| SpringTank | there is no master clock system for syncing events? | 01:31 |
| JeffM[m] | There is no real lag compensation strategy in bzflag | 01:32 |
| SpringTank | not just for lag comp, but pretty much anything that needs to be synced accross clients and server. | 01:32 |
| SpringTank | so no master clock? | 01:32 |
| JeffM[m] | Just time of day for lighting and weather | 01:33 |
| SpringTank | :/ | 01:33 |
| JeffM[m] | Nothing with any real granularity | 01:33 |
| JeffM[m] | It’s a lan game at heart | 01:33 |
| SpringTank | i thought there was.. something like that in bzflag for stuff like rotating drawinfo, etc. | 01:33 |
| SpringTank | but yeah, that should be the next priority for 2.6 IMO | 01:34 |
| blast007 | draw info might have some time sync | 01:34 |
| SpringTank | hmmm | 01:34 |
| JeffM[m] | Redo the network sim? | 01:34 |
| blast007 | yeah, that ain't happening for 2.6 :) | 01:34 |
| SpringTank | no, just add a master clock system with sub ms precison | 01:34 |
| JeffM[m] | There is something for time in draw info but it’s odd iirc | 01:34 |
| OkinaMatara | IIRC, drawInfo isn't really kept in sync... that's why things like moving doors couldn't be made or something. | 01:35 |
| SpringTank | the usefull ness of such a system is nearly limitless | 01:35 |
| blast007 | yeah, it's not synced between clients, but I think there is some time sync, as in wall clock time | 01:35 |
| SpringTank | right | 01:36 |
| blast007 | there was an analog clock that trepan made that I think used that | 01:36 |
| SpringTank | I think i remember that. | 01:36 |
| SpringTank | Sooo many things such as lag comp can be fixed with a master time system with sub ms precision. | 01:37 |
| blast007 | we tried one lag comp system in 2.99.x | 01:37 |
| SpringTank | i remember you telling me about that | 01:37 |
| blast007 | that one at least made things worse since clients with high lag would get an advantage | 01:38 |
| SpringTank | and that's why clients with high lag should be kicked/autodisconnected. :D | 01:39 |
| JeffM[m] | Yeah it was crap, it’s author did not know what they were doing | 01:39 |
| blast007 | well, what I mean is that higher lag got an advantage over low lag | 01:39 |
| SpringTank | lol | 01:40 |
| SpringTank | i think I might work on a time keeping system like what I described for 2.5/2.6, weather or not it is used, and how it's used, is up to you guys. | 01:41 |
| SpringTank | i've already look into precision time keeping. it's a challange on non-realtime computers such as what is common everywhere... | 01:42 |
| SpringTank | I think SDL might support something like it | 01:42 |
| blast007 | what problem are you trying to solve? | 01:43 |
| SpringTank | pretty much any problem that requires clients/server to be synced in some way. Events can be then be marked with a time stamp so the client/server knows when it happens, and can do the math to figure out exactly where/when to put things such as players, shots, mabye doors in the future? You know, lag comp. | 01:45 |
| OkinaMatara | Hmm, actually less of lag compensation is needed... more of server state/awareness. | 01:46 |
| SpringTank | well... yeah. | 01:47 |
| blast007 | https://www.gafferongames.com/categories/networked-physics/ | 01:47 |
| SpringTank | ^ what blast said. | 01:48 |
| blast007 | This kind of thing really needs to be the focus of a major release. I feel that exceeds the scope of 2.6. | 01:49 |
| SpringTank | a time keeping system could be implemented but only used for a very limited number of unimportant but easy to implement things in 2.6 in order to test and refine it for use in the next major version which full utilizes it. | 01:54 |
| SpringTank | and sould make further implementations and fixes much easier. | 02:03 |
| SpringTank | but that's just my own opinion | 02:03 |
| SpringTank | all this time I thought bzflag had something like that already. | 02:03 |
| SpringTank | shows how much I know about how it works :D | 02:04 |
| JeffM[m] | yeah it just needs a pretty standard rollback system | 02:14 |
| OkinaMatara | This would also help deal with a lot of problematic cheats, maybe not preventing them, but detecting them in a timely manner. | 02:18 |
| JeffM[m] | yeah, that's why modern games do it that way | 02:18 |
| JeffM[m] | bzflag started as a lan game, anti-cheat was 'go smack the cheater on the back of the head' | 02:18 |
| SpringTank | lmao | 02:19 |
| JeffM[m] | it was never designed for internet play | 02:19 |
| OkinaMatara | lan == "what's lag". | 02:19 |
| SpringTank | well, it's a step in the right direction. a baby step, but a step no less. | 02:19 |
| JeffM[m] | yes, it has no real concept of lag from a gameplay standpoint | 02:20 |
| JeffM[m] | it needs a modern networking backend. | 02:20 |
| JeffM[m] | and yeah a game clock is part of that | 02:20 |
| SpringTank | I would think that a game clock is the most important part of that. | 02:21 |
| JeffM[m] | no, the state is, but the clock is needed | 02:21 |
| JeffM[m] | some kind of tick mechanism is needed | 02:21 |
| JeffM[m] | you could do it without a good clock, it'd just suck | 02:21 |
| SpringTank | having every event time stamped per ms, and having sub ms timing on at least the server end | 02:21 |
| JeffM[m] | but without state you are screwed | 02:21 |
| SpringTank | right | 02:21 |
| JeffM[m] | the problem is that a clock on it's own doesn't solve anything, and is the most trivial part of a new networking system to implement. | 02:22 |
| JeffM[m] | it could easily be added at the same time the clock data was needed/used. | 02:23 |
| JeffM[m] | the update packets allready have a timestamp field | 02:23 |
| SpringTank | what is the precison on those? | 02:23 |
| JeffM[m] | they arn't set to anything meaninful, so they don't have anh | 02:24 |
| SpringTank | :/ | 02:24 |
| JeffM[m] | it's just a field | 02:24 |
| JeffM[m] | and is ignored by gameplay | 02:24 |
| SpringTank | figures | 02:24 |
| OkinaMatara | The problem is the server is like "oh, look, seconds included, let me forget about it". | 02:24 |
| JeffM[m] | having a server tick and storing states would be a good place to start | 02:25 |
| SpringTank | the *problem* I see is that neither the client or server can tell when an event happened within about 1ms | 02:25 |
| OkinaMatara | What we don't have is something like "if tank movement not altered, if distance crossed is more than x, likely is cheat based on movement by x". | 02:25 |
| JeffM[m] | that would al least let the server API do more stuff | 02:25 |
| OkinaMatara | ^ | 02:25 |
| SpringTank | yeah | 02:26 |
| OkinaMatara | More customized aspects and possible flag subsets I'd imagine, eventual decoupling of various aspects, so we can give tanks flag aspects at will. | 02:27 |
| SpringTank | that's been discussed | 02:27 |
| SpringTank | i think it was going to be in 2.99 | 02:27 |
| JeffM[m] | multiple times :) | 02:27 |
| JeffM[m] | everything was going to be in 2.99 | 02:27 |
| JeffM[m] | 2.99 was going to cure cancer and feed the world | 02:28 |
| SpringTank | aaand it was a horrible mess of feature creep | 02:28 |
| SpringTank | :) | 02:28 |
| JeffM[m] | if only bzflag had a producer | 02:28 |
| SpringTank | or simply, a maintainer who gave a &%$ | 02:28 |
| OkinaMatara | (humor) no, it wasn't, it was wonderful, we just need to keep on putting money into it like the concorde and eventually 2.99 would have taken the lead in indie gaming. | 02:28 |
| SpringTank | lol | 02:29 |
| JeffM[m] | tim's non invlovlemnt has no effect on anything | 02:29 |
| SpringTank | lack of leadership | 02:29 |
| SpringTank | that's a maintainers job, isn't it? | 02:29 |
| JeffM[m] | there isn't anything that can't be done without him, other than maybe some DNS sguff | 02:29 |
| JeffM[m] | it can vbe | 02:29 |
| JeffM[m] | but others can lead too | 02:29 |
| SpringTank | it should be | 02:29 |
| SpringTank | but you're right | 02:30 |
| JeffM[m] | that would be what a producer does, keeps things on track | 02:30 |
| JeffM[m] | the focus on tim is misguided | 02:30 |
| JeffM[m] | he's just a copyright holder, blast is defacto maintainer | 02:30 |
| JeffM[m] | and he's doing what he can | 02:30 |
| SpringTank | true | 02:30 |
| JeffM[m] | he IS mainaining it | 02:30 |
| JeffM[m] | the fact that he doesn't hold copyright doesn't change anything | 02:30 |
| blast007 | right now clients send their current position speed. An alternative way is to send their input state and run the simulation of that state on both the client and server. | 02:30 |
| JeffM[m] | if he suddenly did, nothing would change for day to day in bzflag | 02:31 |
| SpringTank | what blast said; yeah i agree. | 02:32 |
| OkinaMatara | Hmm, going back to the networking, I wonder how much of rubber-banding would we have in BZ simulations, give around 20 clients on a ducati style map. | 02:32 |
| JeffM[m] | yeah, a traditional roolback system just sends client inputs. | 02:32 |
| blast007 | and the simulation could be decoupled from the simulation | 02:32 |
| JeffM[m] | it' all what quake does | 02:32 |
| SpringTank | it's what pretty much all modern games do | 02:33 |
| JeffM[m] | bzflag is just quake with bouncy rockets | 02:33 |
| JeffM[m] | from a networking perspective | 02:33 |
| SpringTank | lol | 02:33 |
| SpringTank | read my mind | 02:33 |
| OkinaMatara | I'm not entirely sure, (I haven't played quake, but have played another indie FPS), but one of the things is basically the speed of shots which throw things off to an extent... at least that was one thing I read about why lag compensation is tricky in BZ. | 02:35 |
| JeffM[m] | most FPSs have two kinds of shots | 02:36 |
| JeffM[m] | hitscan, and projectile | 02:36 |
| SpringTank | typiclly, in other games it's either hit scan or projectiles | 02:36 |
| SpringTank | yeah | 02:36 |
| JeffM[m] | a rocket in quiake is a projectile | 02:36 |
| SpringTank | L in bzflag is hitscan | 02:36 |
| JeffM[m] | all shots in bz are like rockets in other FPS | 02:36 |
| SpringTank | *should be* | 02:36 |
| JeffM[m] | yes, L would be hitscan | 02:37 |
| SpringTank | same with TH | 02:37 |
| JeffM[m] | everything else would be processed like a rocket/grenade in another FPS | 02:37 |
| JeffM[m] | it's all a VERY solved problem, it just needs an implementation | 02:38 |
| JeffM[m] | you just need a nice network state synced ECS with rollback | 02:40 |
| OkinaMatara | ^True. I suppose the only thing which becomes the key focus is the updated mechanics after this. | 02:42 |
| JeffM[m] | heh, then you run into the true problem of bzflag, defining what bzflag is ;) | 02:43 |
| SpringTank | ^ | 02:43 |
| blast007 | "tanks with 2.5D physics" | 02:44 |
| SpringTank | if it changes the mechanics in a way that can't be undone or emulated then it changes what bzflag is. | 02:44 |
| SpringTank | lol | 02:44 |
| OkinaMatara | lol | 02:44 |
| SpringTank | now it would be cool to have that as a game option... | 02:44 |
| OkinaMatara | (humor) nah, just make it 3rd person shooter. :p | 02:45 |
| blast007 | BZFlag XL had a third-person camera | 02:46 |
| JeffM[m] | there was an option for that, it changed gameplay since you could see behind you | 02:46 |
| SpringTank | other games have 3rd person view, some as an option. why not make it a server side option for different play styles. | 02:47 |
| blast007 | SpringTank: cuz we don't need to add 10 million options to the game | 02:47 |
| blast007 | I feel we already have too many | 02:47 |
| SpringTank | i like options... | 02:47 |
| OkinaMatara | Well in engineering, it's a compromise, so 2nd person shooter would solve it. (non-serious) | 02:48 |
| JeffM[m] | bzflag is not a game engine :) | 02:48 |
| OkinaMatara | ^ | 02:48 |
| blast007 | 3rd person mode would just show you the view from another player's perspective | 02:48 |
| JeffM[m] | second person is someone else describing the game, so text adventure mode | 02:49 |
| SpringTank | XD | 02:49 |
| blast007 | > look east | 02:49 |
| * OkinaMatara sees sun rise | 02:49 | |
| OkinaMatara | We must be in Japan. :p | 02:49 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 02:50 | |
| SpringTank | It's dark. Just the way grus like it. | 02:50 |
| OkinaMatara | https://www.youtube.com/watch?v=mC8QoRa8y_Q = This Is What a "Second-Person" Video Game Would Look Like | 02:51 |
| SpringTank | what version of SD does bzflag use? | 03:05 |
| SpringTank | SDL* | 03:05 |
| blast007 | by default we use SDL 2 | 03:11 |
| blast007 | I plan to remove SDL 1 support in master before we release 2.6 | 03:11 |
| SpringTank | cool, just making sure. | 03:12 |
| SpringTank | there some SDL2 features I was looking at | 03:12 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 05:05 | |
| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 05:10 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 06:12 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has quit IRC (Read error: Connection reset by peer) | 06:15 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 06:18 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has quit IRC (Read error: Connection reset by peer) | 08:05 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:27 | |
| *** nitroxis <nitroxis!n@nxs.re> has quit IRC (Quit: nitroxis) | 08:58 | |
| *** nitroxis <nitroxis!n@nxs.re> has joined #bzflag | 13:17 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 15:34 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 16:20 | |
| *** ellrinidhogg <ellrinidhogg!~ellrinidh@184.101.38.48> has joined #bzflag | 20:02 | |
| *** ellrinidhogg <ellrinidhogg!~ellrinidh@184.101.38.48> has quit IRC (Remote host closed the connection) | 20:03 | |
| Optic_Delusion | If you are looking for a set of custom sounds to replace the stock sounds I have a set that I got (i think) in 2005. They have the correct names and are ready to go in .wav format. You just swap out your sounds folder... Maybe they are still available on the BZBB forum, maybe they were removed because of copyright | 22:30 |
| Optic_Delusion | Star wars | 22:30 |
| Optic_Delusion | At one point Jeff had playhHistoryTracker plugin playing a custom sound *MU-AHAHAHA". I have a small collection of laughing sounds that would work with that. | 22:32 |
| Optic_Delusion | And I think at one point , devs had a warning sound playing when another player locked-on to you with GM. But that was removed, i think because it would play over and over when the player with GM wailed on the lock key. | 22:34 |
| Optic_Delusion | Origin date on the files are 11-27-07, just over 14 years ago. | 22:36 |
| Optic_Delusion | Legolas Originated them. https://forums.bzflag.org/viewtopic.php?f=62&t=6651&hilit=Star+Wars | 22:41 |
| blast007 | custom sounds in our repository or hosted on our resources site will need to be OSI licensed | 22:58 |
| Optic_Delusion | so contact me directly if you want them | 23:26 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!