| 00:07.44 | JeffM | got flag grab/drop mostly working, drops don't fly in the air, but they work, they just pop to the ground after the drop time. |
| 00:15.58 | *** join/#bzflag anakoluda_ (uid273324@gateway/web/irccloud.com/x-suppjhjvpyvuvvyb) |
| 00:47.01 | L4m3r | blinks |
| 00:47.10 | L4m3r | wow, people remember that map? |
| 00:48.38 | L4m3r | and yes, macsforme had it right, unfortunately it would fall on its face if there weren't a bunch of players in it, so it only worked for short periods of hosting |
| 00:51.47 | L4m3r | I think I had a plugin handing out flags on spawn to speed it up |
| 00:56.00 | JeffM | do some maps require specific plugins? |
| 00:56.42 | L4m3r | that plugin was written specifically for the map |
| 00:57.06 | JeffM | I mean in general |
| 00:57.28 | L4m3r | You could probably play without it, but all the superflags would be stuck on a platform in the sky someplace :) |
| 00:58.00 | JeffM | was that before zones? |
| 00:58.34 | L4m3r | I think it used zones to control flag spawns |
| 00:58.56 | L4m3r | <PROTECTED> |
| 01:01.23 | allejo | jeffm, sure maps like KOTH or AHOD require plugins to function |
| 01:01.45 | JeffM | I'm thinking should the map block have a section for "required plugins" |
| 01:02.12 | JeffM | and they will error out if they aren't loaded when the map is loaded. |
| 01:04.13 | JeffM | soon I'm going to have to start doing map stuff |
| 01:04.33 | Delusional | going back a day, when macsforme asked about the _flagheight variable.. for me it works like this⦠flags spawn in the air and then drop to the floor/object⦠if you want flags to be available in a spot with a low ceiling, you have to set _flagHeight very low. |
| 01:05.35 | JeffM | it looks like if there is not flag height clearance above the tank, then it'll treat it like there is no room. |
| 01:06.02 | JeffM | probalby height + altitude. |
| 01:06.20 | JeffM | since everything is measured from the base of the flag. |
| 01:07.39 | Delusional | you can see them dropping when they spawn right in front of you⦠it looks like they spawn low, then suddenly jump to a higher level, then drop slowly |
| 01:08.03 | JeffM | yeah the inital velocity computation is not great |
| 01:08.15 | JeffM | a bunch of that is controlled by the server thankfully |
| 01:08.20 | JeffM | I think it needs to be smarter |
| 01:11.14 | Delusional | if you set _flagHeight above say 20, it makes it a lot harder to track flag respawns |
| 01:11.26 | Delusional | on radar |
| 01:12.09 | JeffM | well I allow a plug-in to override the entire flag spawn path if it wants to, so you could do all kinds of custom stuff. |
| 01:12.48 | Delusional | and zapping flags to players will be much welcomed |
| 01:13.04 | JeffM | you mean just transfering them from the world to a player? |
| 01:13.30 | Delusional | i dont care what mechanism it uses, as long as it works reliably |
| 01:13.36 | JeffM | public bool GrantFlag(ServerPlayer player, FlagInstance flag) |
| 01:13.55 | JeffM | that's how pickups work, it's triggered by the client, but it cold be triggered by anything |
| 01:14.20 | L4m3r | the plug-in analog of /flag give worked pretty well the last time I used it |
| 01:14.22 | JeffM | you want to give someone a flag on the field, DropFlag(player); GrantFlat(player,flag); done |
| 01:14.51 | L4m3r | though there was the odd quirk in which the player would immediately drop the flag |
| 01:15.13 | Delusional | L4m3r: it works great until thereâs lag or worse (lost packets) |
| 01:15.24 | JeffM | should not be an issue with this server codebase. |
| 01:18.48 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:18.48 | *** 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.48 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:19.18 | L4m3r | Is death still on the client? |
| 01:19.19 | JeffM | Delusional: I've got support for that, but the client will auto-drop the flag. I can regrant it. |
| 01:19.22 | JeffM | yeah |
| 01:19.37 | JeffM | L4m3r: all flags are sent as PZ |
| 01:19.48 | JeffM | I even have a mode where every pickup is randomized :) |
| 01:19.55 | L4m3r | nice |
| 01:20.17 | Delusional | hmm⦠if itâs fast enough, could do a âfive second invulnerableâ |
| 01:20.19 | JeffM | the only time the real flag type is used is on the grant update. |
| 01:21.05 | JeffM | due to lag, the client realy needs to know about shield drop when it gets hit, the next shot may hit before a lag cycle. |
| 01:21.30 | L4m3r | but I didn't mean ID cheating, but rather that when someone's holding a flag and dies, they'll watch radar to see where it respawns |
| 01:21.41 | JeffM | I would like to transmit shot limits and hit immunities to the client on pickup |
| 01:21.41 | L4m3r | and then go grab it again |
| 01:22.02 | JeffM | L4m3r: it doesn't have to be that flag, I have an event for every pickup, it can be changed. |
| 01:22.08 | JeffM | that's why I mean by randomized grabs |
| 01:22.13 | L4m3r | yeah |
| 01:22.18 | JeffM | the flag type isn't selected untill pickup |
| 01:22.54 | L4m3r | could be a lot of interesting applications for that |
| 01:23.23 | JeffM | my standard ruleset doesn't do it, but it could be made an option |
| 01:23.56 | L4m3r | override it to give flags in a specific order |
| 01:24.11 | Delusional | progressive mode |
| 01:24.14 | JeffM | whatever you wanted, it's just a delegate. |
| 01:24.22 | L4m3r | or make every third grab a bad flag >:D |
| 01:25.00 | JeffM | ServerInstance.State.Flags.OnGrantFlag = MyFlagRandomizer |
| 01:25.23 | L4m3r | nice |
| 01:25.47 | JeffM | and your given the player and the flag instance to mess with |
| 01:26.11 | Delusional | could be used with -handicap |
| 01:26.30 | JeffM | I was going to not bother with handicap |
| 01:26.35 | JeffM | let a plug-in do it |
| 01:26.41 | L4m3r | agreed |
| 01:26.52 | JeffM | like I didn't even bother with solo bots |
| 01:26.57 | JeffM | server rejects them |
| 01:27.20 | echelon | i don't get it, the map actually stops working if there aren't enough players? |
| 01:27.34 | L4m3r | no, it just gets boring and everyone bails |
| 01:27.39 | JeffM | it becomes non-fun |
| 01:28.03 | Delusional | almost NEEDED two players per team |
| 01:28.06 | JeffM | BZFlag's main product is fun, so when it is non-fun it isn't doing it's primary job anymore. |
| 01:28.54 | L4m3r | basically, if most of the bzflag players online at a given time were all in the one server, it was a blast |
| 01:29.01 | L4m3r | otherwise it was meh |
| 01:30.55 | Delusional | fun with low player count (i think) i the main success of apocalypse⦠with good players it can be almost compelling at only 2 on 2 |
| 01:31.30 | Delusional | itâs gotta be at least half decent with low player counts nowadays |
| 01:33.02 | echelon | well, pillbox is no fun without more than two players per team |
| 01:33.24 | echelon | isn't it kind of subjcetive |
| 01:33.49 | echelon | L4m3r: are you just reluctant to host the server, or not upload the files? |
| 01:34.36 | L4m3r | I'd have to find the files first, and update the plugin(s) |
| 01:35.04 | echelon | well, if it's going to be a scavenger hunt to find the files, can i offer a bounty? |
| 01:36.32 | Delusional | I gace it |
| 01:36.39 | Delusional | err, I have it |
| 01:36.50 | echelon | how do you have it |
| 01:36.51 | L4m3r | how much of it? |
| 01:37.21 | L4m3r | Compound is/was mofo-affiliated and run from whatever server we were using then |
| 01:37.45 | echelon | what does that entail |
| 01:37.47 | echelon | oh |
| 01:37.53 | echelon | that's why Delusional has it you mean |
| 01:38.25 | Delusional | i have everything, even the server logs and reports dated july 26, 2008 |
| 01:38.30 | Delusional | plugin too |
| 01:38.35 | echelon | cool :) |
| 01:38.56 | L4m3r | yeah but what version was it? weren't we on 2.0.x still? |
| 01:41.02 | Delusional | i donât know that, i do have the helpfiles⦠donât seem to have the superstealth plugin |
| 01:43.20 | Delusional | yes i do have superstealth |
| 01:43.44 | L4m3r | ooh yeah I remember that one! ha |
| 01:44.32 | L4m3r | another reason I really liked randomly-assigned flags was that some could be "turned up" without unbalancing the game... like stealth |
| 01:48.01 | JeffM | I just made the default behavor not replace flags that don't just drop untill the flag count gets below the minimum number, and new ones respawn. |
| 01:48.07 | JeffM | not the same ones. |
| 01:49.02 | JeffM | so you say I want a min of 10 flags and a max of 20. each cycle it picks a random number between those two and then spawns untill there are that many |
| 01:49.24 | JeffM | when a flag disappears, it checks to see if the count is below the min, and if so starts another cycle with another random count. |
| 01:56.04 | JeffM | well that should get me to my milestone "Flag Playable" |
| 01:58.01 | JeffM | just don't run the server on a raspberry PI :) |
| 02:01.51 | L4m3r | is that a challenge? ;) |
| 02:07.39 | JeffM | this server codebase makes heavy use of threads. |
| 02:07.45 | JeffM | the pi does not like that |
| 02:09.00 | JeffM | well crap.. my server is actually running on the internet and hasn't crashed yet.. what the fudge? |
| 02:09.57 | JeffM | and it's even running on linux |
| 02:14.25 | JeffM | blast007 tried to run it on a Pi under windows 10, but it doesn't have the right version of .net. |
| 02:14.43 | JeffM | it ran under linux with mono but was hella slow for him |
| 02:17.40 | blast007 | I should try it again with clients on separate systems |
| 02:17.51 | JeffM | oh god! |
| 02:18.03 | blast007 | could have just been because the client running autopilot was minimized |
| 02:18.21 | JeffM | I was reading, the PI does not do threads very efficiently |
| 02:18.22 | blast007 | oh, if you're thinking I meant I was running the client on the pi, that's not what I meant |
| 02:18.30 | JeffM | oh ok, good |
| 02:18.34 | JeffM | yeah it's probalby threads. |
| 02:18.44 | blast007 | CPU load was only around 37% |
| 02:18.46 | JeffM | I run multiple clients and didn't see the issues you had |
| 02:18.53 | JeffM | yeah it's not CPU, it's cache |
| 02:19.02 | JeffM | the cache gets flushed all the time and the CPU waits for it. |
| 02:19.13 | blast007 | ah |
| 02:19.44 | JeffM | all those reasons why the PI isn't vulnerable to Meltdown and Specter... make for slow thread swaping |
| 02:20.20 | JeffM | I was thinking about it more. If the pi was a target it would only take a few code changes. |
| 02:20.53 | JeffM | add options to limit how often the loops run and then just call the worker functions from the same thread instead of a bunch of threads. |
| 02:21.01 | JeffM | the overall code structure could stay the same. |
| 02:21.40 | JeffM | I may need to do that for regular use too, it may allocate too many threads for regular machines as player counts increase. |
| 02:25.05 | JeffM | gotta do GM lock, identify, and theif now. |
| 02:27.51 | L4m3r | first session in years, and my aim still stinks! |
| 02:41.32 | JeffM | once again, for the brave at heart. https://github.com/JeffM2501/LibBZFlag/releases/tag/2.4.99.2a_testing_build |
| 04:02.13 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 04:03.28 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 04:07.20 | *** join/#bzflag dngor (abuse@p3m/dngor) |
| 07:24.22 | *** join/#bzflag DTRemenak (~DTRemenak@cpe-172-112-10-183.socal.res.rr.com) |
| 07:24.22 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 07:24.22 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 07:26.40 | *** join/#bzflag infobot (ibot@rikers.org) |
| 07:26.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 |
| 07:26.40 | *** mode/#bzflag [+v infobot] by ChanServ |
| 08:42.00 | echelon | should you kick someone that pauses every time they become rabbit? |
| 10:27.58 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 11:25.35 | *** join/#bzflag galileo_ (~quassel@d216-108-171-73.nt.northwestel.net) |
| 13:43.01 | *** join/#bzflag tupone (~alfredo@gentoo/developer/tupone) |
| 17:36.56 | *** join/#bzflag Krunch (~krunch@xvm-9-71.dc0.ghst.net) |
| 17:48.53 | JeffM | it's been talked about, there are several things that need to change, mostly at the services level |
| 17:49.19 | JeffM | my server codebase supports it already |
| 17:49.42 | *** mode/#bzflag [+v Krunch] by JeffM |
| 17:59.34 | Krunch | what do you mean by services level? |
| 17:59.44 | JeffM | list server, authentication, etc... |
| 18:00.10 | Krunch | ah, yeah, i don't really care about that tbh :) |
| 18:00.19 | JeffM | it all works together |
| 18:00.44 | JeffM | the IPv4 address is used as part of that process |
| 18:01.51 | JeffM | but yeah, blast007 has been concerned about it for a while now. |
| 18:01.55 | Krunch | is any of that actually used in a game that doesn't use the registration service? |
| 18:02.20 | JeffM | the client always checks with the list server |
| 18:02.38 | JeffM | but yes it is minimized at the server level |
| 18:03.02 | JeffM | my guess is that it'll happen during the next protocol break |
| 18:03.16 | JeffM | we've been writing up notes on what to change for that |
| 18:03.51 | Krunch | are your notes online somewhere? maybe there should be a wiki page about this |
| 18:04.04 | Krunch | looks at irc logs |
| 18:04.29 | JeffM | I have put them in a google doc untill they figure out where they should live, Github issues list or project list |
| 18:04.56 | JeffM | https://docs.google.com/document/d/151M1NGDo6ubqr6WY6Vo_vARAS7bopSCWb_TOAoK9hLw/edit?usp=sharing |
| 18:13.56 | Krunch | if you are going to change the serialisation format may i suggest switching to thrift or protobuf instead of doing your own? |
| 18:14.35 | JeffM | what would be the advantage? |
| 18:15.24 | Krunch | less code to write/maintain/debug |
| 18:15.41 | JeffM | so there is a lib that does it? |
| 18:16.16 | Krunch | i think that's very much the point yes :) so you don't have to worry about writing/maintaining your own parser/packer |
| 18:16.46 | JeffM | it would depend what the overhead was |
| 18:16.53 | Krunch | sure |
| 18:17.36 | JeffM | does it searlized the structure into the data? |
| 18:17.53 | Krunch | and they are more designed to work with streams-oriented connections so there may be some awkwardness |
| 18:18.10 | JeffM | yeah that would be my fear |
| 18:18.14 | Krunch | but i think you may benefit from having a look and considering it |
| 18:18.53 | JeffM | I've recently redone the data packing to be much more maintainable. |
| 18:19.41 | JeffM | there may also be changes to other networking libraries that do there own packing |
| 18:19.46 | JeffM | like enet |
| 18:19.59 | JeffM | all depends on what blast007 decides |
| 18:20.29 | Krunch | what's enet? can't find anything relevant in source |
| 18:20.39 | JeffM | it's a networking library |
| 18:21.34 | JeffM | there are a number of networking libs designed specifically for real time games. |
| 18:21.58 | JeffM | I personaly prefer lidgrin |
| 18:22.05 | Krunch | i mean, that's not used in bzflag right now is it? |
| 18:22.10 | JeffM | oh no |
| 18:22.22 | JeffM | it's just an option that's been talked about. |
| 18:22.32 | Krunch | right |
| 18:23.16 | Krunch | yeah ok if you are going for a whole game networking library, thrift/protobuf is probably not appropriate |
| 18:23.38 | JeffM | it is a silly tank game, not a web based service :) |
| 18:24.18 | JeffM | the changes for the server for IPV6 are relativly easy, just adding additonal sockets at the listen level |
| 18:24.34 | JeffM | took me like 10 min to add it to my codebase. |
| 18:24.56 | Krunch | afaict there is a bit of refactoring to do |
| 18:25.10 | JeffM | in the current bzfs codebase yes |
| 18:25.14 | JeffM | I was not using that |
| 18:25.51 | JeffM | I have a different bzfs implementation |
| 18:26.24 | Krunch | i got that :) i am interested in getting the regular bzflag game working over ipv6 |
| 18:26.43 | Krunch | i assume you only reimplemented the server, not the whole game? |
| 18:27.00 | JeffM | I have a client component for the networking part |
| 18:27.05 | JeffM | it is not as complete as the server |
| 18:27.45 | JeffM | it'll do a full connect, get the map, spawn and drive around, but it needs collision code still |
| 18:28.25 | Krunch | cool; still more than i expected |
| 18:28.50 | JeffM | yeah C++ bzfs will need to store some more data with the player connections to hadle it's sending and brodcasts for IPV6 and itll have to take the second UDP socket into account. |
| 18:29.33 | JeffM | and the ban list processing is very much based on IPV4 |
| 20:07.00 | blast007 | I'm not sure how best to add IPv6 support to the game. We're using some Address class right now that kinda seems like it's designed to hold multiple addresses yet also doesn't seem like it's supposed to. |
| 20:08.36 | blast007 | For the web services, it'll be reasonably easy. |
| 20:33.41 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 20:41.48 | Krunch | yes, i think Address should just be made to unambiguously hold exactly one address which could be v6 or v4 |
| 20:43.22 | Krunch | everything else should just manipulate Address and possibly serialised versions of it when necessary (probably as strings returned by inet_ntop) |
| 20:45.17 | Krunch | although i wasn't aware of the BanInfo situation; need to thin k about that |
| 20:45.44 | blast007 | that or change Address into a utility class instead of address storage |
| 20:46.17 | Krunch | define utility class? |
| 20:47.32 | blast007 | static functions for stuff like "is address X within range X" |
| 20:48.12 | blast007 | or functions for coverting to/from string representations of IP addresses |
| 20:48.19 | Krunch | no need for static actually: Address.isIn(containing_address, cidr) |
| 20:48.38 | Krunch | but yes, that logic should probably be in Address |
| 20:49.06 | blast007 | I just don't know useful the Address class is for storing an IP |
| 20:49.42 | blast007 | I had been reading through this: https://tools.ietf.org/html/rfc4038 |
| 20:52.46 | blast007 | this as well: https://www.akkadia.org/drepper/userapi-ipv6.html |
| 20:53.52 | blast007 | and I had used this to find areas we were using outdated functions/structures, based on the list from that second link: |
| 20:53.57 | blast007 | git grep -E '(sockaddr_in|gethostbyname|gethostbyname2|getservbyname|gethostbyaddr|getservbyport|inet_addr|inet_aton|inet_nsap_addr|inet_ntoa|inet_nsap_ntoa|inet_makeaddr|inet_netof|inet_network|inet_neta|inet_net_ntop|inet_net_pton|rcmd|rexec|rresvport)' |
| 20:54.11 | Krunch | yes, i have seen the drepper guide before; i like this one http://beej.us/guide/bgnet/html/multi/ip4to6.html |
| 20:55.39 | blast007 | part of the migration will have to be making the ban system easier to use. nobody is gonna want to type out a /ban command with an IPv6 address :) |
| 20:57.27 | Krunch | i am not familiar with the ban system but i kind of assume the way you would want it would be "/ban <user|ip> <netmask>" |
| 20:58.21 | Krunch | well, that's already how it looks apparently |
| 20:58.39 | Krunch | if you can specify a username instead of an IP that looks fine to me |
| 20:58.52 | Krunch | nobody is going to type an ipv6 address but they may want to be able to paste it |
| 21:01.45 | Krunch | wait, the cidr/netmask doesn't even seem to be used outside of BanInfo |
| 21:09.41 | blast007 | CIDR/mask is only relevant to bans |
| 21:10.13 | blast007 | also, if a player leaves before you can ban them, you need to type the IP currently |
| 21:10.58 | blast007 | I'd prefer a dialog that shows current and recent players and provides some sort of way to ban from there |
| 21:16.36 | Delusional | that sounds really good |
| 21:22.11 | blast007 | it's a super vague concept at the moment |
| 21:24.28 | Krunch | you could allow banning by username for users who have left in the last N inutes |
| 21:25.04 | Krunch | a dialogue would be nice but more work |
| 21:25.50 | blast007 | There's gonna be new dialogs anyway, such as one for team selection after joining a server |
| 21:26.13 | blast007 | (which also will be used for changing teams without rejoining) |
| 21:26.41 | blast007 | and I would like plugins to be able to build their own dialogs to send to clients |
| 21:26.45 | blast007 | but we'll see how that goes |
| 21:27.14 | blast007 | our UI system is very basic |
| 21:27.37 | blast007 | we don't even have real sliders or checkboxes :) |
| 21:29.15 | Krunch | is there any plan to add unit tests? |
| 21:30.23 | blast007 | I had tried at one point, but our code isn't really well suited for it right now |
| 21:30.46 | blast007 | unit tests seem to work better for libraries, not final executable programs |
| 21:31.41 | blast007 | a lot of our important or complex code is within the client/server code directly, not some lib we build |
| 21:32.00 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 21:32.26 | Krunch | there could be unit test per class or per file; then it becomes much easier to change things in there with some confidence you are not breaking something unknowingly |
| 21:32.42 | Krunch | like the Address refactoring |
| 21:33.27 | blast007 | I don't know how that works though |
| 21:34.12 | blast007 | I had been building other files separately for the tests, but that was making the build system angry |
| 21:34.40 | Krunch | yeah that probably require a fair bit of plumbing |
| 21:38.08 | JeffM | heh, so one unit test would test bzfs because most of it is in one file? :) |
| 21:38.16 | JeffM | most of it is in a single function |
| 21:39.24 | Krunch | yeah well, for that bit that wouldn't be very useful |
| 21:41.20 | JeffM | I built test harnesess for the major parts of my codebase, a tester for service integration, sockets, etc... |
| 21:42.11 | Krunch | easier when you are not dealing with decades of legacy :) |
| 21:42.44 | JeffM | well it's still compatible with the legacy protocol. |
| 21:42.48 | JeffM | but yes, |
| 21:43.29 | blast007 | maybe for 2.8 we can focus on refactoring into separate smaller libs |
| 21:43.40 | blast007 | and then unit tests would be much easier to implement |
| 21:43.40 | JeffM | not having to deal with the same command line options was nice. |
| 21:47.27 | Krunch | maybe don't frame the unit tests as the goal; they are just a tool to make the code easier to change |
| 21:48.39 | JeffM | there are so many ways to make bzflag easier to change :) |
| 22:03.46 | blast007 | Krunch: being able to more easily support unit tests would be a side-effect of splitting code out into separe libs |
| 22:15.19 | JeffM | pings start from the server and go to the client? |
| 22:23.47 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 22:23.47 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:35.26 | blast007 | JeffM: I think so, because bzadmin shows high lag values because it doesn't respond to pings |
| 22:36.26 | JeffM | then that's the next thing I'll have to implement |
| 22:48.51 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 22:48.52 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 22:58.16 | JeffM | trying to decide if lag should be hanled by the underlying receive threads or if by the thread that processess the messages. |
| 22:58.56 | JeffM | the former is a more accurate measurement of actual network latency, the later is actual functional latency. |