| 00:14.06 | *** join/#bzflag pacman87 (n=Timothy@resnet2-46-90.dorm.utexas.edu) |
| 00:25.07 | Winny | debate in 30 min! |
| 00:30.46 | Thumper_ | JeffM: includes/languages/english/meta_tags.php maybe - defines for TITLE and TAG_LINE |
| 00:30.59 | Thumper_ | er SITE_TAGLINE |
| 00:31.02 | me1 | JeffM, do you have to register on the store site to order something, or is there an easier way? |
| 00:31.26 | temp_dist | registering is pretty easy |
| 00:31.33 | blast007 | me1: easier way is to just give me the money directly, in small bills |
| 00:33.50 | me1 | JeffM, nvm |
| 00:40.00 | JeffM | me1, yes you have to register, so that we know you know.. where to ship it to and who to send the tracking email to |
| 00:42.15 | JeffM | Thumper_, don't you have an account on .bz? |
| 00:44.00 | Thumper_ | um yeah but I have no idea where your store code is :) |
| 00:44.00 | me1 | JeffM, okay |
| 00:44.24 | JeffM | in a store dir in mybo IIRC |
| 00:45.06 | JeffM | cus I don't remember where it is ether :) |
| 00:45.59 | Thumper_ | like so? |
| 00:46.12 | Thumper_ | had no idea what you wanted in there but the title changed :) |
| 00:46.25 | JeffM | it's as good as anything I could have come up with :) |
| 00:46.28 | JeffM | thanks |
| 00:46.40 | Thumper_ | np |
| 00:47.20 | blast007 | man, that my.bzflag.org directory sure has a lot of crap in there ;) |
| 01:30.12 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 01:46.22 | *** join/#bzflag KingofCamelot (i=KingofCa@ip68-6-42-246.sb.sd.cox.net) |
| 02:08.20 | *** join/#bzflag TD-Linux (n=fedora@96-42-91-234.dhcp.roch.mn.charter.com) |
| 02:08.30 | TD-Linux | I just destroyed my partition table :( |
| 02:09.41 | blast007 | you shouldn't do that |
| 02:11.34 | TD-Linux | yeah I figured that out now |
| 02:14.05 | blast007 | ;) |
| 02:16.56 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.156) |
| 02:20.34 | TD-Linux | I think I saved one partition |
| 02:20.39 | TD-Linux | the other one is dead |
| 02:22.55 | F687s | hopes the dead partition was his swap, and not his /home. |
| 02:23.35 | blast007 | how did you kill it? (so that I know what not to do) ;) |
| 02:29.37 | BulletCatcher | JeffM: ~WorldEventManager now segfaults because it deletes the same StatsLink object twice, due to multiple calls to bz_registerEvent() in the StatsLink constructor. I don't see a simple solution to this. |
| 02:30.14 | TheRedBaron | BulletCatcher: duct-tape |
| 02:30.32 | BulletCatcher | Which color? |
| 02:31.08 | spldart | silver... you can't go wrong with silver |
| 02:32.47 | BulletCatcher | I suspect we would have the same problem in MatchManager if it were used. |
| 02:38.07 | TD-Linux | it was a /, and also the system restore partition |
| 02:38.12 | TD-Linux | aka everything |
| 02:38.20 | TD-Linux | forunately I think I'll be able to get it back |
| 02:38.32 | TD-Linux | I tried to make a hackintosh :( |
| 02:38.54 | TD-Linux | apple disk utility died when I tried to format my logical volume HFS+ |
| 02:39.20 | TD-Linux | moral of the story: don't mess with semilegal stuff |
| 02:39.31 | BulletCatcher | backups! |
| 02:39.38 | TD-Linux | those too |
| 02:39.40 | TD-Linux | I have backups |
| 02:39.43 | TD-Linux | but I only did my / partition |
| 02:39.45 | TD-Linux | not the whole disk |
| 02:39.48 | TD-Linux | so no mbr :( |
| 03:33.39 | *** join/#bzflag lol_udied (n=lol_udie@cpe-76-93-133-132.san.res.rr.com) |
| 03:34.04 | *** part/#bzflag lol_udied (n=lol_udie@cpe-76-93-133-132.san.res.rr.com) |
| 03:52.46 | JeffM | BulletCatcher, ok, then I make it remove on destruct |
| 03:52.51 | JeffM | I'll fix that when I get home |
| 04:14.37 | *** join/#bzflag L4m3r (i=L4m3r@bzflag/developer/L4m3r) |
| 04:14.37 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 04:15.55 | *** join/#bzflag short_circuit (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 04:19.40 | *** join/#bzflag spldart2 (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 04:29.12 | *** join/#bzflag delusional (n=delusion@pool-96-236-228-253.pitbpa.fios.verizon.net) |
| 04:30.37 | *** join/#bzflag JeffM2501 (n=Jeff@bzflag/projectadmin/JeffM) |
| 04:30.37 | *** mode/#bzflag [+o JeffM2501] by ChanServ |
| 04:35.22 | *** mode/#bzflag [+v spldart] by ChanServ |
| 05:00.03 | *** join/#bzflag Flash (n=jwmelto@bzflag/developer/Flash) |
| 05:04.52 | *** join/#bzflag ahs3- (n=alvin@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 05:09.18 | *** join/#bzflag bier (n=bier@p54A57AEA.dip.t-dialin.net) |
| 06:14.37 | Flash | BulletCatcher: ping |
| 06:54.51 | *** join/#bzflag DTRemenak|RDP (i=DTRemena@about/essy/CrazyCoder/DTRemenak) |
| 06:54.51 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 06:58.29 | CIA-42 | BZFlag: 03jwmelto * r18772 10/trunk/bzflag/ (include/bzfsAPI.h src/bzfs/WorldEventManager.cxx): |
| 06:58.29 | CIA-42 | BZFlag: prevent multiple delete of memory for a bzfs-side event handler that services |
| 06:58.29 | CIA-42 | BZFlag: multiple events. |
| 06:58.29 | CIA-42 | BZFlag: This is just a work-around though; cleaning up the memory here is a poor excuse |
| 06:58.30 | CIA-42 | BZFlag: for proper scoping and memory management. |
| 06:58.32 | CIA-42 | BZFlag: Added an RAII class to bzfsAPI to handle register/deregister automagically |
| 07:41.15 | *** join/#bzflag Upsetter (n=ups@i577B44CD.versanet.de) |
| 07:48.23 | *** join/#bzflag quantumdot (n=jmlopez@bzflag/player/QuantumDot) |
| 07:56.49 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 07:56.49 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 08:59.19 | *** join/#bzflag Upsetter (n=Upsolett@i577B44CD.versanet.de) |
| 10:12.57 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 10:16.16 | *** join/#bzflag LongDon (n=LongDon@vpn199-028.hrz.uni-oldenburg.de) |
| 10:46.30 | delusional | joe the plumber had to be a plant. |
| 10:55.01 | delusional | http://www.bartcop.com/mccains-golem.jpg |
| 11:20.17 | delusional | look at the pre and post- depression electoral maps here http://rejectmccain.com/ |
| 11:39.00 | *** join/#bzflag Abominable (n=Abominab@user-0ce2hpi.cable.mindspring.com) |
| 11:53.33 | *** join/#bzflag KTL (n=KTL@213.219.141.17.adsl.dyn.edpnet.net) |
| 11:54.08 | KTL | i upgraded my kernel to 2.6.26-1-openvz-amd64 (debian unstable ) |
| 11:54.20 | KTL | had to get my nvidia binaries working too |
| 11:54.28 | KTL | and ... pfff ... cant play bzflag with it |
| 11:54.30 | KTL | it hangs |
| 11:54.43 | KTL | the game goes fine but the controls seem to ... hang |
| 11:55.24 | KTL | if i say "do this" it waits for a second sometimes before actually letting the command through to the game |
| 11:55.25 | Manu | KTL: 2.6.26 sucks ;) |
| 11:55.35 | KTL | aha widely known issue ? :) |
| 11:55.39 | Manu | it's really broken |
| 11:55.46 | ruskie | nahh just nvidia not wanting to release proper drivers |
| 11:55.55 | Manu | I had to move back to 2.6.25 now 2.6.27 is fine again |
| 11:56.08 | KTL | and you got nvidia too manu? |
| 11:56.13 | Manu | 2.6.26 and nvidia works fine |
| 11:56.19 | Manu | the problem was with laptops |
| 11:56.24 | Manu | KTL: yes |
| 11:56.35 | Manu | in my desktop computer I had 2.6.26 and nvidia |
| 11:56.49 | KTL | has a dual core and a gforce 7900gt, that's not a laptop configuration |
| 11:57.03 | KTL | looks for another kernel-image |
| 11:57.04 | Manu | I have AMD64 2 cores |
| 11:57.32 | KTL | it's going to be tricky to have both virtualbox and another kernel |
| 11:58.29 | Manu | KTL: may be your nvidia model is not well supported |
| 12:12.56 | KTL | if i think about it: the game itself moved on smoothly, it were the controls, maybe i should blame the openvz patch |
| 12:51.25 | *** join/#bzflag LongDon (n=LongDon@vpn199-029.hrz.uni-oldenburg.de) |
| 12:53.13 | *** join/#bzflag KTL (n=KTL@213.219.141.17.adsl.dyn.edpnet.net) |
| 12:53.50 | KTL | running 2.6.26-1-vserver-amd64 now, i dont see the same problem anymore |
| 12:56.57 | *** part/#bzflag LongDon (n=LongDon@vpn199-029.hrz.uni-oldenburg.de) |
| 13:27.21 | blast007 | KTL: are you running a VPS on your system? |
| 13:27.29 | blast007 | or a VM? |
| 13:27.48 | *** join/#bzflag swigg (n=Paul@bzflag/player/Swigg) |
| 13:29.19 | KTL | blast007, just a vm to toy with windows progs |
| 13:29.30 | blast007 | k |
| 13:35.52 | *** join/#bzflag eTangenT (i=etangent@inge069019.halls.colostate.edu) |
| 13:53.18 | *** join/#bzflag spldart (n=short_ci@bzflag/contributor/spldart) |
| 13:53.18 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:55.09 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.155) |
| 14:35.01 | BulletCatcher | ~Flash++ |
| 14:35.03 | BulletCatcher | r18772 solves the problem, and is a fine solution short of a major change to the way WorldEventManager works. Thanks. |
| 14:36.39 | *** join/#bzflag LongDon1 (n=LongDon@vpn199-061.hrz.uni-oldenburg.de) |
| 14:36.53 | *** part/#bzflag LongDon1 (n=LongDon@vpn199-061.hrz.uni-oldenburg.de) |
| 14:37.39 | Flash | BulletCatcher: I was going to use the RAII class in StatsLink, but it doesn't get destroyed until WorldEventManager does |
| 14:38.16 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 14:38.17 | Flash | that's what bothered me... in bzfs.cxx, there is a naked "new StatsList();" relying on WorldEvent Manager to clean it up. That's wrong |
| 14:38.36 | Flash | all the plugins need to register/deregister (and should migrate to the RAII class) |
| 14:38.52 | Flash | works....... |
| 14:39.15 | BulletCatcher | No argument from me, but you need to take that up with JeffM. |
| 14:40.02 | *** join/#bzflag wert613 (n=jon@unaffiliated/wert613) |
| 14:40.22 | *** part/#bzflag wert613 (n=jon@unaffiliated/wert613) |
| 14:44.08 | CIA-42 | BZFlag: 03bullet_catcher * r18773 10/trunk/bzflag/src/bzfs/Stats.cxx: |
| 14:44.08 | CIA-42 | BZFlag: Protect process() from a null parameter. |
| 14:44.08 | CIA-42 | BZFlag: Correctly recognize a bz_eListServerUpdateEvent event when it occurs. |
| 14:56.34 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 15:27.32 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 16:03.18 | CIA-42 | BZFlag: 03JeffM2501 * r18774 10/trunk/db/bzfstats/ (bzfstats/server.cs bzfstats.suo): read in the XML correctly |
| 16:05.02 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 16:25.58 | *** join/#bzflag pacman87 (n=Timothy@resnet-45-219.dorm.utexas.edu) |
| 16:31.21 | CIA-42 | BZFlag: 03bullet_catcher * r18775 10/trunk/bzflag/src/ (3 files in 3 dirs): Do not bother to use sprintf() when its formatting features are not needed. |
| 16:40.32 | *** join/#bzflag JeffM (n=JeffM@bzflag/projectadmin/JeffM) |
| 16:40.32 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 16:44.06 | *** join/#bzflag beanpole (n=beanit@ip70-171-170-31.om.om.cox.net) |
| 16:47.05 | JeffM | thank you to whoever fixed the event auto delete in the way I didn't have time to do :) |
| 16:49.16 | *** join/#bzflag L4m3r (i=l4m3r@bzflag/developer/L4m3r) |
| 16:49.16 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 16:51.56 | ts | JeffM: I saw you changed this: http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/BUGS?r1=18770&r2=18769&pathrev=18770 but..did you check they're gone? |
| 16:52.24 | JeffM | yes, I was able to duplicate it before my fix, and not able to after my fix |
| 16:52.29 | JeffM | it was tested |
| 16:52.43 | ts | Hmm |
| 16:53.13 | JeffM | didn't you also see my commits before that? |
| 16:53.43 | ts | Yes, but that looked like having to do with double jumps only |
| 16:53.48 | JeffM | the variable pressedJump was not being set to false after it was sent to wantJump |
| 16:53.55 | JeffM | the jump physics have changed |
| 16:53.56 | JeffM | slightly |
| 16:54.01 | JeffM | that is intendend and not a bug |
| 16:54.11 | JeffM | so it will be a little different |
| 16:55.13 | JeffM | so unless someone can provide a better description of what is "wrong" then that one, it'll stay off the list |
| 16:55.21 | ts | JeffM: The different jumping for each tank is intended? |
| 16:55.35 | JeffM | yes, since it's based on a speed add, not a speed set |
| 16:55.59 | ts | Let me clarify: The different _direction_ |
| 16:55.59 | JeffM | there is some DR problems too with jumping, but that is not a bug with the jumping code |
| 16:56.11 | JeffM | the new DR dosn't take gravity into account, so it can look like people jump differently |
| 16:56.12 | JeffM | then you |
| 16:56.19 | JeffM | but they are using the same rules |
| 16:56.45 | JeffM | again, since it's a velocity add, the direction can change based on your movment |
| 16:57.08 | JeffM | but if you wish to provide me an example I can review it |
| 16:57.11 | ts | The directinal changes were caused by the inertia, based on FPS, IIRC. |
| 16:57.47 | JeffM | I belive that was caused by the fact that you could jump before you landed |
| 16:57.54 | JeffM | so your speed was not set |
| 16:58.29 | JeffM | now with the mininum jump time, you have at least one frame on the ground so you always jump after you land and have your speed set by the ground hit |
| 16:58.36 | ts | Well, I'll do a new checkup and will try to confirm |
| 16:58.45 | ts | checkout* |
| 16:58.46 | *** join/#bzflag think_tank (n=think_ta@unaffiliated/thinktank/x-168245) |
| 16:59.04 | JeffM | well don't try to "confim" just describe what is happening as besy you can, and why you feel it is "wrong" |
| 16:59.25 | JeffM | some things will be different from 2.0.x |
| 16:59.31 | JeffM | such as -a is always on now |
| 17:00.03 | JeffM | so before you could probalby jump, move controlls backwards, land, and jump backwards, where now, you probalby can't do that |
| 17:00.28 | JeffM | not with out setting -a 0 and _rejumpTime 0 |
| 17:00.35 | JeffM | then you could probalby do that again |
| 17:02.41 | L4m3r | so the max upward velocity for Wings is _wingsJumpVelocity? |
| 17:28.58 | *** join/#bzflag kirun (n=kirun@93.30.125.91.gr6.adsl.brightview.com) |
| 17:31.11 | blast007 | L4m3r: I belive so |
| 17:31.37 | L4m3r | methinks it might be good to have the limit as its own variable |
| 17:54.28 | SportChick | JeffM: you're evil |
| 17:55.36 | L4m3r | lol |
| 17:55.51 | L4m3r | yeah, I hate the inertia limit |
| 17:56.19 | *** join/#bzflag TheRedBaron1 (n=kemhof@75.144.224.155) |
| 17:56.20 | L4m3r | it seems so silly to argue about "mouse enhancements" when the keyboard players can switch direction completely and immediately |
| 17:56.57 | BulletCatcher | I thought inertia applied to keyboard input, too. |
| 17:57.27 | BulletCatcher | (the inertia setting, I mean) |
| 17:57.29 | L4m3r | it does |
| 17:57.52 | L4m3r | but for some reason it was mice that caused the arguments that lead to the inertia settings |
| 17:57.56 | blast007 | L4m3r: keyboard users have some slight delay already, I thought |
| 18:04.00 | TheRedBaron1 | L4m3r: keyboard players do not have that immediate switch |
| 18:04.34 | L4m3r | heh |
| 18:04.39 | TheRedBaron1 | there was a request a while back ago - to add a small level of acceleration to the keyboard so player could control jumps |
| 18:04.42 | L4m3r | well it's fast enough for me |
| 18:05.02 | TheRedBaron1 | instead of always being stuck with full speed jumps + and full turn jumps |
| 18:05.16 | L4m3r | I find that the "slow keyboard motion" key gives me enough control for precise jumps about 95% of the time |
| 18:05.20 | TheRedBaron1 | that also led to the adaptation of the 'a' key to toggle half speed |
| 18:06.07 | TheRedBaron1 | Now I do not know if its -a that may be causing this - but you can still see this effect on some servers. especially when turning + jumping |
| 18:06.23 | TheRedBaron1 | without using 'toggle half speed' |
| 18:06.27 | L4m3r | yeah |
| 18:06.41 | L4m3r | especially if you try to jump right after landing |
| 18:06.53 | TheRedBaron1 | L4m3r: the "problem" from the mouse - is the ability to rapidly change directions at a much higher rate then they keyboard can |
| 18:06.59 | TheRedBaron1 | rapidly + repeatedly |
| 18:07.13 | L4m3r | what's funny, though, is that (in 2.0.x at least) inertia is relative to the tank, not the game world |
| 18:07.52 | L4m3r | so if you make a spinning jump and land in reverse, and try to jump backward to continue in the same direction, you'll probably jump forward :) |
| 18:08.29 | L4m3r | TheRedBaron1: right, but the faster you change direction, the less you actually move, right? :) |
| 18:08.45 | L4m3r | I mean, you can fudge your position with lag, but you still need to get out of the way |
| 18:08.47 | TheRedBaron1 | L4m3r: with -a 'yes' |
| 18:10.50 | BulletCatcher | Any objection to changing trunk's _inertiaLinear default value from 50 to 45 to match the Ducati league standard (http://my.bzflag.org/bb/viewtopic.php?t=9368)? _inertiaAngular already defaults to their standard of 38. |
| 18:11.43 | TheRedBaron1 | BulletCatcher: none from me |
| 18:13.27 | *** join/#bzflag me1 (n=khazhy@bzflag/player/Me1) |
| 18:19.14 | *** join/#bzflag mmarshall (n=mmarshal@adsl-99-190-39-104.dsl.rcsntx.sbcglobal.net) |
| 18:31.09 | CIA-42 | BZFlag: 03bullet_catcher * r18776 10/trunk/bzflag/src/common/global.cxx: Default to Ducati league standard inertia settings. |
| 18:59.00 | *** join/#bzflag kirun_ (n=kirun@91.125.88.207) |
| 19:27.12 | *** join/#bzflag a_meteorite (n=a_meteor@adsl-75-15-112-123.dsl.snlo01.sbcglobal.net) |
| 19:29.11 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 19:29.11 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 20:08.22 | *** join/#bzflag me1 (n=khazhy@bzflag/player/Me1) |
| 20:11.17 | *** join/#bzflag noyb (n=noyb@nat/sun/x-725bc20bec7cea3b) |
| 20:14.00 | *** join/#bzflag Think_Differentl (n=fatass__@bzflag/player/ThinkDifferent) |
| 20:31.20 | SportChick | brlcad: curse you! |
| 20:32.57 | *** join/#bzflag Think_Differentl (n=fatass__@pool-71-178-117-139.washdc.east.verizon.net) |
| 20:56.27 | Manu | hugs SportChick |
| 20:57.16 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 20:57.16 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 20:58.08 | SportChick | hugs Manu |
| 20:58.14 | Manu | ;) |
| 20:59.46 | *** join/#bzflag LongDon (n=LongDon@host-091-097-101-224.ewe-ip-backbone.de) |
| 21:06.53 | Manu | dmesg |
| 21:21.25 | me1 | Is 3.0 going to have flags on server side only, so you could add extra hard-coded flags later without having to break protocol? |
| 21:23.51 | *** join/#bzflag spldart (n=short_ci@bzflag/contributor/spldart) |
| 21:23.51 | *** mode/#bzflag [+v spldart] by ChanServ |
| 21:24.03 | Think_Differentl | oh, what about downloadable client modifications? as in, you connect to a server which requires a client modification, it gets the zip or tar file from the server, then puts it in some sort of path to run? |
| 21:24.05 | Think_Differentl | hm |
| 21:24.09 | Think_Differentl | maybe that would be too hard. |
| 21:26.14 | *** join/#bzflag tj13820 (n=TJ13820@unaffiliated/tj13820) |
| 21:29.40 | a_meteorite | Think_Differentl: you mean have a client API? for what purpose? |
| 21:31.53 | a_meteorite | well, to think of that, that could actually be pretty cool |
| 21:36.18 | L4m3r | easier to just make the client dumber and give the server more control |
| 21:38.24 | a_meteorite | yeah |
| 21:38.40 | a_meteorite | but think of being able to change proto on the fly? |
| 21:39.04 | a_meteorite | for what reason, I need to figure that out :) |
| 21:39.23 | me1 | Yeah, but if you make the client dumb enough, you won't need proto modifications. |
| 21:39.49 | me1 | (theoreticly, of course) |
| 21:40.33 | a_meteorite | me1: yes, just compress jpegs back to the client. problem solved! |
| 21:40.34 | Think_Differentl | a_meteorite, i was thinking more along the lines of q3 |
| 21:40.36 | a_meteorite | :) |
| 21:41.18 | Think_Differentl | you can download files, it will put them in a mod directory, and then there is a mod menu you can just click, which uses a similar procol iirc, but different interface/commands/gameplay |
| 21:54.36 | *** join/#bzflag JeffM (n=JeffM@bzflag/projectadmin/JeffM) |
| 21:54.36 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 22:03.21 | *** join/#bzflag me1 (n=khazhy@bzflag/player/Me1) |
| 22:06.32 | TD-Linux | Think_Differentl: a couple problems |
| 22:06.44 | TD-Linux | executables aren't platform independent and a major security risk |
| 22:06.50 | TD-Linux | a scripting language would work |
| 22:07.12 | TD-Linux | but require massive parts of bzflag to be rewritten |
| 22:07.18 | TD-Linux | in a scripting language |
| 22:08.11 | JeffM | badidea sense... tingling |
| 22:08.29 | me1 | what about my idea? |
| 22:08.35 | JeffM | was it bad? |
| 22:08.45 | me1 | <me1> Is 3.0 going to have flags on server side only, so you could add extra hard-coded flags later without having to break protocol? |
| 22:08.54 | me1 | etc. |
| 22:08.54 | JeffM | what does that mean? |
| 22:08.59 | JeffM | "flags on the server side"? |
| 22:09.05 | TD-Linux | that would require a description language of what each flag does |
| 22:09.18 | TD-Linux | the client needs to know what's going on too |
| 22:09.18 | JeffM | yeah the flag effects are tied to the flags and processed by the client |
| 22:09.21 | TD-Linux | for dead reckoning etc |
| 22:09.27 | JeffM | OO, BU, etc... |
| 22:09.38 | me1 | so the client would get flag info from the server, that way new flags could be introduced without a client change, and maybe for bzw etc. as well |
| 22:09.47 | JeffM | no 3.0 will not have that |
| 22:09.58 | JeffM | once we seperate the effect from the flag, then yes we can do that |
| 22:10.09 | JeffM | we started it with shot type |
| 22:10.18 | JeffM | so the shot type descriptor is now independent of the flag |
| 22:10.44 | me1 | is 3.0 in feature-lock? |
| 22:10.50 | JeffM | techicnaly |
| 22:11.00 | JeffM | like a year ago |
| 22:12.29 | JeffM | also totaly cusotm flags may not be the best idea from a gameplay standpoint, like super combo flags, they could confuse players who don't know that one server is running different form others. so there could be additional implications that we would like to address ( list server flags, etc..) |
| 22:13.20 | JeffM | eventualy I'd like the flag to just be a graphical object that can be attached to another graphical object ( the tank ) and then the server just defines the effects and shots a tank has |
| 22:13.31 | JeffM | that's optimal from a protocoll standpoint |
| 22:13.45 | JeffM | and a cheat prevention outlook |
| 22:14.14 | JeffM | a scripting system could be dangerous, as you would not want to blindly trust code that comes from any old server you connect too. |
| 22:14.28 | JeffM | so you'd have to do a lot of work to ensure that the scirpting system can only do specific things |
| 22:14.39 | jorgenpt | JeffM: Often not that hard. :) |
| 22:14.50 | JeffM | true, but it's just another concern |
| 22:15.09 | JeffM | and in the end, that type of flag work isn't THAT big on our list |
| 22:15.17 | JeffM | there are other things that should be done first |
| 22:15.28 | JeffM | such as shot collisions, etc... |
| 22:15.40 | JeffM | a new graphics engine ;) |
| 22:16.58 | JeffM | the cusotm flags that we have in 3.0 are mostly just custom names, the client dosn't do anything special when you get them. You can set the shot type, and do anything in a plugin that you want for people that have that flag |
| 22:17.40 | JeffM | so like if I get gates working, you could say, open a gate for someone with a "key" custom flag |
| 22:18.31 | TD-Linux | gates would be awesome |
| 22:18.45 | JeffM | part of them is done |
| 22:18.47 | TD-Linux | by gates, do you mean just enabling / disabling parts of a map? |
| 22:18.52 | JeffM | no |
| 22:18.59 | JeffM | dynamicly setting drivethru |
| 22:19.05 | TD-Linux | okay, what I meant :) |
| 22:19.08 | TD-Linux | but not moving objects |
| 22:19.11 | JeffM | no |
| 22:19.14 | TD-Linux | because that would mess up the octree |
| 22:19.16 | JeffM | tha'ts a lot harder |
| 22:19.24 | JeffM | no it woudln't we'd just have to readd it |
| 22:19.29 | JeffM | or keep them in ther eown |
| 22:19.33 | JeffM | the vis portion is not hard |
| 22:19.36 | JeffM | the sync is |
| 22:19.40 | JeffM | since objects rico shots |
| 22:19.59 | JeffM | once shot paths and updates are server side we can do a lot more |
| 22:20.23 | TD-Linux | moving platforms would be hard with physics too |
| 22:20.30 | TD-Linux | because you would want the tank to move with it |
| 22:20.35 | Winny | coughs up a hairball |
| 22:20.47 | TD-Linux | and it to push the tank away if it moves into a location where the tank is |
| 22:20.57 | TD-Linux | so drivethrough is fine :D |
| 22:24.39 | *** join/#bzflag beanpole (n=beanit@ip70-171-170-31.om.om.cox.net) |
| 22:26.47 | JeffM | yeah but those arn't unsolvable problems |
| 22:27.03 | JeffM | we would just need to spec out how each case should be handled in our wierd physics system :) |
| 22:27.35 | Winny | is it actually a modular physics system? |
| 22:27.46 | Winny | like everything has a force, weight, etc? |
| 22:28.05 | JeffM | no |
| 22:28.38 | JeffM | I just mean that we have a set of rules that we apply, so we'd have to work those cases into our rules |
| 22:29.28 | Winny | ah |
| 22:29.40 | JeffM | cus there could be cases where the tank could be pushed into places where it could not be (trash compactor) |
| 22:29.51 | JeffM | they are cases we don't have to handle now |
| 22:30.05 | TD-Linux | BOOOOM! |
| 22:30.08 | me1 | "You gots squashd" |
| 22:30.09 | TD-Linux | would work nicely |
| 22:30.12 | JeffM | that could be one possiblity |
| 22:30.17 | JeffM | but we'd have to code for that |
| 22:30.25 | TD-Linux | also |
| 22:30.29 | JeffM | and decide "how close" does it get before it explodes |
| 22:30.34 | TD-Linux | hmm |
| 22:30.46 | JeffM | or what if there is area to the side does it push you along? |
| 22:30.49 | JeffM | do we do pinching? |
| 22:30.53 | TD-Linux | we could handle it like sealed is right now |
| 22:31.01 | *** join/#bzflag MindstormsKid (n=chatzill@wikipedia/MindstormsKid) |
| 22:31.10 | *** join/#bzflag temp_dist (n=temp_dis@bzflag/serverop/TemporalDistraction) |
| 22:31.12 | JeffM | think of a pencil in scissors |
| 22:31.15 | JeffM | we could |
| 22:31.21 | JeffM | these would just be choices we'd have to make |
| 22:31.29 | TD-Linux | that would be very difficult |
| 22:31.48 | JeffM | and that aspect is a lot more work then just "adding moving objects" to the graphics system |
| 22:32.10 | JeffM | yeah the choices and specing out of what we want it to do is the hard part |
| 22:32.18 | JeffM | cus part of that also means you have to know exactly what we do now |
| 22:32.34 | Winny | it seems like if you add moving objects the only way to do it well would be to implement actual physics |
| 22:32.43 | Winny | at least from my limited experience |
| 22:32.53 | JeffM | real world physics would change the rest of the game |
| 22:33.04 | JeffM | when you drive off a ledge you'd tilt down |
| 22:33.09 | JeffM | and land turret in the mud |
| 22:33.22 | Winny | hm, true |
| 22:33.22 | JeffM | you'd not be able to shoot peple that were jumping, etc... |
| 22:33.28 | JeffM | so it's a HUGE impact |
| 22:33.28 | TD-Linux | a "real world" physics system isn't totally different than what bzflag has |
| 22:33.33 | TD-Linux | it's just more rules |
| 22:33.37 | JeffM | TD-Linux, sure it is |
| 22:33.45 | JeffM | since we have the no roation constraint |
| 22:33.52 | JeffM | it becomes very different |
| 22:34.01 | JeffM | sure our base rules were "inspired" by real physics |
| 22:34.11 | JeffM | but to think that one is a subset of the other is folly |
| 22:34.24 | JeffM | we don't even do tank/tank collisions |
| 22:39.29 | TD-Linux | wonders how to record sound effects |
| 22:39.55 | Winny | get a plunger |
| 22:39.59 | Winny | and some jello |
| 22:40.28 | TD-Linux | thinks is $5 radioshack mike won't cut it |
| 22:40.37 | Winny | I'd say no |
| 22:44.39 | JeffM | be mindfull of the bitrate and format |
| 22:44.45 | JeffM | the current sound reader is very picky |
| 22:46.48 | *** join/#bzflag MindstormsKid (n=chatzill@wikipedia/MindstormsKid) |
| 22:47.01 | *** join/#bzflag darklust (n=darklust@ool-4577089a.dyn.optonline.net) |
| 22:57.50 | *** join/#bzflag L4m3r (i=l4m3r@bzflag/developer/L4m3r) |
| 22:57.50 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 22:59.30 | TD-Linux | oh hmm |
| 22:59.41 | TD-Linux | I was going to go for either 44.1 or 48 khz, 16 bit |
| 23:00.36 | me1 | I though the bzflag sounds were 32-bit? |
| 23:01.11 | me1 | nvm, my mistake |
| 23:01.21 | *** join/#bzflag TheRedBaron (n=kemhof@75.144.224.155) |
| 23:05.48 | TD-Linux | 32 bit is probably overkill |
| 23:19.18 | *** join/#bzflag QBeep (n=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 23:28.30 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 23:33.19 | *** join/#bzflag macsforme (n=const@bzflag/developer/Constitution) |
| 23:36.23 | *** join/#bzflag Ratfink (n=clay@nc-67-76-227-5.sta.embarqhsd.net) |
| 23:36.36 | *** part/#bzflag Ratfink (n=clay@nc-67-76-227-5.sta.embarqhsd.net) |
