| 00:20.35 | *** join/#bzflag infobot (ibot@208.53.50.136) |
| 00:20.35 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:20.35 | *** mode/#bzflag [+v infobot] by ChanServ |
| 05:27.07 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 07:11.35 | *** join/#bzflag Dracos85 (~dracos85@24-119-188-49.cpe.cableone.net) |
| 08:13.41 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 10:21.07 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 10:32.29 | *** join/#bzflag Swant (~IKEA@freenode/staff/ikea) |
| 10:56.28 | *** join/#bzflag Swant (swant@freenode/staff/ikea) |
| 11:34.30 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 12:12.37 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
| 15:41.49 | *** join/#bzflag tommy_ (~tommy@47.38.244.41) |
| 15:45.18 | *** join/#bzflag atrixnet (~tommy@47.38.244.41) |
| 17:16.28 | *** join/#bzflag bboles (~quassel@2607:fcd0:100:8300:1c::a3ed) |
| 17:28.48 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 17:57.19 | moriah | is #bzflag +R? |
| 18:39.18 | JeffM | no it's +ntz |
| 18:41.05 | Zehra | Small request for API event or something which can be allowed or disallowed. |
| 18:41.27 | Zehra | When a player joins a team, their team flag appears, if it is CTF. |
| 18:41.50 | Zehra | However it disappears right afterwards, if all leave. |
| 18:42.07 | Zehra | kind of would like to be able to disable it |
| 18:42.26 | Zehra | (without a server modification.) |
| 18:45.48 | JeffM | when would it clear the flag? |
| 18:47.11 | Zehra | That's the thing, I wouldn't want to clear the flag. |
| 18:47.55 | JeffM | so you want a team flag for a team that doens't exist? |
| 18:48.04 | Zehra | I'd like for it to stay, unless no players from eRedTeam, eGreenTeam, eBlueTeam, ePurpleTeam are around. |
| 18:48.42 | Zehra | I asked for custom team flags, but since this is too much effort..etc, I'd rather use 3 slots, and give the teams a single flag to play with. |
| 18:48.48 | JeffM | why? |
| 18:49.02 | Zehra | CTF with a single flag. |
| 18:49.03 | JeffM | actualy 2.6 supports custom team flags |
| 18:49.11 | JeffM | that's not CTF then ;) |
| 18:49.29 | JeffM | use a custom flag |
| 18:49.53 | Zehra | It doesn't show up on radar well. |
| 18:50.17 | JeffM | bzflag isn't really designed for that |
| 18:50.42 | JeffM | CTF makes a bunch of assumptions about flags existing and not existing |
| 18:50.50 | JeffM | keeping it around would mess up the state. |
| 18:51.17 | Zehra | People have done this before, by keeping a little bot for a single player slot. :P |
| 18:51.35 | JeffM | sure that means there IS a player for the rest of the code |
| 18:51.49 | JeffM | it's no an API thing, it's a server side state thing |
| 18:53.20 | Zehra | I did try to use the serverSideBots for the extra player, so no server mod would be needed. |
| 18:53.37 | JeffM | SSPs are not functional enough for that in 2.4 |
| 18:57.12 | Zehra | Is there an event when a flag moves to another position? |
| 18:57.28 | JeffM | flags don't move by themselves |
| 18:57.48 | Zehra | Except when they leave the world. :p |
| 18:59.43 | Zehra | I guess the only solution is either modifying BZFS or writing a custom bot to connect to the server. :p |
| 19:03.27 | Zehra | hopes better documentation on the BZFlag protocol will be available in the future |
| 19:04.06 | JeffM | that's flag add |
| 19:04.27 | JeffM | or using a custom team flag in 2.6 |
| 19:04.36 | JeffM | the protocol is documented in the code. |
| 19:04.49 | JeffM | how much do you know about sockets and data buffers? |
| 19:05.38 | Zehra | Not much. |
| 19:05.59 | Zehra | Probably not more than what I've read in a book about sockets and stuff. :p |
| 19:05.59 | JeffM | I would not recommend writing a bot at your level of knowledge. |
| 19:06.30 | JeffM | do you know what a byte buffer is and how to put data into it? |
| 19:07.05 | Zehra | Nope, but I'd learn if I would try. |
| 19:07.27 | JeffM | you won't learn the basics of C, or how to do assignments, so I don't quite belive you |
| 19:09.38 | Zehra | Everyone has their own opinion. |
| 19:09.44 | JeffM | true |
| 19:10.01 | Zehra | might try to find another way to make 1 flag ctf |
| 19:10.02 | JeffM | I'm basing it on my observations, you say you'll do stuff, then come back later and ask the same questions |
| 19:14.31 | Zehra | I try to find a different way of doing the same thing and I need to stop trying to reinvent the wheel. :p |
| 19:15.04 | Zehra | CustomTeam flags I'll be taking advantage of in 2.6, but I kind of was trying to do something in 2.4.x. |
| 19:15.06 | JeffM | you need to take a break from making a ton of little plugins and study the basics of the langauge. |
| 19:15.26 | JeffM | nobody is impressed by you busting out plugins. |
| 19:16.14 | JeffM | 2.4.x is not getting any enhancements, it has no more planned releases. |
| 19:17.23 | Zehra | Good to know. |
| 19:17.57 | Zehra | I only create, because I can, and I think it is also better than me asking for someone to do it for me. :p |
| 19:18.42 | JeffM | what is your end goal? |
| 19:19.52 | Zehra | To try to introduce new game modes, and to try to enhance the current ones. |
| 19:20.16 | JeffM | do you run servers with players? |
| 19:20.36 | Zehra | Nope. |
| 19:20.45 | blast007 | JeffM: I think when he was talking about SSP's he was just saying he had one take up a slot so the flag would spawn |
| 19:20.46 | JeffM | who runs your plugins then? |
| 19:20.53 | blast007 | the team flag* |
| 19:20.57 | JeffM | ahh |
| 19:21.31 | Zehra | Nobody runs them, maybe someone will, who knows, but I hope that at least it provides something someone can use. |
| 19:23.19 | Zehra | 2.6 holds a lot of promise, and it means a lot can be made in it. |
| 19:31.50 | blast007 | 2.6 may not be as different as you're imagining |
| 19:32.35 | JeffM | it is not going to have an authoritative server state. |
| 19:32.54 | Zehra | It's not really the differences, but what becomes available via the API. |
| 19:33.10 | JeffM | ok, you really need to stop using the term API when you mean "server" |
| 19:33.18 | JeffM | the API is not the server and the server is not the API |
| 19:33.28 | JeffM | the API exposes SOME of the server features. |
| 19:33.30 | JeffM | that's it |
| 19:33.47 | JeffM | the server is not getting any huge features that affect clients. |
| 19:33.49 | blast007 | there's not a bunch of API stuff planned either |
| 19:34.15 | blast007 | main things might be stuff for SSPs, and the team changing stuff I added |
| 19:34.16 | JeffM | really just the minium need to support the changes to the server |
| 19:34.30 | JeffM | map reload, and limbo |
| 19:34.39 | blast007 | can't recall if I added an event for team changes |
| 19:35.03 | JeffM | but you arn't going to be able to change shots and have them show up everywhere, or zip players around the map, or change motion |
| 19:36.05 | JeffM | SSPs are super complicated and not release critical, if release time comes and they arn't done, they don't get done. |
| 19:36.19 | JeffM | they don't break protocol and can be finished after 2.6.0 |
| 19:36.47 | Zehra | This might sound crazy, but here's what I see... |
| 19:38.25 | Zehra | SSPs allow me to make 1flag ctf, forced spawning allows me to reset players positions.. not zip them around.. |
| 19:38.57 | JeffM | they have no extra flag abilities than they do now |
| 19:39.20 | JeffM | so if SSPs do't work for you now, they may do the same thing in 2.6 |
| 19:39.41 | Zehra | :p |
| 19:39.50 | JeffM | SSPs have a lot more code in 2.6, but most of it is unused. |
| 19:40.37 | Zehra | :/ |
| 19:41.11 | Zehra | But even if they don't run, humans vs zombies can be made, without bypassing the API. :p |
| 19:41.40 | JeffM | if that was true you could do that now |
| 19:42.55 | blast007 | bigger priorities are IPv6 support (which is a multi-project process) |
| 19:43.04 | JeffM | indeed |
| 19:43.19 | JeffM | that's the main goal for the release |
| 19:44.58 | blast007 | need to make the client able to connect to mixed IPv4/IPv6 servers, need to make the servers able to bind on a dual-protocol socket (and probably on multiple independent sockets to allow binding to specific IPs), need to update the ban system to support IPv6, need to make authentication work with IPv6 |
| 19:45.03 | blast007 | etc |
| 19:45.24 | JeffM | indeed |
| 19:46.07 | blast007 | right now I'm starting to learn how to use C++11 threads so I can replace c-ares |
| 19:47.08 | JeffM | nice |
| 19:47.13 | JeffM | that's a good skill to learn |
| 19:47.18 | JeffM | I need to do that one of these days |
| 19:55.08 | JeffM | maybe move the spawn code in to a thread |
| 19:55.27 | JeffM | there is allready code to delay a spawn by time, coudl just make it be time and "is the spawn ready" |
| 19:55.39 | JeffM | chat filtering too |
| 19:56.35 | blast007 | move chat filtering to the cloud |
| 19:56.53 | JeffM | just give me a restful api |
| 20:07.05 | allejo | restful? pfft that's so 2018. it's all about graphql now |
| 20:09.25 | blast007 | allejo: k, I'll start migrating the Web Services API code to that |
| 20:09.29 | blast007 | ;) |
| 20:09.47 | blast007 | and Ruby |
| 20:09.57 | allejo | squees |
| 20:10.24 | blast007 | or maybe Java |
| 20:11.01 | allejo | java 10? |
| 20:16.33 | blast007 | definitely |
| 20:17.24 | allejo | i'm sold. let's do it! |
| 20:33.15 | JeffM | and this is why I wanted to break development up into a game dev group and a services group :) |
| 20:33.59 | moriah | :) |
| 20:34.17 | JeffM | and a community management group |
| 20:35.54 | Zehra | Exactly how will this work? |
| 20:36.09 | JeffM | with bits and bytes |
| 20:36.38 | JeffM | or do you mean the BZFlag Triumvirate of Power? |
| 20:37.17 | Zehra | Like with community management, is it like the karma system we heard of a while back, but never was implemented? |
| 20:37.31 | Zehra | Or is it more like the BZCop system which was thought of. |
| 20:38.09 | JeffM | oh no, not at techincal solution |
| 20:38.12 | JeffM | a social one |
| 20:38.27 | JeffM | community management is more than just game servers |
| 20:38.44 | JeffM | assets, forums, players, all that |
| 20:38.54 | JeffM | making sure the player community is taken care of |
| 20:39.04 | JeffM | as well as getting feedback from players for the other 2 teams |
| 20:39.42 | Zehra | Makes sense. |
| 20:41.56 | JeffM | https://usercontent.irccloud-cdn.com/file/d06xriQg/image.png |
| 20:46.01 | Zehra | I think allejo would be a good match for community manager. |
| 20:47.55 | JeffM | I had several people in mind |
| 20:48.01 | JeffM | but the proposal was not accepted |
| 20:48.03 | JeffM | so it's moot |
| 20:49.09 | allejo | shrugs |
| 21:08.44 | JeffM | for new service features, optimally ether service or dev group would build a proof of concept or reference implementation of any client <-> services communication for testing and review before impelemntation. |
| 21:09.25 | JeffM | like if the list server format was changing, you'd say " here is a test app that just dumps out what services will send". |
| 21:09.45 | JeffM | then that could be used to impelent the actual client/server code in game. |
| 21:10.12 | JeffM | while also providing a unit test for the services group to use while developing the actual service backend. |
| 21:10.30 | JeffM | but I'm probably over-designing it :) |
| 21:11.06 | allejo | that any different from just writing a spec of the structure of responses that will be returned |
| 21:11.07 | allejo | ? |
| 21:11.20 | JeffM | a spec can't actualy run as a test |
| 21:11.40 | JeffM | I'd start with a rough spec, that's where everyone involved would agree on what is needed for the feature etc.. |
| 21:11.53 | JeffM | but the groups are probalby too small to do full blown formal specifications |
| 21:12.06 | JeffM | so a small test article/prototype serves the same function |
| 21:12.20 | JeffM | and is easier for people to make if they arn't used to formal specifications. |
| 21:12.29 | JeffM | and has the advantage of being a unit test. |
| 21:13.12 | JeffM | the spec may seem good, but you may find actual issues that don't show up untill a simple reference implementation of a protocoll is made for instance. |
| 21:13.37 | JeffM | for the way this project works, little code things seem to fit better than big documents |
| 21:13.58 | JeffM | mostly because everyone complains the big documents I write are too big and nobody reads them :) |
| 21:17.15 | allejo | well unit tests would be to test that things actually return what's needed. so the web services would have tests that it returns in the spec and the client would have tests to ensure it knows how to handle the possible spec |
| 21:17.16 | allejo | no? |
| 21:18.17 | JeffM | sure, you could have little apps that did both sides of it, and use that to test the production code of the other side as you develop it |
| 21:18.46 | JeffM | so I write a little app that spits out a little sample list server data blob, and a little app that reads it. |
| 21:18.57 | JeffM | with those 2 I can test the spec |
| 21:19.24 | JeffM | but I can use the app that spits out data, to also test the cllient as I write the final production code (make sure it can read the data) |
| 21:19.58 | JeffM | while you can use the app that reads the data while you implmeent the service backend that returns real data,( you make sure the little app can read your data) |
| 21:20.09 | JeffM | so I can develop the client, WHILE you develop the service backend |
| 21:20.34 | JeffM | yet we both have little test tools that we can use while we do it, so I'm not stuck waiting on you, and you aren't stuck waiting on me... |
| 21:20.51 | JeffM | and if there is a bug, we both can look at the test apps, because we know they work. |
| 21:21.39 | allejo | that makes sense |
| 21:21.58 | JeffM | for some stuff it does |
| 21:22.08 | JeffM | like application / service interaction |
| 21:22.16 | JeffM | when both sides are sizeable projects. |
| 21:53.37 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |
