| 00:02.46 | blast007 | it looks like it assumes that flags 0 through world->GetMaxFlags() - 1 are all a valid instance of Flag |
| 00:02.58 | blast007 | s/Get/get/ |
| 01:18.49 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:18.49 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 01:18.49 | *** mode/#bzflag [+v infobot] by ChanServ |
| 03:37.22 | JeffM | Wonder if I should just always allocate a ton of flags and then enable/disable as needed |
| 03:45.06 | JeffM | There was an issue with flooding the server with large flag counts during new player join wasnât there? |
| 05:40.21 | BulletCatcher | The server sends data about each flag to the client at join time. Too many flags flood the connection and especially Windows clients would choke. |
| 06:35.15 | BulletCatcher | https://www.atlasobscura.com/places/sierra-army-depot is where we store BZFlag tanks when they aren't being used. |
| 06:52.02 | JeffM | So if I forced a delay between packets would that help? |
| 06:52.29 | JeffM | For that initial update I mean not all packets |
| 07:01.12 | BulletCatcher | I don't recall the exact nature of the problem. It is possible that the server is too single-threaded and waits for the client to receive all of the data. If that is it, then delaying is less important than sending small chunks per frame. |
| 11:08.35 | *** join/#bzflag nitroxis (n@nxs.re) |
| 11:44.23 | blast007 | I think the problem was on the server end. It would send all the flag updates at once, which would exceed the send queue limit, so it would kick that client. |
| 11:45.09 | blast007 | So, I don't think it was Windows *clients*, but Windows *servers* that had more of an issue |
| 11:49.27 | blast007 | (or at least, Windows servers hit a limit sooner than others) |
| 12:35.11 | *** join/#bzflag nitroxis (n@2001:19f0:5001:e8b::1) |
| 12:46.24 | *** join/#bzflag nitroxis (n@2001:19f0:5001:e8b:5400:1ff:fe4e:791f) |
| 13:42.47 | *** join/#bzflag ZLSA_ (uid97184@gateway/web/irccloud.com/x-xrdamqdoaivqdlrz) |
| 14:31.55 | JeffM | ok, so if I have a seperate buffer for the outbound messages because it's all processed in a thread, it should be fine. |
| 14:32.31 | JeffM | I'm not relying on the raw TCP buffers |
| 14:35.43 | JeffM | the server can't know how many messages the client gets in one frame. |
| 15:14.04 | JeffM | ok, so I can treat flags as a map, with IDs from 0 to max flags. just setting inactive flags inactive. |
| 15:14.54 | JeffM | next proto break I recommend, making the client dynamically allocate flag IDs in a map, and then not requiring the server owner to figure out the max flags. Would let plugins add/remove flags as needed with out needing to care about an upper limit. |
| 17:10.35 | JeffM | preGetWorld on the client preallocates all the flags and sets them to not exist. That means on the server I should be able to keep a map, adding and deleting flags as needed, just sending an update with the appropriate state when they are changed. I just have to make sure that I never allocate more than MaxFlags. |
| 17:11.26 | JeffM | so I'm thinking that no mater what I always send at least 200 for the flag count to the client, that way there will be "room" for plugins to add flags as needed. |
| 17:11.34 | JeffM | thoughts? |
| 18:08.39 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 18:08.39 | *** mode/#bzflag [+o ChanServ] by weber.freenode.net |
| 18:14.59 | blast007 | JeffM: you'd have to send that many flags, not just a count |
| 18:15.26 | JeffM | you sure about that |
| 18:15.46 | JeffM | void WorldBuilder::preGetWorld() preallocates them |
| 18:15.52 | JeffM | that's not tied to the flag update |
| 18:16.06 | JeffM | they get set to FlagNoExist, so they won't draw or do anything |
| 18:16.10 | blast007 | ah, then maybe not |
| 18:16.21 | JeffM | basicly all I have to do is send the active falgs |
| 18:16.23 | JeffM | flags |
| 18:16.42 | JeffM | and when is "removed", I send an update that sets the state back to FlagNoExist |
| 18:17.04 | JeffM | that's my thought process at least |
| 18:17.18 | blast007 | you'd probably want to define a specific amount of "plugin flags" so that it's consistent |
| 18:17.29 | JeffM | possibly |
| 18:17.45 | JeffM | or ask them how many they each expext to create |
| 18:17.47 | JeffM | and total them up |
| 19:01.19 | *** join/#bzflag infobot (ibot@rikers.org) |
| 19:01.19 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 19:01.20 | *** mode/#bzflag [+v infobot] by ChanServ |
| 19:07.40 | *** join/#bzflag infobot (ibot@208.53.50.138) |
| 19:07.40 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 19:07.40 | *** mode/#bzflag [+v infobot] by ChanServ |
| 19:30.23 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-chnagwobkzcdugdo) |
| 19:35.21 | JeffM | heh, the protocoll seems to support 65535 teams, but only 200 players :) |
| 19:43.17 | blast007 | heh |
| 20:12.37 | the_map | you going to give all those teams a color? |
| 22:00.41 | JeffM | sadly the client will probably crash if you send it a team higher than it knows about |
| 22:00.59 | JeffM | but team IDs are written with 16 bits... |
| 22:03.27 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-lxwgzgccfhffygpf) |
| 22:03.27 | BZnotify | [13bzflag] 15allejo closed pull request #95: C++ Defect Report Core Issue 1344. (062.4...062.4) 02https://git.io/vboQY |
| 22:03.27 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-lxwgzgccfhffygpf) |
| 23:26.29 | *** join/#bzflag ZLSA_ (uid97184@gateway/web/irccloud.com/x-vnrantgmoovxcbgc) |
| 23:46.40 | macsforme | we should make a list of things we want to do at the next protocol break so we can add to it as we think of them so they don't get overlooked when we get to that point |