| 00:47.33 | *** join/#bzflag spldart (d03653a1@bzflag/contributor/spldart) |
| 00:47.33 | *** mode/#bzflag [+v spldart] by ChanServ |
| 01:34.44 | *** join/#bzflag JPT (~jpt@mail.jpt.lu) |
| 04:24.16 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 04:39.25 | *** join/#bzflag Patlabor221 (uid48618@gateway/web/irccloud.com/x-ekwqrigvuishsvli) |
| 07:30.58 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 07:35.31 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 07:47.43 | *** part/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 07:58.52 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 08:34.57 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 09:50.48 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 10:05.02 | *** join/#bzflag noyb_ (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 11:56.47 | *** join/#bzflag Warrior (56b3c198@gateway/web/freenode/ip.86.179.193.152) |
| 11:57.29 | Warrior | any1 around for fm? |
| 12:01.35 | Warrior | apparently not |
| 12:11.56 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 14:50.02 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 15:00.29 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 15:35.02 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 16:01.30 | *** join/#bzflag Patlabor221 (~JeffM@2605:e000:7d02:c700:d9f2:6cdc:1e4a:2afe) |
| 16:57.57 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 17:42.46 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 18:12.33 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 18:31.33 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 18:35.50 | *** join/#bzflag khonkhortisan (~Khonkhort@2601:8:8600:9b0:4a5b:39ff:fe94:be23) |
| 19:02.17 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 19:52.12 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 20:01.18 | *** join/#bzflag tw1sted (~tw1sted@unaffiliated/tw1sted) |
| 20:35.04 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 21:16.33 | Foo_man_choo | !shockwave! |
| 21:16.53 | Foo_man_choo | so when did mines become part of the game? 8~P |
| 21:19.41 | Patlabor221 | They arn't, some servers use a plug-in to fake it |
| 21:19.49 | zlsa | it actually works pretty well, too |
| 21:20.32 | Patlabor221 | with lots of tweaks yeah they got it playable |
| 21:22.29 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 23:01.12 | *** join/#bzflag short_circuit (ac380ee8@gateway/web/freenode/ip.172.56.14.232) |
| 23:02.03 | short_circuit | Oh! ok... when was that added to server side operation?... Oh... and is there a counterflag for mines? |
| 23:04.52 | zlsa | it's a plugin |
| 23:04.58 | zlsa | counterflags are all client-side |
| 23:05.10 | zlsa | some server operators chose to use the mines plugin, some didn't |
| 23:05.20 | zlsa | it's not mandatory or part of the default server configuration |
| 23:16.36 | Patlabor221 | short_circuit, yeah it's NOT part of the core game, a plug-in just spawns world weapons |
| 23:17.40 | short_circuit | oh! I could have sworn it said (*me* is killed by so and so's mine) so I thought another tank/player left it. |
| 23:18.06 | short_circuit | anywho.... gotta reboot... my OS has lost nearly all it's fonts O_o |
| 23:18.33 | Patlabor221 | sure it SAID that, the plugins can craft those messages |
| 23:21.56 | Patlabor221 | I can make the server say you were killed by a fish :) |
| 23:22.18 | *** join/#bzflag short_circuit_ (ac380ee8@gateway/web/freenode/ip.172.56.14.232) |
| 23:23.29 | short_circuit | that's better |
| 23:23.37 | zlsa | it's possible to write a custom useless geno plugin that kills everyone on the opposite team _and_ have the death message be "bob was killed by so-and-so" |
| 23:23.40 | zlsa | ? |
| 23:24.24 | gnu-sense | *cough* probably. |
| 23:24.35 | alezakos | doesn't mofo do this with their genos |
| 23:24.37 | alezakos | ? |
| 23:25.49 | gnu-sense | both US mine and team flag geno are still buggy, however. |
| 23:26.27 | Patlabor221 | there is an event to edit the killed by message |
| 23:26.48 | gnu-sense | If I understand it correctly, the problems may not entirely be able to be fixed, because they come down to a disagreement between client and server on the game state, which can be affected by lag and lost packets. |
| 23:27.28 | Patlabor221 | yeah that's why I say it's almost working right, there would need to be more messages in the protocoll to give the client better info |
| 23:28.09 | gnu-sense | something like a game status update |
| 23:28.28 | Patlabor221 | it's more then that but yeah |
| 23:28.33 | Patlabor221 | more info about the state of shots |
| 23:28.40 | Patlabor221 | right now the client manages shots |
| 23:28.51 | Patlabor221 | and only accepts updates for some kinds |
| 23:29.03 | gnu-sense | gmupdate |
| 23:31.25 | gnu-sense | game recordings get a periodic big-honkin-message that has most of the game state (not shots) -- scores, server variables and such. Does that actually get sent out to the client or is it just a recorded game feature? |
| 23:31.57 | gnu-sense | maybe once per session? |
| 23:31.57 | Patlabor221 | that's a recording thing |
| 23:32.01 | Patlabor221 | recording is kinda a hack |
| 23:32.22 | gnu-sense | ikr. but a genious hack. |
| 23:32.42 | Patlabor221 | yes usualy to overide the state that the playback server was in |
| 23:32.52 | Patlabor221 | it's just a record of the raw packets |
| 23:32.58 | Patlabor221 | it's not very extensible |
| 23:33.10 | Patlabor221 | and the recordings get broken each proto change |
| 23:33.49 | gnu-sense | once could convert them. most of the incremental changes have not been so great |
| 23:33.59 | gnu-sense | the real prob is the crashing bug |
| 23:34.35 | Patlabor221 | sure someone could do a mapping, but then it isn't quite a recording :) |
| 23:34.44 | Patlabor221 | but it's not something we'll make a tool for |
| 23:34.52 | gnu-sense | should that hack eventually get moved plugin-side? |
| 23:34.55 | Patlabor221 | it'd be better not save packets but logical messages |
| 23:35.01 | Patlabor221 | what hack? |
| 23:35.10 | gnu-sense | recording/playback |
| 23:35.19 | Patlabor221 | that would be best |
| 23:35.33 | Patlabor221 | record messages, and then have playback spawn server side tanks |
| 23:35.43 | Patlabor221 | then it's not just spraying messages |
| 23:35.48 | Patlabor221 | but that will need shots on the server |
| 23:36.19 | Patlabor221 | bassicly record the player input, not the server's output |
| 23:36.38 | Patlabor221 | the server should be able to generate output from input at any time |
| 23:37.17 | gnu-sense | Interesting. One advantage I see is it would rip out a lot of freaky-looking hybrid C/C++ from the server |
| 23:37.39 | Patlabor221 | huh? |
| 23:37.42 | gnu-sense | the naming and other things seem not to be consistent with later code |
| 23:37.54 | Patlabor221 | sure that happens in any long project |
| 23:38.35 | Patlabor221 | but names arn't really a C or C++ thing |
| 23:38.46 | gnu-sense | well the types |
| 23:38.48 | Patlabor221 | C++ is a superset of C |
| 23:38.53 | Patlabor221 | still just names |
| 23:39.16 | gnu-sense | yeah, but it's confusing to have multiple names for the same kind of int |
| 23:39.30 | Patlabor221 | there is a style guide in devinfo |
| 23:39.34 | Patlabor221 | that's what it should follow |
| 23:41.05 | gnu-sense | I think there's also some inconsistency in terms of accessing packets via directly peeking at contents as opposed to a consistent OO approach |
| 23:41.27 | Patlabor221 | probably |
| 23:41.42 | Patlabor221 | who said bzflag was consistent? |
| 23:41.46 | Patlabor221 | it's a horrible code base |
| 23:42.51 | gnu-sense | would there be a general way in the plugin API to grab the client input messages like you're suggesting? |
| 23:43.11 | Patlabor221 | not in a consistent way |
| 23:43.25 | gnu-sense | it's a venerable 20-year old code base, isn't it? It's legal for it to be drinking. |
| 23:43.33 | Patlabor221 | we need server side state before we can do beter recording |
| 23:43.41 | gnu-sense | ic |
| 23:44.09 | Patlabor221 | then you get events about when the state is updated from the input and record those updates |
| 23:44.22 | Patlabor221 | then it's all in a protocol independent method |
| 23:44.38 | gnu-sense | rather than just accepting any kind of messages from the client |
| 23:44.52 | Patlabor221 | the message transport may change in any version |
| 23:44.56 | Patlabor221 | you don't want to tie to that |
| 23:45.04 | gnu-sense | good point |
| 23:45.19 | Patlabor221 | if/when we swap to raknet, the entire packet structure will change |
| 23:45.30 | Patlabor221 | it'll all be synced objects and RPC calls |
| 23:46.04 | Patlabor221 | the game should know how to play itself, the recording is just telling the game who moved where and when |
| 23:46.10 | Patlabor221 | not "they sent 14 bytes" |
| 23:46.23 | Patlabor221 | some players may not even have network connections |
| 23:46.23 | gnu-sense | yeah, that is kind of icky |
| 23:46.43 | Patlabor221 | server side players don't send network based input |
| 23:47.24 | gnu-sense | but getting server-side state is a big job. |
| 23:47.54 | Patlabor221 | yeah but it's what we need |
| 23:48.06 | gnu-sense | of course, the plugins like mines and geno-team flag kind of imply that, because they affect scoring |
| 23:48.09 | Patlabor221 | anything else is dressing up a pig |
| 23:48.19 | gnu-sense | true enough |
| 23:48.49 | Patlabor221 | better to swap to a system that alraedy has server side state |
| 23:58.39 | *** join/#bzflag Patlabor221_ (uid48618@gateway/web/irccloud.com/x-wotbsnpizvgrrudn) |
| 23:58.53 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |