| 00:06.17 | *** join/#bzflag bier|tp (n=bier@p54A56499.dip.t-dialin.net) |
| 00:10.05 | *** join/#bzflag Constitution (n=const@unaffiliated/macsforme) |
| 00:39.30 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 00:43.13 | *** join/#bzflag bryjen (n=bryjen@CPE-76-177-176-191.natsoe.res.rr.com) |
| 00:43.14 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 01:16.26 | *** join/#bzflag eTangenT (n=etangent@71-211-200-94.hlrn.qwest.net) |
| 01:18.08 | Constitution | are local shot IDs supposed to be negative? |
| 01:18.46 | Winny | they encourage you to think positively. |
| 01:19.00 | Constitution | ha |
| 01:19.05 | JeffM | yes |
| 01:19.16 | JeffM | they are negitive untill they get replaced with a global ID |
| 01:19.27 | Constitution | okay... I'm getting 0 to -2 for three shots |
| 01:19.30 | JeffM | good |
| 01:19.39 | CBG | 0's not negative :/ |
| 01:19.41 | Constitution | but when the server unpacks them they're all -1, it appears |
| 01:19.47 | JeffM | hmm |
| 01:19.49 | JeffM | that'd not be good |
| 01:19.57 | JeffM | it should be negitive |
| 01:20.01 | JeffM | non repeating |
| 01:20.04 | JeffM | the idea is this |
| 01:20.09 | JeffM | client fires a shot |
| 01:20.26 | JeffM | gives it a temporary negitive ID |
| 01:20.33 | JeffM | that way it can never overlap the global IDs |
| 01:20.40 | JeffM | then sends the ID with the shot begin |
| 01:20.55 | JeffM | server gets the message, and greates a real global shot |
| 01:20.58 | JeffM | with a real global shot ID |
| 01:21.17 | JeffM | then sends a shotID message back to the shooter |
| 01:21.20 | JeffM | it has his local ID and the new global ID |
| 01:21.31 | JeffM | client gets that then changes the local shot to the new global ID |
| 01:21.53 | JeffM | then the server broadcasts the shot message with the global ID to everyone |
| 01:21.56 | JeffM | including the shooter |
| 01:22.19 | JeffM | then everyone updates that global shot to the server provided data |
| 01:22.26 | JeffM | creating the shot if it did not exist |
| 01:22.35 | JeffM | so everyone but the shooter will create the shot |
| 01:22.42 | JeffM | the shooter will update to the servers data |
| 01:22.46 | JeffM | and all will be good |
| 01:22.46 | Constitution | right, ok |
| 01:23.12 | Constitution | let me correct myself... the shot IDs are correct, but player->findShot() consistently returns -1 |
| 01:23.27 | JeffM | on the server or client? |
| 01:23.30 | Constitution | server |
| 01:23.37 | Constitution | which makes the HitHandler return |
| 01:23.40 | Constitution | and no one dies |
| 01:23.41 | JeffM | hmmm |
| 01:23.43 | JeffM | ok |
| 01:23.54 | JeffM | wait |
| 01:23.56 | JeffM | your in hit? |
| 01:24.02 | JeffM | you should never have negs on a hit |
| 01:24.14 | Constitution | HitHandler |
| 01:24.23 | Constitution | the client sends MsgHit |
| 01:24.28 | JeffM | yeah the hit should never/rarely happen with the local ide |
| 01:24.31 | JeffM | ID |
| 01:24.46 | JeffM | the shooter should have goten back the global ID and used THAT for the msg Hit |
| 01:24.54 | JeffM | ok, so just the shot lookups are bad |
| 01:25.09 | JeffM | what ID is being sent into FindShot? |
| 01:25.18 | JeffM | a positive or a negitive? |
| 01:25.19 | Constitution | same ones... 0, -1, 02 |
| 01:25.22 | Constitution | *-2 |
| 01:25.28 | JeffM | that's the problem |
| 01:25.35 | JeffM | the client never got the update message |
| 01:25.53 | Constitution | hmm |
| 01:25.58 | JeffM | look over what we do when whe get a MsgShotBegin |
| 01:26.10 | JeffM | I have to leave but I can look at it when I get home |
| 01:26.16 | JeffM | after I feed myself |
| 01:26.44 | JeffM | basicly negitive IDs in anything other then msgBegin mean 1 of 2 things |
| 01:26.47 | JeffM | or 3 things |
| 01:26.49 | JeffM | lag is high |
| 01:26.54 | JeffM | distances are close |
| 01:26.55 | JeffM | or bug |
| 01:27.07 | Constitution | I just tried from far away... same thing |
| 01:27.24 | Constitution | er, I think... |
| 01:27.31 | JeffM | actualy 1 and 2 can ONLY happen on a suicide |
| 01:27.49 | Constitution | yeah... other players do not see shots at all |
| 01:28.15 | JeffM | Check the shotbegin handler |
| 01:28.23 | JeffM | I'll be back in like 45 min |
| 01:28.34 | JeffM | or less if I can swing it |
| 01:28.39 | Constitution | k, I've got fencing for 2 hours... I'll be back after that |
| 01:28.44 | JeffM | ok |
| 01:29.03 | JeffM | then I'll go over it while you learn how to do things before you get shot ;) |
| 01:36.02 | *** join/#bzflag Invisionfree (n=kvirc@12-203-90-214.client.mchsi.com) |
| 01:36.31 | Invisionfree | How can I fix this? "Unknown BZDB variable: _countdownResumeDelay" |
| 01:37.06 | blast007 | remove it from your config/map |
| 01:37.13 | Invisionfree | .. |
| 01:37.21 | Invisionfree | It's for a GU league practice server tho :( |
| 01:37.22 | blast007 | your bzfs version must not support that variable |
| 01:37.33 | blast007 | what version of bzfs are you running? |
| 01:37.52 | Invisionfree | 2.0.8 |
| 01:37.55 | blast007 | that's old |
| 01:37.57 | blast007 | upgrade |
| 01:38.06 | blast007 | 2.0.10 is the current version |
| 01:38.12 | blast007 | I assume it's in there |
| 01:38.19 | blast007 | I know it's in my 2.0.11 build |
| 01:38.30 | Invisionfree | 2.0.8 was in Debians repos |
| 01:38.43 | AAA_awright | Debian is ignorant like that |
| 01:38.46 | blast007 | build your own then :) |
| 01:38.46 | AAA_awright | ducks |
| 01:38.55 | AAA_awright | It isn't hard to build bzfs |
| 01:39.12 | Invisionfree | Link to 2.0.11 for it? |
| 01:39.24 | AAA_awright | Have SVN? |
| 01:39.34 | AAA_awright | Wait, I can provide a tar.gz |
| 01:40.08 | AAA_awright | http://bzfx.net/cgi-bin/gitweb.cgi?p=bzflag_gitsvn/.git;a=snapshot;h=bc3d5e677da04da880f4117816f205f7c31013db;sf=tgz |
| 01:40.34 | Invisionfree | Is there a direct link so I can wget it? :x |
| 01:41.41 | Invisionfree | AAA_awright: ? |
| 01:42.58 | AAA_awright | Invisionfree: That is a semi-direct link |
| 01:43.08 | AAA_awright | It should provide a working tarball... |
| 01:43.09 | AAA_awright | checks |
| 01:43.41 | Invisionfree | Hm |
| 01:43.47 | Invisionfree | There's a beta of 2.1.x? |
| 01:44.46 | AAA_awright | Invisionfree: That is 2.0.11 |
| 01:45.19 | Invisionfree | How do I CLI install a .deb? |
| 01:46.43 | AAA_awright | dpkg -i packagename |
| 01:46.54 | AAA_awright | packagefile that is |
| 01:47.00 | AAA_awright | Invisionfree: You found a .deb? |
| 01:47.15 | Invisionfree | Yep :) |
| 01:47.31 | Invisionfree | http://beta.bzflag.bz/builds/2.0.x/ |
| 01:47.43 | AAA_awright | Then: sudo dpkg -i package.deb |
| 01:48.17 | AAA_awright | So it doesn't have the very latest commits, but it shouldn't matter, that works |
| 01:49.05 | Invisionfree | Still doesnt have _countdownResumeDelay, damn it. |
| 01:50.04 | Invisionfree | AAA_awright: svn co what for 2.0.11 server? |
| 01:50.20 | AAA_awright | ~bzsvn |
| 01:50.24 | ibot | extra, extra, read all about it, bzsvn is http://my.bzflag.org/w/BZFlag_SVN and svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag bzflag |
| 01:51.13 | AAA_awright | Invisionfree: svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag/ bzflag |
| 01:51.28 | AAA_awright | note the "v2_0branch" checkout |
| 01:54.36 | Invisionfree | AAA_awright: What's the last file it shoudl get? |
| 01:54.50 | Invisionfree | It stopped at teleporter.cxx |
| 01:55.12 | AAA_awright | I don't think order matters, it takes me 3-4 minutes to get everything though |
| 01:55.25 | Invisionfree | Mine just froze though . |
| 01:55.27 | Invisionfree | ..* |
| 01:56.01 | AAA_awright | Lemme check to see exactly which version _countdownResumeDelay was introdiced |
| 01:57.24 | AAA_awright | 2.0.7? |
| 01:57.36 | *** join/#bzflag Quol (n=ian@modemcable199.71-57-74.mc.videotron.ca) |
| 01:57.47 | Invisionfree | Quol! |
| 01:57.48 | AAA_awright | commit 13522: Fix resuming countdowns and change _countdownResumeDelay to _countdownResumeTime in order to be consistant with the other variables |
| 01:57.49 | Invisionfree | Help! :( |
| 01:57.54 | blast007 | Invisionfree: 2.1.x was changed to 2.99.x (which will become 3.0) |
| 01:57.57 | AAA_awright | That is version 2.0.7 |
| 01:58.19 | Quol | hello all |
| 01:58.23 | blast007 | hi Quol |
| 01:58.25 | Invisionfree | Quol |
| 01:58.28 | AAA_awright | Because we can't just adopt a major.minor.release convention |
| 01:58.30 | Invisionfree | Is AA around? |
| 01:58.33 | Quol | hello Invisionfree |
| 01:59.01 | *** join/#bzflag KingofCamelot (i=KingofCa@SCT-52-221.resnet.ucsb.edu) |
| 01:59.02 | blast007 | Invisionfree: I think that debian build was done by me, and I'm not sure if it works ;) |
| 01:59.08 | blast007 | I really didn't have a means to test it |
| 01:59.14 | blast007 | it was on debian etch iirc |
| 02:00.24 | Invisionfree | set variable: _angleTolerance = 0.008 |
| 02:00.24 | Invisionfree | Unknown BZDB variable: _countdownResumeTime |
| 02:00.33 | blast007 | hmm |
| 02:00.43 | *** join/#bzflag eT``out (n=etangent@71-211-200-94.hlrn.qwest.net) |
| 02:00.46 | blast007 | and you're sure that not still 2.0.8? |
| 02:00.53 | blast007 | that's* |
| 02:01.02 | Invisionfree | Sigma:~# bzfs -v |
| 02:01.02 | Invisionfree | BZFlag server 2.0.10.20071008-RC3-linux-gnu-SDL (protocol 0026) http://BZFlag.org/ |
| 02:01.02 | Invisionfree | Copyright (c) 1993 - 2007 Tim Riker |
| 02:01.26 | blast007 | hmm |
| 02:01.42 | Quol | Invisionfree, you trying to set a variable on the client side? or server side? |
| 02:01.53 | Invisionfree | Quol: Trying to set up a GU server |
| 02:01.55 | blast007 | that's an RC3 as well, not a 2.0.10 release build. Wonder if that was added/fixed during RC |
| 02:02.11 | Invisionfree | I saved world on your server |
| 02:02.20 | Quol | in your config, you can just do "-set <variableName> <setting>" |
| 02:02.22 | Invisionfree | And when I try and run it, i get that =[ |
| 02:02.35 | Invisionfree | I knwo |
| 02:02.36 | blast007 | Invisionfree: you're running a debian system? |
| 02:02.37 | Invisionfree | Quol |
| 02:02.43 | Invisionfree | It's part of the map file |
| 02:02.44 | Invisionfree | Yea |
| 02:02.48 | Invisionfree | yeah blast007* |
| 02:02.49 | blast007 | wonder if I can throw together a .deb for ya |
| 02:03.12 | Invisionfree | How long would it take? |
| 02:03.56 | Invisionfree | waves |
| 02:04.37 | Quol | Invisionfree, you have a good upload speed on your internet connection? |
| 02:04.53 | Invisionfree | god no Quol |
| 02:05.30 | Quol | you wanting to host it from home - or you are hosting it somewhere else? or you just having fun at home? :) |
| 02:05.47 | Invisionfree | It's not that bad, and it won't be overused |
| 02:06.42 | Quol | ya - just checking...I know that I have got many questions on "why is my server so laggy" - and it's because server's need good upload speeds |
| 02:06.47 | Quol | so was just checking |
| 02:07.01 | blast007 | Invisionfree: I'm attempting a deb build right now |
| 02:07.09 | bryjen | 2.0.10 is from November and it didn't make it into the debian released in February? |
| 02:07.45 | Quol | I know packages that are *years* old that aren't in the debian release :) |
| 02:07.52 | Quol | shouldn't be anything new there |
| 02:08.20 | Quol | is apache 2.x in the stable branch yet? last time I checked it wasn't |
| 02:10.23 | AAA_awright | Gentoo ftw |
| 02:10.55 | blast007 | Quol: etch has apache2.2 |
| 02:11.17 | blast007 | and php 5.2 |
| 02:12.04 | Quol | ahh - finally - that's good to know... |
| 02:13.46 | AAA_awright | bzflag.python-sports.com:5154 is in the list server twice |
| 02:14.06 | AAA_awright | Once without the :5154 at the end do there are no conflicts in the database |
| 02:14.25 | AAA_awright | blast007: Any clue? |
| 02:15.18 | blast007 | AAA_awright: fun |
| 02:15.37 | blast007 | Invisionfree: sorry, can't get a build done from here. I'd need to install x11 stuff and SDL, etc etc |
| 02:15.43 | blast007 | don't want to clutter up my server :) |
| 02:15.59 | Invisionfree | No problem, I'm svn building 2.0.11 I guess |
| 02:16.12 | blast007 | K |
| 02:16.28 | AAA_awright | That variable was added in 2.0.7 it looks like |
| 02:17.27 | blast007 | AAA_awright: assuming it worked right ;) |
| 02:17.39 | bryjen | those two python-sports entries have different descriptions. either one is stale, or they're incorrectly running two instances |
| 02:18.58 | AAA_awright | How could two servers on the same port even be registered by bzfs? |
| 02:19.14 | AAA_awright | One was launched with -addr ...:5154 and kill -9'd |
| 02:19.24 | AAA_awright | another without the explicit port and still running |
| 02:19.46 | bryjen | they may not really be on the same port, the -publicaddr parameters may be incorrect |
| 02:26.59 | AAA_awright | That is a bug then |
| 02:27.20 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 02:27.52 | blast007 | AAA_awright: that it is |
| 02:28.08 | blast007 | well, depends what you're meaning by "that", I guess |
| 02:28.26 | blast007 | the fact that someone can use a different port on the -publicaddr than the -p settings is intentional |
| 02:29.38 | Invisionfree | Why? |
| 02:33.36 | blast007 | because a router could be forwarding port 5154 on the outside to port 5000 on the inside |
| 02:33.45 | blast007 | so internally, the server is running on port 5000 |
| 02:33.53 | blast007 | but to the Internet, it's on port 5154 |
| 02:41.08 | AAA_awright | True |
| 02:41.31 | AAA_awright | The fact that the database doesn't seperate port and host |
| 02:41.42 | AAA_awright | Someone didn't follow the RFCs |
| 02:45.23 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 02:47.26 | AAA_awright | Does the database compare case too? |
| 02:47.46 | JeffM | well time to put this bad boy thru it's paces :) |
| 02:47.52 | JeffM | gets shot branch |
| 02:48.01 | blast007 | AAA_awright: follow the RFCs? pfft. |
| 02:48.08 | blast007 | it's a game, not an operating system |
| 02:48.49 | AAA_awright | the domain name MUST be compared case-insensitive, port must be compared separately as an integer |
| 02:48.49 | AAA_awright | (erm, capitalize that last MUST) |
| 02:49.02 | blast007 | that's nice |
| 02:49.14 | JeffM | what's he on about now? kerbos? |
| 02:49.23 | AAA_awright | Heh |
| 02:49.33 | Invisionfree | God damn, can this make install any slower?! |
| 02:49.48 | AAA_awright | A server in the list server twice is breaking my database |
| 02:49.50 | bryjen | be careful what you wish for... |
| 02:49.51 | blast007 | JeffM: the fact that we don't separate the IP/host and the port in our list server |
| 02:49.58 | JeffM | Invisionfree: sure use a mac. |
| 02:50.11 | JeffM | AAA_awright: then fix your database |
| 02:50.32 | bryjen | AAA_awright: the you _*MUST*_ fix your database :P |
| 02:50.33 | JeffM | our list was not made to work with your database |
| 02:50.39 | JeffM | it was made to list servers |
| 02:50.52 | *** join/#bzflag eTangenT (n=etangent@71-211-200-94.hlrn.qwest.net) |
| 02:51.10 | JeffM | ok, started at 7:49:45, lets see how long it takes |
| 02:51.33 | Invisionfree | Lol |
| 02:51.41 | AAA_awright | That server is only listed once on the display list, so the one server must not be displaying, probably the running one. |
| 02:51.46 | Invisionfree | "ended at 6:43:28" |
| 02:52.16 | blast007 | AAA_awright: the defunct server was only up there for 30 minutes |
| 02:52.18 | blast007 | at most |
| 02:52.39 | JeffM | it's up to bzfs already |
| 02:52.41 | AAA_awright | Put it this way, a bug is making the server list provide inaccurate info. A tiny bug, but still bad. |
| 02:52.50 | JeffM | AAA_awright: we have many |
| 02:53.13 | AAA_awright | Oh, really? I didn't notice ;) |
| 02:53.18 | JeffM | but throwing terms like RFC and 'your database' don't contribute to the bug fix in in our software at all |
| 02:53.20 | blast007 | the list server is likely getting replaced in the near (relatively speaking) future |
| 02:53.33 | AAA_awright | Speaking of which |
| 02:54.10 | AAA_awright | http://aaa.busyflag.org/code/ Two nice plugins for phpBB3 and MediaWiki, for authenticating against a seperate MySQL database |
| 02:54.14 | Invisionfree | I've been make installing for E V E R. |
| 02:54.24 | blast007 | Invisionfree: it shouldn't take that long |
| 02:54.44 | JeffM | finished 7:53:20 |
| 02:54.44 | blast007 | only half an eternity |
| 02:54.52 | blast007 | JeffM: nice |
| 02:54.53 | JeffM | that counts as not bad :) |
| 02:55.17 | JeffM | 2 cores were idle for the last 45 seconds tho :( |
| 02:55.22 | blast007 | heh |
| 02:55.32 | AAA_awright | The server is still there it appears |
| 02:55.33 | JeffM | I should install VC9 and see if that helps |
| 02:55.54 | Winny | I wonder what building on an 8 coer mac pro would be like |
| 02:56.08 | JeffM | I whould hope, faster |
| 02:56.12 | blast007 | AAA_awright: ah, guess it is |
| 02:56.16 | JeffM | if not then GCC is for shame |
| 02:56.45 | JeffM | blast007: so the issues is we don't do case sensitivity so you can multi-list the same host in the list? |
| 02:57.00 | blast007 | no |
| 02:57.07 | blast007 | one has the port on publicaddr, one doesn't |
| 02:57.12 | blast007 | it's two servers running |
| 02:57.21 | blast007 | they typed the wrong publicaddr for the second one |
| 02:57.26 | JeffM | ahh |
| 02:57.32 | JeffM | and we verified it |
| 02:57.37 | JeffM | sicne there was one running on that too |
| 02:57.38 | blast007 | yeah :) |
| 02:57.43 | JeffM | so 2 lists point to the same server |
| 02:57.47 | JeffM | not much we can do about that |
| 02:58.04 | JeffM | unless we did a check token or something |
| 02:58.08 | blast007 | well, we could in this case |
| 02:58.09 | AAA_awright | Well, you could check the port |
| 02:58.16 | blast007 | the port is both 5154 |
| 02:58.23 | blast007 | it's just that one didn't include it |
| 02:58.32 | blast007 | we store it without the port for that one |
| 02:58.38 | blast007 | and the other one we store with the port |
| 02:58.40 | JeffM | ahh so then we'd take it as a dupe |
| 02:58.44 | JeffM | I see |
| 02:58.49 | JeffM | not realy a "fix" for the issue |
| 02:58.50 | blast007 | we don't split the host and the port |
| 02:59.04 | JeffM | what is the harm tho? |
| 02:59.21 | blast007 | well, two servers are on there, both pointing to port 5154 |
| 02:59.28 | JeffM | the only person that suffers is the guy who screwed up his listing |
| 02:59.28 | blast007 | same host |
| 02:59.37 | blast007 | and AAA_awright's bad script ;) |
| 02:59.39 | JeffM | ok, and if someone joins ether, they go to the same one right? |
| 02:59.41 | AAA_awright | And me |
| 02:59.45 | JeffM | that dosn't affect players |
| 02:59.48 | blast007 | AAA_awright: go fix your script |
| 02:59.53 | AAA_awright | It is only listed in the server list once |
| 03:00.02 | JeffM | AAA_awright: good |
| 03:00.08 | JeffM | so then there is NO issue |
| 03:00.13 | AAA_awright | With the old information listing probably |
| 03:00.22 | JeffM | he just has to fix his server |
| 03:00.22 | AAA_awright | I don't know which is the defunct one |
| 03:00.34 | JeffM | and you need to fix your script to handle a case you didn't expect to handle |
| 03:00.47 | AAA_awright | Dump duplicates, wonderful |
| 03:00.55 | blast007 | weeee |
| 03:00.56 | blast007 | <PROTECTED> |
| 03:01.01 | blast007 | oh well, I tried |
| 03:01.27 | JeffM | AAA_awright: with networkdata and robutst programing you MUST be able to cleanly handle ANY data anaomaly |
| 03:01.55 | JeffM | you can not assume that the other side will do your dirty work for you. |
| 03:02.41 | bryjen | there's one running on 5154 or the callback would've failed and neither would list. there's no way of knowing what port the misconfigured one is listening on, so about all that can be done is ignore it. |
| 03:02.43 | JeffM | our protocoll is documented by the bzflag source code. |
| 03:02.53 | blast007 | bryjen: they're a second on running on 5155 |
| 03:02.59 | blast007 | which is the one that's misconfigured, I presume |
| 03:03.03 | bryjen | blast007: you guess at that |
| 03:03.05 | Invisionfree | Why doesn't bzadmin ever work for me? =[ |
| 03:03.12 | JeffM | bryjen: other then have each ADD send a tokenID to the list server that we send on the check that the server verifies. |
| 03:03.34 | JeffM | like a public key |
| 03:03.35 | AAA_awright | JeffM: Generally when you have a UNIQUE column you expect the data coming from it to be... unique |
| 03:03.50 | blast007 | AAA_awright: our database column IS unique :) |
| 03:03.58 | blast007 | it's just that one doesn't show a port number |
| 03:04.05 | bryjen | it's the implicit :5154 that's not unique |
| 03:04.14 | JeffM | the strings are not the same ;) |
| 03:04.22 | JeffM | you just made a bad assumption, deal with it. |
| 03:04.26 | AAA_awright | The bug is that that column is not atomic |
| 03:04.34 | JeffM | there is no bug |
| 03:04.38 | JeffM | our software works fine |
| 03:04.47 | JeffM | the bug is in your script |
| 03:04.56 | AAA_awright | I have no problem with it, I just had to deal with the cron mail |
| 03:05.05 | JeffM | your script does not do the same thing that bzflag does, YOU have the bug |
| 03:05.09 | blast007 | fix your script, and you won't have cron mail |
| 03:05.13 | AAA_awright | ... |
| 03:05.31 | JeffM | just because you don't agree with how it's writen does not make it a bug |
| 03:05.48 | AAA_awright | So the fact that the same port for the same host and IP is not a bug? |
| 03:06.05 | JeffM | what problem does our software have with the data being like that? |
| 03:06.12 | JeffM | does it fail? |
| 03:06.20 | AAA_awright | Ideally the host column is just a lookup, the constraint is UNIQUE on the server IP and port. |
| 03:06.27 | AAA_awright | Yes? |
| 03:06.30 | JeffM | you arn't listening |
| 03:06.36 | AAA_awright | I'm reading |
| 03:06.40 | JeffM | does it have any problem to bzfs, or bzflag client? |
| 03:06.47 | JeffM | do they fail? |
| 03:07.05 | AAA_awright | It isn't a fatal bug, if that is what you mean |
| 03:07.16 | JeffM | when you use the list to get to that server does it take you to a server? |
| 03:07.29 | blast007 | AAA_awright: even OUR stats site handles it okay |
| 03:07.31 | AAA_awright | Yes. |
| 03:07.37 | Invisionfree | bad argument "set" |
| 03:07.37 | JeffM | AAA_awright: then there is no bug |
| 03:07.37 | Invisionfree | BZFlag server 2.0.11.20080603-DEVEL-linux-gnu (protocol 0026) http://BZFlag.org/ |
| 03:07.37 | Invisionfree | Copyright (c) 1993 - 2008 Tim Riker |
| 03:07.37 | Invisionfree | <PROTECTED> |
| 03:07.38 | Invisionfree | Usage: bzfs |
| 03:07.39 | Invisionfree | Now I get this error .. |
| 03:07.40 | blast007 | it shows one server with that unique host/prt |
| 03:07.40 | AAA_awright | That isn't the issue |
| 03:07.47 | blast007 | Invisionfree: that's not an error |
| 03:07.49 | JeffM | AAA_awright: our stuff works |
| 03:07.51 | blast007 | the error is above that line |
| 03:08.03 | Invisionfree | "bad argument "set"" |
| 03:08.05 | JeffM | the server owner has provided invalid data |
| 03:08.07 | blast007 | er, yeah, missed that |
| 03:08.14 | AAA_awright | Just because it works doesn't mean it is bug free. |
| 03:08.28 | blast007 | Invisionfree: you probably missed a - somewhere before |
| 03:08.31 | JeffM | AAA_awright: you are correct that there is some garbage input |
| 03:08.35 | blast007 | and did 'set' instead of '-set' |
| 03:08.45 | JeffM | but you are saying how we are currently handling the invalid case is a bug |
| 03:08.48 | JeffM | when it is not |
| 03:08.53 | JeffM | we are handling it |
| 03:08.56 | JeffM | just not in a way you like |
| 03:09.03 | JeffM | and that is not the defintion of a bug |
| 03:09.15 | AAA_awright | But it is, there is duplicate data that could cause incorrect data to be displayed on the server list in the client and other stats programs |
| 03:10.15 | bryjen | blast007: any clue how the new list server stuff might handle this? |
| 03:10.30 | Invisionfree | base was not defined for Green Team |
| 03:10.31 | Invisionfree | ERROR: A world was not specified |
| 03:10.31 | blast007 | I think my rewrite used separate columns for the host and the port |
| 03:10.32 | Invisionfree | blast007: ^ |
| 03:10.41 | blast007 | Invisionfree: define an -mp that doesn't have the green team |
| 03:10.59 | blast007 | -mp rogue,red,green,blue,purple,observer (filling in numbers for each name there) |
| 03:11.20 | AAA_awright | blast007: Put the UNIQUE constraint on the IP and Port column, the host:port should be seperate, indexed, but not unique |
| 03:11.51 | blast007 | AAA_awright: or I can just make my code do that work for me |
| 03:12.07 | blast007 | it's not hard to set a variable to 5154 if it wasn't specified |
| 03:12.34 | AAA_awright | That minimizes duplicates. Absolutely ideally you would generate a UUID and bzfs would be identified by that, so you can't have a server listed on multiple IP's |
| 03:12.37 | AAA_awright | blast007: That is what I do |
| 03:12.39 | blast007 | uh |
| 03:12.44 | blast007 | you don't read, do you? |
| 03:12.49 | blast007 | I said I would make the code check for that |
| 03:13.01 | AAA_awright | $port = isset($port)?(int)$port:5154; or something |
| 03:13.03 | *** join/#bzflag JeffMMain (n=Jeff@pool-71-109-223-10.lsanca.dsl-w.verizon.net) |
| 03:13.12 | blast007 | AAA_awright: again, don't you read? |
| 03:13.13 | JeffMMain | wheeee |
| 03:13.22 | blast007 | 07:17:11 <+blast007> it's not hard to set a variable to 5154 if it wasn't specified |
| 03:13.26 | AAA_awright | I read that |
| 03:13.31 | JeffMMain | so, does the list server provide any invalid links to servers that don't work? |
| 03:13.35 | AAA_awright | And explained that I do in fact do that |
| 03:13.38 | JeffMMain | or just dupes? |
| 03:13.38 | blast007 | so why did you give an example of how to do it? |
| 03:13.43 | blast007 | I said it's not hard |
| 03:13.43 | AAA_awright | blast007: Don't you read? |
| 03:13.45 | JeffMMain | cus there are lots of ways to have dupes? |
| 03:13.51 | JeffMMain | even right now |
| 03:13.52 | blast007 | that means that I already KNOW HOW to do it |
| 03:14.09 | JeffMMain | we don't define dupes as an error case currently |
| 03:14.12 | bryjen | what if a server has multiple nic's, each with different, valid IP addys? |
| 03:14.14 | blast007 | JeffMMain: that's the only way to have a dupe |
| 03:14.22 | JeffMMain | blast007: not if I get nasty ;) |
| 03:14.23 | blast007 | bryjen: they'd have a different hostname |
| 03:14.36 | JeffMMain | blast007: I can have more then one domain name that maps to the same server |
| 03:14.42 | blast007 | uh |
| 03:14.44 | JeffMMain | and have multiple adds |
| 03:14.46 | blast007 | that would be unique though |
| 03:15.06 | blast007 | you couldn't run two servers on the same IP on the same port with different hostnames |
| 03:15.24 | AAA_awright | bryjen: I mentioned using a UUID to identify servers, which is globally unique. But that is overkill. constraining UNIQUE to IP and port doesn't solve everything, but it permits less dupes then host:port alone |
| 03:15.29 | JeffMMain | blast007: no but I could have the API send more then one ADD with different publicADDRS ;) |
| 03:15.31 | blast007 | the only duplicate we can have is on port 5154 |
| 03:15.48 | AAA_awright | The most commonly used port. And? |
| 03:15.50 | blast007 | sure, but that wouldn't probably affect his stuff |
| 03:16.04 | JeffMMain | so the issue now is that there is a rare case where we can get 2 items in the vissible game list that both work? |
| 03:16.12 | blast007 | yeah :) |
| 03:16.18 | JeffMMain | ok |
| 03:16.39 | JeffMMain | then I see that as an area for enhancment, but not a bug |
| 03:16.40 | AAA_awright | Except only one is displayed |
| 03:16.44 | JeffMMain | AAA_awright: ok good |
| 03:16.49 | JeffMMain | then there is no issue |
| 03:17.04 | JeffMMain | so basicly what you are saying is, the server with bad input, is ingored by the client |
| 03:17.05 | AAA_awright | Except that your correct server description and port is missing, and you may never know |
| 03:17.25 | JeffMMain | I don't see the problem here then? |
| 03:17.31 | JeffMMain | if only one is listed |
| 03:17.31 | blast007 | AAA_awright: just like how many licks to get to the center of a tootsipop? |
| 03:17.37 | AAA_awright | ... |
| 03:17.39 | blast007 | the world may never know |
| 03:17.46 | JeffMMain | if our softwware filters it at some point |
| 03:17.50 | bryjen | i was trying to put this to rest by asking blast about the new bzfls. perhaps i should've called him a nazi too ;) |
| 03:18.07 | AAA_awright | Then it isn't a *fatal* bug. |
| 03:18.08 | blast007 | bryjen: the new bzfls is shiny |
| 03:18.14 | JeffMMain | and the only thing that has the issue is some other software that is trying to do a man in the middle thing, I don't see why we should care? |
| 03:18.19 | JeffMMain | AAA_awright: it isn't a bug |
| 03:18.24 | JeffMMain | not in our stuff |
| 03:18.33 | JeffMMain | sure it's not the most logical protocoll, but it WORKS |
| 03:18.46 | JeffMMain | the bug is in your assumption |
| 03:18.51 | JeffMMain | lets make it simple |
| 03:19.02 | JeffMMain | lets say that I decide to change the list to add 1000 to all the port numbers |
| 03:19.05 | AAA_awright | Yes, when a flaw in the list server allows you to add a server that will not be displayed when you want it to, that is a bug |
| 03:19.14 | JeffMMain | then have the clients subtract 1000 |
| 03:19.17 | JeffMMain | so it all works |
| 03:19.23 | JeffMMain | it makes no sense |
| 03:19.25 | JeffMMain | but it works |
| 03:19.42 | JeffMMain | is it my bug that I do that because you didn't subtract 1000 in your third party software? |
| 03:20.07 | JeffMMain | AAA_awright: it's a flaw to ingore bad input? |
| 03:20.17 | JeffMMain | I mean we ignore bad input all the time now |
| 03:20.19 | AAA_awright | This has nothing to do with my implementation, I only found about it because of that |
| 03:20.33 | bryjen | that's something |
| 03:20.33 | JeffMMain | AAA_awright: then WHAT is the bug in our client? |
| 03:20.35 | blast007 | your implementation is the only one with issues |
| 03:20.50 | AAA_awright | See, you are not listening |
| 03:20.53 | AAA_awright | (sorry) |
| 03:20.57 | JeffMMain | user lists 2 servers but only one has valid info right? |
| 03:21.06 | JeffMMain | game only lists one of them |
| 03:21.13 | JeffMMain | is that the scenario? |
| 03:21.45 | AAA_awright | The list server is allowing two servers to be added when it should not be, because of this BZFlag will not display one of them |
| 03:22.02 | blast007 | it shouldn't display them both anyway |
| 03:22.08 | JeffMMain | yeah |
| 03:22.10 | blast007 | so what is your point there? |
| 03:22.13 | JeffMMain | one of them has bad info |
| 03:22.17 | JeffMMain | we don't list games with bad info |
| 03:22.19 | AAA_awright | Then there is a bug because it isn't displaying the up-to-date and correct data |
| 03:22.20 | blast007 | if we "fixed" it, it would still show one server |
| 03:22.29 | JeffMMain | if your public addr was wrong we'd NOT LIST IT |
| 03:22.42 | JeffMMain | his public addr is WRONG |
| 03:22.48 | AAA_awright | But it is being listed |
| 03:22.54 | AAA_awright | Over the other one |
| 03:22.58 | JeffMMain | not on the client |
| 03:23.03 | JeffMMain | one of them is |
| 03:23.07 | JeffMMain | with a valid address |
| 03:23.09 | JeffMMain | the other is not |
| 03:23.29 | blast007 | AAA_awright: honestly, it's not worth the time to fix it |
| 03:24.01 | AAA_awright | For you |
| 03:24.10 | bryjen | was it worth talking about for 1h11m ? |
| 03:24.17 | blast007 | well, it's obvious that you don't want to fix your own code |
| 03:24.34 | blast007 | bryjen: has it been that long? geez, guess so |
| 03:25.16 | blast007 | AAA_awright: in this amount of time, you could have fixed your code :P |
| 03:25.27 | AAA_awright | My code is not broken |
| 03:25.35 | AAA_awright | It rejects the duplicate just like BZFlag |
| 03:25.49 | bryjen | "My code is not broken" And that is why you fail |
| 03:26.06 | AAA_awright | The bug is that no case should that be needed, and that is the problem I am bringing up. |
| 03:26.35 | blast007 | AAA_awright: you SAID your stuff was broken |
| 03:26.36 | AAA_awright | bryjen: I never even explained what "my code" is, all I ever mentioned is that I was getting out of place errors |
| 03:26.37 | blast007 | 06:54:52 < AAA_awright> A server in the list server twice is breaking my database |
| 03:26.46 | blast007 | see that word? "breaking" |
| 03:26.50 | blast007 | that's on your end |
| 03:26.55 | AAA_awright | ... |
| 03:27.00 | blast007 | the database is yours, not ours |
| 03:27.08 | blast007 | your database is breaking, so it's your problem |
| 03:27.12 | AAA_awright | e.g. rejecting input. Which is fine. |
| 03:27.18 | AAA_awright | Just like BZFlag is rejecting the input. |
| 03:27.21 | blast007 | rejecting input != breaking |
| 03:27.34 | AAA_awright | Alright, I used the wrong word, big deal |
| 03:27.44 | blast007 | well, that was the main point of your discussion |
| 03:28.01 | blast007 | so getting it wrong that far back was a big deal |
| 03:31.36 | AAA_awright | Fine, lets play word games |
| 03:31.43 | JeffMMain | dude, enough |
| 03:31.45 | JeffMMain | both of you |
| 03:31.55 | JeffMMain | AAA_awright: thanks for identifying an issue, please write it up |
| 03:32.08 | JeffMMain | I agree that is a place where we could have more logical input handling into the list |
| 03:32.16 | JeffMMain | there are a NUMBER of ways to fix it |
| 03:32.33 | JeffMMain | you are correct it is not a fatal bug, because it's not a bug at all |
| 03:32.34 | AAA_awright | Thanks for understanding |
| 03:32.43 | JeffMMain | it is a logical incnosistency |
| 03:32.58 | JeffMMain | and in generaly we'd like to make our protocoll as logical a possible |
| 03:33.14 | JeffMMain | but on the flip side, you too should also make your code as robust as possible. |
| 03:34.22 | JeffMMain | it sounds like our client is robust enough to filter them |
| 03:35.00 | JeffMMain | so yeah, report it. it's not bad info to have for when we do redo the list system, but it is not a bug, just a logical inconsitency |
| 03:35.17 | JeffMMain | since normaly we fail bad input at add time, not later at list time. |
| 03:38.55 | JeffMMain | Constitution: you still fencin? |
| 03:58.43 | Flash | <PROTECTED> |
| 03:58.51 | Flash | what do we think this is trying to test? |
| 03:59.28 | Flash | (not the syntax but the semantics) |
| 03:59.30 | JeffM | if the player does not have the perm to list |
| 04:03.46 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 04:04.52 | *** join/#bzflag eT``out (n=etangent@71-211-200-94.hlrn.qwest.net) |
| 04:10.24 | Flash | so if the player does not have perms to list, should anything come back from the command? |
| 04:10.28 | Flash | (I think now) |
| 04:10.31 | Flash | *not) |
| 04:11.02 | JeffM | that looks to me like an easy out section of a command |
| 04:11.11 | JeffM | where if they don't have it, we throw a meesage and return |
| 04:30.25 | Flash | brlcad: ping |
| 04:30.33 | brlcad | Flash: sup? |
| 04:30.59 | Flash | you changed NetHandler (revision 16127) to pass char[] to getPlayerList |
| 04:31.15 | Flash | I'm not aware of that doing what you wanted it to do in C++ |
| 04:31.57 | Flash | instead, it's being interpreted as char* , so sizeof(char*) is 4 and we don't get what was expected |
| 04:33.43 | Flash | which is more important, not overflowing the char buffer or keeping the interface tidy? |
| 04:36.11 | Flash | http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/game/NetHandler.cxx?r1=16045&r2=16127 |
| 04:36.18 | Flash | (if that helps) |
| 04:43.55 | Constitution | JeffM: back |
| 04:44.14 | JeffM | have fun? |
| 04:44.50 | Constitution | yep |
| 04:44.56 | JeffM | cool |
| 04:45.32 | JeffM | as far as I can see, we send out the correct MsgShotID to the client so on anything other then a suicide shot IDs should be positive |
| 04:46.56 | Constitution | well, other clients cannot see player A's shots at all... but that's another bug afaik |
| 04:47.12 | JeffM | I'm guessing that's the start of all the bugs ;) |
| 04:47.26 | JeffM | so start there |
| 04:47.27 | Constitution | oh, hm |
| 04:47.35 | JeffM | make sure the shots are getting created correctly |
| 04:47.49 | JeffM | otherwise it makes total sense that on hit, they arn't being found ;) |
| 04:48.19 | Constitution | MsgShotBegin and MsgEndShot are getting sent out from the server... I've verified that |
| 04:48.40 | Constitution | MsgEndShot immediately follows MsgShotBegin |
| 04:48.43 | JeffM | is the begin from the client unpacked correctly |
| 04:48.47 | brlcad | Flash: hm, I don't recall doing that exactly |
| 04:48.49 | JeffM | then is it sent out with a valid positive ID? |
| 04:48.57 | brlcad | but yeah, i can certainly see that being a problem |
| 04:49.03 | Constitution | I can check |
| 04:49.23 | Flash | I can choose a variety of ways to fix it |
| 04:49.27 | brlcad | iirc, it'll depend on whether the caller uses an array or pointer |
| 04:49.36 | JeffM | Constitution: you need to, that's where it has to start |
| 04:49.41 | Flash | only if they are in the same compile unit |
| 04:49.42 | brlcad | so if someone passes in a pointer, it's screwed |
| 04:49.48 | Flash | otherwise, the compiler can't know |
| 04:50.16 | Flash | otherwise, for all intents and purposes char[] and char* are identical |
| 04:50.37 | brlcad | either way, it's still not what was intended so it's bad |
| 04:50.57 | Flash | the code I'm looking at does pass an array |
| 04:51.01 | Flash | but it doesn't matter |
| 04:51.06 | Flash | sizeof provides 4 |
| 04:51.19 | brlcad | probably should just add the length |
| 04:51.30 | brlcad | better than relying on std::string container repacking |
| 04:51.38 | Flash | really? |
| 04:52.40 | Flash | I was thinking towards std::stringstream buf << stuff; return buf.str(); |
| 04:53.28 | Flash | but I'm easily directed |
| 04:56.16 | brlcad | it's more an issue of consistency, char buffers have been the predominant use by callers (at least that was the case last I looked in depth) |
| 04:56.45 | brlcad | to turn all the char buffers into std::strings just to turn around and unpack them as char arrays for the send() doesn't make sense |
| 04:57.06 | Flash | the char buffers are definitely predominant, but I figured that was a history thing |
| 04:57.13 | brlcad | network handler was intentionally/originally made to just work at the network buffer level |
| 04:57.53 | brlcad | a minor performance win as the other can inject a hell of a lot of malloc/free's implicitly |
| 04:57.54 | Flash | it would be nice if there were actually a distinction between octets and chars (and strings) |
| 04:58.14 | JeffM | it would be nice if it simply handles networking again |
| 04:58.19 | JeffM | insted of doing proto stuff |
| 04:58.19 | brlcad | if they start as std::strings, it's a bit more different, but then you can get the char buffers from them easily as it is |
| 04:58.50 | Flash | yes, certainly for the network stuff having buffers is appropriate. This particular function is diagnostic formatting, so the line is blurrier (to me) |
| 04:59.00 | brlcad | by doing char buffers, it's lightweight where it matters and if the caller has std::strings, then it can pass the char* easily enough |
| 04:59.49 | brlcad | it has other funcs that are buffer, len -- for consistency, it should probably just match |
| 04:59.57 | brlcad | even if it is debug |
| 04:59.58 | Flash | already coded |
| 05:00.30 | Flash | now, can you (or someone else) explain to me what is supposed to happen on /playerlist |
| 05:00.43 | JeffM | where? we can't read your mind |
| 05:01.01 | Flash | well, to start at a macro level, but I will be more specific |
| 05:01.18 | Flash | there is a block of code that gets the players from NetHandler and returns them |
| 05:01.24 | JeffM | you just want to know what the command is suposed to do? what does the docs say? |
| 05:01.46 | Flash | then there's a block of code that gets a player list from every player and returns that |
| 05:02.02 | JeffM | line? |
| 05:02.19 | Flash | about 1879 (my lines have moved a few) |
| 05:02.24 | JeffM | file? |
| 05:02.31 | Flash | bzfs/commands.cxx |
| 05:02.34 | JeffM | remember, can't read mind |
| 05:02.46 | Flash | aw, don't you have the code memorized? |
| 05:03.49 | Flash | there's a logic flaw where the first set is returned if you DON'T have playerlist perm (at least, I think it's a flaw), followed by a return |
| 05:04.06 | Flash | or maybe that's not a set... it is just the current player (self) ? |
| 05:04.47 | JeffM | so what is your question? what we do if you don't have the perm? or what we do if you do? |
| 05:05.02 | Flash | my question is what is the desired behavior |
| 05:05.13 | Flash | I'm not sure what is there is correct |
| 05:05.20 | JeffM | if you don't have the perm it sends back your host info |
| 05:05.34 | JeffM | if you do, it sends back the info for all players |
| 05:05.39 | Flash | ok, is that better than "you can't do that"? |
| 05:05.41 | JeffM | network and server side |
| 05:05.54 | JeffM | yes it's the defined behavor |
| 05:05.58 | Flash | ok |
| 05:06.00 | Flash | thank you |
| 05:06.00 | JeffM | since that is the ONLY player you can list |
| 05:06.08 | JeffM | you can always list yourself |
| 05:06.25 | JeffM | then you can see your own host mask |
| 05:07.02 | Constitution | JeffM: just verified that shooting player IDs and shotIDs > 0 are being correctly packed and unpacked by the server/client |
| 05:07.27 | JeffM | is your confusion over why the listing tests if each player has a netHandler or not Flash ? |
| 05:07.53 | JeffM | Constitution: then why arn't the remote players seeing the shots? ;) |
| 05:08.13 | Constitution | good question |
| 05:08.23 | Flash | JeffM: no, it was that I thought the test for perms was backwards |
| 05:08.35 | Constitution | isn't MsgShotEnd supposed to be sent out... uh... when the shot ends? |
| 05:08.43 | Flash | I naively thought getPlayerList would return a list of players rather than just one |
| 05:08.47 | JeffM | Constitution: yes |
| 05:09.00 | JeffM | Flash: it is not |
| 05:09.08 | Flash | I see that now |
| 05:10.51 | CIA-33 | BZFlag: 03jwmelto * r17377 10/trunk/bzflag/ (4 files in 4 dirs): Fix formatting of host info so /playerlist works again |
| 05:10.53 | JeffM | just so you know, that is a common thing for us to do in commands, to the perm test first |
| 05:10.56 | JeffM | and bail |
| 05:11.14 | Flash | right, it just didn't look like a "bail" to me |
| 05:11.22 | Flash | now, I see that it is |
| 05:11.41 | JeffM | there are many forms of bailing ;) |
| 05:11.46 | Flash | indeed |
| 05:11.56 | JeffM | and not all bails are bad |
| 05:12.03 | JeffM | they are just simple assumptions |
| 05:12.52 | JeffM | Constitution: begin at the begining and track what happens, don't jump around ;) |
| 05:13.01 | JeffM | it all changed so it's best to follow it from start to end |
| 05:13.14 | JeffM | at the first step that fails, find and fix that. then move on |
| 05:13.20 | JeffM | since they all depend on each other. |
| 05:13.25 | Constitution | right, ok |
| 05:13.36 | Constitution | MsgShotEnd is being sent immediately following MsgShotBegin |
| 05:13.44 | JeffM | THAT is not good |
| 05:13.46 | Constitution | I'm setting breakpoints to figure out what code is calling it |
| 05:13.54 | JeffM | probably in my lifetime check |
| 05:14.07 | JeffM | I have the server setup to send the end when it thinks they are dead based on lifetime |
| 05:14.22 | JeffM | shot manager has an update method |
| 05:14.32 | JeffM | slap one in there and see if the timer functions are good |
| 05:19.12 | CIA-33 | BZFlag: 03jwmelto * r17378 10/branches/v2_99_net_branch/ (3 files in 3 dirs): Apply r17377 so it doesn't get lost |
| 05:25.01 | Constitution | you refer to ShotManager::updateShot(), correct? that isn't getting called at all |
| 05:25.33 | Constitution | it looks like sendMsgShotEnd() is getting called from BZFSShotCallbacks::shotEnded() in bzfs.cxx |
| 05:26.06 | blast007 | and what is calling shotEnded? |
| 05:26.30 | blast007 | set up a breakpoint on that function call, and get the call stack |
| 05:26.40 | Constitution | ok |
| 05:28.27 | Constitution | shotManager::update() |
| 05:28.36 | blast007 | ;) |
| 05:28.37 | Constitution | guess JeffM actually meant update() when he said update() |
| 05:28.43 | blast007 | hehehe |
| 05:28.57 | JeffM | I say what I mean I mean what I say ;) |
| 05:29.22 | JeffM | but yeah that shoud go thu the server side shot list each frame and update each shot postion |
| 05:29.39 | JeffM | THAT is where you'll be doing your major work in getting the server to maintain a valid shot state |
| 05:30.00 | JeffM | tho techincaly at some point that can be put into it's own thread |
| 05:30.05 | JeffM | and not just called every frame |
| 05:30.18 | JeffM | well loop, not frame, since we don't have server frames |
| 05:38.12 | AAA_awright | I just figured out another problem |
| 05:39.13 | AAA_awright | I use the list server to keep track of which servers I need to connect to. This depends on the list server providing somewhat reliable player counts, but if the numbers are very different, it means I bombard a server every two minutes asking for new data. |
| 05:39.47 | blast007 | AAA_awright: k |
| 05:40.03 | AAA_awright | (Well, that is hardly a bombardment, but considering I connect an average of 30 mins per server between connections...) |
| 05:40.10 | blast007 | still sounds like a problem with your server |
| 05:40.27 | blast007 | the only server of that player's that will HAVE players is the one on port 5154 |
| 05:40.32 | AAA_awright | It deals with it the best it can, but it is hardly ideal |
| 05:40.51 | JeffM | ok, I put all this in the wrong window |
| 05:40.57 | JeffM | big page INC Constitution |
| 05:41.04 | JeffM | <JeffM> and yeah the shot manager dosn't actualy send any message |
| 05:41.04 | JeffM | <JeffM> it uses those callbacks |
| 05:41.05 | JeffM | <JeffM> cus the idea is for shot manager to be generic and used by both the server and the client eventualy |
| 05:41.05 | JeffM | <JeffM> so we can't have it have any server specific stuff |
| 05:41.05 | JeffM | <JeffM> so that's wraped in the callback section |
| 05:41.05 | JeffM | <JeffM> the client would have it's own callbacks |
| 05:41.07 | JeffM | <JeffM> that would tie into renderingste |
| 05:41.43 | Constitution | I see |
| 05:42.19 | JeffM | my guess is the lifetime calc is wrong |
| 05:43.05 | JeffM | meds kicking in must sleep |
| 05:43.08 | JeffM | good luck wiht it |
| 05:44.34 | AAA_awright | What did I come here for hours ago anyways? |
| 05:45.33 | AAA_awright | Constitution blast007: How about instead of pulling current data, applications can pull the buffer of all events for the past <x> seconds from a server? |
| 05:45.55 | Constitution | why? |
| 05:46.03 | AAA_awright | Milage will vary by implementation |
| 05:46.18 | AAA_awright | Because the current pull system is "broken" (no it isn't) |
| 05:47.15 | Constitution | no idea why you would do that, when you can pull the current data and diff it to your own |
| 05:47.38 | Constitution | unless you went incredibly precise statistics |
| 05:48.38 | AAA_awright | Supposedly we need a push system where we can host all the data centrally (JeffM says this) |
| 05:49.07 | AAA_awright | I don't like centrally though. What is wrong with decentralized, each server keeps their own buffer? |
| 05:49.51 | Constitution | 'cause then you have to query hundreds of servers to get the data |
| 05:50.17 | blast007 | AAA_awright: how would that be better? |
| 05:50.26 | AAA_awright | That is the idea Constitution |
| 05:50.50 | AAA_awright | blast007: The data availability is dependent on the availability of the server |
| 05:51.10 | AAA_awright | Additionally, you can make direct queries with what you need, like uptime to UID servers |
| 05:51.17 | AAA_awright | er |
| 05:51.31 | AAA_awright | Middle man is bad |
| 05:51.46 | blast007 | it's a damn game. we're not monitoring patients' heartrate.... so what if the stats are down for 5 minutes. my god. |
| 05:52.08 | AAA_awright | That is not what I am worried about, didn't you read? |
| 05:52.18 | blast007 | 09:55:54 < AAA_awright> blast007: The data availability is dependent on the availability of the server |
| 05:52.27 | AAA_awright | Of bzfs |
| 05:52.30 | blast007 | what server are you talking about? |
| 05:52.40 | blast007 | I really see no benefit |
| 05:52.46 | AAA_awright | But it does work the other way too |
| 05:52.52 | blast007 | WHY would we do that? |
| 05:53.12 | Constitution | if the server (as in bzfs) is "unavailable" then one can safely assume that there are no stats to collect |
| 05:53.14 | AAA_awright | Because we will still need to hit the servers for current data anyways |
| 05:53.16 | blast007 | what does it give us over a central push-based stats system? |
| 05:53.23 | blast007 | no |
| 05:53.28 | blast007 | the servers would GIVE us that info |
| 05:53.39 | blast007 | we wouldn't have to "hit" them |
| 05:53.45 | AAA_awright | Stats collectors like me still have to pull |
| 05:53.56 | blast007 | from our central stats server, yes |
| 05:54.06 | blast007 | you would pull from us |
| 05:54.15 | blast007 | not 300 servers |
| 05:54.21 | AAA_awright | There is nothing wrong with a great massive list server that tells you where a player is |
| 05:54.58 | AAA_awright | Don't get me wrong. |
| 05:56.13 | Constitution | you have not said what is "wrong" with the system we want, either |
| 05:57.27 | AAA_awright | Pulling is still required, either way. I have reason to believe I have the most efficient data collection system there is, not to be egotistic or anything, I know when I need new data and what servers I have to hit. |
| 05:57.43 | blast007 | .... |
| 05:58.18 | blast007 | explain what you would be pulling from |
| 05:58.28 | blast007 | are you saying that pulling from bzfs is still required? |
| 05:58.38 | AAA_awright | The problem is you are thinking up a system of how everything is going to be implemented without actually knowing any facts |
| 05:59.19 | AAA_awright | If the list server goes the way I think it will though, It will give me more reasons to hit servers, not less |
| 05:59.36 | blast007 | the list server is not the same as the stats site |
| 05:59.38 | AAA_awright | (Oh, this player died? Lets connect and find out why) |
| 06:00.03 | blast007 | I guess I'm not understanding what you're meaning |
| 06:00.09 | blast007 | why would you hit servers more? |
| 06:00.21 | blast007 | and what does "how the list server is going" have anything to do with that? |
| 06:00.23 | AAA_awright | Because it is more information to act off of |
| 06:00.41 | AAA_awright | Right now I connect to servers based on player counts and past data |
| 06:01.00 | AAA_awright | Nothing would change, except now I have more data |
| 06:02.55 | AAA_awright | ...lighttpd is breaking my CSS, why is lighttpd breaking my CSS... |
| 06:03.16 | blast007 | because it wants you to use apache |
| 06:04.53 | AAA_awright | I have to say, meteorite was correct about it being faster though |
| 06:05.40 | Constitution | what is this "more data" that you want? |
| 06:06.16 | AAA_awright | Supposedly it would include player joins, parts, kills |
| 06:06.24 | blast007 | what is "it" ? |
| 06:06.31 | AAA_awright | "more data" |
| 06:07.23 | blast007 | more data from what? |
| 06:07.31 | blast007 | where are you getting "player joins, parts, kills" ? |
| 06:07.37 | Constitution | when the stats say the player is playing at server A, the player has "joined". when the stats say he is playing elsewhere, the player has "parted". the stats also report player scores. what more do you want? |
| 06:10.56 | AAA_awright | You know what, I'll /part from this topic until I can explain things better. |
| 06:15.08 | AAA_awright | I am working on this website thing again, hopefully someone will get something out of it. It is very buggy though: http://aaa.busyflag.org/page/Main_Page |
| 06:16.01 | AAA_awright | Under "Development" then "Services Proposal" I have links to two plugins for MediaWiki and phpBB3 that would work with an internal authentication system that would be meshed with the list server |
| 06:16.59 | AAA_awright | Thanks Winny for the wonderful template I had to migrate to MediaWiki and phpBB. |
| 06:18.20 | AAA_awright | blast007: I had a moment of inspiration like you with the web form toolkit, what if there was a standard XML format that could be used to generate templates for different frameworks, using XSL and stuff? |
| 06:29.41 | *** join/#bzflag unotmeu (n=menotume@pdpc/supporter/active/menotume) |
| 06:29.41 | *** mode/#bzflag [+v unotmeu] by ChanServ |
| 06:53.14 | Flash | AAA_awright: I really should go to bed instead of getting in the middle of this, but how do you know where the servers are to pull from them? |
| 06:53.47 | Flash | each game server must push it's identity to the list server (central registry of game servers) |
| 06:54.00 | Flash | why is it a stretch for them to push their stats to the same place? |
| 06:54.09 | Flash | simple, consistent, QED |
| 07:01.36 | *** join/#bzflag Gilly (n=btw@83.146.211.140) |
| 07:19.09 | *** join/#bzflag Deepa|AFK (i=deepa@abused.armchairs.be) |
| 08:04.53 | Lukstr | DTRemenak, and others interested: I aplogize for slow development up until now. I've been reading up/playing around with Automake for the last few days, and haven't yet quite figured out where to start adding a library. Also my workstation (PIII 600MhZ, TNT2) can hardly handle BZFlag, so I'm looking into an alternative system. Until I replace it with a decent box, I'll be coding on it/my laptop. I made a dumb decis |
| 08:04.53 | Lukstr | ion to dedicate this one box to BZFlag coding development only for it to be insufficient, and am quite angry about it :P. I'm currently aiming to be a commit fiend by the end of the week! |
| 08:07.24 | ruskie | http://www.reghardware.co.uk/2008/06/03/rwjf_videogame_study/ <-- O.o |
| 08:39.27 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 09:47.46 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 10:01.24 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 10:16.51 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 10:32.32 | *** join/#bzflag LongDon (n=LongDon@vpn199-120.hrz.uni-oldenburg.de) |
| 10:44.05 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-227-134.pools.arcor-ip.net) |
| 10:55.08 | *** join/#bzflag whodaman- (n=whodaman@dslb-088-064-177-179.pools.arcor-ip.net) |
| 10:57.13 | *** part/#bzflag LongDon (n=LongDon@vpn199-120.hrz.uni-oldenburg.de) |
| 11:14.14 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 11:34.05 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-50.hsd1.tx.comcast.net) |
| 11:34.06 | *** mode/#bzflag [+v spldart] by ChanServ |
| 11:36.50 | *** join/#bzflag Mets2 (n=Mets@cpe-72-224-55-41.nycap.res.rr.com) |
| 11:45.58 | *** join/#bzflag QuantumBeep (i=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 11:58.07 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 12:05.24 | *** join/#bzflag Wyk3d (n=Wyk3d@c7.campus.utcluj.ro) |
| 12:19.26 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-227-134.pools.arcor-ip.net) |
| 12:22.42 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 12:23.39 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 12:39.44 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 12:46.27 | *** join/#bzflag delusional_ (n=delusion@pool-71-253-19-54.pitbpa.east.verizon.net) |
| 12:47.04 | CIA-33 | BZFlag: 03bthansen * r17379 10/trunk/bzflag/src/bzfs/commands.cxx: |
| 12:47.04 | CIA-33 | BZFlag: Remove leftover debug output |
| 12:47.04 | CIA-33 | BZFlag: For permanent debug messages use logDebugMessage() with an appropriate message level |
| 12:57.54 | *** join/#bzflag RedBaron3 (n=d8ada652@gateway/web/cgi-irc/zeebrothers.net/x-29c0d6c434f3dafb) |
| 13:29.20 | *** join/#bzflag KTL (n=KTL@213.219.188.181.adsl.dyn.edpnet.net) |
| 14:06.13 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 14:13.38 | Thumper_ | top |
| 14:14.20 | Thumper_ | :-P |
| 14:20.45 | *** join/#bzflag eT``out (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 14:27.11 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 14:31.44 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 14:35.36 | *** join/#bzflag spldart (n=short_ci@adsl-70-240-215-74.dsl.hstntx.swbell.net) |
| 14:35.37 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:46.37 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 14:53.45 | *** join/#bzflag TimRiker (n=timr@99-204-240-106.area1.spcsdns.net) |
| 14:53.45 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:33.27 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
| 15:52.01 | *** join/#bzflag bugQ (n=bugQ@c-67-166-124-4.hsd1.ut.comcast.net) |
| 16:12.52 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 16:13.43 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 16:27.32 | *** join/#bzflag BenUrban (n=benurban@c-68-49-10-243.hsd1.md.comcast.net) |
| 16:30.57 | JeffM | brlcad, did you pick up your stuff? |
| 16:32.31 | brlcad | yep, saw it right before leaving for my trip |
| 16:32.33 | brlcad | looked great |
| 16:32.59 | brlcad | the hat embroider could use some work, but it looked good |
| 16:33.57 | JeffM | ahh trip? where you at? |
| 16:36.44 | *** join/#bzflag DTRemenak|RDP (n=dtremena@about/essy/CrazyCoder/DTRemenak) |
| 16:36.45 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 16:39.29 | *** join/#bzflag Wyk3d1 (n=Wyk3d@c7.campus.utcluj.ro) |
| 16:51.22 | donny_baker | he would tell ya, but then he would have to kill you |
| 16:52.33 | spldart | isn't looking forward to his trip :( |
| 16:53.05 | Thumper_ | trips spldart. |
| 16:53.13 | Thumper_ | there's you can stop worrying about it |
| 16:53.14 | spldart | Doh! |
| 16:53.19 | Thumper_ | s/'s// |
| 16:54.59 | JeffM | brlcad, you take the book along? |
| 17:12.09 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:22.56 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 17:36.12 | brlcad | JeffM: new york, long island |
| 17:36.27 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 17:37.26 | brlcad | i actually don't remember seeing the book now that you mention it .. though I was in a hurry |
| 17:42.22 | *** join/#bzflag KTL (n=KTL@213.219.188.181.adsl.dyn.edpnet.net) |
| 17:47.24 | JeffM | brlcad, there should have been one shoved in there |
| 17:49.28 | brlcad | i might have just overlooked it, i'll check when I get home |
| 17:50.07 | KTL | how far are the mountains drawn ? i try to get them inside a skydome |
| 18:02.08 | KTL | isnt there a sound associated with a tank in the rain? |
| 18:11.13 | JeffM | no |
| 18:12.00 | KTL | a hackish way simulate a terrible rain: dont draw any sky at all + lots of rain -> the garbage sky out the memory of the graphics card will be filled with rain |
| 18:13.48 | bugQ | KTL: probably "plink", "rat-a-tat", or white noise, depending on the volume of downpour. |
| 18:14.44 | KTL | would want to put the mountains closer by |
| 18:14.44 | bugQ | at least, that's what I've got from sitting under a steel awning |
| 18:30.55 | *** join/#bzflag bier__ (n=bier@p54A577D0.dip.t-dialin.net) |
| 18:32.26 | *** join/#bzflag Quol (n=ian@modemcable199.71-57-74.mc.videotron.ca) |
| 18:50.39 | *** join/#bzflag bier (n=bier@p54A544EA.dip.t-dialin.net) |
| 19:23.03 | *** join/#bzflag bier (n=bier@p54A55C71.dip.t-dialin.net) |
| 19:26.04 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-255-231.hsd1.md.comcast.net) |
| 19:30.57 | *** join/#bzflag wanda (n=coredump@p54999BC7.dip0.t-ipconnect.de) |
| 19:38.52 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 19:40.30 | *** join/#bzflag Erroneous (n=dtremena@about/essy/CrazyCoder/DTRemenak) |
| 19:40.31 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 19:41.08 | *** join/#bzflag kirun (n=kirun@222.5.gr6.adsl.brightview.com) |
| 19:43.08 | *** join/#bzflag bier (n=bier@p54A5684A.dip.t-dialin.net) |
| 19:43.27 | *** join/#bzflag Warinthestar (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 19:43.41 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 19:44.29 | *** join/#bzflag TimRiker (n=timr@pdpc/supporter/bronze/TimRiker) |
| 19:44.29 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 19:58.53 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 20:00.12 | *** join/#bzflag KTL (n=KTL@213.219.188.181.adsl.dyn.edpnet.net) |
| 20:01.48 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 20:02.23 | *** join/#bzflag bier (n=bier@p54A564A7.dip.t-dialin.net) |
| 20:14.15 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-008-003.ewe-ip-backbone.de) |
| 20:22.35 | *** join/#bzflag QuantumT1m (n=tim@62-249-230-206.no-dns-yet.enta.net) |
| 20:27.05 | *** join/#bzflag bier (n=bier@p54A554F2.dip.t-dialin.net) |
| 20:29.29 | *** join/#bzflag delusional (n=delusion@pool-71-240-52-67.pitt.east.verizon.net) |
| 20:31.08 | wanda | ping Mets |
| 20:43.30 | *** join/#bzflag BenUrban (n=benurban@c-68-49-10-243.hsd1.md.comcast.net) |
| 20:48.47 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 20:54.07 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-227-134.pools.arcor-ip.net) |
| 20:56.43 | Winny | mm... WWDC in 2 days |
| 20:56.46 | Winny | :) |
| 21:01.04 | *** join/#bzflag bier (n=bier@p54A55991.dip.t-dialin.net) |
| 21:09.34 | whodaman- | Winny, :O |
| 21:10.40 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 21:12.09 | *** join/#bzflag Constitution (n=const@unaffiliated/macsforme) |
| 21:23.55 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 21:44.03 | *** join/#bzflag bugQ (n=bugQ@c-67-166-124-4.hsd1.ut.comcast.net) |
| 21:44.22 | *** join/#bzflag eTangenT (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 21:45.28 | *** join/#bzflag javawizard2539 (n=javawiza@c-98-202-192-106.hsd1.ut.comcast.net) |
| 21:46.25 | javawizard2539 | Am I appearing as away to anyone? |
| 21:46.52 | Winny | nope |
| 21:58.30 | JBdiGriz | goes to survey checkin activity for the past week |
| 21:59.36 | *** join/#bzflag eT``out (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 22:03.41 | JeffM | students, how you doing? |
| 22:05.20 | Constitution | it appears that the Shot timers are not getting initialized correctly... currentTime is always getting initialized 0 < value < 1 |
| 22:05.22 | JBdiGriz | So far it's a 3-way tie between bugQ, Thumper_, and Erroneous. Come on students, you can beat the mentors. |
| 22:05.49 | JeffM | Constitution, why is it using currentTime? |
| 22:05.54 | Constitution | but even so, there are other problems... I disabled the lifetime check and it's still not working |
| 22:05.56 | JeffM | oh timers |
| 22:05.58 | JeffM | got it |
| 22:05.59 | *** join/#bzflag eTangenT (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 22:06.16 | JeffM | Constitution, oh I'm sure there are more then one problem, but we have to fix them in time order |
| 22:06.16 | Constitution | yeah, if ( currentTime - startTime > lifetime ) |
| 22:06.26 | Constitution | okay |
| 22:06.33 | JeffM | ok so what's your fix for the current time? |
| 22:06.41 | JeffM | that should be simple |
| 22:07.10 | Constitution | I was in the process of tracing back the initialization of the Shot, and where the info is set |
| 22:07.19 | Constitution | 'cause obviously currentTime is wrong... that would be the first step |
| 22:07.28 | Constitution | I'm getting stuff like |
| 22:07.30 | Constitution | currentTime =$145 = 0.079900026321411133 |
| 22:07.30 | Constitution | startTime =$146 = 7.6079744640631552e-39 |
| 22:07.30 | Constitution | lifetime =$147 = 4.0058789618768742e-11 |
| 22:07.44 | JeffM | hmm |
| 22:07.48 | JeffM | this is in shotManager right? |
| 22:07.51 | Constitution | actually startTime and lifetime are always those exact numbers |
| 22:07.55 | Constitution | yes |
| 22:08.04 | Constitution | currentTime varies between 0 and 1 |
| 22:08.19 | JeffM | should be set in the constructor |
| 22:08.57 | Constitution | right, and that constructor is getting passed a FiringInfo or something |
| 22:09.22 | Constitution | that's about as far as I got last night |
| 22:09.27 | JeffM | well current time should just come from TimeKeeper::GetCurrent().getSeconds(); |
| 22:09.43 | JeffM | start time should be passed in with the info |
| 22:09.50 | JeffM | as part of the timestamp |
| 22:10.15 | Constitution | okay... maybe it's a simple fix |
| 22:11.20 | JeffM | starTime comes from info->timeSent |
| 22:11.44 | JeffM | then lastUpdateTime and currentTime are always set from startTime |
| 22:12.32 | JeffM | put a breakpoint in int ShotManager::newShot ( FiringInfo *info ) and see what the passed in info is |
| 22:12.40 | JeffM | that is sent into the shot constructor |
| 22:16.44 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 22:17.56 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-227-134.pools.arcor-ip.net) |
| 22:18.07 | Constitution | timeSent =$160 = 7.61122548e-39 |
| 22:18.07 | Constitution | lifetime =$161 = 4.00587896e-11 |
| 22:18.14 | Constitution | same values every time |
| 22:18.41 | JeffM | and where are those packed from? |
| 22:19.11 | JeffM | ShotBeginHandler |
| 22:19.49 | JeffM | ok I see the big issue |
| 22:19.53 | JeffM | I need a stamp on the begin |
| 22:20.09 | *** join/#bzflag leviathan (n=d9e5dc8a@gateway/web/cgi-irc/zeebrothers.net/x-4bd2e395bc120c1c) |
| 22:24.01 | CIA-33 | BZFlag: 03JeffM2501 * r17380 10/branches/v2_99_shot_branch/src/ (bzflag/ServerLink.cxx bzfs/bzfsClientMessages.cxx): |
| 22:24.01 | CIA-33 | BZFlag: pack in the shot time on the MsgShotBegin from shooters, so we can know what update it goes with. |
| 22:24.01 | CIA-33 | BZFlag: stub out the lifetime. |
| 22:24.07 | JeffM | Constitution, ok that should get you closer |
| 22:24.10 | *** join/#bzflag eT``out (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 22:24.28 | JeffM | what you'll have to do at some point is make a method to compute the lifetime based on shot type on the server, like the client does |
| 22:24.34 | JeffM | right now I just set it as 5 seconds |
| 22:24.49 | JeffM | also we need to replot the shot start pos from the timestamp |
| 22:25.08 | JeffM | but those can be done after |
| 22:30.13 | delusional | blast007, does the new image submission system have a sticky post on the forum... if there is, it's hard to find.... if there isn't, there needs to be one. |
| 22:34.23 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-50.hsd1.tx.comcast.net) |
| 22:34.23 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:36.18 | Constitution | in other words, compensate for lag, right? |
| 22:36.30 | JeffM | yes and no |
| 22:37.10 | JeffM | we will use the local state |
| 22:37.16 | JeffM | since the shot dosn't have a state anymore |
| 22:37.20 | JeffM | so that will comp for lag |
| 22:37.33 | JeffM | what we have to compensate for is the time between the last update and the shot time |
| 22:37.44 | JeffM | but I think this stuff is still all wrong |
| 22:38.05 | JeffM | I'm not sure the inintal postion and vectors are corret now |
| 22:39.13 | JeffM | the firing info struct isn't created properly |
| 22:39.16 | Constitution | fwiw, when I was playing around with the MsgShotEnd's, I got a small flash on the radar when I fired... but always right in the middle of the map and at the same angle |
| 22:39.26 | JeffM | Constitution, exactly |
| 22:39.33 | JeffM | I don't think it's setting the info correctly |
| 22:39.37 | JeffM | I'm coding that now |
| 22:40.03 | JeffM | make me a generic function to compute the lifetime of a shot based on the flag type |
| 22:40.04 | delusional | oh I found it blast007, it's in "news and announcements" seems like bad placement, to me. Mappers won't be able to find it, there. |
| 22:40.05 | JeffM | and check that in |
| 22:40.13 | JeffM | then we can do this in paralel |
| 22:41.03 | Constitution | okay... GM is the only shot that could have a different lifetime, right? |
| 22:41.03 | *** join/#bzflag Pimpinella (n=frank@gondolin.pimpi.org) |
| 22:41.04 | Constitution | and what exactly do you mean by "the shot doesn't have a state anymore"? |
| 22:41.20 | JeffM | Constitution, the MsgShotBegin dosn't send the firinginfo over the wire |
| 22:41.21 | delusional | Oh that post is for the OLD image submitter, blast |
| 22:41.47 | Constitution | hm, ok |
| 22:48.15 | *** join/#bzflag QuantumBeep (i=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 22:48.38 | *** join/#bzflag fatass (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 22:49.14 | JeffM | Constitution, yeah looks like I missed some code |
| 22:49.17 | JeffM | I'm writing it now |
| 22:49.24 | JeffM | and getting wierd with it :) |
| 22:49.51 | delusional | get crazy with the cheez whiz |
| 22:50.13 | Constitution | heh |
| 22:50.24 | *** join/#bzflag Think_Problems (n=shedelj@pool-96-231-87-87.washdc.east.verizon.net) |
| 22:58.03 | Constitution | so, this function that computes shot lifetime... how extensive should it be? does it need to tie into the shot strategy to compute what path it will follow and when it will hit the wall and die, or just a calculator for normal life based on applicable bzdb values? |
| 22:59.25 | JeffM | Constitution, no, it should be max lifetime if it hits nothing |
| 22:59.34 | JeffM | just the bzdb vars |
| 22:59.40 | *** join/#bzflag _Lukstr (n=Lukstr@CPE0080c6efd3fb-CM00195efb656e.cpe.net.cable.rogers.com) |
| 22:59.40 | Constitution | oh, okay |
| 22:59.41 | JeffM | we end em early if they hit stuff ;) |
| 22:59.49 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 23:00.10 | *** join/#bzflag BZ_Win (n=KyleVE@unaffiliated/winny) |
| 23:00.29 | JeffM | Constitution, I'll also need one to get the inital speed of the shot too |
| 23:02.05 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 23:02.19 | *** join/#bzflag mithro (n=tim@unaffiliated/mithro) |
| 23:05.39 | *** join/#bzflag fatass_ (n=shedelj@pool-96-231-90-43.washdc.east.verizon.net) |
| 23:09.36 | CIA-33 | BZFlag: 03JeffM2501 * r17381 10/branches/v2_99_shot_branch/src/bzfs/ (GameKeeper.cxx GameKeeper.h bzfsClientMessages.cxx): |
| 23:09.36 | CIA-33 | BZFlag: move the DR logic into a common function that works on a copy of the data, not the data, so it can be used in more then one place. |
| 23:09.36 | CIA-33 | BZFlag: build up a more accurate firing info on the server based on the last update state from the client. |
| 23:09.37 | CIA-33 | BZFlag: Stub out places where we need common functions and API hooks. |
| 23:09.44 | JeffM | Constitution, that should get you even better |
| 23:10.07 | JeffM | the 2 places that need the functions you are writing are taged with *** CONST REPLACE THIS |
| 23:10.28 | JeffM | probably should add API hooks there too |
| 23:10.31 | JeffM | after we get it all |
| 23:10.41 | JeffM | to let the API change the speed or the lifetime |
| 23:10.55 | JeffM | heck or even the direction |
| 23:11.04 | JeffM | since the client will update to the server postion when it gets it ;) |
| 23:11.29 | Constitution | okay, great |
| 23:19.55 | JeffM | we'll probalby have to expand it a bit more for some of the wierder shots like SW |
| 23:22.28 | JeffM | then we'll wrap that code into a common method that just takes a player and a time and builds a shot |
| 23:22.35 | JeffM | and one that takes a pos and a time and builds one |
| 23:22.47 | JeffM | then we can juse those to create shots anywhere on the server :) |
| 23:23.34 | JeffM | just so you know. I may become angry at the code in the week and add in a common vector and matrix class to make stuff easier ;) |
| 23:24.07 | Constitution | seems we could almost build it straight into the Shot constructor |
| 23:24.50 | Constitution | but anyway, code first, formalities later :) |
| 23:24.52 | JeffM | well there are 2 ways to construct them |
| 23:24.58 | JeffM | so not all the time |
| 23:25.15 | JeffM | and remember the shot contructor will eventaly go on the client too |
| 23:25.25 | JeffM | that's why it's abstracted into the firing info records |
| 23:25.38 | JeffM | world weapons won't use player postions for instance. |
| 23:26.17 | JeffM | so utility functions to build firingInfos for each case will be clean enough |
| 23:26.25 | JeffM | rather then packing up the shot with a bunch of constructors. |
| 23:36.56 | *** join/#bzflag eTangenT (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 23:40.02 | Mets | JeffM: when you have a second, any chance you might have an idea what's causing my compile error on solaris? |
| 23:42.48 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-008-003.ewe-ip-backbone.de) |
| 23:43.06 | JeffM | Mets, I have never used a solaris machine |
| 23:43.12 | JeffM | but what is the error? |
| 23:43.38 | Mets | http://my.bzflag.org/bb/viewtopic.php?t=12641 |
| 23:44.09 | Mets | wanda was trying to help me yesterday, he thought it had something to do with the sequence, as libcurl is there and it understands those functions |
| 23:44.20 | JeffM | what version of curl do you have installed? |
| 23:45.13 | Mets | 7.15 |
| 23:45.34 | JeffM | do you perhaps have more then one? |
| 23:45.50 | Mets | more than one version of libcurl? |
| 23:46.14 | JeffM | likeyes |
| 23:46.28 | JeffM | the error is that your lib does not have the multi interface |
| 23:46.32 | JeffM | I wonder if you have more then one lib |
| 23:46.37 | JeffM | an old one and a new one |
| 23:46.42 | Mets | ah |
| 23:46.55 | Mets | whereis curl returns curl: /usr/local/bin/curl |
| 23:47.19 | Mets | so only one path |
| 23:47.30 | JeffM | search for all instances of libcurl.so |
| 23:48.11 | JeffM | well probably libcurl*.so |
| 23:49.01 | *** join/#bzflag delusional (n=delusion@pool-71-253-7-59.pitbpa.east.verizon.net) |
| 23:49.24 | Mets | searching right now |
| 23:51.54 | Mets | found /usr/local/lib/libcurl.so |
| 23:53.15 | JeffM | was that installed as part of the system? |
| 23:54.06 | Mets | I believe so, I didn't install a new version |
| 23:54.26 | JeffM | it was probalby not built with multi support |
| 23:54.31 | Mets | I tried downloading a new version from the website, compiled for solaris, and gave it the --with-libcurl switch, but it didn't change anything |
| 23:54.37 | JeffM | do you have any other packages for it available |
| 23:54.54 | JeffM | you want to update the one on the system, not just use another for link |
| 23:55.03 | JeffM | or use ours and build it static |
| 23:55.06 | Constitution | if it's in /usr/local it shouldn't have been installed with a package manager or as part of the system |
| 23:55.21 | Mets | how do I use ours? |
| 23:55.27 | JeffM | I don't know |
| 23:55.35 | JeffM | probably remove the one you have on the system |
| 23:55.45 | Mets | this is the one in trunk or branch? |
| 23:55.45 | JeffM | then rerun autogen etc.. |
| 23:55.55 | JeffM | what are you trying to build? |
| 23:56.01 | JeffM | trunk or branch? |
| 23:56.03 | Mets | I tried 2.0.10 first |
| 23:56.13 | Mets | so old branch |
| 23:56.28 | JeffM | I don't know if we include curl in branch |
| 23:56.34 | JeffM | that was before we had src/other |
| 23:57.35 | JeffM | does solaris have it's own package system? |
| 23:58.10 | Mets | sort of, it's not like apt or yum |
| 23:58.11 | JeffM | and no, 2.0.x does not include curl, so it has to use your installed one |
| 23:58.25 | JeffM | does whatever it uses have more then one version of curl? |
| 23:58.39 | Mets | I have the latest installed |
| 23:58.50 | JeffM | then sounds like solaris sucks |
| 23:58.52 | *** join/#bzflag eT``out (n=etangent@71-211-225-228.hlrn.qwest.net) |
| 23:58.54 | Mets | lol |
| 23:59.00 | JeffM | I'd get source for it and build your own |
| 23:59.13 | JeffM | making sure that the multi interface is enabled. |
| 23:59.28 | Mets | k, can I use the libcurl source in src/other on branch? |
| 23:59.41 | JeffM | I would recomend using the offical curl sources |
| 23:59.46 | JeffM | it'll be cleaner |