00:25.28 | *** join/#bzflag whodaman- (n=whodaman@pdpc/supporter/student/whodaman-) |
00:33.14 | SportChick | anyone else having slow-net issues today? |
00:33.23 | Winny | nope |
00:34.47 | Macrosoft | everyone decided to open bittorrent and seed /dev/zero :p |
00:35.05 | Winny | everyone is viewing the macworld keynote ;) |
00:38.06 | *** join/#bzflag F687s (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
00:38.46 | *** join/#bzflag CBG (n=CBG@cpc2-stme1-0-0-cust307.cdif.cable.ntl.com) |
00:39.35 | *** join/#bzflag F687s (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
00:49.20 | *** join/#bzflag L4m3r (n=l4m3r@about/essy/warning/L4m3r) |
00:49.20 | *** mode/#bzflag [+v L4m3r] by ChanServ |
00:54.15 | JeffM | is __int64 a valid way to define 64 bit ints on all platforms? |
00:58.12 | [dmp] | if you have stdint.h, you could use int64_t (http://en.wikipedia.org/wiki/Stdint.h) (But im not sure how widespread it is in reality) |
01:02.07 | JeffM | wonder what the "C++" way is :) |
01:03.51 | L4m3r | couldn't you just use a long? |
01:04.01 | L4m3r | or is that not consistent on different platforms? |
01:04.11 | Macrosoft | L4m3r: isnt that just 32 bits? |
01:04.31 | [dmp] | bitset<64> ;) |
01:04.37 | L4m3r | I think a "normal" int is 32 bits, but I could be wrong |
01:05.13 | Macrosoft | odd, the refernce i have shows both normal and long as being 32 bits |
01:05.21 | Macrosoft | maybe a typo |
01:05.52 | Macrosoft | time to try sizeof(long int a); |
01:05.59 | Macrosoft | ;) |
01:06.02 | [dmp] | long long are at least 64bits long |
01:06.29 | L4m3r | is long int the same as just long? |
01:06.50 | Macrosoft | i think so |
01:07.05 | JeffM | long long is one MS way |
01:07.15 | JeffM | it's for data packing so I want specific sizes |
01:07.38 | [dmp] | http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html .. long long int :) |
01:07.54 | Macrosoft | oh, heres something: "* The values of the columns Size and Range depend on the system the program is compiled for. The values shown above are those found on most 32-bit systems. But for other systems, the general specification is that int has the natural size suggested by the system architecture (one "word") and the four integer types char, short, int and long must each one be at least as large as the one preceding it, with char b |
01:07.54 | Macrosoft | eing always 1 byte in size. The same applies to the floating point types float, double and long double, where each one must provide at least as much precision as the preceding one." |
01:08.24 | L4m3r | ah, so it's inconsistent and can't be used |
01:08.29 | [dmp] | there was a paper from open-std suggesting that c++ should adobt "long long" for 64bit, but the author wasnt happy with it (should 128bit then be long long long, he asks) |
01:08.47 | [dmp] | L4m3r: c types only got a minimum requirement :( |
01:09.17 | Macrosoft | this sucketh |
01:09.30 | [dmp] | basically, char could be 64bit too, i belive :) |
01:09.34 | L4m3r | well damn, 32 bit systems were the main platform for so long, I can't say I'm surprised :P |
01:12.38 | Macrosoft | im on a 64bit system, ill try out some stuff and see what sizes i get |
01:19.49 | *** join/#bzflag blast007_nokia (n=blast007@pdpc/supporter/active/blast007) |
01:19.49 | *** mode/#bzflag [+v blast007_nokia] by ChanServ |
01:20.25 | Macrosoft | im getting the same sizes as a 32bit system should |
01:22.29 | Macrosoft | the code i made to check. someone hit me if i screwed up: http://pastebin.ca/856766 |
01:30.34 | L4m3r | you're running a 64bit OS as well, I take it? |
01:30.52 | Macrosoft | yeah |
01:31.03 | L4m3r | interesting |
01:31.24 | Macrosoft | didnt get any compiler warnings either |
01:34.25 | blast007 | what compiler? |
01:35.53 | Macrosoft | g++ |
01:42.57 | *** join/#bzflag AHA (n=aha@unaffiliated/aha) |
01:55.29 | *** join/#bzflag Suspect (n=Suspect@68-114-69-187.dhcp.plt.ny.charter.com) |
02:07.40 | *** join/#bzflag whodaman-_ (n=whodaman@pdpc/supporter/student/whodaman-) |
02:25.26 | *** join/#bzflag sigonasr2 (n=sigonasr@ip72-200-88-154.tc.ph.cox.net) |
02:30.34 | *** join/#bzflag Macrosoft (n=Macrosof@c-75-65-81-245.hsd1.la.comcast.net) |
02:45.32 | *** join/#bzflag me1 (n=khazhy@pool-71-248-175-134.bstnma.fios.verizon.net) |
02:45.38 | *** part/#bzflag me1 (n=khazhy@pool-71-248-175-134.bstnma.fios.verizon.net) |
03:26.04 | *** join/#bzflag short_circuit (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
03:35.00 | *** join/#bzflag JeffM (n=Jeff@pool-71-109-231-178.lsanca.dsl-w.verizon.net) |
03:46.17 | AAA_awright | ~bzsvn |
03:46.17 | ibot | bzsvn is probably http://my.bzflag.org/w/BZFlag_SVN and svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag bzflag |
03:57.19 | Constitution | for the group manager, will there be any use for locking of groups and organizations by admins? |
03:57.39 | Constitution | I'm wondering whether I need an "inactive" state value option |
03:58.09 | JeffM | like so it can be there but unused? |
03:58.21 | JeffM | there'd be no point, they would just pull the perms from it on the local servers |
03:58.28 | JeffM | that would make it efectivly pointless |
03:58.54 | Constitution | right |
03:59.27 | JeffM | so no, I don't think you need that level of controll |
03:59.33 | JeffM | if they don't want the group, they delete it |
04:02.34 | *** join/#bzflag praetorian (n=praetori@124-168-170-173.dyn.iinet.net.au) |
04:37.55 | *** mode/#bzflag [+o brlcad] by ChanServ |
05:32.12 | *** join/#bzflag winwinwin (n=chatzill@unaffiliated/davidhkmrpowers) |
06:16.27 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
06:16.27 | *** mode/#bzflag [+v Tupone] by ChanServ |
06:55.52 | *** join/#bzflag bier_ (n=bier@p54A5591A.dip.t-dialin.net) |
07:52.15 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
07:53.04 | a_meteorite | ~bz20svn |
07:53.04 | ibot | from memory, bz20svn is http://my.bzflag.org/w/BZFlag_SVN and svn co https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag |
07:56.34 | *** join/#bzflag L4m3r (n=l4m3r@about/essy/warning/L4m3r) |
07:56.34 | *** mode/#bzflag [+v L4m3r] by ChanServ |
08:05.12 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
09:58.58 | *** join/#bzflag deprecated (n=deprecat@c-24-18-19-17.hsd1.mn.comcast.net) |
10:16.25 | *** join/#bzflag LongDon (n=LongDon@host-091-097-064-109.ewe-ip-backbone.de) |
10:26.02 | *** join/#bzflag PrezzKennedy (i=Matt@74.86.45.130) |
10:45.22 | *** join/#bzflag I_Died_Once (n=I_Died_O@unaffiliated/idiedonce/x-1828535) |
11:18.55 | *** join/#bzflag Suspect (n=Suspect@68-114-69-187.dhcp.plt.ny.charter.com) |
11:23.31 | *** join/#bzflag Warinthestar (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
11:30.53 | *** join/#bzflag blast007 (i=blast@pdpc/supporter/active/blast007) |
11:30.53 | *** mode/#bzflag [+v blast007] by ChanServ |
11:55.54 | *** join/#bzflag MickyFr (n=Miranda@dyn-91-168-44-18.ppp.tiscali.fr) |
12:50.39 | *** join/#bzflag CIA-24 (n=CIA@208.69.182.149) |
13:00.44 | *** join/#bzflag F687s (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
13:02.50 | *** join/#bzflag lepoulpe303 (n=LePoulpe@about/essy/MobileTarget/LePoulpe303) |
13:36.47 | *** part/#bzflag LongDon (n=LongDon@host-091-097-064-109.ewe-ip-backbone.de) |
14:17.07 | *** join/#bzflag lepoulpe304 (n=LePoulpe@LSt-Amand-152-32-5-35.w82-127.abo.wanadoo.fr) |
14:33.02 | *** join/#bzflag TrioTorus (n=TrioToru@213.219.137.21.adsl.dyn.edpnet.net) |
14:34.34 | TrioTorus | when following a tank as observer, I can see that rotating the tank is faster than what I can do with my keyboard. It looks as if there is a button pressed to snap to a certain angle. Can this be achieved with keyboard steering? |
14:38.50 | catay | Maybe the player was using a mouse |
14:39.57 | catay | but I have no idea if a mouse lets you turn faster then keyboard |
14:40.09 | catay | never really played with keyboard |
14:40.17 | donny_baker | TrioTorus: that snap, i believe is your client anticipating the turn, and then getting an update that it stopped and correcting |
14:40.36 | donny_baker | it happens no matter if the client is using a mouse or keyboard |
14:40.48 | donny_baker | in fact it happens no matter who you are following |
14:40.56 | CBG | It does. There is a delay when using keyboard controls whereas the only delay with a mouse is the human reaction time which can be reduced to practically nothing if the mose box is small enough and the mouse speed is fast enough. |
14:41.13 | TrioTorus | donny_baker, I thought of that. It could be, I just feel that I'm not making all that much progress in the game the way I'm doing things right now... |
14:41.50 | donny_baker | TrioTorus: some of us never make progress, take me for instance :P |
14:42.04 | CBG | I'd have to say (even though I used to always use keyboard) that the majority of the 'top players' were always mouse users... |
14:42.15 | TrioTorus | I found mouse to be too sensitive and keyboard, well, I get shot far too often. I seem to always end up at the bottom of the scoreboard |
14:42.32 | TrioTorus | hmm, maybe need to improve my mouse skills then. |
14:43.16 | TrioTorus | I'll give it another go. Thanks gusy, see you on the battlefield. |
14:43.31 | donny_baker | f your client does have a lot to do with it too.. as cbg said most skilled players swear by a small mouse box, and short quick movements |
14:43.39 | catay | play the next year two hours a day and you will become good at it :) |
14:43.46 | CBG | Try and catch randomparticle here if you can - he'll explain more about the difference between mouse and keyboard. He's done some very intelligent calculations and proved that there is a delay built into keyboard movements. |
14:43.59 | TrioTorus | does the size of your mouse box influence the mouse movement then? |
14:44.27 | CBG | No, but the smaller the mouse box, the shorter the distance you have to move your hand -> the faster you turn. |
14:45.18 | TrioTorus | CBG, okay. I'll try to see if I can find a setting that suits me. |
14:46.12 | donny_baker | TrioTorus: i tend to get out of control if i make my mouse box too small...i make too large of movements |
14:46.26 | donny_baker | it takes practice |
14:48.07 | TrioTorus | funny game it is. I haven't come across a game that was so hard to get good at but players keep on trying very hard to get better. |
14:48.33 | TrioTorus | that was a bit of a crap sentence, but you know what I mean. |
14:49.04 | donny_baker | easy to play... difficult to master |
14:52.13 | TrioTorus | new question: how to you configure keyboard to use 3 keys to fire? I can only set s OR d for example... |
14:52.34 | ruskie | what makes you think you can? |
14:52.59 | TrioTorus | in the forums I can see other players saying: fire: s,d,f |
14:53.21 | donny_baker | TrioTorus: when you see those sprays of bullets... the fire key is mapped to mouse scroll wheel |
14:53.23 | TrioTorus | I want to fire 3 shots close together, as I found in the forums too |
14:53.43 | TrioTorus | ah, I didn't know that |
14:53.57 | donny_baker | or so i've been told |
14:54.00 | ruskie | yup |
14:54.03 | ruskie | that's how it's done |
14:54.05 | ruskie | :) |
14:54.44 | TrioTorus | so, so way to achieve that with keyboard? |
14:54.54 | TrioTorus | s/so/no/ |
14:55.17 | donny_baker | i suppose you could with some sort of key mapping software... possibly |
14:55.40 | donny_baker | but not through our client, i don't believe |
14:56.28 | donny_baker | like keyboard macros is what i mean.. but i am not certain |
15:04.42 | CBG | Edit the config.cfg file to set multiple keybard keys to shoot, for example. |
15:29.15 | *** join/#bzflag KTL (n=KTL@213.219.144.106.adsl.dyn.edpnet.net) |
15:34.38 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
16:23.20 | blast007 | TrioTorus: technically I think you could manually modify the configuration file and map additional keys. |
16:28.51 | *** join/#bzflag MickyFr (n=Miranda@dyn-91-168-44-18.ppp.tiscali.fr) |
16:42.27 | *** join/#bzflag stylus (i=stylus@freenode/helper/stylus) |
17:18.19 | ndim | TrioTorus: I recommend an analog gamepad. That lets you stop on point, turn and accelerate quickly, but still gives you proportional control on that. |
17:18.53 | ndim | And unless a large joystick, you don't have to move that far to get into saturation. |
17:19.35 | ndim | s/unless/unlike/ |
17:20.41 | ruskie | just need to find a decent analog gamepad |
17:20.53 | ruskie | all the ones I tried had a 50%> deadzone |
17:21.02 | ruskie | so it maxed after like half an axis |
17:29.28 | *** join/#bzflag LongDon (n=LongDon@host-091-097-064-109.ewe-ip-backbone.de) |
17:48.40 | *** join/#bzflag randomparticle (n=faber@about/essy/snick/randomparticle) |
17:51.31 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
18:15.09 | *** join/#bzflag Pimpinella (n=frank@gondolin.pimpi.org) |
18:23.22 | *** join/#bzflag Erroneous (n=dtremena@67-131-219-2.dia.static.qwest.net) |
18:29.01 | JeffM | Erroneous, gary found a simpler way to do the 1 <-> 0 swap |
18:29.04 | JeffM | x = 1-x; |
18:29.35 | Erroneous | yup |
18:30.06 | JeffM | too bad we didn't get a square root in there ;) |
18:30.58 | Erroneous | could have....sqrt(x*x) <=> abs(x) |
18:31.21 | JeffM | heh |
18:31.43 | Erroneous | also takes several hundred times as many cpu cycles |
18:32.42 | JeffM | yeah |
19:01.03 | *** join/#bzflag O-Neil (n=Miranda@dslb-088-070-061-055.pools.arcor-ip.net) |
19:29.17 | *** join/#bzflag TimRiker (n=timr@psnet.cc) |
19:29.17 | *** mode/#bzflag [+o TimRiker] by ChanServ |
19:36.39 | *** join/#bzflag SpazzyMcGee (n=Spazzy_M@unaffiliated/spazzymcgee) |
19:39.51 | *** join/#bzflag bier_ (n=bier@p54A5591A.dip.t-dialin.net) |
19:46.50 | ndim | Just make sure that x \in {0, 1} before you start iterating x=1-x; :) |
19:48.08 | ndim | BTW... on i386++, you can code x = (x!=0)?0:1; as two assembly instructions. |
19:49.40 | *** join/#bzflag Suspect (n=Suspect@68-114-69-187.dhcp.plt.ny.charter.com) |
19:58.18 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
20:04.14 | *** join/#bzflag a_meteor_work (n=cfe91b36@gateway/web/cgi-irc/zeebrothers.net/x-af2cf1633d29e9e4) |
20:07.13 | *** join/#bzflag Warinthestar (n=Warinthe@1.168.188.72.cfl.res.rr.com) |
20:12.20 | *** join/#bzflag jftsang (n=chatzill@88-108-202-244.dynamic.dsl.as9105.com) |
20:12.32 | jftsang | can I make a suggestion for the next version of BZFS |
20:13.04 | jftsang | get rid of the -j option and make all servers jumping automatically, unless they set _jumpVelocity to 0 |
20:13.45 | jftsang | and then the JP flag, if used, will set your tank's jump velocity to the _jumpFlagVelocity (or something) velocity |
20:15.04 | spldart | how do I get player's ip for ban again? |
20:15.22 | jftsang | spldart, do you mean /playerlist |
20:16.58 | JeffM | jftsang, the internals don't realy work that way |
20:17.06 | JeffM | bzdb vars are for everyone |
20:17.09 | JeffM | not per tank |
20:17.22 | JeffM | all your doing is making the code more complex |
20:17.50 | JeffM | simpler would be to keep the guts, default to jumping and change -j to be -nojump |
20:17.52 | jftsang | it would be useful if you forgot to add -j, you could /set _jumpVelocity |
20:18.05 | JeffM | reboot the server |
20:18.14 | Winny | yeah |
20:18.25 | Winny | hit ctrl+c, the up arrow, and then enter |
20:18.38 | jftsang | or rather still, make Jumping a bool variable, and the same for maxshots, rico |
20:18.44 | JeffM | the propblem with your method is you have both per tank jump vels being added with a global one |
20:19.04 | JeffM | what if you have tanks with jump flags, and a personal jump vel, then you set the global one? |
20:19.06 | JeffM | do they add? |
20:19.12 | JeffM | average? |
20:19.21 | spldart | Yes.. that's it thankies |
20:19.52 | jftsang | basically, if you have jump flag, they use the _jumpFlagVelocity, and if not, they use _jumpVelocity |
20:20.08 | jftsang | it was possible with rapid fire, machine gun, etc |
20:20.19 | JeffM | so in your case, you can have people with the jump flag get LESS of a jump then those without ;) |
20:20.39 | JeffM | shot times are hardcoded to look at the flags |
20:20.44 | JeffM | on a per person basis |
20:21.00 | JeffM | I don't see what the avantage to the game is, other then for people who screw up |
20:21.10 | JeffM | how does it make the game and the code better? |
20:21.47 | jftsang | well, say for example I was having a map hosted by another guy |
20:22.22 | jftsang | who is now on holiday, and there is absolutely no means of contacting him to restart the server, and I discover I left out +r, or -j, or something like that |
20:22.36 | JeffM | then you were stupid for geting hosting you can't controll |
20:22.55 | JeffM | jumping is just one of the many things you need access to the server to set |
20:23.08 | JeffM | what if he didn't do CTF? |
20:23.17 | JeffM | what if he didn't load the right map |
20:23.24 | JeffM | what if he didn't set the shots right? |
20:23.38 | jftsang | in a nutshell, what I propose is that all gameplay settings should become BZDB variables |
20:24.02 | JeffM | I'd say that in an optimal world they shoudl all be dynamic |
20:24.03 | jftsang | whereas server administration, e.g. group files, user files, bad words, should be a BZFS switch |
20:24.06 | JeffM | not nesisarly bzdb |
20:24.13 | JeffM | bzdb is NOT the best soltion for all things. |
20:24.17 | JeffM | state the problem |
20:24.27 | JeffM | not the solution you came up with off the top of your head |
20:24.57 | JeffM | I'd take a bit of rework to get it to be dynamic |
20:25.02 | JeffM | simiar to per tank gravity, etc.. |
20:25.12 | JeffM | it's not something we store per tank now |
20:25.32 | JeffM | but if you wan to write it, have at it |
20:31.10 | JeffM | I'd do it with /allowjump or some slash command |
20:31.16 | JeffM | then have per tank jumps |
20:31.21 | JeffM | so that you can do all sorts of trickyness |
20:31.35 | JeffM | and just use the bzdb var for the base value that can be overiden |
20:31.50 | JeffM | then the jump flag just sets that tank to an overide |
20:31.53 | JeffM | on the server |
20:32.13 | JeffM | then the client dosnt' do any special logic for it |
21:13.33 | *** join/#bzflag F687s (n=noah@cpe-71-67-112-44.woh.res.rr.com) |
21:18.38 | *** join/#bzflag noyb (n=noyb@nat/sun/x-358b9bcbaed0069d) |
21:21.38 | *** join/#bzflag AHA (n=aha@unaffiliated/aha) |
21:30.25 | *** join/#bzflag iWinny (n=kylevane@unaffiliated/winny) |
21:48.26 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
21:48.26 | *** mode/#bzflag [+v Tupone] by ChanServ |
21:48.54 | *** join/#bzflag TD-Linux (n=wheeeeee@24-159-201-10.dhcp.roch.mn.charter.com) |
21:50.35 | *** part/#bzflag LongDon (n=LongDon@host-091-097-064-109.ewe-ip-backbone.de) |
22:28.05 | *** join/#bzflag pacman87 (n=Timothy@resnet-46-58.dorm.utexas.edu) |
22:34.08 | *** join/#bzflag TJ13820 (n=tj13820@c-71-206-201-73.hsd1.pa.comcast.net) |
22:41.10 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
22:44.32 | *** join/#bzflag ducktapebz (n=chatzill@71.92.108.61) |
22:44.36 | ducktapebz | hellow |
22:44.39 | ducktapebz | hello* |
22:44.55 | spldart | Yellow |
22:46.21 | F687s | hi! |
22:47.21 | ducktapebz | hey F6 |
22:52.53 | brlcad | donny_baker (or whomever if you know): do you know how to associate multiple resolutions of images on mediawiki? |
22:53.21 | *** join/#bzflag blast007_nokia (n=blast007@pdpc/supporter/active/blast007) |
22:53.21 | *** mode/#bzflag [+v blast007_nokia] by ChanServ |
22:53.25 | brlcad | I went to upload a big image and it warned that it was big, so I scaled it down and uploaded it. Now it says "No higher resolution available" on the small one |
23:02.22 | *** join/#bzflag PrezKennedy (i=Matt@74.86.45.130) |
23:04.03 | brlcad | never mind, figggured it out |
23:16.01 | *** join/#bzflag triclops (n=triclops@59.154.120.204) |
23:22.25 | *** join/#bzflag sigonasr2 (n=sigonasr@ip72-200-88-154.tc.ph.cox.net) |
23:51.57 | *** join/#bzflag [dmp] (n=dennis@static.88-198-0-201.clients.your-server.de) |