| 00:42:00 | Bakemono | did someone do something to ibot? |
| 00:42:03 | | you are, like, |
| 00:42:03 | Bakemono | ibot: Bakemono? |
| 00:42:07 | Bakemono | hmm |
| 00:42:14 | Bakemono | that's odd... |
| 02:56:34 | vogon_jeltz | is back (gone 06:59:24) |
| 06:33:29 | captain_proton | hi tim |
| 06:34:26 | iLL_Away | he |
| 06:34:27 | iLL_Away | h |
| 06:34:39 | iLL_Away | I figured out how to force people up for tightrope |
| 06:34:41 | iLL_Away | heh |
| 06:35:19 | captain_proton | how? |
| 06:35:27 | iLL_Away | join my server |
| 06:36:17 | captain_proton | which is it again? |
| 06:36:27 | iLL_Away | l8tr.dyndns.org |
| 06:36:32 | iLL_Away | I just got the force part done |
| 06:36:33 | iLL_Away | heh |
| 06:36:40 | iLL_Away | gotta add in 2 sets of teleporters |
| 06:36:45 | iLL_Away | one to reward those who make it to top level |
| 06:36:58 | iLL_Away | and one for those who gotta restart at bottom |
| 06:41:26 | iLL_Away | heh |
| 06:41:34 | iLL_Away | bizarre but it'll work you'lls ee |
| 06:44:19 | iLL_Away | that looks like a heat sink I know |
| 06:44:22 | iLL_Away | but it'll work =) |
| 06:44:59 | captain_proton | BZFlag: you're like a damn yoyo |
| 06:45:48 | iLL_Away | heh |
| 06:45:48 | captain_proton | ooh pretty |
| 06:45:57 | BZFlag | captain_proton: heh. trying to get auto-op working |
| 06:45:58 | captain_proton | wonders if he's still chanserv's buddy |
| 06:46:05 | iLL_Away | heh |
| 06:46:10 | iLL_Away | you get it running? |
| 06:46:20 | iLL_Away | owns a few channels if you need a bit of cmd info |
| 06:46:56 | captain_proton | no more op for me here :( |
| 06:46:57 | BZFlag | nope. |
| 06:47:01 | iLL_Away | heh |
| 06:47:06 | iLL_Away | nice |
| 06:47:07 | iLL_Away | =P |
| 06:47:09 | captain_proton | :) |
| 06:47:27 | BZFlag | happy? |
| 06:47:30 | iLL_Away | heh |
| 06:47:33 | captain_proton | now i don't feel special :( |
| 06:47:44 | BZFlag | course iLL's not really away. |
| 06:47:45 | iLL_Away | you can deop me so he can feel all special |
| 06:47:46 | iLL_Away | heh |
| 06:47:55 | BZFlag | deop yourself. ;-) |
| 06:48:11 | iLL_Away | forgets he doesn't need to use chanserv for that heh |
| 06:48:22 | BZFlag | wonder what happens if I deop chanserv... |
| 06:48:28 | iLL_Away | nothing |
| 06:48:40 | BZFlag | heh, sure enough. |
| 06:48:46 | iLL_Away | kline |
| 06:48:46 | iLL_Away | heh |
| 06:48:47 | iLL_Away | =P |
| 06:48:48 | iLL_Away | jk |
| 07:59:52 | iLLf8d | hmm |
| 07:59:56 | iLLf8d | anyone around? |
| 08:00:08 | captain_proton | sorta |
| 08:00:17 | iLLf8d | does the current cvs server require a different map format |
| 08:00:31 | iLLf8d | I just recompiled now my map isn't working in the new server |
| 08:00:31 | captain_proton | shouldn't |
| 08:00:33 | iLLf8d | hmm |
| 08:00:36 | captain_proton | how is it not working? |
| 08:00:54 | iLLf8d | it doesn't error it just doesn't show up to let me connect |
| 08:01:15 | captain_proton | probably not a map error |
| 08:01:18 | iLLf8d | hmm |
| 08:01:31 | iLLf8d | 1.7e4 works tho |
| 08:01:36 | iLLf8d | just not e5 |
| 08:01:43 | iLLf8d | no compile errors |
| 08:02:16 | captain_proton | so you're getting no errors at all? |
| 08:02:21 | iLLf8d | did you change the flags or anything |
| 08:03:01 | iLLf8d | game full or over |
| 08:03:03 | iLLf8d | try again later |
| 08:03:05 | captain_proton | ohhhh |
| 08:03:15 | iLLf8d | it wasn't showing I typed in the ip |
| 08:03:15 | captain_proton | add -p <port> -pr <port+1> |
| 08:03:30 | iLLf8d | new settings? |
| 08:03:55 | captain_proton | no not really |
| 08:04:02 | captain_proton | just breakage of the net code |
| 08:04:31 | iLLf8d | hmm |
| 08:04:44 | iLLf8d | i'll have to record that so I don't forget heh |
| 08:05:04 | iLLf8d | is the latest assumed degree based maps? |
| 08:05:07 | captain_proton | yeah |
| 08:05:24 | iLLf8d | thats why I upgraded the other one was turding heh |
| 08:06:00 | iLLf8d | bzedit looks alot slicker =) |
| 08:06:18 | iLLf8d | seems its lost the ability to highlight objects in the list tho |
| 08:06:28 | iLLf8d | I mean select from the highlight |
| 08:06:47 | iLLf8d | mouse controls help tons tho |
| 08:06:53 | iLLf8d | thanks for the work =) |
| 08:06:54 | captain_proton | yeah thats because i haven't written that part yet |
| 08:07:10 | iLLf8d | seems theres a bug in spin controls |
| 08:07:15 | iLLf8d | sometimes the reverse |
| 08:07:21 | iLLf8d | and a bug in object removal |
| 08:07:35 | iLLf8d | selections go haywire |
| 08:07:35 | captain_proton | spin controls are handled by gtk, not me |
| 08:12:56 | iLLf8d | hmm |
| 08:13:05 | iLLf8d | hmm |
| 08:13:17 | iLLf8d | seems I need to do something to tell the server i'm using degrees still |
| 08:13:20 | iLLf8d | know what that is? |
| 08:13:36 | captain_proton | it uses degrees by default... |
| 08:13:48 | iLLf8d | wherever i've tried to > rotation 90 < its locking it up |
| 08:13:56 | captain_proton | it is?! |
| 08:13:59 | captain_proton | bizzare |
| 08:14:03 | iLLf8d | well on the teleporters |
| 08:14:12 | iLLf8d | haven't tried on anything else on that field |
| 08:14:37 | iLLf8d | I commented out all the 90 deg ones and the 0 rotation ones work fine |
| 08:14:53 | iLLf8d | BZFlag server, version 1.7e5 |
| 08:14:55 | iLLf8d | hmm |
| 08:14:55 | captain_proton | never heard of anything like that |
| 08:15:26 | iLLf8d | wasn't there some kinda degree thing in a map file at some time? |
| 08:15:33 | iLLf8d | like you put degree in somewhere |
| 08:16:15 | captain_proton | it was supposed to be where you could but 'radians' in there for backwards compatibility |
| 08:17:05 | iLLf8d | hmm |
| 08:17:12 | iLLf8d | no I don't think thats the issue actually |
| 08:17:22 | iLLf8d | I just ran another map fine with degrees on it |
| 08:17:27 | iLLf8d | is there a limit to object numbers? |
| 08:17:32 | iLLf8d | i'm almost topping 100 |
| 08:18:13 | captain_proton | don't think so |
| 08:23:59 | iLLf8d | curious |
| 08:24:13 | iLLf8d | it doesn't like 2 teleporters when they're set to 90degrees |
| 08:24:14 | iLLf8d | hmm |
| 08:25:37 | iLLf8d | woa wierd |
| 08:25:45 | captain_proton | lol |
| 08:25:51 | iLLf8d | I moved the positioning |
| 08:25:55 | iLLf8d | it was at 0 6 0 |
| 08:25:59 | iLLf8d | I moved it to 0 50 0 |
| 08:26:01 | iLLf8d | and now it runs |
| 08:26:03 | iLLf8d | wtf |
| 08:26:17 | iLLf8d | hmm |
| 08:26:31 | captain_proton | lol |
| 08:26:52 | iLLf8d | #!name teleporter-84 |
| 08:26:52 | iLLf8d | teleporter |
| 08:26:52 | iLLf8d | position 0 50 0 |
| 08:26:52 | iLLf8d | rotation 90 |
| 08:26:52 | iLLf8d | size 0 380 20.16 |
| 08:26:53 | iLLf8d | border 1 |
| 08:26:55 | iLLf8d | end |
| 08:26:57 | iLLf8d | #!name teleporter-85 |
| 08:26:59 | iLLf8d | #teleporter |
| 08:27:01 | iLLf8d | #position 0 -6 0 |
| 08:27:03 | iLLf8d | #rotation 90 |
| 08:27:04 | iLLf8d | #size 0 380 20.16 |
| 08:27:08 | iLLf8d | #border 1 |
| 08:27:11 | iLLf8d | #end |
| 08:27:13 | iLLf8d | those are the 2 |
| 08:27:15 | iLLf8d | the first was 0 6 0 |
| 08:27:32 | iLLf8d | wonders why the teleporter code cares where it is |
| 08:28:22 | iLLf8d | works at 0 10 0 |
| 08:29:09 | iLLf8d | not at 0 6 0 |
| 08:29:13 | iLLf8d | thats messed |
| 08:30:34 | iLLf8d | works at 0 8 0 |
| 08:30:35 | iLLf8d | hmm |
| 08:30:42 | captain_proton | hahaha |
| 08:30:50 | iLLf8d | wierd huh |
| 08:31:08 | iLLf8d | you know how much tank clearance is needed when teleporters are against wall? |
| 08:31:11 | iLLf8d | is it 4 units? |
| 08:31:26 | iLLf8d | maybe I can get away with the 2 |
| 08:31:27 | captain_proton | no i don't know |
| 08:32:12 | iLLf8d | hmm |
| 08:32:23 | iLLf8d | wonders if its a vidcard issue or something wierd |
| 08:33:47 | iLLf8d | seems these big teleporters won't run in close proximity to one another |
| 08:33:49 | iLLf8d | wierd |
| 08:34:03 | captain_proton | big teleporter->small teleporter = bad situation |
| 08:34:19 | iLLf8d | yeah they're unlinked so far |
| 08:34:25 | iLLf8d | shouldn't be an issue yet... |
| 08:34:39 | captain_proton | still - be careful with the sizes |
| 08:34:51 | captain_proton | ie. people got stuck in danworld all the time b/c of that |
| 08:34:57 | iLLf8d | yeah |
| 08:36:05 | iLLf8d | well looks like they work if they're 10 apart |
| 08:36:12 | iLLf8d | oops 20 I mean heh |
| 08:36:19 | iLLf8d | 10 a piece from the centerline |
| 08:36:20 | iLLf8d | heh |
| 08:36:27 | iLLf8d | go figure |
| 08:36:59 | iLLf8d | come to think of it I really only need one there |
| 08:37:01 | iLLf8d | hmm |
| 09:09:46 | MrApathyCream | notices FlagEntryZone listing in patches on sourceforge. |
| 09:30:35 | | what's up, captain_proton |
| 09:30:35 | captain_proton | MrApathyCream: hi |
| 09:30:51 | captain_proton | MrApathyCream: did you just break down and do vogon_jeltz's part? |
| 09:31:50 | MrApathyCream | somebody did, don't know who.... |
| 09:31:55 | MrApathyCream | elves, i guess |
| 09:32:00 | captain_proton | rofl |
| 09:34:38 | MrApathyCream | i like your: flags { GM L ST } syntax |
| 09:34:46 | captain_proton | :) |
| 09:34:50 | captain_proton | so do I ;) |
| 09:34:56 | MrApathyCream | much better, if only I could say flags ( good } :) |
| 09:35:09 | captain_proton | yeah...i'll get on it once my time frees up some more |
| 09:35:42 | MrApathyCream | flags {GM} doesn't work though |
| 09:35:48 | captain_proton | it doesn't? |
| 09:35:52 | MrApathyCream | flags { GM } does |
| 09:35:54 | captain_proton | oh yeah of course |
| 09:35:58 | captain_proton | because of how bzflag gets tokens |
| 09:36:12 | MrApathyCream | minor |
| 09:36:29 | captain_proton | yeah, and it would require serious changes to fix |
| 09:36:57 | | ChanServ is a service running on the IRC server that lets you register channels and control who is allowed OP privileges and stuff. Try /msg chanserv help |
| 09:36:57 | MrApathyCream | ibot, what is ChanServ? |
| 09:37:57 | iLLf8d | sorry cream heh |
| 09:37:58 | iLLf8d | =P |
| 09:37:58 | MrApathyCream | I like chestal's two new patches, --- quite useful |
| 09:38:07 | iLLf8d | where you just on decks? |
| 09:38:07 | captain_proton | which are they? |
| 09:38:11 | MrApathyCream | yes |
| 09:38:12 | iLLf8d | or is someone using your nick |
| 09:38:16 | captain_proton | iLLf8d: right now? |
| 09:38:24 | iLLf8d | about 10 seconds ago |
| 09:38:27 | captain_proton | they left? |
| 09:38:30 | iLLf8d | yeah |
| 09:38:31 | MrApathyCream | yes it's me, was waiting for someone to show up |
| 09:38:35 | iLLf8d | ah |
| 09:38:41 | iLLf8d | I was just checking out the field |
| 09:38:41 | MrApathyCream | i see someone did |
| 09:38:47 | iLLf8d | I figured i'd be alone |
| 09:38:49 | iLLf8d | heh |
| 09:38:50 | captain_proton | oh you were talking to apathy |
| 09:38:58 | iLLf8d | yeah sorry |
| 09:39:05 | iLLf8d | was making sure we didn't have an imposter |
| 09:39:15 | captain_proton | was worried about someone using his nick |
| 09:39:22 | iLLf8d | I wouldn't be surprised |
| 09:39:55 | MrApathyCream | iLLf8d: are you option_testing? |
| 09:40:00 | iLLf8d | I was before |
| 09:40:10 | iLLf8d | I found out one of the settings really messes things up |
| 09:40:21 | MrApathyCream | ? |
| 09:40:22 | iLLf8d | depth buffer setting |
| 09:40:29 | iLLf8d | when I jump and shoot by a huge roof |
| 09:40:36 | iLLf8d | my framerates plummet |
| 09:40:38 | MrApathyCream | hmm |
| 09:40:43 | iLLf8d | when I turn it off their fine |
| 09:41:07 | MrApathyCream | how much video ram? |
| 09:41:25 | iLLf8d | at first I got all excited and was hoping my decks frame rates would be better but it didn't help there (just my k6-crap 500) can't handle the math I think heh |
| 09:41:28 | iLLf8d | uhm |
| 09:41:31 | iLLf8d | 32MB |
| 09:41:45 | iLLf8d | I got a bum AGP chipset supposedly |
| 09:41:56 | iLLf8d | Ali Alladin V |
| 09:42:03 | MrApathyCream | what happens when you run in -window mode |
| 09:42:14 | iLLf8d | haven't tried it |
| 09:42:22 | iLLf8d | my brightness gets all fscked |
| 09:42:39 | iLLf8d | the window looks right but the desktop gets blasted |
| 09:42:48 | iLLf8d | and when I quit the desktop doesn't go back to normal |
| 09:42:50 | captain_proton | iLLf8d: yeah thats a sucky part of how it does brightness |
| 09:42:56 | captain_proton | iLLf8d: it doesn't? |
| 09:42:59 | iLLf8d | nope |
| 09:42:59 | MrApathyCream | yeah, it's a pain |
| 09:43:11 | iLLf8d | and sometimes I scroll off the window |
| 09:43:21 | iLLf8d | or something to that effect and it gets screwed too |
| 09:43:23 | MrApathyCream | mouse off window == big pain |
| 09:43:30 | iLLf8d | so I run full screen |
| 09:43:54 | MrApathyCream | i had a 10fps vid card for a while and tried -window.. not a pleasant experience |
| 09:43:59 | iLLf8d | heh |
| 09:44:01 | iLLf8d | me too... |
| 09:44:10 | iLLf8d | I went from ati 4mb xpression |
| 09:44:17 | iLLf8d | to 32mb geforce2mx |
| 09:44:18 | iLLf8d | heh |
| 09:44:19 | iLLf8d | =P |
| 09:44:31 | iLLf8d | 5-12fps to 45-140 heh |
| 09:44:37 | MrApathyCream | Now 85fps at 1152x864x32 (GeForce3) |
| 09:44:52 | iLLf8d | apathy what kinda cpu? |
| 09:44:58 | MrApathyCream | 1.8 p4 |
| 09:44:59 | iLLf8d | wonders if you have decks issues too |
| 09:45:02 | iLLf8d | ah no... |
| 09:45:02 | iLLf8d | heh |
| 09:45:11 | MrApathyCream | decks is fine now |
| 09:45:16 | captain_proton | MrApathyCream: 85 on a gf3?! |
| 09:45:21 | iLLf8d | I need to find someone with a geforce2 or better and a 500k6-2 or comparable |
| 09:45:22 | MrApathyCream | captain_proton: yes |
| 09:45:23 | captain_proton | i get 110 at 1600x1200x32 on my gf3 |
| 09:45:30 | iLLf8d | to see if they experience the same racheting |
| 09:45:47 | captain_proton | well, at least 110 |
| 09:45:51 | iLLf8d | MrApathyCream: which field tho? |
| 09:45:58 | captain_proton | maxes out at about 250 |
| 09:46:02 | MrApathyCream | iLLf8d: pretty much universal constant |
| 09:46:05 | iLLf8d | I can even get 140 with noone on it just tooling around shooting |
| 09:46:11 | iLLf8d | something sounds b0rked |
| 09:46:26 | iLLf8d | my gf2 rates with my wimpy cpu can be better then that at times |
| 09:46:46 | iLLf8d | which os? |
| 09:46:50 | MrApathyCream | 56K probably effects things |
| 09:47:24 | iLLf8d | i'm running linux with the latest nvidia drivers |
| 09:47:25 | iLLf8d | works well |
| 09:47:53 | MrApathyCream | slurps on decks now... |
| 09:48:03 | captain_proton | slurps? |
| 09:48:04 | iLLf8d | I need ideas for my heatsink =P |
| 09:48:05 | iLLf8d | heh |
| 09:48:24 | iLLf8d | got the teleporters setup heh |
| 09:48:36 | captain_proton | lol that IS a heatsink |
| 09:48:40 | iLLf8d | cap send me tightrope |
| 09:48:44 | iLLf8d | i'll put that above it |
| 09:49:05 | iLLf8d | then you can call it |
| 09:49:15 | iLLf8d | Tightrope watercooled |
| 09:49:16 | iLLf8d | heh |
| 09:49:21 | captain_proton | its not water |
| 09:49:33 | captain_proton | tightrope - now with cooling! |
| 09:49:34 | iLLf8d | what water cooling uses no veins comeon |
| 09:49:55 | iLLf8d | may have to make a few mods tho... |
| 09:49:56 | captain_proton | do you see water in this version of bzflag? i think not |
| 09:50:01 | iLLf8d | heh |
| 09:50:13 | iLLf8d | semantics, i've never seen a flying tank either |
| 09:50:14 | iLLf8d | heh |
| 09:50:29 | iLLf8d | gotta use your imagination |
| 10:22:31 | iLLf8d | ROFLMAO |
| 10:22:32 | iLLf8d | heh |
| 10:22:40 | iLLf8d | my pc can't handle the super cooling heh |
| 10:22:41 | iLLf8d | =P |
| 10:22:54 | iLLf8d | I just plopped them together |
| 10:23:00 | iLLf8d | i'm getting 9-11fps |
| 10:23:00 | iLLf8d | heh |
| 10:35:12 | captain_proton | LOL |
| 10:35:22 | captain_proton | maybe with your new heatsink you could overclock it? |
| 10:35:40 | captain_proton | is your sever up? |
| 10:38:19 | iLLf8d | heh |
| 10:38:23 | iLLf8d | i'll put it up now |
| 10:40:13 | iLLf8d | l8tr.dyndns.org |
| 10:40:17 | iLLf8d | port 5000 |
| 10:41:03 | captain_proton | you forgot -pr |
| 10:41:27 | iLLf8d | yeah I made it 5001 heh I'll make it larger |
| 10:41:28 | iLLf8d | heh |
| 10:41:48 | iLLf8d | nothing like 3-4 fps heh |
| 10:42:14 | iLLf8d | game is full =P |
| 10:43:06 | iLLf8d | are you in? |
| 10:43:24 | captain_proton | yeah i was |
| 10:43:30 | iLLf8d | shit sorry |
| 10:43:34 | iLLf8d | didn't show you connected |
| 10:44:01 | iLLf8d | I set p 5000 and pr 5001 |
| 10:44:06 | iLLf8d | oops 5010 I mean heh |
| 10:44:09 | iLLf8d | wouldn't let me connect |
| 10:44:17 | captain_proton | hmmm |
| 10:44:20 | iLLf8d | its back up |
| 10:44:43 | iLLf8d | I still have to cape that center section ie the center teleporter shouldn't have access to the sides |
| 10:44:58 | iLLf8d | its setup so you have to fight your way to the top to get access to new flags below |
| 10:45:50 | iLLf8d | hmm |
| 10:46:05 | iLLf8d | I wonder if one of those fake floors would improve my framerates |
| 10:46:08 | iLLf8d | I bet it would |
| 10:46:23 | MrApathyCream | Host not found 11001 -> 18tr.dyndns.org |
| 10:46:53 | iLLf8d | hmm |
| 10:46:57 | iLLf8d | just use my ip |
| 10:46:57 | captain_proton | is there any way to get up to the top level? |
| 10:47:10 | iLLf8d | not yet |
| 10:47:17 | iLLf8d | I need to add a teleporter int he center room |
| 10:47:26 | captain_proton | ahh i see |
| 10:47:28 | iLLf8d | my 3fps sucks tho ... |
| 10:47:30 | MrApathyCream | 63.204.177.95? |
| 10:47:31 | iLLf8d | heh |
| 10:47:32 | captain_proton | the heatsink looks cool |
| 10:47:37 | iLLf8d | whats your framerate like? |
| 10:47:45 | iLLf8d | 63.204.177.95 |
| 10:47:50 | captain_proton | me? probably about 70-80 |
| 10:47:54 | iLLf8d | no shit |
| 10:47:56 | captain_proton | in general |
| 10:47:59 | iLLf8d | mine is 3 fps |
| 10:48:00 | iLLf8d | suck |
| 10:48:08 | iLLf8d | gotta be my cpu |
| 10:48:09 | captain_proton | has a very nice setup |
| 10:48:37 | iLLf8d | i'm gonna put a fake cieling/floor on it |
| 10:48:45 | iLLf8d | on top of the heatsink |
| 10:48:48 | captain_proton | that won't help |
| 10:48:55 | captain_proton | bzflag doesn't do occlusion culling atm |
| 10:48:59 | iLLf8d | why not? i'd think it won't try to render whats outta view |
| 10:49:09 | iLLf8d | oh bummer |
| 10:49:34 | iLLf8d | wonder why it won't let me connect |
| 10:49:35 | captain_proton | it really should, but it doesn't |
| 10:50:24 | MrApathyCream | hmm can't connect either with numeric ip |
| 10:50:28 | MrApathyCream | port 5010, right? |
| 10:50:31 | iLLf8d | no |
| 10:50:33 | iLLf8d | 5000 |
| 10:50:38 | MrApathyCream | oh |
| 10:50:43 | captain_proton | ok i need to go to sleep |
| 10:50:43 | iLLf8d | if protons on I dunno if it'll letya in |
| 10:50:56 | iLLf8d | its missing a teleporter and a few walls sitll |
| 10:51:10 | iLLf8d | need to seperate the center teleporter from the side ones |
| 10:51:18 | iLLf8d | the lower sides will bring you to base |
| 10:51:22 | MrApathyCream | running 1.7e5? |
| 10:51:25 | iLLf8d | yeah |
| 10:51:35 | iLLf8d | it just crashed |
| 10:51:36 | iLLf8d | try again |
| 10:51:37 | MrApathyCream | oh, yeah, we need to fix that |
| 10:51:40 | iLLf8d | Segmentation fault |
| 10:51:51 | iLLf8d | I can run 4 |
| 10:51:53 | iLLf8d | np |
| 10:51:54 | iLLf8d | =) |
| 10:52:02 | iLLf8d | take me sec |
| 10:52:04 | iLLf8d | lemme try it |
| 10:52:07 | iLLf8d | ok? |
| 10:52:07 | captain_proton | MrApathyCream: at this point i think we should just concentrate on 1.8 |
| 10:52:39 | iLLf8d | ok should be up now |
| 10:53:05 | iLLf8d | its 1.7e4 |
| 10:53:11 | iLLf8d | dunno if its degrees or rads |
| 10:53:15 | iLLf8d | that might be messed up too |
| 10:53:16 | iLLf8d | hmm |
| 10:53:44 | captain_proton | e3.5+ is degrees |
| 10:54:10 | iLLf8d | do I need the p and pr in 1.7e4? |
| 10:54:19 | captain_proton | no |
| 10:54:22 | captain_proton | just e5 |
| 10:54:39 | MrApathyCream | Why'd riker add that anyway? |
| 10:54:47 | MrApathyCream | old clients or something? |
| 10:55:04 | iLLf8d | hmm |
| 10:55:09 | iLLf8d | mine locks up in 1.7e4 |
| 10:55:11 | iLLf8d | wierd |
| 10:56:02 | iLLf8d | 4 definately doesn't like it heh =P |
| 10:56:50 | iLLf8d | soon as I click my mouse my client bails heh |
| 10:59:55 | MrApathyCream | Where's the 1.8 project plan... I want to download it... :p |
| 11:00:42 | MrApathyCream | lol |
| 11:01:06 | iLLf8d | so like I heard its like to make the game more better man |
| 13:53:58 | Chestal | *sob*, our file server is gone |
| 15:50:27 | | Chestal was last seen on #bzflag 17 hours, 33 minutes and 17 seconds ago, saying: that sucks [Fri Feb 1 22:17:10 2002] |
| 15:50:27 | MrApathyCream | ibot, seen Chestal? |
| 16:38:53 | | chestal was last seen on #bzflag 0 seconds ago, saying: ibot: seen chestal? [Sat Feb 2 16:38:53 2002] |
| 16:38:53 | Chestal | ibot: seen chestal? |
| 17:03:43 | Chestal | hi Cream |
| 17:03:46 | MrApathyCream | hey! |
| 17:04:10 | MrApathyCream | Chestal: I like your respond to nemesis, and paused/not responding hud indicators.... nice |
| 17:05:13 | MrApathyCream | How goes server-de-obfuscation? |
| 17:05:23 | Chestal | only two tiny patches. I foudn myself looking who is the not responding tank too often |
| 17:05:43 | MrApathyCream | yeah... and not having respond was really annoying. thanks |
| 17:05:48 | Chestal | well, I still do not grasp al lof the net code |
| 17:06:03 | Chestal | with 1.8 everythign will be better of course |
| 17:06:29 | Chestal | but I guess for the next minor release we'd better dump multicasting and related stuff altogehter |
| 17:06:47 | Chestal | I won't be able to do any work nz bz for soem days |
| 17:06:53 | MrApathyCream | Any idea why the -pr stuff was put in? |
| 17:07:03 | Chestal | our fileserver crashed (a hard disk died) :-( |
| 17:07:08 | MrApathyCream | ooof |
| 17:07:25 | Chestal | Tim was trying to get rid of the silly reconnect altogether |
| 17:07:36 | Chestal | I guess using a fixed port for reconnecting was a first step |
| 17:07:43 | MrApathyCream | ah.. |
| 17:07:43 | Chestal | IIRC the odl versions used a random port? |
| 17:08:06 | MrApathyCream | Why the need for reconnect, again? |
| 17:08:10 | Chestal | I did some analysis on message frequency durign the last days |
| 17:08:36 | Chestal | well, the client connects to the server port 5155, gets basic info abot the server and then has to reconnect to another port |
| 17:08:45 | Chestal | don't ask me why it was designed this way |
| 17:08:51 | MrApathyCream | seems silly |
| 17:08:58 | MrApathyCream | sorry, anyway about your analysis |
| 17:08:59 | Chestal | I think the random reconnect port is being used as part of the player id |
| 17:09:20 | Chestal | Tim changed the playerid from server/port to client/port I think |
| 17:09:28 | Chestal | thus the id pathcing hack for compatability |
| 17:09:34 | MrApathyCream | PlayerID: why not just array index? |
| 17:09:47 | MrApathyCream | in bzfs players array |
| 17:10:04 | Chestal | hmm, maybe I am mistaken and the player index is used for the new player id |
| 17:10:07 | Chestal | I am not that sure |
| 17:10:22 | MrApathyCream | Message frequency? |
| 17:10:36 | Chestal | yep, as was to be expected MsgPlayerUpdate is by far the dominant mesasge type |
| 17:10:43 | Chestal | and it's sent far too often for my taste |
| 17:11:03 | MrApathyCream | should have throttling for fast network clients |
| 17:11:13 | Chestal | I measured the rate of update msgs sent by each client |
| 17:11:27 | Chestal | I had as much as 90 update mssg sent in one second |
| 17:11:44 | Chestal | of course this was the maximum, but clients with high frame rates often sent lots of update messages |
| 17:11:58 | MrApathyCream | 90 msgs by 1 client or by all clients |
| 17:12:08 | Chestal | by 1 client |
| 17:12:14 | MrApathyCream | oooh.... yikes |
| 17:12:20 | Chestal | I could push my client up to as much as about 30 mesasges |
| 17:12:26 | Chestal | my framerate deosn't get higher than 40 |
| 17:12:38 | Chestal | do you know about the dead reckoning stuff? |
| 17:12:41 | MrApathyCream | fps = #messages, maybe would make sense |
| 17:12:56 | MrApathyCream | dead reckoning.. no |
| 17:13:25 | Chestal | this is a measure to skip sending of unnecessary upadte msgs in the client |
| 17:13:38 | MrApathyCream | ah |
| 17:13:43 | Chestal | the basic idea is that every client tries to project the movement of other tanks into the future |
| 17:13:43 | MrApathyCream | good name ? |
| 17:14:17 | Chestal | it taskes the tanks current speed and angular velocity into account |
| 17:14:24 | MrApathyCream | What if my tank only actually moves in reaction to network messages |
| 17:14:34 | Chestal | thus clients who do net send any messages will seem to drive on a circular path |
| 17:14:40 | MrApathyCream | ahhh, yes |
| 17:14:47 | Chestal | this scheme works quite nicely |
| 17:14:49 | MrApathyCream | the death spiral |
| 17:15:07 | Chestal | whenever a player does not push his mouse no packages are sent |
| 17:15:16 | Chestal | well, actually at least 1 packet/s is sent nonetheless |
| 17:15:48 | Chestal | the client does this projection for its own tank and whenever the projection differs from the actual data by more than a tolerance a new packet is sent |
| 17:16:03 | MrApathyCream | pretty nice |
| 17:16:16 | Chestal | so, lots of packages will onkly be sent when you're doing soem steering |
| 17:16:44 | Chestal | the tolerance values are very low, they;er 0.01m currently (with a tank having a length of about 6m) |
| 17:16:46 | MrApathyCream | have you concluded that dead reckoning actually works as advertised? |
| 17:16:49 | Chestal | maybe we could increase these |
| 17:16:54 | Chestal | yes, it works ok |
| 17:17:08 | MrApathyCream | yes, .01 sounds sillyly low to me |
| 17:17:10 | Chestal | I also patched my client to sent at most 20 messages/s |
| 17:17:40 | Chestal | the question is whether this does have any unwanted effects |
| 17:17:40 | MrApathyCream | and .01 i assume is in x,y,z distance? >> really small |
| 17:17:44 | Chestal | I can't tell myself |
| 17:18:06 | Chestal | what I do is to test how much tiem has passed since the last mesage was sent, if it's below 0.05s it won't be sent |
| 17:18:28 | MrApathyCream | I would think .4 or so would be fine |
| 17:18:31 | Chestal | whenever the tanks' status changes, a message is sent nonetheless |
| 17:18:53 | Chestal | I think we coudl experiment with different settings and see if they have any side effects |
| 17:18:58 | MrApathyCream | yes. |
| 17:19:21 | Chestal | then I thought I'd do a server patch to reduce network load even with odl clients by not relaying all update mesasges to the other players |
| 17:19:21 | MrApathyCream | I'd sure like fixing 1.7e5 too, just so it works as good as 1.7e4 |
| 17:19:51 | Chestal | first I tried a naive approach which failed (and I think I know why it failed). But my more refined approach also failed :-( |
| 17:20:49 | MrApathyCream | Seems as most are interested in dumping any 1.7 work in favor of 1.8 |
| 17:20:52 | MrApathyCream | I fear a long winter |
| 17:21:13 | Chestal | hehe |
| 17:21:33 | Chestal | but I think we should at least do a 1.7e6 release with small fixes and enhancements |
| 17:21:39 | MrApathyCream | I agree |
| 17:22:01 | MrApathyCream | Frankly I'd prefer refactory 1.7 into 1.8 in a bunch of smaller steps |
| 17:22:09 | MrApathyCream | given the glacial pace of opensource dev |
| 17:23:16 | Chestal | I am also quite skeptical about startign from scratch |
| 17:23:25 | MrApathyCream | YES!!! a voice of reason |
| 17:23:35 | Chestal | but some changes are difficult to achieve by redesigning |
| 17:23:35 | MrApathyCream | You must not be 20 |
| 17:23:49 | Chestal | e.g. it woudl be very nice to decouple game logic from the UI |
| 17:24:14 | Chestal | this is necessary to create a robot binary without doign cut'n'paste reuse |
| 17:24:22 | MrApathyCream | yup |
| 17:24:44 | Chestal | well, at least it looks as if Chris will actively participate in creatign the new version |
| 17:24:47 | MrApathyCream | To me though bzfs is #1 focus... |
| 17:24:56 | MrApathyCream | crs: yes that's great |
| 17:25:49 | Chestal | I have no problem with braeking compatability |
| 17:26:00 | MrApathyCream | Do you expect any formalized planning (project plan) |
| 17:26:03 | Chestal | I guessit's ok when no pre-1.8 clients can join a 1.8 server |
| 17:26:07 | MrApathyCream | laughs at himself |
| 17:26:27 | MrApathyCream | break away... fine by me |
| 17:27:01 | Chestal | I don't know. It would be nice to at least define some objectives, share ideas, prolems etc. |
| 17:27:38 | MrApathyCream | My fear is some will go off for a few weeks and come back with 'something' |
| 17:27:44 | Chestal | I'm really like working on bz, but I fear that I won't have that much tiem in the near future |
| 17:27:50 | MrApathyCream | bummer |
| 17:27:58 | Chestal | yes, I'd like peopel to communicate more |
| 17:28:13 | Chestal | this # is a nice place, butwe also need to use the dev mailign list or some other place |
| 17:28:22 | MrApathyCream | Yes. |
| 17:28:22 | Chestal | put some iformal documents on a website or something |
| 17:28:45 | Chestal | btw,: we need to fix the radar issues for e6 :-) I hate most of the changes |
| 17:29:21 | MrApathyCream | Actually I like new radar, but, what's the state of turning it off.... I assumed you could have either, no? |
| 17:29:43 | MrApathyCream | saw Chestals ezboard thread |
| 17:29:50 | Chestal | there is an 'enhanced radar' option |
| 17:30:01 | Chestal | but I think that only relates to the drawing of buildings |
| 17:30:13 | MrApathyCream | ah, should hook all 'enhancements' into it |
| 17:30:53 | MrApathyCream | oh yeah, you don't do jump :) |
| 17:31:21 | Chestal | the radar seems to have changed since 1.7e4 |
| 17:31:44 | MrApathyCream | iirc, just radar size of flags to correspond with height |
| 17:31:45 | Chestal | the CVS one scales flags and tanks |
| 17:32:04 | MrApathyCream | I think tank scaling was in 1.7e4 |
| 17:32:23 | Chestal | I tried E4 win98 yesterday and it didn't do that, i.e. flags and tanks are drawn at a fixed size independent of radar zoom |
| 17:32:38 | MrApathyCream | ooh, isee, i meant scaled based on Z |
| 17:34:19 | MrApathyCream | as for 1.8, my gut thought would have been n udp ports-1 per client- with n threads |
| 17:34:43 | MrApathyCream | perhaps a thread for flag management, one for connections, one for admin/cheat |
| 17:34:55 | MrApathyCream | Doesn't seem like that's what anyone is thinking |
| 17:35:14 | Chestal | hmm, thtat's a major design deciciosn, threaded or multiplexing server |
| 17:35:29 | Chestal | I don;t know what's better |
| 17:35:31 | MrApathyCream | I fear starvation of lagging client messages in a multiplexing server |
| 17:35:35 | Chestal | I guess a multiplexing server can work quite well |
| 17:35:44 | Chestal | how so? |
| 17:35:55 | MrApathyCream | with n ports, lagging client only competes with n messages |
| 17:36:16 | MrApathyCream | with 1 port, lagging client competes with n x m messages |
| 17:36:33 | MrApathyCream | where m is number of messages each non-lagging client can send in lag period |
| 17:36:48 | Chestal | well, the server should be at least one order of magnitude faster than is necessary to process incoming messages |
| 17:37:06 | MrApathyCream | not likely, do you think? |
| 17:37:07 | Chestal | and procxessign of a single message must be real fast |
| 17:37:20 | Chestal | currently even a mediocre computer has no problem with htis |
| 17:37:30 | Chestal | ducati is on a p75 and can handle the load withotu problems |
| 17:37:49 | Chestal | network bandwidth and latency are the big issues here |
| 17:38:06 | MrApathyCream | have you measured ip backlog? |
| 17:38:35 | MrApathyCream | meaning how long messages sit in inbound port queue until picked up for processing? |
| 17:38:43 | Chestal | no, but at least I got the impression that the server is waiting on select() mot of the time |
| 17:38:47 | Chestal | no hard numbers though |
| 17:39:17 | MrApathyCream | Hmm if that's true i guess it's not an issue |
| 17:39:25 | Chestal | I have never seenbzfs eating up more than 8% of CPU |
| 17:39:44 | Chestal | but it also depends on how 1.8 should handle messages |
| 17:39:54 | MrApathyCream | Then perhaps packet utilization is poor |
| 17:40:00 | Chestal | with a more intelligent server the cpu load might go up |
| 17:40:23 | MrApathyCream | Perhaps clients could 'batch' messages in one packet |
| 17:40:28 | MrApathyCream | and server as well? |
| 17:40:41 | Chestal | I think this is a good idea for the server, but nto for the client |
| 17:41:09 | Chestal | the server upstream will use approximately n times the bandwidth of its downstream (n=number of players) |
| 17:41:23 | MrApathyCream | yeah you're probably right |
| 17:41:31 | Chestal | so it would be feasible to put several messages sent to the same player in one udp packet |
| 17:41:57 | Chestal | messages shoudln't be delayed more than maybe 20ms, though |
| 17:41:59 | MrApathyCream | Is there a univeral min packet size? |
| 17:42:10 | MrApathyCream | for udp? |
| 17:42:12 | MrApathyCream | 1024? |
| 17:42:15 | Chestal | maximum? |
| 17:42:24 | Chestal | minimum is just the header :-) |
| 17:42:39 | MrApathyCream | ok, what's the smallest maximum |
| 17:42:44 | Chestal | I guess that as a rule of thumb we can take ethernet frame - headers |
| 17:43:02 | Chestal | althoguh that is not guaranteed to work everywhere I think it will |
| 17:43:32 | MrApathyCream | Is there ever a need for tcp or was that a relic of past impls |
| 17:43:33 | Chestal | I can't imagine it workign any other way |
| 17:44:00 | Chestal | but about 1000 bytes (or maybe 1200) would be enough, I don't think the typical package will eat up all those bytes |
| 17:44:10 | MrApathyCream | eat: no |
| 17:44:26 | Chestal | well, mot peopel want to dump tcp for 1.8 |
| 17:44:43 | MrApathyCream | it really should be much simpler |
| 17:44:46 | Chestal | of course this means we will have to emulate most of TCP's features for some msg types |
| 17:45:01 | MrApathyCream | reliability, in order , you mean |
| 17:45:04 | Chestal | we can live with lost update msgs but most other msg types must be reliable |
| 17:45:07 | Chestal | yes |
| 17:45:25 | MrApathyCream | probably some libs available that do that |
| 17:45:35 | Chestal | but I also think it's a good idea to just use one protocol |
| 17:45:41 | Chestal | but it's not that easy to write it |
| 17:45:45 | MrApathyCream | yes |
| 17:46:05 | Chestal | we might still want to have the reliabilty overhead only for certain msg types |
| 17:46:53 | Chestal | I also hope that we can integrate soem kind of quality of service measurement into the new code |
| 17:47:01 | Chestal | current lagstats just doesn't cut it |
| 17:47:05 | MrApathyCream | :) |
| 17:47:29 | Chestal | for example it woudl be very easy to do stats on umber of packets lost etc. |
| 17:49:08 | Chestal | message rate throttlign doesn't seem to be so easy, I tried a simpel appraoch with the current server and it produced some ill effedts which I do not quite understand yet |
| 17:50:06 | Chestal | throttling in the client is probably easier, but I can't say if those ill effects are also there |
| 17:50:49 | Chestal | hmm, I have an idea. |
| 17:50:59 | MrApathyCream | throttleing in client seems like a good idea |
| 17:51:02 | MrApathyCream | ? |
| 17:51:09 | Chestal | it should be possible to implement some type of quality measurement in the client |
| 17:51:31 | Chestal | the ill effects I observed was that sometimes other tanks jsut jumped from one place to another |
| 17:51:41 | Chestal | or changed their orientation abruptly |
| 17:52:15 | Chestal | I coudl patch the client to compare the real position data of another tank with it's dead reckoning projection whenever it receives a MsgUpdate |
| 17:53:17 | Chestal | a constant delay of mesasges won't be detected this way, but changign delays or lost packets might be |
| 17:53:24 | Chestal | and these are the more irritating issues |
| 17:53:28 | MrApathyCream | yes |
| 17:53:55 | Chestal | this should detect the problems I observed with my sevrer throttling. I woudl at least have some kind of objective metric then |
| 17:54:10 | MrApathyCream | I'd still like to experiment with only moving one's tank in response to network packets |
| 17:54:23 | Chestal | of course lag:=time between receiving and sending of update message cannot be detected currently |
| 17:54:34 | vogon_jeltz | MrApathyCream: the BZFlag netcode isn't nearly good enough to provide for that |
| 17:54:37 | Chestal | hmm, I don't quite understand that idea |
| 17:54:45 | Chestal | hi vogon |
| 17:54:48 | vogon_jeltz | hi |
| 17:54:58 | MrApathyCream | Well if my tank updated to me the same way it updated to others, the lag should go to 0 |
| 17:55:09 | MrApathyCream | although, my display would get choppy if i had slow network connection |
| 17:55:15 | vogon_jeltz | MrApathyCream: hell, even the Quake3 engine barely achieves that |
| 17:55:34 | vogon_jeltz | (over a modem, at least) |
| 17:55:37 | Chestal | Mr: hmm, I think youre mistaken. Or I just do not understand it :-) |
| 17:55:44 | Chestal | you will always have a delay |
| 17:55:53 | vogon_jeltz | MrApathyCream: no, you're just moving the lag to another part of the connection |
| 17:56:19 | Chestal | you can get a consistens view of the world by all players (although still a delayed one), but that would mean we would have to synchronize, that would be sloooow |
| 17:56:24 | vogon_jeltz | yup |
| 17:57:05 | vogon_jeltz | for every changed object, you'd have to send a facing, position, and velocity |
| 17:57:21 | vogon_jeltz | much like we do now, but you'd also be increasing the load on the server |
| 17:57:22 | Chestal | I think we have differentiate when speakign about lag |
| 17:57:29 | MrApathyCream | i just sent velocity and angle |
| 17:57:38 | Chestal | first there is lag caused by network latency,m we cannot do anythign about that |
| 17:57:39 | MrApathyCream | everyone receives that and update tank positions, including self |
| 17:57:53 | Chestal | we can't get lag below ping times |
| 17:57:54 | MrApathyCream | dead reckoning handles stalls, including self |
| 17:57:57 | vogon_jeltz | MrApathyCream: but then you end up with it adding up to a whole pile of fuzziness after a few thousand packets |
| 17:58:19 | vogon_jeltz | MrApathyCream: for that to work correctly, you need an infinite packet rate |
| 17:58:25 | MrApathyCream | true, ok send positions periodically |
| 17:58:35 | vogon_jeltz | MrApathyCream: that's just what I was going to type ;) |
| 17:58:59 | MrApathyCream | even if you just sent 'future position' always |
| 17:59:11 | MrApathyCream | just don't move your tank, until you receive the position you sent out in the past |
| 17:59:22 | vogon_jeltz | hmm... good idea :) |
| 17:59:36 | vogon_jeltz | but it won't work all that well with jumping or strafing |
| 17:59:51 | MrApathyCream | would make more choppy for self |
| 17:59:54 | vogon_jeltz | you'll still have to send out facing for strafing |
| 18:00:04 | MrApathyCream | who added strafing? |
| 18:00:07 | MrApathyCream | cool |
| 18:00:12 | vogon_jeltz | someone proposed it |
| 18:00:16 | Chestal | Cream: even with good connections you'll probably have a 100ms delay between pushgn the mouse and update on screen then |
| 18:00:19 | MrApathyCream | yeah, i saw |
| 18:00:26 | vogon_jeltz | and we don't want to have to have a bunch of people hacking on the protocol |
| 18:00:30 | Chestal | Cream: that will not 'feel right' |
| 18:00:43 | MrApathyCream | 10fps!! woowoo |
| 18:00:48 | Chestal | uh, dont do strafing |
| 18:00:50 | MrApathyCream | but lo lag |
| 18:00:54 | MrApathyCream | :) |
| 18:01:17 | MrApathyCream | ok, bad idea |
| 18:01:20 | Chestal | it;s hard enough to hit a skilled player without strafing |
| 18:01:23 | vogon_jeltz | Chestal: the way I think the Quake3 and Torque (Tribes2) engines handle it is that they send a pile of position change packets every second, then the server sends back what it has periodically |
| 18:01:38 | vogon_jeltz | s/they/the clients/ |
| 18:01:54 | Chestal | vogon: I never played Quake or another FPS over the net, but they will also have the basic latency problems |
| 18:02:08 | Chestal | so that the player really has advanced roung_trip_time*speed already |
| 18:02:10 | vogon_jeltz | Chestal: but (take my word on this) Tribes2 has incredibly smooth play, even on my 56k |
| 18:02:19 | vogon_jeltz | best netcode ever! |
| 18:02:32 | MrApathyCream | So message coalescing in packets probably only improvement? |
| 18:02:44 | vogon_jeltz | possibly |
| 18:02:52 | Chestal | coalescing messages can reduce bandwidth used |
| 18:03:06 | Chestal | this should help when we have addiotnal lag because of bandwidth shortage |
| 18:03:08 | MrApathyCream | Why is Tribes net so good? different game dynamics? |
| 18:03:12 | Chestal | won't help with basic latency, though |
| 18:03:16 | vogon_jeltz | MrApathyCream: it's just an overall great game |
| 18:03:24 | Chestal | I am not sure that most FPS are comparable to bzflag |
| 18:03:28 | vogon_jeltz | MrApathyCream: and it's got lots of physics fluff, too :) |
| 18:03:32 | MrApathyCream | What's differnt about network code |
| 18:03:37 | MrApathyCream | what do they do? |
| 18:03:42 | vogon_jeltz | MrApathyCream: jetpacks, aircraft, ground vehicles... plus some incredibly overoptimized netcode |
| 18:03:51 | Chestal | e.g. whern you have a game where someone shoots at you with a shotgun you cannot tell if it is corect when he hits you or not |
| 18:03:56 | Chestal | with bz's slow shots, you can |
| 18:04:09 | vogon_jeltz | MrApathyCream: alternately, you can go get the Quake2 sourcecode from ID software and steal the netcode |
| 18:04:17 | vogon_jeltz | MrApathyCream: (they recently released it under GPL) |
| 18:04:25 | Chestal | I don't know where the collision detection is located with tribe |
| 18:04:38 | vogon_jeltz | Chestal: server |
| 18:04:46 | Chestal | uah |
| 18:04:49 | Chestal | that woudl suck with bz |
| 18:04:54 | MrApathyCream | would reduce network traffic |
| 18:04:59 | vogon_jeltz | I could prolly fire up Ethereal and log a quick game of T2 |
| 18:05:07 | Chestal | this would mean that you'll get kile dvery often, although from your point of view you evaded a shot |
| 18:05:17 | Chestal | I'd find that very annoying |
| 18:05:30 | MrApathyCream | Chestal: true |
| 18:05:30 | vogon_jeltz | Chestal: well, not all of us are on lans |
| 18:05:48 | Chestal | vogon: hmm? |
| 18:05:52 | vogon_jeltz | MrApathyCream: if you have some download and play time to kill, I'd recommend downloading the Tribes2 demo from http://www.tribes2.com |
| 18:05:57 | MrApathyCream | Although if bzfs is only 8% utilized.. should move more onto it |
| 18:05:59 | vogon_jeltz | Chestal: lag is a fact of life in FPSes |
| 18:06:04 | MrApathyCream | vogon_jeltz: will do |
| 18:06:12 | vogon_jeltz | MrApathyCream: it's a killer game :) |
| 18:06:20 | vogon_jeltz | MrApathyCream: in fact, it's what drew me away from BZFlag :P |
| 18:06:24 | Chestal | vogon: yes, but I think the bz way (client decides whetehr it dies) is better |
| 18:06:35 | Chestal | vogon: its better not to hit someone else becuase of lag than dying because of lag |
| 18:06:36 | vogon_jeltz | Chestal: except for the cheating problems |
| 18:06:46 | MrApathyCream | yeah |
| 18:06:52 | Chestal | vogon; yes, cheating is of course easier with a lightweight server |
| 18:07:15 | Chestal | to improve curernt lag situation we need betetr data |
| 18:07:19 | vogon_jeltz | Chestal: I think the first thing we need to do is implement some server doublechecking |
| 18:07:29 | Chestal | currently we do not know what's the main problem |
| 18:07:45 | vogon_jeltz | MrApathyCream: what video card do you have? |
| 18:08:00 | MrApathyCream | Probably would a good idea to know problems before desiging 1.8 :) :) |
| 18:08:03 | vogon_jeltz | hehe |
| 18:08:09 | Chestal | but I am quite sure that we shoudl reduce # of update messages |
| 18:08:12 | MrApathyCream | vogon_jeltz: GeForce3 (not titanium) |
| 18:08:17 | vogon_jeltz | MrApathyCream: ooh, nice |
| 18:08:27 | vogon_jeltz | MrApathyCream: you'll want it for Tribes2... beautiful terrains |
| 18:08:42 | MrApathyCream | tribes2 free? |
| 18:08:44 | vogon_jeltz | MrApathyCream: nope |
| 18:08:55 | vogon_jeltz | MrApathyCream: but it's been out for a while, so it's under 25 bucks |
| 18:09:11 | MrApathyCream | I like BZFlag! :) |
| 18:09:15 | vogon_jeltz | :P |
| 18:09:40 | vogon_jeltz | finds ApathyCream some screenshots |
| 18:10:34 | MrApathyCream | looking on web site |
| 18:11:26 | vogon_jeltz | http://gamespot.com/gamespot/filters/products/screens/0,11105,914210-202,00.html |
| 18:11:43 | MrApathyCream | Chestal: Reliable UDP gonna be costly? |
| 18:12:18 | MrApathyCream | vogon_jeltz: loading.. |
| 18:12:49 | Chestal | Apathy: depends on how reliable it is :-) |
| 18:12:54 | vogon_jeltz | that thing on the left and off in the distance is a vehicle station, BTW |
| 18:13:11 | MrApathyCream | vogon_jeltz: nice |
| 18:13:25 | vogon_jeltz | :) |
| 18:13:38 | Chestal | Apathy: when most reliable messages are request/reply style we can do implicit acknowledgements easily without sendign extra packets |
| 18:13:39 | MrApathyCream | vogon_jeltz: Glad to see there's a BFG |
| 18:13:44 | vogon_jeltz | http://gamespot.com/gamespot/filters/products/screens/0,11105,914210-164,00.html |
| 18:14:25 | MrApathyCream | draws a blank as to which messages are request/reply types |
| 18:14:35 | vogon_jeltz | MrApathyCream: yup, but it's all class-based, so only the slow, big-target players can have the fusion mortar |
| 18:15:04 | vogon_jeltz | and that second one is a shot from the gunnery seat of a tank |
| 18:15:11 | Chestal | at least it won't be easy to do the protocol udp-only, a lot of thought will have to go into this |
| 18:15:35 | vogon_jeltz | the problem with UDP is that it is by its very nature unreliable |
| 18:15:50 | MrApathyCream | is it... my understanding was udp was actually pretty good |
| 18:16:00 | MrApathyCream | prblem is, you can't be positive, so it doesn't matter |
| 18:16:01 | vogon_jeltz | UDP datagrams aren't guaranteed to go through in the proper order or, indeed, at all |
| 18:16:04 | Chestal | well, UDP is simple and that's it |
| 18:16:25 | Chestal | we woudl have to add send and receve queues and f course sequence numbers |
| 18:16:45 | vogon_jeltz | they already have that |
| 18:16:47 | vogon_jeltz | it's called TCP |
| 18:16:53 | Chestal | hopefully, flow control won't be necessary |
| 18:17:29 | Chestal | as we will assume that our data stream is below available bandwidth at all times |
| 18:17:31 | | I haven't seen 'the', vogon_jeltz |
| 18:17:31 | vogon_jeltz | MrApathyCream: seen the second screenie yet? :)) |
| 18:17:46 | | MrApathyCream: what? |
| 18:17:46 | MrApathyCream | ibot, lol |
| 18:17:51 | MrApathyCream | vogon_jeltz: yes |
| 18:18:00 | vogon_jeltz | cool, eh? :) |
| 18:18:16 | MrApathyCream | Chestal: Perhaps a packet numbering scheme for could disambiguate mandatory vs. non mandatory messages |
| 18:18:46 | MrApathyCream | Would be ashame to have a missing packet number and try to figure if it really was necessary |
| 18:18:46 | Chestal | Cream: we could just set a single status bit in each message or decide onmesage type, that's no problem |
| 18:19:09 | MrApathyCream | Perhaps we need two udp ports, one for mandatory and one for superfluous messages |
| 18:19:10 | Chestal | Cream: for not reaiable mesage types when we receive packets out of order, just dump the packet or ignore the missing one |
| 18:19:38 | MrApathyCream | packet 4 and then packet 6 have been received. Do i need packet 5? |
| 18:19:46 | Chestal | Cream: hmm, you're right, we need distinct sequence numbers for both types of messages |
| 18:19:50 | Chestal | Cream: but that's no problem |
| 18:20:30 | MrApathyCream | -nums = superflous +nums = mandatory.... or something |
| 18:20:54 | Chestal | yes, something like that |
| 18:21:40 | Chestal | we msut also for some mesages decide whether they're mandatory or not |
| 18:21:51 | Chestal | for exampel for msgshotbegin the answer isn't that easy |
| 18:21:54 | vogon_jeltz | what advantages does this hold over just using TCP and UDP in conjunction? |
| 18:22:09 | MrApathyCream | lighter handshaking i think |
| 18:22:20 | vogon_jeltz | not really |
| 18:22:50 | vogon_jeltz | if the UDP "I got it" or "I didn't get it" messages miss, then you're all screwed up |
| 18:22:59 | Chestal | vogon: I am not sure that we will have any real advantages (except for not having to have two distinct communication channels, which might yield problems for firewalls etc.) |
| 18:23:18 | vogon_jeltz | Chestal: just suck up one port in both TCP and UDP... problem solved |
| 18:23:19 | Chestal | vogon: we might still have advantages as we do not need to mimic all of TCP's features |
| 18:23:40 | vogon_jeltz | Chestal: if you just do increment-by-one, then you leave the connection open to hijacking |
| 18:23:44 | Chestal | vogon: that woudl still make it two kinds of connections, would be easier to just have one |
| 18:23:50 | MrApathyCream | what's superfluous anyway MsgMessage, and ... |
| 18:24:11 | Chestal | vogon: well, security on this level realyl is a non-issue here, the current scheme is all but secure |
| 18:24:19 | vogon_jeltz | Chestal: your whole +/- "superfluous or not" thing sounds like Type of Service... |
| 18:24:32 | vogon_jeltz | Chestal: it's secure on the protocol and hardware levels... |
| 18:24:46 | vogon_jeltz | Chestal: only the application layer is insecure |
| 18:24:56 | Chestal | vogon: there's no security issues onthe level of system security here anyway |
| 18:25:15 | Chestal | vogon: our protocol being insecure just means that someone could cheat with a lot of effort |
| 18:25:24 | MrApathyCream | what types of messages can we safely ignore, anyway? |
| 18:25:24 | Chestal | or do DOS attacks |
| 18:25:34 | Chestal | Cream: well, MsgUpdate of course |
| 18:25:41 | Chestal | Cream: MsgShotBegin is a mixed bag already |
| 18:26:11 | vogon_jeltz | Chestal: and it's less-optimized, incurs a lot of overhead, and it's proprietary... whoop-de-fricking-doo... |
| 18:26:35 | MrApathyCream | Chestal: MsgPlayerUpdate? |
| 18:26:43 | Chestal | vogon: skipping TCP wasn't my idea. I am also not too sure abou tit |
| 18:26:46 | vogon_jeltz | Chestal: the lower-level you can make these features, the faster and more transparent they are |
| 18:26:51 | Chestal | Mr: yes, PlayerUpdate |
| 18:27:02 | MrApathyCream | That's it, along with MsgMessage? |
| 18:27:16 | Chestal | MsgMessage should be reliable |
| 18:27:17 | MrApathyCream | seems like a lot of work for so little impact |
| 18:27:25 | Chestal | MsgShotBegin is in-bewteen :-) |
| 18:27:41 | MrApathyCream | We should just find a fix for PlayerUpdate |
| 18:27:46 | vogon_jeltz | Chestal: MsgShotBegin is the client's only way of knowing where a shot it |
| 18:27:47 | vogon_jeltz | is, even |
| 18:28:02 | vogon_jeltz | Chestal: MsgShotUpdate is only sent if the shot goes off-course for some reason |
| 18:28:18 | Chestal | yes, but if we need to retransmit a lost MsgSHotBegin the delay will probably be that high that we can skip it inthe first place |
| 18:28:42 | vogon_jeltz | shot lifetime is 3 seconds, IIRC... that's not a non-trivial amount of time |
| 18:28:45 | Chestal | there's no MsgShotUpdate, only a MsgGmUpdate that is sent when a palyer relocks |
| 18:29:02 | Chestal | vogon; yes, but imagine the retransmisison will come in 0.6s late |
| 18:29:11 | Chestal | the whoel shot will then lag 0.6s, that's near useluss |
| 18:29:15 | Chestal | useless even |
| 18:29:22 | vogon_jeltz | it's useful for hittests |
| 18:29:51 | MrApathyCream | wonders if there is any really good solutions... Seems as though problems abound everywhere |
| 18:29:59 | vogon_jeltz | how about lag compensation? |
| 18:30:22 | Chestal | I don't think that's goign to work, if you're talkign about projecting tanks' positions into the future |
| 18:30:35 | vogon_jeltz | each client keeps a table of where it was the past n milliseconds, then looks it up in a table when they start a hittest |
| 18:31:12 | Chestal | I amnot sure I understand what you;re trying to achieve |
| 18:31:30 | MrApathyCream | hmmm, client does self-hit detection on network received position |
| 18:31:35 | vogon_jeltz | if we can somehow measure lag, you can go back in time to when the shot was originally fired from the firer's perspective and see if the bullet hits the tank |
| 18:31:36 | Chestal | AFAIK what the client already does is to use all the area covered by the tank between two frames for the hittest |
| 18:32:12 | Chestal | vogon; no, that's a bad idea IMHO. I strongly vote for the curent I-only-get-hit-when-I-perceive-this-myself mode |
| 18:32:19 | vogon_jeltz | heh |
| 18:32:27 | vogon_jeltz | Chestal: OK, lemme re-explain my idea... |
| 18:32:31 | Chestal | I would hate it to blow up althoguh a shot on radar never came near me |
| 18:33:00 | MrApathyCream | If we could live with that, we could let the server determine kills |
| 18:33:09 | Chestal | I think we need a bzflag developers conference -) |
| 18:33:28 | Chestal | I wonder if the univeristy is going to pay for the flight and hotel :-) |
| 18:33:43 | vogon_jeltz | hmm |
| 18:33:57 | Chestal | Cream: I can't live with that, that's for sure |
| 18:34:05 | vogon_jeltz | I think heavy-server would be the way to go here |
| 18:34:06 | MrApathyCream | Honolulu? |
| 18:34:10 | Chestal | I guess the best way is to try to determien cause for lag and try to lwoer it |
| 18:34:17 | MrApathyCream | Chestal: agreed |
| 18:34:18 | Chestal | never been to Hawaii, good idea |
| 18:35:17 | MrApathyCream | on Riker? |
| 18:35:26 | Chestal | well, I really have to do some work now |
| 18:35:38 | Chestal | some real work, i.e. work that I get paid for |
| 18:35:42 | vogon_jeltz | vgb |
| 18:36:01 | MrApathyCream | cya |
| 18:36:46 | MrApathyCream | pulls the plug as well |
| 18:36:52 | vogon_jeltz | vgb |
| 20:35:47 | Chestal | welcome back |
| 20:36:11 | MrApathyCream | heh... work done/ |
| 20:36:32 | Chestal | Cream: no, I didn't really start :-( |
| 20:36:36 | MrApathyCream | heh |
| 20:37:28 | MrApathyCream | Just curious, how long does select wait after receiving first FDSet fulfillment |
| 20:38:27 | Chestal | it shouldn't wait at all after that |
| 20:38:38 | Chestal | in my understanding |
| 20:39:08 | MrApathyCream | I just can't shake the feeling that that is inefficient for us |
| 20:40:46 | Chestal | and I still don't see why :-) |
| 20:41:02 | Chestal | except that using poll() is the way to go nowadaysI guess |
| 20:41:24 | MrApathyCream | with low client connections, just reading and writing would seem to me to be the most optimal |
| 20:41:43 | MrApathyCream | I see select as a necessary evil, when hi client conections require multiplexing |
| 20:42:47 | Chestal | well, withotu select you'd have to do polling |
| 20:42:57 | MrApathyCream | no one thread per client |
| 20:43:18 | Chestal | and n ports? |
| 20:43:22 | MrApathyCream | yup |
| 20:43:51 | vogon_jeltz | you guys do realize that having about 10 threads up at once isn't a good idea, right? |
| 20:43:53 | Chestal | that would add thread synchronization of course, we'd have to do protect some data structures |
| 20:44:07 | MrApathyCream | ridiculous, any modern machine can hav > 100 |
| 20:44:10 | Chestal | vogon: I don't see a problem with having even 100 threads |
| 20:44:12 | vogon_jeltz | heh |
| 20:44:14 | MrApathyCream | specially if most are waiting on io |
| 20:44:21 | Chestal | a modern machien can handle 10000s of threads |
| 20:44:24 | vogon_jeltz | Chestal: besides all of the task-and-state-swapping? |
| 20:44:33 | MrApathyCream | most are sleeping on read |
| 20:44:59 | vogon_jeltz | MrApathyCream: if you're running 100 threads, that means each one will have to be awakened at least once per second to check if the select() has timed out |
| 20:45:01 | Chestal | you get soem advantages by using multiple threads on you also get soem overhead |
| 20:45:10 | MrApathyCream | No selects just reads |
| 20:45:21 | vogon_jeltz | Chestal: threading is only an advantage for code simplicity |
| 20:45:27 | vogon_jeltz | Chestal: and on SMP boxen |
| 20:45:36 | Chestal | vogon: most would be using infinite waitign time for select |
| 20:46:01 | MrApathyCream | don't need selects, just read with infinite timeout |
| 20:46:03 | Chestal | vogon; it could give you better real-time behaviour in some cases |
| 20:46:23 | vogon_jeltz | Chestal: infinite select timeout only delays until one of the sockets gets data |
| 20:46:25 | Chestal | but I still prefer the one-thread-solution here |
| 20:46:42 | Chestal | vogon: ah, ok, you're right it wil lreceive once a second |
| 20:46:48 | vogon_jeltz | :) |
| 20:46:53 | Chestal | vogon: but thread-sdwithcign shouldn't be very expensive |
| 20:47:12 | vogon_jeltz | it takes at least (IIRC) 20 or so clock cycles on x86 |
| 20:47:25 | vogon_jeltz | and then 20 back, assuming no data is involved |
| 20:47:48 | Chestal | vogon: processing a apcket will probably take > 50000 clock cycles |
| 20:47:54 | MrApathyCream | if 10 clients are at 100ms lag, and i'm at 500ms lag, and each is sending 10 messages per my 2, my 2 have to wait for 100 messages in queue |
| 20:47:58 | Chestal | but I see no problem with multiplexing |
| 20:48:14 | MrApathyCream | with threads, my 2 only wait for 20 competing messages |
| 20:48:40 | MrApathyCream | single queue, make lag worse, imo |
| 20:48:42 | Chestal | cream: they do not necessarily have to wait so long |
| 20:48:45 | vogon_jeltz | MrApathyCream: I had an idea awhile back to shuffle connections betwixt listening thread |
| 20:48:48 | vogon_jeltz | threads |
| 20:49:01 | Chestal | cream: we could process msgs round-robin-style |
| 20:49:10 | Chestal | but I do not think many messages will queue up anyway |
| 20:49:13 | vogon_jeltz | MrApathyCream: to load-balance (you group an infrequently-used connection with a frequently-used one) |
| 20:49:38 | MrApathyCream | too much logic, imo, one thread per client - simple |
| 20:50:08 | vogon_jeltz | one thread per client - wasted process table entries, time in the scheduler, and context-switching |
| 20:50:10 | Chestal | IMHO threads are advantgeous only if the server has to do some siginificant processing from time to time |
| 20:50:30 | Chestal | so we have low- and hi-priprity tasks within the server and withotu threads the high-priority tasks might get delayed |
| 20:50:31 | MrApathyCream | vogon_jeltz: compared to select setup, switching is small |
| 20:51:35 | MrApathyCream | It all goes back to, "Why the hell is performance so bad".... I don't think we really know. |
| 20:52:00 | Chestal | performance isn't bad |
| 20:52:13 | Chestal | when palyign on a LAN performance is good |
| 20:52:39 | Chestal | I think we really need to try to sampel some data for laggy connections |
| 20:52:58 | MrApathyCream | I can volunteer, I'm almost always laggy more than most |
| 20:53:04 | MrApathyCream | :( |
| 20:53:05 | Chestal | :-) |
| 20:53:23 | Chestal | we can do some tests when ducati is back up and we both have time |
| 20:53:51 | MrApathyCream | i'm always getting booted for lag there :) :( :0 :P |
| 20:54:12 | Chestal | then you'll have an avg round-trip time on TCP >400ms |
| 20:54:33 | MrApathyCream | yes, 550-600 usually |
| 20:54:40 | Chestal | hmm, try pinging or tracerouting 141.99.131.69 |
| 20:54:55 | Chestal | I'm not sure if the packet filters here will let the ICMP packets pass |
| 20:55:32 | Chestal | is your lag constant or does it seemto vary much? do other tanks sometimes jump around or do their movements look smooth? |
| 20:56:18 | MrApathyCream | ping doesn't go thru |
| 20:56:22 | MrApathyCream | nor tracert |
| 20:56:33 | MrApathyCream | constant with number of tanks |
| 20:56:35 | Chestal | silly filters |
| 20:56:46 | MrApathyCream | logarithmic |
| 20:56:57 | MrApathyCream | oops wrong curve |
| 20:57:07 | MrApathyCream | hyperbolic |
| 20:57:29 | MrApathyCream | chardonnay the tanks jump like mexican jumping beans |
| 20:58:05 | MrApathyCream | ducati isn't too bad, occasional 'packet storm-like' behavior |
| 20:58:49 | MrApathyCream | lag should be 2xping about, right? |
| 20:59:47 | Chestal | number from lagstats will pe ping time+0.5/fps optimally |
| 20:59:57 | Chestal | with your gfx card ignore the fps :-) |
| 21:01:09 | Chestal | try pinging boogie.bzflag.org or chardonnay then |
| 21:01:12 | Chestal | just to get an idea |
| 21:03:25 | MrApathyCream | boogie is 250 |
| 21:03:49 | Chestal | that's not very good, but acceptable |
| 21:06:18 | MrApathyCream | lag with 3 players is 300ms |
| 21:06:41 | Chestal | did your ping lose packets? |
| 21:06:57 | MrApathyCream | if players went up to 10 or so, i'd be at 1800ms or so, as I recall |
| 21:07:01 | MrApathyCream | boogie is a no go for me |
| 21:07:30 | Chestal | hmm, I woudl specualte that the bandwidth of the connection between boogie and your computer is then too low to handle all the packets |
| 21:07:46 | MrApathyCream | howto: lost packets |
| 21:08:06 | Chestal | your ping statistics should show % packet loss |
| 21:08:28 | Chestal | can you join boogie and at the same time do a ping? |
| 21:10:57 | MrApathyCream | yeh |
| 21:11:11 | MrApathyCream | 0 lost packets |
| 21:11:25 | Chestal | did your ping time increase with bflag running? |
| 21:11:53 | MrApathyCream | no |
| 21:12:01 | Chestal | hmm, that's strange |
| 21:13:27 | Chestal | so you have measured ping time while your client was connected to boogie? |
| 21:14:25 | MrApathyCream | hasn't changed ... went down a little 230 |
| 21:14:44 | Chestal | hmm, Iguess we really have to try to sort this out on ducati next week |
| 21:15:04 | Chestal | we could try increasing the number of packets sent to you sythetically for example, instead of addign more players |
| 21:15:25 | MrApathyCream | good idea |
| 21:15:39 | Chestal | Cream: but when you have high lag according to netstats, it also feels laggy, doesn't it? |
| 21:16:03 | MrApathyCream | absolutley |
| 21:16:25 | iLLf8d | morning |
| 21:16:35 | Chestal | that would mean that UDP packets are also delayed and not only the TCP ones used for lagstats |
| 21:16:37 | Chestal | hi ill |
| 21:17:10 | Chestal | Cream: is it only delayed or do you think that packets are lost, too (choppy movements, tanks jumping from one place to another)? |
| 21:17:42 | MrApathyCream | i think just delayed... hard to say for sure |
| 21:17:57 | MrApathyCream | tank stalls, then zooms up but no hopping |
| 21:19:48 | MrApathyCream | pushed wrong close box |
| 21:19:52 | Chestal | what OS are you using? |
| 21:20:40 | MrApathyCream | *blush* |
| 21:20:45 | MrApathyCream | *er* |
| 21:20:50 | MrApathyCream | *em* |
| 21:20:51 | MrApathyCream | win xp |
| 21:21:14 | | i heard cable was at ... before http://ipaq.secret.org.uk/Cable1.jpg and after... http://ipaq.secret.org.uk/Cable2.jpg |
| 21:21:14 | Chestal | cable? |
| 21:21:21 | iLLf8d | my gf runs xp |
| 21:21:34 | Chestal | silly ibot |
| 21:21:49 | MrApathyCream | 56k |
| 21:21:55 | Chestal | ah :-) |
| 21:22:10 | Chestal | heh, no wonder you lag |
| 21:22:11 | iLLf8d | MrApathyCream: is still on a p133 too |
| 21:22:19 | iLLf8d | walking up hill in the snow to work |
| 21:22:30 | iLLf8d | both ways |
| 21:22:46 | Chestal | ApathyCream: you will just be receiving far more MsgPlayerUpdate than your modem can handle |
| 21:23:14 | Chestal | let's say 10 active players and 10 msgs/s |
| 21:23:18 | MrApathyCream | really like [not responding] |
| 21:23:29 | Chestal | that's 90 messages for you/s |
| 21:23:35 | iLLf8d | =) |
| 21:23:53 | Chestal | that eats up a minimum of about 70*90=6300 bytes |
| 21:24:27 | Chestal | I'm still perplexec that your ping did not lose packets, hmm |
| 21:25:23 | Chestal | it will be hard to optimize the net code so much, that 56k users can play on server with 5 or more people |
| 21:25:46 | MrApathyCream | we should fix PlayerUpdate in e6 then, or elleviate it, at least, as a test |
| 21:26:06 | Chestal | yes, I'd like to do some experiments with throttling PlayerUpdate |
| 21:27:04 | Chestal | you could also add a small patch to you rlcient to count # of PlayerUpdate msgs sent and recvd |
| 21:27:10 | MrApathyCream | yup |
| 21:27:19 | Chestal | I could compare that with the server stats to see if you get significant packet loss |
| 21:27:23 | MrApathyCream | i think its a good idea, on its own and for 1.8 |
| 21:28:32 | Chestal | 1.8 should have integrated connection quality metrics |
| 21:29:33 | Chestal | for 56k your boogie pign time is ok |
| 21:29:44 | Chestal | what is the smallest ping time you get? |
| 21:29:49 | Chestal | I mean on soem server near you? |
| 21:31:29 | MrApathyCream | really depends on user load. |
| 21:31:39 | MrApathyCream | I can be 200 when lo users |
| 21:37:32 | MrApathyCream | lagstats =920 ping = 230 3 users |
| 21:37:35 | MrApathyCream | boogie |
| 21:39:16 | muDsKippY | hey can someone check out the new map now? im ill's gf |
| 21:39:16 | Chestal | hi mud |
| 21:39:30 | muDsKippY | hiya Chestal |
| 21:39:35 | Chestal | Cream: hmm |
| 21:39:59 | Chestal | is not the personof choise for checkign out maps, his PC is too slow for most custom worlds |
| 21:43:35 | BZFlag | who had the server with stats compiled in? can we get that as a patch for cvs ? |
| 21:43:53 | Chestal | I had, but my fiel server crashed :-( |
| 21:44:02 | BZFlag | ugh. sorry to hear it. |
| 21:44:10 | Chestal | and it's modified against some E3 version |
| 21:44:15 | BZFlag | another reason for putting patchs up on SF. ;-) |
| 21:44:19 | Chestal | I started with E5 but the curent versin has some problems |
| 21:44:39 | Chestal | and as always it's just a quick hack and was in a state of heavy flux :-) |
| 21:44:52 | BZFlag | next thought: client needs to cache worlds in the same format that the server -world option expects. |
| 21:45:10 | BZFlag | so you can hit a server and then start your own with the same world. ;-) |
| 21:45:13 | MrApathyCream | current md5 caches them as binary object stream |
| 21:45:19 | MrApathyCream | not bzw format |
| 21:45:29 | BZFlag | they should both be xml |
| 21:45:58 | MrApathyCream | dunno, <is capn around, shsss> I think xml just reduces bandwidth |
| 21:46:11 | Chestal | bzflag: did you read about the large number of msgplayerupdate messages that get sent? |
| 21:46:12 | MrApathyCream | Even if it is not downloaded often, still takes up room |
| 21:46:33 | BZFlag | Chestal: yes, that's why I want the patch to start fixing it on the server side. |
| 21:46:37 | MrApathyCream | bzw file, sure, network, i vote no |
| 21:47:12 | Chestal | bzflag: I tried some server-side throttling, but it didn't work so well. I amnot sure why. I also throttled my cleint but others will have to say if they see ill effects |
| 21:47:19 | BZFlag | the saved format might as well be xml like the ui config files etc. |
| 21:47:32 | Chestal | xml file might be easier to parse but I think it's harder to read for humans |
| 21:47:40 | Chestal | is not that big an XML fan |
| 21:47:43 | BZFlag | the net format can do what it want's but needs to change from the current so that it is extensible. |
| 21:47:58 | MrApathyCream | I agree with that. |
| 21:48:09 | Chestal | XML is somewhere between a human and a machien format |
| 21:48:17 | Chestal | it's expensive to parse and hard to read |
| 21:48:25 | MrApathyCream | made for programs to read, not humans |
| 21:48:33 | MrApathyCream | but allows nice transformations. |
| 21:48:38 | Chestal | it has its merits |
| 21:48:42 | BZFlag | xml it tougher to read/write than the current bzw format, but it is a standard so people are more likely to know it to begin with. |
| 21:48:45 | MrApathyCream | not sure what BZ would use transforms for though |
| 21:49:13 | Chestal | I have no strogn feeligns about the format of the world files |
| 21:49:14 | MrApathyCream | I don't care, except i'd rather not pump xml through the network anywhere |
| 21:49:26 | Chestal | yes cachign worlds can alleviate that, but not for random worlds |
| 21:49:31 | MrApathyCream | yup |
| 21:50:09 | Chestal | ok, the typical random world is probably much smaller than a customized one |
| 21:50:42 | Chestal | and we could use [bg]zipped xml for transfering |
| 21:51:26 | BZFlag | I just want the cached worlds to be somewhat editable. |
| 21:51:34 | BZFlag | and reuseable |
| 21:51:46 | MrApathyCream | cached editable? |
| 21:52:05 | MrApathyCream | just for stealing worlds, etc? |
| 21:52:25 | BZFlag | this is open source. I could add a bzw save function now. |
| 21:52:34 | BZFlag | there is nothing private about worlds |
| 21:52:57 | MrApathyCream | yeah, i know, why would one edit a cached world? |
| 21:52:58 | BZFlag | now there _may_ be something private about a world generator. ;-) |
| 21:53:15 | Chestal | having world files (both original and cached) in xml dosn notnecessarily mean we have to transfer them as XML |
| 21:53:31 | BZFlag | let's sat I like decks but I hate the look of the supports. join, edit the supports, start a server. |
| 21:53:41 | BZFlag | the original author can join my server to get the mods. |
| 21:53:59 | MrApathyCream | so... like i said, world stealing <not that there's anything wrong with that> |
| 21:54:04 | Chestal | does the current caching scheme also expire worlds? |
| 21:54:11 | MrApathyCream | no, |
| 21:54:15 | BZFlag | Chestal: you will notice I did _not_ ask for xml transfer. I did not preclude it either. |
| 21:54:17 | Chestal | it must have that |
| 21:54:34 | MrApathyCream | thought was, either by date or by size of total cache |
| 21:54:52 | BZFlag | it should probably just expire worlds based on least recently used. |
| 21:54:58 | MrApathyCream | yeah |
| 21:55:14 | BZFlag | size, then kill old files to meet the size. |
| 21:55:41 | MrApathyCream | still need to add map directory support for unix, to what's in cvs patches |
| 21:55:44 | BZFlag | notes that a huge world would effectively flush your entire cache. |
| 21:56:05 | MrApathyCream | not that 1.8 won't need a rewrite probably |
| 21:56:29 | BZFlag | 1.8 will see major portions rewritten. much will stay the same though. |
| 21:56:55 | iLLf8d | it'd be nice to have automatic random teleporter linking as an option |
| 21:57:05 | iLLf8d | would make it easy to combine 2 worlds fast |
| 21:57:25 | MrApathyCream | Does already! :) --> as long as you like teleporting from one side of tp to other :) |
| 21:57:27 | Chestal | we should probably have someplace to collect ideas |
| 21:57:33 | iLLf8d | heh |
| 21:57:34 | MrApathyCream | Yes, stole my thoughts |
| 21:57:34 | iLLf8d | =P |
| 21:57:43 | Chestal | the wiki could be used for this of course |
| 21:58:02 | MrApathyCream | A project plan |
| 21:58:33 | Chestal | I suppose everyone is subscribed to the dev ml? |
| 21:58:59 | MrApathyCream | iLLf8d: random teleporter links would be easy... maybe i'll patch up something for random worlds |
| 21:59:19 | iLLf8d | I was just thinking for a cut and past combining of maps |
| 21:59:24 | iLLf8d | s/past/paste |
| 21:59:27 | MrApathyCream | surprised it doesn't do that already |
| 21:59:35 | MrApathyCream | Yes, i'm on ml |
| 21:59:53 | MrApathyCream | oh, for file maps,... i see |
| 22:00:13 | BZFlag | Chestal: that's what the wiki it for. start a page |
| 22:00:31 | iLLf8d | can't get into that wiki thing heh |
| 22:00:41 | iLLf8d | can pyshically .... |
| 22:00:57 | iLLf8d | woa transposition |
| 22:00:58 | MrApathyCream | http://www.bzflag.org/wiki/ ? |
| 22:02:07 | BZFlag | yep. or http://BZFlag.org/wiki/ |
| 22:02:29 | MrApathyCream | As chestal suggests, I'd think expirementing with 1.7e6 (or whatever) for PlayerUpdate squashing would be a good preliminary |
| 22:03:01 | iLLf8d | ah one more suggestion... perhaps a bzflag email or memoserv like they have in tribes |
| 22:03:11 | MrApathyCream | 'splain? |
| 22:03:19 | iLLf8d | you can send email to the players int he game |
| 22:03:32 | MrApathyCream | through a tribes email server? |
| 22:03:37 | MrApathyCream | or just users accounts |
| 22:03:40 | iLLf8d | I duno how it does it |
| 22:03:48 | iLLf8d | I just heard about it and everyone raves about it |
| 22:03:50 | Chestal | ill: to players currently online or to all registered players? |
| 22:03:57 | iLLf8d | not sure |
| 22:04:11 | iLLf8d | cool for a contact aspect... |
| 22:04:19 | iLLf8d | taunts flames commeraderie |
| 22:04:27 | Chestal | we want to have a player database for 1.8, we could do things liek that then |
| 22:04:46 | iLLf8d | great for ctf teams i'd think |
| 22:04:54 | iLLf8d | clan stuff |
| 22:04:55 | iLLf8d | etc.. |
| 22:05:03 | MrApathyCream | anyone ever use bz-radio? |
| 22:05:10 | MrApathyCream | what does it do? |
| 22:05:18 | iLLf8d | maybe its the voice part |
| 22:05:27 | iLLf8d | someone says it has partial b0rked voice support |
| 22:07:59 | BZFlag | it's just incomplete. |
| 22:08:22 | BZFlag | the radio passing code is there, but the client does not do anything once it has it. |
| 22:08:32 | BZFlag | needs an audio codec |
| 22:09:03 | BZFlag | it's not likely to be added due to the increased net traffic is requires and that most users these days are internet players. |
| 22:09:22 | BZFlag | it would be very cool on a local lan, and probably usable on a fast connection. |
| 22:09:57 | BZFlag | if/when we have support for tracking each users net throughput, then addign a radio that is only usable by fast players would be good. |
| 22:10:09 | BZFlag | ie: don't slow down the modem user any more than you have to. |
| 22:11:14 | Chestal | I am pondering: Is limitign the rate of control over your tank feasible? i.e. do not check mouse input more often than 20 times a second? |
| 22:11:36 | Chestal | this would of course auroamtically reduce number of playerupdate messages sent without causing any further problems |
| 22:11:57 | Chestal | but I wonder whether peopel with high framerates would notice it |
| 22:12:25 | iLLf8d | human response time is like what 2 tenths of a second I'd think thats as fast as you'd have to check |
| 22:12:39 | BZFlag | chestal possible, yes. desired? no. for lan play you want as fast as you can get. well, at least once per frame. |
| 22:13:48 | Chestal | well, only a thought, because I couldn't figured out the problems I had with my message throttling |
| 22:13:52 | Chestal | but results are very preliminary |
| 22:14:13 | MrApathyCream | server should dictate throttling numbers to clients |
| 22:14:36 | MrApathyCream | so if you are 100ms, and most are 300ms, server tells you -> slow down! |
| 22:15:32 | BZFlag | exactly |
| 22:16:18 | vogon_jeltz | is away: killing time while I push 736 megabits through a 56 kilobit-per-second pipe... does it get any better than this? |
| 22:16:22 | Chestal | I just activated message throttling in my client to a max. of 20msgs/s (approx.) |
| 22:17:02 | Chestal | I just don't know how to test if an observer can see the differnece |
| 22:17:26 | iLLf8d | would be nice to have a way to save randomly generated maps too |
| 22:17:41 | Chestal | hmm, mayeb I should implement the calculation of difference between dead reckoning and new position received int he client |
| 22:17:58 | Chestal | ill: well, these could be cached, too |
| 22:18:15 | Chestal | ill: might even be reused when you reconnect to the same server before all players left |
| 22:18:36 | MrApathyCream | sure, should work that way now |
| 22:18:51 | Chestal | is there any way to undo an cvs update operation? |
| 22:19:00 | MrApathyCream | hehe |
| 22:19:29 | BZFlag | iLLf8d: they will be in the client cache. |
| 22:19:38 | iLLf8d | =) |
| 22:19:38 | Chestal | I can't compiel my bots right know, wanted to use them for doing the dead reckoning stuff |
| 22:20:23 | BZFlag | Chestal: cvs up -PdA -D "date spec" |
| 22:20:58 | iLLf8d | I know this is way off base but perhaps a training field setup.... (maybe just a field where you can place tanks, ie in the map configs static tanks) for target practice. ie you get score and it reincarnates in the same place |
| 22:21:11 | iLLf8d | would make it like a training mission in the commercial games |
| 22:21:34 | iLLf8d | like a ctf base option... |
| 22:21:40 | iLLf8d | but for target tanks |
| 22:22:28 | iLLf8d | i'd love to make up a few practice courses for myself |
| 22:23:09 | MrApathyCream | when bots are more refined, you could probably just use that as training |
| 22:23:15 | MrApathyCream | set bots intelligence to real low |
| 22:23:28 | iLLf8d | I was hoping for placement tho... |
| 22:23:38 | iLLf8d | ie varying building heights drive by shooting |
| 22:23:39 | iLLf8d | etc... |
| 22:24:01 | BZFlag | iLLf8d: my goal is smart bots that adjust abilities based on score |
| 22:24:14 | MrApathyCream | good idea |
| 22:24:14 | iLLf8d | hmm |
| 22:24:30 | iLLf8d | sounds like alot of code |
| 22:24:36 | BZFlag | so bots will never thrash you, but you have to be _very_ good to thrash them. |
| 22:24:58 | iLLf8d | would be nice to have a terminator bot too |
| 22:25:04 | BZFlag | no point in playing an invincible bot. ;-) |
| 22:25:08 | iLLf8d | where its the world against the bot heh |
| 22:25:24 | MrApathyCream | would be nice if you get set bot level at you+5 or you-5, etc. |
| 22:25:25 | Chestal | tries to compile his bots |
| 22:25:57 | BZFlag | iLLf8d: bots will learn team play. so if you all join one team and the bot is on another, he will be very tough to kill. |
| 22:26:04 | Chestal | I need my server back :-( |
| 22:26:12 | iLLf8d | heh |
| 22:26:19 | MrApathyCream | as i recall in ducati, bot was actually pretty good <no jumping, no flags> makes it easier |
| 22:26:33 | iLLf8d | you guys think this is gonna take what a year or more to get together? |
| 22:26:54 | MrApathyCream | kick me in the groin, why don't you |
| 22:27:12 | MrApathyCream | i hope not, you're probably right. |
| 22:27:15 | iLLf8d | that wasn't sarcasm... I was just curious |
| 22:27:18 | Chestal | yes, my bots are dumb but already very tough |
| 22:27:22 | Chestal | because of their accuracy |
| 22:27:35 | iLLf8d | I dunno timeframes for projects such as these |
| 22:27:40 | captain_proton | is back |
| 22:27:48 | captain_proton | any important discussions |
| 22:28:05 | MrApathyCream | coming up with new name for you.. nothing so far |
| 22:28:11 | captain_proton | for me? |
| 22:28:18 | MrApathyCream | just funnin' |
| 22:28:24 | captain_proton | captain_parser not good enough? |
| 22:28:35 | MrApathyCream | Doesn't have the ring of Crazy 1.8 guy |
| 22:28:48 | captain_proton | ahh |
| 22:28:53 | BZFlag | I'd like 1.8 released by late summer. |
| 22:29:04 | MrApathyCream | bless you |
| 22:29:10 | BZFlag | whatever features are in, are in. |
| 22:29:19 | BZFlag | but some update is available. |
| 22:29:34 | Chestal | hmm, ideally, when a clien treceives MsgPlayerUpdate, the position and rotation of the tank as in the message shouldn't differ from the current one the client has at all, right? |
| 22:29:41 | MrApathyCream | any plans for 1.75+? |
| 22:29:47 | BZFlag | my hope is that the net changes are complete, and all the exiting functionality is still there. |
| 22:30:05 | BZFlag | any new functions will not alter the net protocol. |
| 22:30:31 | BZFlag | MrApathyCream: I need to fork a 1.7 stable in cvs. |
| 22:30:46 | BZFlag | there may be bug fixes added there that want to be released before 1.8 is ready. |
| 22:31:02 | BZFlag | the main cvs trunk will shortly be 1.8pre stuff. |
| 22:31:07 | Chestal | about bug fixes: we need to fix the bugs in bzfs |
| 22:31:11 | Chestal | I found 2-3 |
| 22:31:32 | BZFlag | patches on sf? |
| 22:31:48 | Chestal | one bug report on sf :-) |
| 22:31:49 | BZFlag | if they are just bug fixes, you are free to commit them yourself. |
| 22:32:08 | BZFlag | MrApathyCream has been doing a bunch of those. (and we thank him ;-) |
| 22:32:13 | Chestal | I never ever did a cvs co anywhere, hmm |
| 22:32:20 | Chestal | I am scared ;-) |
| 22:32:26 | BZFlag | live a little |
| 22:32:32 | BZFlag | OS? |
| 22:32:36 | Chestal | linux |
| 22:32:42 | BZFlag | then it's easy. ;-) |
| 22:33:12 | BZFlag | http://sourceforge.net/cvs/?group_id=3248 <- use the SF username version to get write access |
| 22:33:43 | Chestal | cvs with username is workign fine here |
| 22:33:59 | Chestal | for some days without having to type password each time, I finally read the docs :-) |
| 22:34:29 | BZFlag | =) |
| 22:34:50 | Chestal | how does it work? does it take my local source file and uploads it to the cvs repository? |
| 22:35:14 | Chestal | so when I made several changes to it and only want to upload one change I have to create a local file that only has the one change first? |
| 22:35:25 | Chestal | my bzfs is always full of patches |
| 22:35:38 | Chestal | most are only temporary, though |
| 22:39:34 | Chestal | ok, bot is working again |
| 22:39:41 | Chestal | hmm, I coudl start a local server |
| 22:59:41 | MrApathyCream | BZFlag: what about these simpleton patches that aren't exactly bug fixes, can we squeeze some of these in? |
| 23:01:57 | Chestal | Cream: always, when they're mine :-) |
| 23:02:58 | MrApathyCream | I'd love to checkin about 6 or 7... quality of life changes |
| 23:03:25 | Chestal | are they all on sf? |
| 23:03:29 | MrApathyCream | yes |
| 23:03:47 | MrApathyCream | my understanding is only to checkin bug fixes |
| 23:05:06 | MrApathyCream | I could pretend your respond to nemesis is a bug fix!! :) |
| 23:05:14 | Chestal | it sure is :-) |
| 23:05:36 | Chestal | problem with patches is of course that peopel could disagree upon whether they're good or not |
| 23:05:56 | MrApathyCream | my feeling is if it's not obnoxious, it's ok |
| 23:06:05 | MrApathyCream | radar, while I like it, is obnoxious |
| 23:06:10 | captain_proton | BZFlag: new wiki? |
| 23:06:23 | captain_proton | BZFlag: where? |
| 23:06:31 | MrApathyCream | I added it... as a motivational tool |
| 23:06:37 | MrApathyCream | www.bzflag.org/wiki |
| 23:07:17 | captain_proton | hahaha just a link? |
| 23:08:56 | MrApathyCream | yes |
| 23:09:44 | captain_proton | rofl |
| 23:31:19 | BZFlag | Chestal: cvs commit -m "my message" src/bzfs/bzfs.cxx will commit all changes in bzfs.cxx |
| 23:32:39 | Chestal | ok, thanks |
| 23:32:50 | MrApathyCream | easy, even an idiot like me figured it out |
| 23:33:01 | MrApathyCream | ok, so i needed much help to get ssh working |
| 23:33:21 | Chestal | I guess it's more difficult on windows |
| 23:35:37 | captain_proton | MrApathyCream: what names had you come up for me? |
| 23:37:19 | MrApathyCream | Chestal: windoz need to strip 0x13.s other than that, same |
| 23:37:30 | MrApathyCream | captain_proton: sorry capn, nothing yet |
| 23:37:36 | captain_proton | :( |
| 23:39:19 | captain_parser | i'll be like this for now |
| 23:45:42 | iLLf8d | restart brb |
| 23:55:50 | captain_parser | http://www.microsoft.com&item%3Dq209354@hardware.no/nyheter/feb01/Q209354%20-%20HOWTO.htm |
