| 00:02.18 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 00:03.09 | *** join/#bzflag Anxuiz (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 00:03.09 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 00:17.38 | CIA-103 | BZFlag: 03Thumper 07http://my.bzflag.org * r7731 10/w/BZFS_2.4_Upgrade: |
| 00:48.01 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:48.01 | *** mode/#bzflag [+v spldart] by ChanServ |
| 01:15.51 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 01:37.04 | CIA-103 | BZFlag: 03trepan * r21914 10/branches/experimental/v2_99continuing/bzflag/src/include/foreach.h: |
| 01:37.04 | CIA-103 | BZFlag: * this version of << foreach(var, con) >> balks on temporary containers |
| 01:37.04 | CIA-103 | BZFlag: (it sets up a pointer to the container to avoid redefinition in the macro) |
| 01:38.57 | trepan | DTRemenak: foreach(c, std::string("ouch")) -- doesn't compile anymore :) |
| 01:39.58 | Erroneous | heh. that's one way to handle it, I guess :) |
| 01:41.46 | trepan | disallowing temporaries is not such a bad thing |
| 01:42.48 | delusional | took me awhile, but here it is.... upgraded SDL to 1.3 and compile poops.... I have my warnings with V.1.2..... then I upgraded and that's at the end..... http://pastebin.com/4RP03NpF |
| 01:42.49 | Erroneous | not sure useful cases of foreach over temporaries are common anyway |
| 01:43.02 | Erroneous | and the workaround is easy enough |
| 01:44.05 | trepan | Erroneous: agreed |
| 01:44.47 | trepan | although i do find myself using: for k in { 'data', 'goes', 'here' } do ... structures in dynamic languages |
| 02:18.14 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 02:18.14 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 02:24.55 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 02:24.55 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:43.31 | blast007 | hmm. so OpenFFA doesn't send a MsgTeamUpdate, which explains why my script hangs :) |
| 02:53.43 | blast007 | ah, the perl and python versions also hang |
| 02:55.17 | blast007 | Thumper_: when the game mode is OpenFFA, the MsgTeamUpdate never comes - seems that the pl/py version of bzfquery still assume it will come and sit there waiting. |
| 02:56.37 | blast007 | also seems like the time limit isn't multipled by 10 before being sent out anymore, since my script divides it by 10 and is showing 3 instead of 30 |
| 02:59.52 | trepan | blast007: wouldn't be too hard to setup bzfs to reply in xml/python/lua/json with the current server state |
| 03:00.18 | blast007 | true, but not much point now |
| 03:00.38 | trepan | "now" being now the 2.3 is feature frozen? |
| 03:00.45 | trepan | *now that |
| 03:00.48 | blast007 | we'll have HTTP plugins soon enough which can handle that, and we'll be doing push stats soon(ish) anyway |
| 03:01.00 | trepan | it can't be a plugin |
| 03:01.24 | blast007 | why not? |
| 03:01.33 | trepan | you'd want it to always work |
| 03:02.20 | blast007 | meh |
| 03:03.17 | trepan | but as you mentioned, if pushstats works out, it may not matter |
| 03:04.07 | trepan | </meh> |
| 03:18.58 | CIA-103 | BZFlag: 03blast007 * r21915 10/trunk/bzflag/misc/bzfquery.php: Update bzfquery.php to support the 2.3 protocol |
| 03:21.22 | *** join/#bzflag Anxuiz (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 03:21.22 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 03:23.00 | CIA-103 | BZFlag: 03blast007 * r21916 10/trunk/bzflag/misc/ (bzfquery.pl bzfquery.py): Update bzfquery.py/pl to the 0213 protocol string |
| 03:40.29 | CIA-103 | BZFlag: 03blast007 * r21917 10/trunk/bzflag/misc/bzfquery.pl: Do not try to read MsgTeamUpdate when the server is OpenFFA, and display the same time/wins when they are enabled. |
| 03:41.08 | blast007 | Thumper_: so just the bzfquery.py needs some work done now to properly support OpenFFA. |
| 03:59.09 | *** join/#bzflag Chestal (thilo@141.99.42.43) |
| 03:59.09 | *** mode/#bzflag [+o Chestal] by ChanServ |
| 04:17.20 | *** join/#bzflag CIA-117 (~CIA@cia.atheme.org) |
| 04:41.34 | *** join/#bzflag TimRikerOLS (~TimRiker@66.135.114.72) |
| 04:55.57 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7732 10/w/Bz_Load: wrote page for bz_load |
| 05:00.30 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7733 10/w/Bz_registerEvent: |
| 05:04.43 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7734 10/w/Bz_Load: fixed typo |
| 05:07.54 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7735 10/w/Bz_removeEvent: added deprecated info |
| 05:15.31 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7736 10/w/Bz_Unload: wrote page for bz_Unload |
| 05:23.05 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7737 10/w/Bz_removeCustomSlashCommand: added bz_removeCustomSlashCommand page |
| 05:33.44 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7738 10/w/Bz_registerCustomSlashCommand: added bz_registerCustomSlashCommand page |
| 05:38.26 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7739 10/w/Bz_PlayerRecord: added page to redirect to new bz_BasePlayerRecord info |
| 05:43.51 | allejo | woops. sorry about the wiki revision spam |
| 05:53.00 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7740 10/w/Functions%28API%29: added registration and clean up info of events for 2.3+ |
| 06:57.31 | *** join/#bzflag Marzipan- (~Marzipan@p5B22343E.dip.t-dialin.net) |
| 06:59.11 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:05.38 | *** join/#bzflag trepan_ (~trepan@204.237.8.232) |
| 07:38.33 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 07:38.33 | *** mode/#bzflag [+v trepan] by ChanServ |
| 08:13.55 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 08:13.55 | *** mode/#bzflag [+o GvzEvxre] by ChanServ |
| 08:19.45 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:20.13 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 09:02.46 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 09:07.37 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 09:13.13 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 09:20.07 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 09:57.27 | *** join/#bzflag a_meteorite (~bzmeteori@unaffiliated/ameteorite/x-000000001) |
| 11:40.44 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 11:42.47 | mdskpr_ | why /playerlist for everyone? <---from changelog |
| 11:56.27 | Thumper_ | blast007: thx, I'll take a look at it |
| 12:16.50 | blast007 | mdskpr_: it shows you just your own if you don't have rights to see others |
| 12:17.20 | mdskpr_ | kinda worthless |
| 12:18.10 | blast007 | less worthless than the Useless flag ;) |
| 12:18.28 | brad | useless flag is great! |
| 12:24.08 | *** join/#bzflag bleach (bleach@osama.destroyislam.org) |
| 12:30.17 | a_meteorite | ~useless |
| 12:30.18 | ibot | ACTION starts crying and hides from a_meteorite in the darkest corner of the room. :( |
| 12:37.32 | blast007 | a_meteorite: meanie |
| 12:37.54 | Thumper_ | mdskpr_: I backported it from one of tupone's 2.99 commits - We can drop it if it's useless |
| 12:39.19 | blast007 | it's not useless |
| 12:40.05 | blast007 | here's an example use: someone is caught in a ban on another server, and they see an admin from that server on a different server - it's much easier to give them your IP that way then it would be to switch back and forth between a web browser |
| 12:41.18 | Thumper_ | ... or that admin could just look the player up with /playerlist there :) |
| 12:41.41 | blast007 | taht's assuming that admin is an admin on that server too |
| 12:41.54 | blast007 | I'm not an admin at bztank, but someone might track me down there for a ban on my server |
| 12:42.23 | Thumper_ | and filter through the 40+ lines of output |
| 12:42.25 | Thumper_ | oh yeah :) |
| 12:42.32 | blast007 | ? |
| 12:42.48 | blast007 | 40 lines of.. what? |
| 12:43.25 | Thumper_ | (I have admin perms on all the servers I play - didn't think of that) |
| 12:43.25 | Thumper_ | assuming we have 40 players... on the box |
| 12:43.26 | Thumper_ | and you are an admin... |
| 12:43.33 | Thumper_ | needs coffee in order to be coherent |
| 12:43.56 | blast007 | my example is if I'm *not* an admin somewhere and someone tracks me down and asks to check on a ban |
| 12:44.28 | blast007 | otherwise there's be no point to my example ;) |
| 12:44.50 | Thumper_ | yes -- that was the 'oh yeah :)' part |
| 12:44.51 | Thumper_ | as in the light went on |
| 12:45.07 | blast007 | heh |
| 12:45.14 | Thumper_ | needs coffee in order to be coherent |
| 12:45.17 | Thumper_ | ;) |
| 12:45.50 | blast007 | I've got a fever... and the only perscription is more coffee! |
| 12:46.17 | blast007 | prescription* knew that didn't look right |
| 12:56.44 | short_circuit | mmMMmm coffeeeeeeee |
| 12:56.59 | short_circuit | heads to work where the coffee is. |
| 13:13.39 | trepan | blast007: initially read it as 'perspiration', odd how the mind tweaks |
| 13:22.28 | CIA-117 | BZFlag: 03bthansen * r21918 10/trunk/bzflag/misc/bzfquery.py: Handle missing team information for OpenFFA style |
| 13:23.17 | Thumper_ | blast007: Does it really make sense for OpenFFA not to return team info (as opposed to returning zero counts for the teams) |
| 13:23.29 | Thumper_ | you need to know the game style before querying this information - is it valid |
| 13:23.39 | Thumper_ | to query for players without knowing the game style? |
| 13:23.47 | Thumper_ | s/valid/useful/ |
| 13:43.22 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 13:43.23 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 13:54.28 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 14:05.19 | blast007 | Thumper_: I'm not sure if it makes sense to not send it. Even rabbit mode sends the team info.. |
| 14:06.37 | blast007 | we'll need to make a note of that for anyone who has a stats site |
| 14:08.00 | blast007 | if we wanted to send it, it's only a two line change |
| 14:08.02 | blast007 | afaik |
| 14:08.25 | Thumper_ | I think it makes sense for the format to be the same no matter what the game style is |
| 14:08.35 | blast007 | then we could turn it back off for 2.6.x and make rabbit mode do the same at that time |
| 14:08.38 | Thumper_ | the interface is much simpler then |
| 14:08.53 | blast007 | or to just send 0 teams, but still send the message |
| 14:09.15 | Thumper_ | personally I'd like the same set of messages for everything and just fill with zero team sizes |
| 14:09.21 | blast007 | yeah |
| 14:09.37 | blast007 | for now we could just make it send it as we have been |
| 14:09.39 | Thumper_ | then you don't need to query the game style first |
| 14:09.47 | blast007 | then do it properly in 2.6/whatever |
| 14:09.52 | Thumper_ | ok |
| 14:10.13 | Thumper_ | replay servers should probably also have a style definition |
| 14:10.29 | Thumper_ | currently it reports TeamFFA |
| 14:10.33 | blast007 | hmm? |
| 14:10.38 | blast007 | ooh, I see |
| 14:10.49 | blast007 | what if you load a CTF replay on it? |
| 14:10.49 | Thumper_ | so Replay should probably be a game style :) |
| 14:11.11 | Thumper_ | checking... |
| 14:13.29 | Thumper_ | hmm seems I broke it |
| 14:13.42 | Thumper_ | Requesting World Hash... and it hangs |
| 14:13.47 | blast007 | *kaboom* |
| 14:13.50 | Thumper_ | when connecting to teh reply server |
| 14:13.51 | Thumper_ | replay* |
| 14:14.03 | blast007 | maybe it's 2012 already and nobody told us. the world ended. |
| 14:14.34 | Thumper_ | heh |
| 14:14.44 | Thumper_ | I'll look at that later |
| 14:17.15 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 14:17.17 | Thumper_ | are replays between 2.0.x and 2.3 compatible? |
| 14:18.53 | cygal | probably. |
| 14:19.20 | blast007 | probably not. |
| 14:19.33 | cygal | I fixed a bug in replays in 2.99, and it looks like it would not work only if the underlying "struct" changed, which is only the case for 2.99/old trunk |
| 14:19.50 | blast007 | the protocol isn't quite the same |
| 14:20.03 | blast007 | messages, for instance, have a 'type' |
| 14:20.11 | blast007 | chat messages* |
| 14:20.15 | Thumper_ | my replay server was still pointing at the 2.0.x recording dir - will try again with a 2.3 recording |
| 14:22.00 | blast007 | cygal: you do realize that our replay system is essentially a network traffic recorder, right? :) |
| 14:22.15 | blast007 | it saves the raw packet data and just resends it when playing the replay |
| 14:22.17 | cygal | yeah |
| 14:22.29 | cygal | I don't know what changed between 2.0 and 2.3 anyway |
| 14:22.31 | blast007 | so there is no way it would be compatible cross majors |
| 14:22.58 | blast007 | 2.3 is incompatible with 2.0 |
| 14:23.58 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
| 14:23.58 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 14:23.58 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 14:25.14 | blast007 | JeffM: thoughts on this: currently OpenFFA doesn't send a MsgTeamUpdate, but all other modes do (including rabbit chase). Should we just send that for 2.4 and then fix it properly for 2.6? |
| 14:25.38 | JeffM | what would you send for data? 0 in all team counts? |
| 14:25.52 | blast007 | the same thing that rabbit chase sends - all zeros |
| 14:26.01 | JeffM | sure |
| 14:26.15 | blast007 | think it's less risky than leaving it out (it breaks query scripts) |
| 14:26.28 | JeffM | sure |
| 14:26.34 | Thumper_ | currently you need to know the game stye because the response you get changes with the game style |
| 14:26.38 | JeffM | and if rabbit does it then we know the rest of the code works with zeros |
| 14:26.39 | Thumper_ | which is more work on the receiving end |
| 14:26.55 | blast007 | for 2.6 we should look at that area more closely |
| 14:27.14 | blast007 | cuz there is another spot that sends out some other team count, and it always seems to send 8 in my testing |
| 14:27.15 | JeffM | maybe we should add a bit to the message that means "teamless" |
| 14:27.27 | JeffM | I don't mind sending a message that says "I have no teams" |
| 14:27.44 | JeffM | then you know for sure it's not teamless and not that the team message got dropped |
| 14:27.52 | blast007 | we could even make it more generic and not hard code team names into the game |
| 14:27.58 | blast007 | and have a string passed with the team update |
| 14:28.03 | JeffM | yes |
| 14:28.08 | JeffM | that I'd leave fro 2.6 |
| 14:28.11 | blast007 | yeah |
| 14:28.42 | JeffM | but I don't think a teamless bit now would hurt |
| 14:28.46 | JeffM | and it may make the script easier |
| 14:28.46 | blast007 | eventually it would be nice to move team selection to after you're joined as well, since some modes (rabbit chase) don't use the team selection |
| 14:28.58 | JeffM | yes just like every OTHER game in the world ;) |
| 14:29.01 | blast007 | ;) |
| 14:29.13 | blast007 | wasn't really a problem when it was just FFA and CTF |
| 14:31.20 | JeffM | yeah and I don't see there beeing less game modes in the future |
| 14:31.22 | Thumper_ | replay servers should also have a gameStyle entry - they report TeamFFA regardless of what replay is playing (currently showing a CTF game) |
| 14:31.31 | JeffM | as we add less flags then what will happen is more game modes |
| 14:32.05 | Thumper_ | and only connected observers show up as players on the replay server (which is what I expected) |
| 14:32.27 | JeffM | good lord..they are still talking about music? |
| 14:36.02 | *** join/#bzflag bier (~bier@p54A59D8F.dip.t-dialin.net) |
| 14:36.07 | *** join/#bzflag bier|tp (~bier@p54A59D8F.dip.t-dialin.net) |
| 14:37.25 | Thumper_ | replay servers should also probably have the protocol in the recording file and refuse to load recordings from incompatible protocols |
| 14:37.56 | Thumper_ | (I tried loading a 2.0.17 recording on a 2.3 server and that didn't go real well) :) |
| 14:38.32 | JeffM | yeah I'm not happy with replay system |
| 14:38.42 | JeffM | I'd rather it not record packages but "events" |
| 14:38.53 | Thumper_ | 'packets' ? |
| 14:39.03 | BulletCatcher | It looks like the BZFS0026 string is already the replay file, so bzfs just needs to check it. |
| 14:40.15 | JeffM | IIRC the record system just records the packed up network data |
| 14:40.22 | JeffM | and saves them |
| 14:40.31 | JeffM | then replay creates message packets for them |
| 14:40.44 | JeffM | so the protocol of the recording is burned into the data it saves |
| 14:42.11 | JeffM | if it stored just a "player joined" or "Player moved" bit of data we could then have it create the correct packet for whatever version was being run |
| 14:42.25 | JeffM | but then it may not make sense cus client behavor may be different |
| 14:42.34 | JeffM | probalby can't get there untill we have server state |
| 14:42.52 | Thumper_ | there's a lot of extra maintenance work if we change it to events - everytime you add something new you need to update the record/replay code too |
| 14:43.01 | JeffM | then a replay would just be something that drove server side players |
| 14:43.14 | JeffM | ohh yeah it's a total reqwrite :) |
| 14:43.22 | JeffM | didn't say it was easy |
| 14:43.34 | Thumper_ | and we want to keep the data as compressed as possible so online replays don't eat all the server memory :) |
| 14:43.36 | JeffM | optimaly there would be a simulation class on the server that would have a serialize method |
| 14:43.44 | JeffM | compression is easy |
| 14:44.01 | JeffM | just gzip the stream as you save it |
| 14:44.45 | Thumper_ | I currently use replays only in a memory buffer so the last N minutes of game play are available to save |
| 14:45.14 | Thumper_ | most of the time we don't care about the data so saving it to a file permanently isn't the way I'd want to use it |
| 14:45.18 | JeffM | I'm sure a similar system could be made to work |
| 14:45.20 | Thumper_ | but that probably makes sense to matches and leagues |
| 14:45.30 | Thumper_ | s/to/for/ |
| 14:45.40 | JeffM | well no it dosn't they think that it shows them "hard data" :) |
| 14:45.56 | JeffM | once we have an authoritive server they will use it a lot less |
| 14:45.59 | Thumper_ | yes it needs to be 'fixed' too ;) |
| 14:46.33 | Thumper_ | so if we get there it may not be worth redoing the current replay system since it won't be needed/used as much as it is today |
| 14:47.16 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 14:47.16 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 14:47.16 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:49.06 | Thumper_ | JeffM: I took a first stab at the server upgrade doc: http://my.bzflag.org/w/BZFS_2.4_Upgrade |
| 14:49.11 | Thumper_ | Am I missing anything major? |
| 14:51.15 | blast007 | this could be referenced for the publickey thing: http://my.bzflag.org/w/ServerAuthentication |
| 14:51.35 | JeffM | did the code to disable TK in team games get backported? |
| 14:54.37 | blast007 | I had thought it did, but I'm not seeing a command line option for it |
| 15:00.44 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:00.44 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 15:05.56 | CIA-117 | BZFlag: 03bullet_catcher * r21919 10/trunk/bzflag/package/win32/nsis/BZFlag.nsi: The current package version number is 2.3.13. |
| 15:07.34 | BulletCatcher | I am looking at the release instructions in DEVINFO. |
| 15:07.35 | BulletCatcher | Should we increment BZ_PROTO_VERSION when doing a protocol-breaking release like 2.4 to lock out all previous development versions? |
| 15:07.52 | JeffM | yes |
| 15:08.06 | JeffM | that's what we have always done in the past |
| 15:08.17 | BulletCatcher | I'll work that into the instructions. |
| 15:08.26 | JeffM | that locks that protocoll as the "release" one to be used for the entire compatable line |
| 15:08.33 | JeffM | and it should be as clean as possible |
| 15:20.45 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7741 10/w/ServerAuthentication: -publickey starts in version 2.4 |
| 15:21.42 | *** join/#bzflag QWork (~QuaWo@d3-4-1-0.r00.dllstx04.us.ce.gin.ntt.net) |
| 15:21.45 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 15:22.45 | BulletCatcher | I still think we need a better name than -publickey. |
| 15:22.46 | BulletCatcher | It isn't too late to change it to -serverkey or something like that. |
| 15:22.59 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 15:22.59 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 15:23.05 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7742 10/w/BZFS_2.4_Upgrade: Reference the ServerAuthentication page for more details |
| 15:23.54 | JeffM | I'm wondering why we need a seperate option for it |
| 15:23.54 | JeffM | it's required |
| 15:23.55 | JeffM | make it paramater 2 for -public |
| 15:23.55 | JeffM | -public "name" "key" |
| 15:24.12 | Thumper_ | -serverlistkey but then we start getting into -really-ridiculously-long-option-names |
| 15:24.28 | Thumper_ | -public is optional |
| 15:24.54 | JeffM | -publickey and -public go together |
| 15:25.00 | JeffM | you can't do -publickey with out public |
| 15:25.00 | Thumper_ | but it's not very useful to be listed on the server list without a map name |
| 15:25.08 | JeffM | and public with out publickey |
| 15:25.24 | Thumper_ | 2.0.x can list servers without -public (not that that's a feature I want to keep) |
| 15:25.29 | JeffM | how? |
| 15:25.39 | Thumper_ | specify -publicaddr and -p only |
| 15:25.41 | *** join/#bzflag FastLizard4|zZzZ (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 15:25.46 | JeffM | ugg |
| 15:25.46 | Thumper_ | -public is just the map name |
| 15:25.53 | JeffM | yeah make em put a description |
| 15:26.03 | JeffM | make it one option |
| 15:26.15 | JeffM | it's publicaddr that should be optional |
| 15:26.21 | JeffM | cus we can always figure out the IP |
| 15:27.01 | CIA-117 | BZFlag: 03bullet_catcher * r21920 10/trunk/bzflag/ (DEVINFO src/date/buildDate.cxx): |
| 15:27.01 | CIA-117 | BZFlag: Update the list of files to be changed when the protocol changes. |
| 15:27.01 | CIA-117 | BZFlag: Add conditional increment of BZ_PROTO_VERSION to release instructions. |
| 15:27.02 | Thumper_ | -publicaddr is normally hostname:port (not IP) |
| 15:27.10 | Thumper_ | since multiple names can map to the same IP |
| 15:27.39 | JeffM | yes but if you don't specify it we use IP and port |
| 15:27.44 | JeffM | so it is optional |
| 15:28.09 | JeffM | I can run a public server with just -public |
| 15:28.19 | JeffM | if I want it to have a fancy name then I use -publicaddr |
| 15:28.23 | Thumper_ | I think -publicaddr currently controls if it is listed on the list server but I may be wrong on that |
| 15:28.35 | JeffM | the both must |
| 15:28.43 | JeffM | cus I have done -public only |
| 15:29.30 | trepan | bzfs:5479 |
| 15:29.37 | trepan | *bzfs.cxx |
| 15:29.37 | Thumper_ | can you see bzflag.norang.ca:5154 on the 2.0.x server list? |
| 15:29.40 | JeffM | yes options.publicizeServer is set for both |
| 15:29.40 | Thumper_ | (now) |
| 15:29.51 | Thumper_ | eek nevemrind |
| 15:29.53 | Thumper_ | Segmentation fault (core dumped) |
| 15:29.56 | JeffM | he |
| 15:30.00 | JeffM | heh |
| 15:30.03 | Thumper_ | bzfs -publicaddr bzflag.norang.ca |
| 15:30.03 | JeffM | I'll clean it up |
| 15:30.56 | Thumper_ | bin/bzfs -publicaddr bzflag.norang.ca:5154 |
| 15:31.01 | Thumper_ | this is listed on the 2.0.x server list |
| 15:31.13 | Thumper_ | (it's running on the wrong host so you can't connect to it) |
| 15:31.45 | trepan | BulletCatcher: the reason it wass -publickey instead of -serverkey is to keep it to keep it close to its associated options; and it's the key required for a publicized server, so "publickey" made sense |
| 15:32.32 | *** join/#bzflag JeffM_ (~JeffM@69.36.85.130) |
| 15:32.36 | JeffM_ | and making -publicaddr only set the address not the public status |
| 15:33.10 | JeffM_ | the point of the server key is to increase the quality of servers that players see, so they should have descriptions |
| 15:33.51 | trepan | you could still do -public "" 3249823498 |
| 15:33.55 | BulletCatcher | How about combining all 3 things into one option? |
| 15:33.57 | BulletCatcher | <PROTECTED> |
| 15:34.03 | trepan | going to enforce a desc length? |
| 15:34.13 | JeffM_ | I think the address should be optional |
| 15:34.17 | JeffM_ | trepan, already does |
| 15:34.29 | trepan | ah, an addition I hadn't see :) |
| 15:34.42 | JeffM_ | BulletCatcher, I may not have a domain so I want the list server to just use my IP and port |
| 15:35.07 | trepan | hm, where is the desc length check done? |
| 15:35.17 | JeffM_ | when -public is read |
| 15:35.19 | trepan | i see that it's clipped at 127 |
| 15:35.45 | JeffM_ | is that too long? |
| 15:35.46 | BulletCatcher | Something like 10.9.8.7:5154 can be used for servers without domain names. |
| 15:36.02 | JeffM_ | BulletCatcher, yes and the list server can figure that out |
| 15:36.10 | JeffM_ | so there is no need to provide it |
| 15:36.27 | JeffM_ | if you are on a dynamic IP you want the list server to get it every time you hit it |
| 15:36.31 | JeffM_ | so I don't want to provide it |
| 15:36.41 | Thumper_ | JeffM_: I don't think there is a minimum length check is there? |
| 15:36.51 | JeffM_ | ahh min len |
| 15:36.51 | trepan | -public " " is something else that might want to be avoided |
| 15:36.53 | JeffM_ | yeah I can do tht |
| 15:37.36 | brad | has lack of description ever been an issue? |
| 15:38.06 | JeffM_ | it would be nice if they all had them |
| 15:38.48 | Thumper_ | my admins can post maps on test server ports and without the -public it's blank on the server list. I added a check on my website used for starting the server but it would be better if bzfs just refused to list it |
| 15:39.18 | JeffM_ | that's what it's going to do when I'm done here |
| 15:39.46 | JeffM_ | what is the min lenght for a key? |
| 15:39.46 | Thumper_ | sounds good to me |
| 15:40.50 | BulletCatcher | IIRC, keys are random numbers so a single digit is possible. |
| 15:41.27 | blast007 | JeffM_: I think it's better to hae -publickey on it's own, since if someone ran their own list they wouldn't necessarily need them. And it's easier to have multiple servers share a common config (interface to bind to, public key, etc) |
| 15:41.59 | trepan | +1 |
| 15:41.59 | JeffM_ | hmm |
| 15:42.00 | Thumper_ | current 2.0.x servers with names are all > 8 chars. 3 minimum should be fine |
| 15:42.22 | Thumper_ | read 'names' not 'keys' |
| 15:42.25 | JeffM_ | I'm less concerned about the "running your own list server" cus nobody has EVER done that IIRC |
| 15:42.31 | JeffM_ | but the config thing is valid |
| 15:42.46 | brad | I have! |
| 15:42.51 | JeffM_ | why? |
| 15:42.56 | JeffM_ | and for how long? |
| 15:42.58 | blast007 | for the lulz? |
| 15:43.00 | brad | for like a day...just to see how it worke |
| 15:43.01 | brad | d |
| 15:43.14 | JeffM_ | then you could have made it accept any string as a key :) |
| 15:43.20 | trepan | blast007: you trying to bring down the heat? they scan for that string :) |
| 15:43.26 | JeffM_ | yeah nobody runs one for realsies |
| 15:43.33 | blast007 | trepan: heh |
| 15:43.38 | brad | well, could be someone somewhere :p |
| 15:43.59 | JeffM_ | it just seems odd that both are efetivly required |
| 15:44.02 | BulletCatcher | I am convinced. Keep the option, and keep it named -publickey . |
| 15:44.22 | blast007 | we'll get better errors when people are upgrading to 2.4 as well |
| 15:44.27 | JeffM_ | actualy I'm convinced that -public should just take the key, and -publicdesc should be added |
| 15:44.38 | blast007 | if we make it part of -public, it will make their config go crazy as it will read the next option as the key |
| 15:44.38 | BulletCatcher | Note that we don't support different keys for different list servers. |
| 15:44.57 | Thumper_ | is it the list server that enforces the requirement for -publickey so if you had your own list server you could remove that requirement? (of course it's completely hypothetical...) |
| 15:45.08 | JeffM_ | yes |
| 15:45.20 | trepan | -publickey is more descriptive, but maybe s/-public/-publictitle/ ? |
| 15:45.36 | JeffM_ | trepan, that's what I was thinking |
| 15:45.37 | trepan | or -publicdesc |
| 15:45.46 | JeffM_ | yeah cus that's all it does |
| 15:45.53 | BulletCatcher | I like title better than desc. |
| 15:45.59 | trepan | i suggesting leaving -publickey with the 'key' attached |
| 15:46.16 | JeffM_ | then make it so if you set any of the -public options we flag the server for listing |
| 15:46.46 | JeffM_ | that should make everyone happy |
| 15:46.53 | trepan | and flag missing opts as necessary, sounds good |
| 15:46.58 | JeffM_ | yeah |
| 15:49.11 | blast007 | also, is our "local bzfs detection" useful anymore? I haven't seen it work in a workstation environment, at least.. it grabs the netbios name, which ares can't resolve. Not sure if it works in a domain environment or on linux/OSX. |
| 15:49.32 | Thumper_ | -public is currently the name of the map normally |
| 15:49.52 | Thumper_ | blast007: a local non-public server shows up on my workstation in linux |
| 15:49.53 | blast007 | (and it generally seems to confuse people that are trying to host because they see it on the list) |
| 15:50.08 | blast007 | k - can you connect to it via the entry on the list? |
| 15:50.13 | Thumper_ | yes |
| 15:50.32 | blast007 | hmm. does it show the server name, FQDN, or the IP? |
| 15:50.57 | Thumper_ | I get gollum.intra.norang.ca as the host and I just pick it from the list with my 2.3 client |
| 15:51.20 | blast007 | and I imagine that your internal DNS can resolve that to the correct IP? |
| 15:51.24 | Thumper_ | yes |
| 15:51.41 | blast007 | probably not a typical situation then |
| 15:51.47 | Thumper_ | tries a fake /etc/hosts entry |
| 15:51.53 | JeffM_ | it dosn't have to be the map that's just convention |
| 15:52.19 | JeffM_ | if we wanted it to always be the "name" of the map then we'd have a name field in the world info object and send it automaticly |
| 15:52.38 | JeffM_ | because map and server not the same thing |
| 15:53.35 | Thumper_ | blast007: works with a host entry for the ip too |
| 15:53.40 | blast007 | k |
| 15:53.43 | Thumper_ | 192.168.1.5 ding.dang.dong.com ding |
| 15:54.03 | CIA-117 | BZFlag: 03JeffM2501 * r21921 10/trunk/bzflag/ (man/bzfs.6.in src/bzfs/CmdLineOptions.cxx): |
| 15:54.03 | CIA-117 | BZFlag: rename -public to -publictitle |
| 15:54.03 | CIA-117 | BZFlag: make -publickey also force the server to be listed |
| 15:54.17 | blast007 | I imagine that would work on Windows as well if I threw in a hosts entry, or if I was in a domain environment where systems had FQDN's registered in the local DNS server |
| 15:55.40 | Thumper_ | but I'm not married to it showing up in the list - since I start it myself I know the ip/address and port |
| 15:55.53 | Thumper_ | and if it's a private server on another host I need to manually enter that info anyway |
| 15:56.09 | Thumper_ | it _might_ help people who start their own servers from the menu (if that works) |
| 15:56.12 | blast007 | and afaik, it only detects servers on 5154 |
| 15:56.31 | CIA-117 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7743 10/w/BZFS_Command_Line_Options: /* The Options */ -public and -publickey |
| 15:56.33 | blast007 | generally though people just get confused by it cuz it doesn't work, or they think their server is publically listed cuz it's on the list |
| 15:56.41 | JeffM_ | that should do er |
| 15:56.41 | Thumper_ | looks like |
| 15:56.48 | Thumper_ | bzfs -p 10000 doesn't show up |
| 15:57.15 | Thumper_ | so I guess I don't care if we pull that feature or not |
| 15:57.38 | blast007 | yeah, something to think about for 2.4.2/2.4.4/whatever |
| 15:57.41 | JeffM_ | in the longrun we should optimize for internet play |
| 15:57.49 | JeffM_ | lan people can set up servers internet style |
| 15:58.01 | blast007 | is the multicast stuff for the server discovery? |
| 15:58.12 | JeffM_ | probalby |
| 15:58.23 | JeffM_ | tho the server used to use multicast for playing |
| 15:58.33 | JeffM_ | sending out player updates etc... |
| 16:00.17 | BulletCatcher | Thumper_: Would you mind if the "serverControl - %d total players, %d observers" message were changed from debug level 2 to 3? |
| 16:00.18 | BulletCatcher | It is noisier than I'd like. |
| 16:00.41 | Thumper_ | not at all. I only care about level 0 messages |
| 16:01.01 | BulletCatcher | Okay, thanks. I'll do it. |
| 16:01.04 | Thumper_ | and at the time I didn't want it buried in the network stuff at level 4 |
| 16:02.16 | trepan | JeffM_: CmdLineOptions.cxx:967 -- that supposed to be 'false' ? |
| 16:02.48 | Thumper_ | goes for lunch |
| 16:03.03 | JeffM_ | probably not |
| 16:03.14 | JeffM_ | can't really run a public server at work :) |
| 16:03.37 | trepan | if (options.publicizedKey.length() == 0) { \n options.publicizeServer = true; |
| 16:03.38 | CIA-117 | BZFlag: 03bullet_catcher * r21922 10/trunk/bzflag/plugins/serverControl/serverControl.cpp: Change player count messages from debug level 2 to 3. |
| 16:03.43 | JeffM_ | yeah I see it |
| 16:03.43 | blast007 | JeffM_: you mean 'probaby' ;) |
| 16:03.45 | JeffM_ | fixing |
| 16:03.48 | blast007 | it's true right now |
| 16:04.43 | CIA-117 | BZFlag: 03JeffM2501 * r21923 10/trunk/bzflag/src/bzfs/CmdLineOptions.cxx: make servers NOT be public if they provide an empty key |
| 16:05.07 | trepan | might want to move the -publiclist processing to after -publickey, it doesn't seem to trigger options.publicizeServer |
| 16:05.16 | *** join/#bzflag Upsetter (~er@i59F6D4F4.versanet.de) |
| 16:05.57 | JeffM_ | order matters in that thing? |
| 16:06.00 | JeffM_ | I thought it was a loop |
| 16:06.40 | blast007 | shouldn't matter |
| 16:06.48 | JeffM_ | if -publickey is after it would go and set the flag alone and then when it is all done it'd use both settings |
| 16:07.20 | blast007 | should we even be setting options.publicizeServer to false? |
| 16:07.41 | JeffM_ | I only did it when they specify a bad key |
| 16:07.41 | trepan | just remove the check and let it fail? |
| 16:07.51 | JeffM_ | figured it was nicer |
| 16:08.00 | JeffM_ | if they are on another list server they won't specify a key at all |
| 16:08.09 | blast007 | ok |
| 16:08.18 | JeffM_ | if we let it go thru they don't get any indication of a problem |
| 16:08.22 | JeffM_ | it just isn't on the list |
| 16:08.55 | CIA-117 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7744 10/w/BZFS_2.4_Upgrade: note -public was renamed -publictitle |
| 16:09.24 | CIA-117 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7745 10/w/BZFS_2.4_Upgrade: /* = -public is now -publictitle */ missing = |
| 16:12.04 | *** join/#bzflag JUR (d50a0f36@gateway/web/freenode/ip.213.10.15.54) |
| 16:22.03 | CIA-117 | BZFlag: 03bullet_catcher * r21924 10/trunk/bzflag/TODO: |
| 16:22.06 | CIA-117 | BZFlag: Remove multiple list servers item; it is done. |
| 16:22.06 | CIA-117 | BZFlag: Remove idea for -email command line option; it is superseded by -publickey. |
| 16:23.43 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7746 10/w/BZFS_2.4_Upgrade: Move the TODO items up front so they are more visible |
| 16:27.30 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7747 10/w/BZFS_2.4_Upgrade: Demote the heading levels |
| 16:30.55 | CIA-117 | BZFlag: 03bullet_catcher * r21925 10/trunk/bzflag/src/bzfs/CmdLineOptions.cxx: Add -publickey to usageString. |
| 16:36.43 | CIA-117 | BZFlag: 03bullet_catcher * r21926 10/trunk/bzflag/ (5 files in 4 dirs): |
| 16:36.43 | CIA-117 | BZFlag: More changes of -public to -publictitle. |
| 16:36.43 | CIA-117 | BZFlag: Update man page descriptions of dependencies between the -public* options. |
| 16:47.21 | JeffM_ | I thought I did the manpage |
| 16:47.25 | JeffM_ | what'd I miss? |
| 16:52.16 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:59.04 | BulletCatcher | The old -public option was mentioned inside some of the other man page descriptions, and not necessarily in a way that was consistent with the code. |
| 17:09.46 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 17:12.21 | JeffM_ | ahh |
| 17:13.31 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 17:13.31 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 17:13.39 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 17:14.03 | *** topic/#bzflag by JeffM -> http://my.BZFlag.org || http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || Alpha testing of 2.3 is going on now || 2.4 beta on 6/20/11 |
| 17:24.12 | meeba | I'm not sure which of you decided bzflag would be cool to work on again, but I can't wait till I'm back on a stable connection again so I can get in on the fun of playing. |
| 17:26.51 | Thumper_ | blames JeffM |
| 17:27.33 | meeba | man, what a jerk that guy is. :) |
| 17:28.03 | blast007 | wasn't it BulletCatcher that initiated the creation of the plan? :) |
| 17:28.25 | Thumper_ | could be - first I heard about it was the email from Jeff |
| 17:28.27 | mdskpr_ | yup, its bulletcatcher's fault |
| 17:28.37 | Thumper_ | see I'm wrong again :/ |
| 17:29.09 | Thumper_ | we're doing something completely new |
| 17:29.16 | Thumper_ | ... there's a plan |
| 17:29.17 | blast007 | planning! |
| 17:29.35 | Thumper_ | and it's not "we plan to fail" |
| 17:29.36 | blast007 | I think this is the first time in my experience with the project that there was a plan. |
| 17:32.47 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 17:40.09 | JeffM | it was BulletCatcher |
| 17:40.19 | JeffM | he started the plan |
| 17:40.32 | JeffM | blast007, and myself just yelled at Tim |
| 17:42.46 | *** join/#bzflag Calzaath (41251e55@gateway/web/freenode/ip.65.37.30.85) |
| 17:43.05 | Calzaath | can i texture with a .gif file? |
| 17:43.17 | blast007 | no |
| 17:43.23 | blast007 | we only support PNG files |
| 17:43.24 | Calzaath | doh |
| 17:43.44 | blast007 | you can certainly convert a GIF to a PNG though, minus any animation |
| 17:44.10 | Calzaath | would it be possible to make a plug-in that would allow me to play .wav or .mp3 files on my map? |
| 17:44.56 | JeffM | nope |
| 17:45.02 | Calzaath | doh |
| 17:45.05 | JeffM | plugins don't do anything with the client |
| 17:45.14 | Calzaath | oh well |
| 17:45.29 | JeffM | well I guess you could make one but it would play the sound on the server machine :) |
| 17:45.41 | Thumper_ | heh - he's gone |
| 17:46.01 | blast007 | JeffM: was the reason that clients crashed when playing plugin-initiated sound files because of older versions of 2.0? or was it just buggy in general? |
| 17:46.04 | Thumper_ | pictures sheet music floating by on the server map |
| 17:46.21 | JeffM | it had to do with where the sounds were located on different machines |
| 17:46.34 | blast007 | I mean files hosted via HTTP |
| 17:46.39 | blast007 | thought we could point them at a resource |
| 17:46.55 | JeffM | it wasn't saved to the disk in a good place where the client could always get it |
| 17:47.00 | blast007 | k |
| 17:47.01 | JeffM | the sound system assumed bzfs dir |
| 17:47.05 | JeffM | sorry client APP dir |
| 17:47.10 | JeffM | where the other sounds are |
| 17:47.11 | blast007 | ah |
| 17:47.17 | JeffM | we need to make it work with the cache system |
| 17:47.27 | JeffM | search multiple dirs etc.. |
| 17:47.29 | blast007 | alright |
| 17:47.52 | JeffM | it is really just an extension of what we do for images |
| 17:47.58 | blast007 | yeah |
| 17:50.41 | trepan | had started patching 3.0 to have it use BzVFS for all file accesses |
| 17:51.17 | trepan | "278431 Sep 27 2010 SVN.vfsChanges.diff" that one :) |
| 17:57.47 | allejo | is it my imagination or is there a variable that will let you take multiple hits with the shield flag? |
| 17:59.21 | JeffM | nope |
| 18:05.11 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 18:14.50 | blast007 | allejo: to be more specific, no, there is not a variable like that |
| 18:17.56 | allejo | alright. thanks for the info |
| 18:26.18 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 18:26.18 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 19:07.04 | *** join/#bzflag ibunny (~alex_2@pdpc/supporter/active/jolie) |
| 19:07.26 | *** part/#bzflag ibunny (~alex_2@pdpc/supporter/active/jolie) |
| 19:29.16 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 19:36.10 | *** join/#bzflag TD-Linux (~thomas@68-115-86-128.dhcp.roch.mn.charter.com) |
| 19:36.10 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 19:48.36 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 19:49.38 | CIA-117 | BZFlag: 03JeffM2501 * r21927 10/trunk/bzflag/src/bzflag/playing.cxx: IFF should not be based off "IsKillable" so add new function "IsFriendly" to say who your true friends are. |
| 19:51.53 | randomparticle | playerID is typed as both uint8_t and int |
| 19:52.27 | randomparticle | ../../include/Address.h:typedef uint8_tPlayerId; |
| 19:52.37 | randomparticle | ../../include/bzfsAPI.h: int playerID; |
| 19:53.03 | JeffM | yep |
| 19:53.14 | JeffM | the byte is jus to cap it for transmison |
| 19:53.16 | JeffM | int is easier to use |
| 19:53.32 | JeffM | I've been making as many of them int as I can so we can support more then 250 players someday |
| 19:53.41 | randomparticle | i've noticed the initial reply from the server is BZFS0026 + a 1 byte player id |
| 19:53.56 | JeffM | yep |
| 19:54.07 | JeffM | it's still a byte over the wire |
| 19:54.09 | randomparticle | but for messages it's len + MsgMessage code + 2 byte player id + string |
| 19:54.16 | Pimpinella | will we ever need more than 250 players? |
| 19:54.30 | JeffM | Pimpinella, yes for awesomeness. |
| 19:54.39 | Pimpinella | ;) |
| 19:57.39 | JeffM | randomparticle, where do we pull the player as a short? |
| 19:57.55 | randomparticle | pull? |
| 19:58.00 | JeffM | unpack |
| 19:58.35 | JeffM | on the client or server? |
| 19:58.48 | blast007 | and which version of the game are we talking about? |
| 19:58.52 | randomparticle | i've been looking at this client side |
| 19:58.57 | JeffM | for the client I see buf = nboUnpackUByte(buf, id); |
| 19:58.59 | JeffM | that's a byte |
| 19:59.02 | blast007 | in 2.3 there's a message type byte now too |
| 19:59.04 | JeffM | so where do you see it read 2 bytes? |
| 19:59.16 | randomparticle | actually looking at the incoming stream of bytes off the net |
| 19:59.31 | blast007 | randomparticle: which version of bzflag? |
| 19:59.48 | randomparticle | the string always starts 6 bytes in for MsgMessage, that is 2 bytes after the length and code header |
| 19:59.51 | trepan | randomparticle: unpack src / dst / type ? |
| 20:00.09 | JeffM | nethandler should pull of 2 for len, 2 for code |
| 20:00.17 | randomparticle | yeah |
| 20:00.23 | blast007 | doesn't think his question is that hard to answer.... |
| 20:00.28 | randomparticle | so that sort of indicates the playerid is an uint16_t |
| 20:00.33 | JeffM | it isn't |
| 20:00.40 | blast007 | randomparticle: please answer my question |
| 20:00.41 | JeffM | only a few messages HAVE a player ID |
| 20:00.48 | Pimpinella | hmm, svn is either extremly slow or it hangs completly for me |
| 20:00.51 | JeffM | yeah trunk or branch? |
| 20:00.52 | randomparticle | this is client side incoming MsgMessage |
| 20:01.06 | randomparticle | 2.0.16 bzfs. i can check trunk |
| 20:01.12 | blast007 | trunk is different |
| 20:01.24 | randomparticle | yeah. let me start it up. few moments plz |
| 20:01.29 | JeffM | yeah it's 2 IDs |
| 20:01.33 | JeffM | from and 2 |
| 20:01.36 | JeffM | to |
| 20:01.48 | JeffM | as trepan said |
| 20:02.00 | JeffM | trunk has 3 bytes |
| 20:02.02 | JeffM | adding a type |
| 20:02.31 | randomparticle | yeah. my code isn't working with trunk: |
| 20:02.34 | randomparticle | 2011-06-15 21:01:57.750 BZX[1544:a0f] An error occurred on the input stream. :--) |
| 20:02.48 | JeffM | optimaly we would extend the type and get rid of the "to" |
| 20:03.00 | blast007 | ? |
| 20:03.02 | JeffM | since it's only used to know if it's a team message, or what |
| 20:03.12 | JeffM | we know who it's to, the socket it got sent to :) |
| 20:03.22 | randomparticle | yeah |
| 20:03.22 | blast007 | type is if it's a chat message or an action message |
| 20:03.34 | JeffM | yes it is, but it could be so much more :) |
| 20:04.17 | JeffM | the dst is a bit of a misnomer, cus it's not like it will ever be a message for another player |
| 20:04.19 | Pimpinella | this tanks and flags don't spawn on bases after cap bug, is that a new bug or is it pre 2.0 ? |
| 20:04.33 | JeffM | the only rason we need it is to know if it's to the team or a private message, etc.. |
| 20:04.37 | JeffM | and that could be put in the type |
| 20:04.48 | blast007 | Pimpinella: does the server have freeCtfSpawns in the map file? |
| 20:04.56 | randomparticle | need a src in there really to fake messages from people you don't like ;--) |
| 20:05.04 | blast007 | or zones? |
| 20:05.19 | JeffM | randomparticle, you need the source to know who it's from, we display that in the chat window |
| 20:05.24 | JeffM | it's the dst we don't need |
| 20:05.33 | JeffM | we know it is for us |
| 20:05.37 | JeffM | or the server would not have sent it |
| 20:05.41 | randomparticle | yeah |
| 20:05.53 | JeffM | it's a holdover from when the server sent ALL chat to ALL clients |
| 20:05.54 | blast007 | ah, I see what you mean |
| 20:06.00 | Pimpinella | blast007: no, it's the buildin map that you get when you just start bzfs with -c |
| 20:06.12 | blast007 | Pimpinella: then yeah, I'd say it's borked :) |
| 20:06.14 | randomparticle | ok, so let's take a look at what bzfs 2.3 is throwing at me. |
| 20:06.23 | JeffM | randomparticle, the extra byte |
| 20:06.42 | JeffM | read the code before you look at the data then you can know what to expect |
| 20:06.48 | Pimpinella | blast007: so, is that a really, really old bug? |
| 20:06.57 | blast007 | dunno |
| 20:07.01 | blast007 | does 2.0.16 do the same thing? |
| 20:07.41 | Pimpinella | checks if he has a 2.0.x server locally |
| 20:10.27 | Pimpinella | yep, seems so |
| 20:10.55 | blast007 | that sucks |
| 20:11.13 | blast007 | however, spawns are server-side, so we could fix that for 2.4.whatever later |
| 20:11.23 | blast007 | and it's not a new bug |
| 20:12.36 | JeffM | stupid clients FTW! |
| 20:12.42 | blast007 | Pimpinella: document it here: http://my.bzflag.org/w/Development_RoadMap |
| 20:13.04 | JeffM | should we just name that page "the plan"? :) |
| 20:13.21 | blast007 | heh |
| 20:13.34 | JeffM | or make a The_Plan page that redirects there |
| 20:13.48 | *** topic/#bzflag by JeffM -> http://my.BZFlag.org || http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || Alpha testing of 2.3 is going on now || 2.4 beta on 6/20/11 || The PLAN http://my.bzflag.org/w/Development_RoadMap |
| 20:14.15 | JeffM | TimRiker, you arround? |
| 20:22.14 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 20:22.14 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 20:22.49 | CIA-117 | BZFlag: 03pimpinella * r21928 10/trunk/bzflag/src/bzfs/bzfs.cxx: Fix random spawns of flags and players after cap. |
| 20:23.31 | *** join/#bzflag Upsetter1 (~er@i59F6C6DF.versanet.de) |
| 20:23.36 | Pimpinella | blast007: should be fixed |
| 20:23.43 | blast007 | hehe, okay |
| 20:25.27 | blast007 | Pimpinella: actually, could you revert that change for now? |
| 20:25.40 | blast007 | I think we should look into that further |
| 20:26.02 | blast007 | random worlds get recreated after all the players leave |
| 20:26.21 | blast007 | so the real problem would probably be if it's not recreating the bases |
| 20:27.01 | blast007 | also, above, I assume you were talking about using -cr, not -c |
| 20:27.26 | blast007 | I'm referring to this: < Pimpinella> blast007: no, it's the buildin map that you get when you just start bzfs with -c |
| 20:27.46 | blast007 | -c requires a world, where -cr is a random CTF map |
| 20:30.43 | Pimpinella | blast007: yep, i can revert it, however -c works without a world, just try |
| 20:31.08 | blast007 | hmm |
| 20:31.16 | blast007 | then how is -c different than -cr? |
| 20:31.39 | bryjen | there was a built-in procedurally generate world, iirc |
| 20:32.22 | blast007 | bryjen: talking about the normal random boxes through around, or the GSoC project? |
| 20:32.28 | blast007 | thrown* |
| 20:32.59 | bryjen | no, the built-in ctf world had more of a pattern |
| 20:33.14 | blast007 | ah |
| 20:34.03 | blast007 | in any case, I don't consider it to be a critical bug, and I think we should take more time to look at it --> so after 2.4.0 is out |
| 20:34.38 | blast007 | kills CIA-117 |
| 20:35.24 | bryjen | heh. when the CIA kills _you_, it'll be quieter about it |
| 20:37.22 | Pimpinella | no log? |
| 20:37.33 | Pimpinella | ah, CIA is out |
| 20:48.59 | Pimpinella | svn is a pain tonight |
| 20:52.38 | JeffM | just SF :) |
| 20:55.46 | randomparticle | does bzfs close the socket if i don't send "BZFLAG\r\n\r\n"? |
| 20:56.27 | randomparticle | i'm getting BZFS0213 etc back from bzfs, but it looks like the socket is being closed |
| 20:56.41 | JeffM | after a bit yes it will |
| 20:56.55 | randomparticle | i'll try sending that before i read anything |
| 20:57.02 | JeffM | it should not send anything untill you send the connection string |
| 20:57.04 | JeffM | you have to |
| 20:57.11 | JeffM | for trunk |
| 20:57.28 | randomparticle | it is sending the server identifier without me sending that (trunk) |
| 20:57.35 | JeffM | that's not good |
| 20:58.22 | randomparticle | that's more or less how it worked with 2.0.16. it would send the identifier when the TCP connection was made |
| 20:58.31 | JeffM | yes it changed in trunk |
| 20:58.42 | JeffM | in trunk the server waits for the client to send data |
| 20:58.51 | JeffM | what are you sending first? |
| 20:58.51 | randomparticle | not here :--) |
| 20:58.54 | *** join/#bzflag CIA-117 (~CIA@cia.atheme.org) |
| 20:58.57 | JeffM | anything? |
| 20:58.59 | randomparticle | nothing. just making a TCP Connection |
| 20:59.06 | JeffM | you sure? |
| 20:59.12 | trepan | nor here, i see the same thing, BZFS0213 without any data sent |
| 20:59.13 | JeffM | oh ok, I know what's happening then |
| 20:59.18 | JeffM | yeah heah I know |
| 20:59.26 | JeffM | what we do is IF you time out I send out the protocoll |
| 20:59.33 | JeffM | so it shows in a browser if no HTTP is installed |
| 20:59.43 | JeffM | and so that old query scrips know to fail |
| 20:59.46 | JeffM | yeah that's expected |
| 20:59.50 | JeffM | forgot about that |
| 20:59.58 | JeffM | so yes it will close RIGHT after that |
| 21:00.04 | JeffM | that's the error case |
| 21:00.10 | randomparticle | ok. so i send the string first thing? |
| 21:00.14 | JeffM | ye |
| 21:00.15 | JeffM | yeah |
| 21:00.26 | randomparticle | ok. giving it a try |
| 21:00.47 | JeffM | if you don't send it, it looks for API handlers to try and accept the connection |
| 21:00.50 | trepan | about a 3 second timeout (from 'nc' to BZFS0213 reply) |
| 21:01.03 | JeffM | it won't hand the connection over to the player code untill you send the bzflag stuff |
| 21:01.12 | JeffM | hmm it should be longer |
| 21:01.21 | JeffM | wonder if I'm off by 10 |
| 21:03.20 | trepan | JeffM: I see bzfs/idleTimeout is set to 30, odd |
| 21:03.36 | *** join/#bzflag Anxuiz (~Anxuiz@c-76-22-102-23.hsd1.wa.comcast.net) |
| 21:03.37 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 21:04.57 | randomparticle | trepan: i've been debugging using breakpoints |
| 21:05.07 | randomparticle | could easily mean a >3s delay |
| 21:05.24 | trepan | i'm seeing 3, using 'nc' (netcat) |
| 21:05.55 | trepan | (and counting with mississippis) |
| 21:07.08 | trepan | for the record, when i 'time' it, it's consistently 2.608s |
| 21:08.05 | trepan | wonder if i'm developing a southern drawl, would account for the 0.4s |
| 21:08.26 | trepan | (oops, wrong way) |
| 21:10.47 | randomparticle | ok. some progress. i'm getting a reject and superkill message before the stream is closed |
| 21:11.00 | randomparticle | but the initial bit's looking okish now |
| 21:11.26 | randomparticle | so i'll have a look and see why i'm being rejected |
| 21:11.45 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 21:11.45 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 21:20.10 | randomparticle | rejection reason:invalid request |
| 21:21.32 | randomparticle | and from bzfs.cxx: |
| 21:21.33 | randomparticle | logDebugMessage(1,"Host %s tried to send invalid message before Enter; 0x%4hx\n",handler->getTargetIP(),code); |
| 21:26.33 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 21:26.33 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 21:27.11 | JeffM | I wonder if I have a sec to ms timer off or something |
| 21:28.04 | JeffM | ahh I see connectionTimeout is set to 2.5 |
| 21:28.29 | JeffM | the 30 sec is for if they send some data but never get accepted by anything |
| 21:29.38 | JeffM | thats 2500 ms , if your TCP latency is that high for your first packet then I don't think we want you playing :) |
| 21:31.21 | bryjen | the 2.5 is 'cause old bzflag client only wait 5 seconds and gives up with a generic error. new bzfs needs to give up quicker and say BZFSxxxx so the old client can say incompatible server version. |
| 21:31.54 | bryjen | if you're talking about what i think you are |
| 21:32.34 | JeffM | that makes sense |
| 21:33.00 | randomparticle | does bzfs have a debugging mode command line arg? |
| 21:33.04 | JeffM | then all seems to be working as it should |
| 21:33.10 | JeffM | -d |
| 21:33.13 | randomparticle | thanks |
| 21:33.27 | JeffM | it just logs more |
| 21:33.41 | JeffM | there are 4 levels depending on how many ds you put in |
| 21:34.38 | Constitution | heya snick |
| 21:35.03 | randomparticle | hi |
| 21:35.04 | randomparticle | Player [0] accept() from 127.0.0.1:51096 on 7 |
| 21:35.04 | randomparticle | Host 127.0.0.1 tried to send invalid message before Enter; 0x 0 |
| 21:35.04 | randomparticle | Player [0] removed at 2011-06-15 22:33:40: /rejected |
| 21:35.25 | JeffM | what exactly are you trying to do? |
| 21:35.40 | randomparticle | connect to my local bzfs server from my program |
| 21:35.54 | JeffM | so implement your own version of the clientprotocoll |
| 21:35.56 | JeffM | good luck |
| 21:36.07 | randomparticle | that's what i'm doing. is it documented fully? |
| 21:36.09 | JeffM | Constitution, you willing/able to build mac bins? |
| 21:36.15 | JeffM | randomparticle, oh god no |
| 21:36.19 | JeffM | hence the good luck |
| 21:36.26 | randomparticle | thanks ;--) |
| 21:36.27 | JeffM | you will be reading a lot of the client code |
| 21:36.36 | randomparticle | had it working under 2.0.16 |
| 21:36.52 | JeffM | ok |
| 21:36.54 | JeffM | it changed |
| 21:51.33 | *** part/#bzflag Upsetter1 (~er@i59F6C6DF.versanet.de) |
| 21:54.00 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 21:54.00 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 22:07.06 | Constitution | JeffM: yeah should be |
| 22:07.16 | JeffM | Constitution, ok |
| 22:07.23 | JeffM | I'd like to have one for beta |
| 22:07.36 | Constitution | k |
| 22:07.51 | JeffM | with no debug info this time too :) |
| 22:07.56 | JeffM | and we decided we don't need a DMG |
| 22:08.11 | Constitution | app store then? ;) |
| 22:08.14 | JeffM | I leave universal/X86 and minium OS version up to you |
| 22:08.18 | JeffM | naw just a zip file |
| 22:08.46 | Constitution | iirc plugins didn't link right when I stripped out symbols, but maybe I was doing it wrong |
| 22:08.56 | JeffM | ok see what you can do |
| 22:09.07 | JeffM | if we have to leave em in for bzfs that's fine |
| 22:09.22 | Constitution | when is the beta due? |
| 22:09.37 | JeffM | the 20th |
| 22:20.59 | trepan | ouch, i'm sure how useable streflop is going to be, the latest version in rough shape |
| 22:21.48 | trepan | (and with that, my recent work on a lua based libbzw like transfer is dead) |
| 22:21.51 | trepan | *without |
| 22:22.18 | trepan | had a nice lua bzw parser started and everything :) |
| 22:34.51 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7748 10/w/BZFS_API_2.4_Upgrade: fixed typo and corrected the name of incorrect function |
| 22:37.05 | *** join/#bzflag TyroneFHornigh (~dbw@adsl-71-136-247-199.dsl.sndg02.pacbell.net) |
| 22:41.43 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 22:41.43 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 22:47.59 | delusional | what's the default path to a saved world in linux |
| 22:48.01 | delusional | ? |
| 22:48.29 | trepan | it should tell you in the console |
| 22:48.40 | CIA-117 | BZFlag: 03Allejo 07http://my.bzflag.org * r7749 10/w/BZFS_API_2.4_Upgrade: clarified purpose of a "NAME" |
| 22:48.45 | trepan | iirc, it's something like ~/.bzf/worlds |
| 22:48.54 | delusional | if I had linux. |
| 22:49.59 | blast007 | delusional: in the same relative location as the config |
| 22:50.31 | blast007 | the worlds folder will be next to the 2.0 folder |
| 22:51.02 | delusional | I'm just gonna tell him to read his console |
| 22:59.32 | *** join/#bzflag DarkCalf (DC@2002:ade7:2862::ade7:2862) |
| 23:36.49 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 23:36.49 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 23:44.05 | *** join/#bzflag cygal_ (~cygal@wtf.awesom.eu) |
| 23:46.22 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7750 10/w/BZFS_2.4_Upgrade: Add details about -publictitle and reformat |
| 23:48.56 | CIA-117 | BZFlag: 03Thumper 07http://my.bzflag.org * r7751 10/w/BZFS_2.4_Upgrade: |
| 23:49.51 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 23:55.54 | *** join/#bzflag dcat (~dcat@c-98-249-63-154.hsd1.va.comcast.net) |
| 23:58.46 | *** join/#bzflag fahadsadah_ (fahad@unaffiliated/fahadsadah) |
| 23:59.56 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
| 23:59.56 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 23:59.56 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 23:59.56 | *** join/#bzflag delusional (~delusiona@unaffiliated/delusional) |
| 23:59.56 | *** join/#bzflag Nitroxis (~nitroxis@2a01:4f8:7d:200:0:4e2f:b550:3) |
| 23:59.56 | *** mode/#bzflag [+ov JeffM JeffM] by anthony.freenode.net |