| 00:50.59 | *** join/#bzflag noyb (~noyb@64.134.229.77) |
| 01:49.25 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 01:49.32 | *** mode/#bzflag [+v trepan] by ChanServ |
| 02:24.44 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 02:24.44 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 03:00.07 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 04:38.54 | *** join/#bzflag spldart (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 04:38.54 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 04:38.54 | *** mode/#bzflag [+v spldart] by ChanServ |
| 04:56.04 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 04:56.04 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 05:40.40 | trepan | JeffM: would 'author' and 'license' be decent requirements for a bzw? (any others?) |
| 05:58.19 | JeffM | source url |
| 05:58.31 | JeffM | not sure if you can make them requirements |
| 06:01.21 | JeffM | if it's for 2.4 I'd rather not change it now and have a proper discussion about what we feel the needs for map transfers are |
| 06:03.05 | trepan | don't know about source-url as a requirement, don't think kid joe is going to be adpet enough to get his 12 line map hosted :) |
| 06:10.55 | *** join/#bzflag Marzipan- (~Marzipan@p5B22521E.dip.t-dialin.net) |
| 06:11.56 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:21.05 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 06:29.04 | *** join/#bzflag brad (~brad@stupid.h-o-s-t.name) |
| 07:03.48 | *** join/#bzflag GOP-USA_dotcom (~machine4@pool-74-111-197-200.lsanca.fios.verizon.net) |
| 08:17.56 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:18.08 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 10:28.11 | Pimpi | kid joe is not adept enough to write a 12 line map, he uses bzedit for it |
| 10:29.05 | Pimpi | suggests to knit bzedit to force them to make their first use of an editor |
| 10:32.45 | Pimpi | that'll lead to one billion occasions to explain why MS Word will not do |
| 10:52.40 | *** join/#bzflag Gilly (~btw@83.146.211.140) |
| 10:52.40 | *** join/#bzflag Gilly (~btw@about/essy/ilkimys/gilly) |
| 14:16.22 | *** join/#bzflag sirquine (~quine@c-71-237-73-109.hsd1.co.comcast.net) |
| 14:18.58 | *** join/#bzflag meeba (~lamer@c-24-8-181-169.hsd1.co.comcast.net) |
| 14:29.46 | *** join/#bzflag bier|tp (~bier@p54A5AEF2.dip.t-dialin.net) |
| 14:31.11 | *** join/#bzflag bier (~bier@p54A5AEF2.dip.t-dialin.net) |
| 14:48.32 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 14:48.32 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 14:48.32 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:59.37 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 15:00.56 | randomparticle | can tokens only be used once? |
| 15:09.23 | blast007 | yes |
| 15:09.44 | blast007 | and a user can only have a single pending token at a time |
| 15:10.02 | randomparticle | ok, thanks |
| 15:11.38 | blast007 | (and tokens have a limited time that they can be used - I think it's an hour right now, but that really needs to be reduced to something like 5 minutes, maybe 15 max) |
| 15:12.12 | randomparticle | can i also ask about messages. is the initial BZFS0026 message the only kind that does not conform to the usual (len, code, body) format? |
| 15:13.50 | blast007 | yeah |
| 15:14.07 | randomparticle | and that occurs only once when you make the tcp connection? |
| 15:14.15 | blast007 | on 2.0.x yes |
| 15:14.29 | randomparticle | that's good news then |
| 15:14.49 | randomparticle | i was a bit worried reassembling the messages would be more complex than it is |
| 15:14.52 | blast007 | on 2.4/2.3/2.99.x/3.x it will be only after you send a specific message to the server |
| 15:15.01 | blast007 | something like BZFLAG\r\n\r\n |
| 15:15.05 | randomparticle | the bzflag\r\r thing? |
| 15:15.05 | blast007 | but I don't know the exact string |
| 15:15.57 | randomparticle | i'm wondering.. might it be better for that message also to be of the (len, code, body) type, for consistency? |
| 15:16.09 | blast007 | why would it? |
| 15:16.28 | randomparticle | it means you need a different bit of code jsut for that one message |
| 15:16.44 | randomparticle | you can't use the normal message parsers |
| 15:16.57 | blast007 | why would you want to? :) |
| 15:17.09 | randomparticle | simplicity, reducing code size, etc :) |
| 15:17.19 | blast007 | wouldn't reduce code size |
| 15:17.24 | blast007 | it would just move it around |
| 15:17.31 | blast007 | so not really any point |
| 15:17.54 | blast007 | wouldn't you think it's easier to read a fixed size string than to read the length, code, and then the data based on the length? :P |
| 15:18.32 | randomparticle | not particularly, since the latter is already written |
| 15:18.40 | blast007 | the former is already written too ;) |
| 15:19.02 | randomparticle | yeah, but every time you change the initial message, you ahve to rewrite that, because it's a hardcode len |
| 15:19.10 | randomparticle | not one that comes in the header etc. |
| 15:19.20 | randomparticle | but it's up to you. i'm not here to persuade you :D |
| 15:19.37 | blast007 | when have we changed that? |
| 15:19.46 | blast007 | it's bee 8 chars since as long as I can remember |
| 15:19.57 | randomparticle | i think it's 9 actually |
| 15:20.08 | randomparticle | BZFS0026 + the player id |
| 15:20.13 | randomparticle | which is 1 byte |
| 15:20.16 | blast007 | probably |
| 15:20.31 | randomparticle | but yeah, 8, 9, makes no diff |
| 15:22.33 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 15:28.58 | BulletCatcher | I see randomparticle's point. |
| 15:28.59 | BulletCatcher | Post-2.0.x, where the client speaks first, it wouldn't hurt for the server's initial response to be encoded the same as all of the subsequent ones. |
| 15:29.35 | *** join/#bzflag TimRiker (~TimRiker@216.49.181.128) |
| 15:29.36 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:29.36 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:35.04 | BulletCatcher | The client's first message is plain text to make it simpler to distinguish a BZFlag player from an HTTP client (which sends a plain text request). |
| 15:42.47 | CIA-103 | BZFlag: 03bullet_catcher * r21844 10/trunk/bzflag/src/game/PlayerInfo.cxx: |
| 15:42.47 | CIA-103 | BZFlag: Log unreadable mottos. |
| 15:42.47 | CIA-103 | BZFlag: Be very careful not to overflow the buffer in the new setCallSign(), setToken(), and setClientVersion() methods. |
| 15:50.00 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:50.00 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:52.07 | *** join/#bzflag JeffM (~JeffM@69.36.85.130) |
| 15:52.07 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:52.07 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 16:04.37 | *** join/#bzflag Upsetter (~er@i59F6A140.versanet.de) |
| 16:36.32 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:40.38 | Pimpinella | is PlayerId signed? |
| 16:41.59 | JeffM | I don't belive so |
| 16:42.08 | JeffM | IIRC it's sent as a byte |
| 16:42.16 | JeffM | and we support up to 245ish players |
| 16:42.32 | Pimpinella | hm, yes |
| 16:42.49 | Pimpinella | but we have NoPlayer = 255 |
| 16:42.54 | Pimpinella | that works for me |
| 16:43.02 | JeffM | yeah some numbers are special |
| 16:43.07 | JeffM | NoPlayer, ServerPlayer |
| 16:43.18 | JeffM | that's why we support less then 256 players |
| 16:48.05 | JeffM | comeon Pimpinella why don't you want the bzflag soundtrack ;) |
| 16:52.09 | Pimpinella | I want it if i can decide what it is ! |
| 16:52.16 | JeffM | heh |
| 16:52.31 | Pimpinella | however we might loose a lot of players then ;) |
| 16:52.37 | JeffM | the simplest things to say to those silly requests is that our sound system dosn't support that kind of stuff |
| 16:52.53 | Pimpinella | well, i said that too ;) |
| 16:53.05 | JeffM | tho at some point we should just move to openAL |
| 16:53.45 | Pimpinella | don't know that lib, but to be honest i really don't need background music |
| 16:53.56 | Pimpinella | custom sound effects would be nice tho |
| 16:54.12 | JeffM | OpenAL is a common sound lib used by games and other stuff. Gives you hardware 3d if drives support it |
| 16:54.24 | JeffM | custom sound effects have other issues, like custom textures |
| 16:54.33 | Pimpinella | sure |
| 16:54.42 | JeffM | but yes I'd like to see the custom resource system extended to include sounds and models |
| 16:54.59 | JeffM | and have the server be able to trigger any sound |
| 16:55.10 | JeffM | as well as map defined sounds |
| 16:57.09 | Pimpinella | will OpenAL also allow ogg or something similar? |
| 16:57.20 | JeffM | it can yes |
| 16:57.44 | JeffM | that's one of the big features we'd get out of it |
| 16:59.11 | JeffM | and if I understand it, it should play nicer on linux |
| 17:00.30 | Pimpinella | alsa support works for me now, but sound was often broken here, yes |
| 17:00.44 | JeffM | yeah you have too many competing sound engines :) |
| 17:00.58 | JeffM | IIRC openAL can link to all the different backends |
| 17:01.06 | JeffM | so it's simpler to get it working |
| 17:01.23 | JeffM | on window it's just a wraper over DirectSound so it just works |
| 17:01.54 | Pimpinella | seems to be what we need |
| 17:02.11 | JeffM | yeah it's pretty much industry standard for game sounds ( for free libs) |
| 17:02.18 | Pimpinella | one further step to solve portability issues |
| 17:02.43 | JeffM | unless you want to license miles for every OS :) |
| 17:03.08 | Pimpinella | uhm... no |
| 17:03.11 | blast007 | JeffM: is it "gives you hardware 3D if you have a card from Creative Labs"? ;) or maybe I just don't have a fancy enough card. |
| 17:03.24 | blast007 | isn't it* |
| 17:03.27 | JeffM | blast007, if you have drivers |
| 17:03.37 | JeffM | and yes a lot of creative cards have drivers |
| 17:03.45 | JeffM | they are the main backers of the proejct |
| 17:03.52 | JeffM | but its' better then nothin |
| 17:03.55 | blast007 | so there's OpenAL drivers you need too? |
| 17:04.09 | JeffM | yes to get the hardware support |
| 17:04.24 | blast007 | why does audio suck so bad on computers? ... |
| 17:04.39 | JeffM | it's not bad on windows |
| 17:04.43 | blast007 | yes it is ;) |
| 17:04.44 | JeffM | it's just the cross plat stuff |
| 17:04.50 | JeffM | on windows just call DirectSound and you are good |
| 17:05.03 | blast007 | Vista/7 killed hardware Direct3D, afaik |
| 17:05.09 | JeffM | it changed it |
| 17:05.12 | blast007 | DirectSound3D* |
| 17:05.14 | JeffM | there are ways to get it |
| 17:05.23 | JeffM | you have to use a different interface |
| 17:05.25 | JeffM | but it's there |
| 17:05.35 | blast007 | my card has some emulation layer for it |
| 17:05.39 | JeffM | yeah |
| 17:05.40 | blast007 | but it sucks |
| 17:05.49 | blast007 | makes the audio get pops |
| 17:05.50 | JeffM | the replacement is what XNA uses |
| 17:06.11 | JeffM | but that's harder to call for cross plat apps |
| 17:06.22 | JeffM | XAudio2 I think is the API |
| 17:06.52 | JeffM | DirectSound was always an odd API |
| 17:06.57 | JeffM | too much buffer management |
| 17:07.20 | JeffM | OpenAL is about as easy as it gets to get support on more then one OS |
| 17:07.41 | JeffM | and if it's good enough for comercial games i should be good for us |
| 17:08.07 | JeffM | I mean I like FMod too but it's not open |
| 17:11.01 | blast007 | I just wonder if we'd lose anything by going to OpenAL |
| 17:11.12 | blast007 | we'd gain hardware 3D on *some* systems |
| 17:11.24 | JeffM | yeah and software emu on others, same as we do now |
| 17:11.30 | blast007 | but on the ones that don't does it all still work the same? |
| 17:11.46 | JeffM | it'll probably sound slightly different as different maths will be used for dopler and stuff |
| 17:11.50 | blast007 | doesn't depend on having EAX or OpenAL drivers to handle some effects we use now like doplar |
| 17:11.51 | JeffM | but it will be comparable for sure |
| 17:12.03 | JeffM | no simple 3d is emulated |
| 17:12.16 | JeffM | what isn't emulated is stuff like dolby out |
| 17:12.20 | blast007 | ok |
| 17:12.24 | JeffM | so it would work fine on 2 speaker systems |
| 17:12.32 | JeffM | just like it does now |
| 17:12.44 | JeffM | but if you have the hardware and a 6 speaker setup it'll use it correctly |
| 17:13.20 | JeffM | EVERYONE does 2 speaker dopler and postional sounds these days, it's a bassic feature |
| 17:14.31 | JeffM | OpenAL threads it's stuff too, so we loose CPU usage :) |
| 17:16.18 | JeffM | this is all of course what it's "suposed to do" If the time comes and it doisn't then perhapos we would want to wrap audio in a class and have 2 implemtations, new and old |
| 17:16.39 | JeffM | we've got code to do ogg in the old sound system if we need it |
| 17:16.41 | JeffM | it's just fugly |
| 17:26.08 | Pimpinella | i hate the mixture of pointers and references in c++ |
| 17:27.49 | randomparticle | there's a server in the list. description: "your shirt look like a dish rag" :--) |
| 17:42.02 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 17:42.02 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 17:51.17 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-125-36.wi.res.rr.com) |
| 17:51.17 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 17:55.24 | Pimpinella | ok, I'm a little confused now and need some help |
| 17:56.35 | Pimpinella | i was looking if the server knows the target of a GM |
| 17:57.47 | Pimpinella | so i looked at ShotUpdate.h if the target is part of MsgGMUpdate, and no there's no target |
| 17:58.08 | Pimpinella | and ShotUpdate::Pack doesn't pack a target in |
| 17:58.30 | JeffM | nope |
| 17:58.34 | blast007 | it does not track the target that I see, from a quick check |
| 17:58.35 | JeffM | the server knows crap about shots |
| 17:58.45 | JeffM | the shooting client drives the shot |
| 17:58.46 | blast007 | it just relays the MsgGMUpdate on |
| 17:58.54 | JeffM | tht's how a moded client can make the shot go anywhere |
| 17:59.00 | JeffM | write your name in the sky :) |
| 17:59.09 | Pimpinella | then i noticed, that the client packs the target _after_ MsgGMUpdate is packed behind the packet |
| 17:59.29 | Pimpinella | JeffM: i try to solve that problem ;) |
| 17:59.31 | JeffM | in the current system only the shooter needs to know the target for the shot update |
| 17:59.36 | JeffM | you can't |
| 17:59.39 | JeffM | the server can't drive the shot |
| 17:59.47 | JeffM | it dosn't have correct client states |
| 17:59.51 | JeffM | nor shot info |
| 17:59.57 | JeffM | that's for when we have server side shots |
| 18:00.02 | JeffM | do NOT do this for 2.4 |
| 18:00.09 | Pimpinella | i dont ;) |
| 18:00.29 | Pimpinella | but i wanted to make sure the target is in MsgGMUpdate |
| 18:00.36 | JeffM | ok |
| 18:00.38 | JeffM | why? |
| 18:00.45 | JeffM | what will use that data? |
| 18:01.03 | JeffM | ahh the radar marker |
| 18:01.04 | JeffM | ok |
| 18:01.09 | Pimpinella | and actually it is, it's packed outside ShotUpdate::pack |
| 18:01.13 | Pimpinella | yep radar |
| 18:01.15 | JeffM | yeah it's constant for the shot |
| 18:01.19 | JeffM | you don't need it in he update |
| 18:01.39 | Pimpinella | yes, i need it, you can relock while the missile is running |
| 18:01.40 | JeffM | do GMs ever change target? |
| 18:01.45 | JeffM | ahh oik |
| 18:01.46 | blast007 | yes |
| 18:01.48 | Pimpinella | and you can lock after the missile is fired |
| 18:01.52 | blast007 | it's one target per tank |
| 18:02.00 | blast007 | all missiles follow that target |
| 18:02.08 | JeffM | interesting |
| 18:02.19 | JeffM | so why not store it as playerDATa |
| 18:02.21 | blast007 | you can even unlock them |
| 18:02.22 | JeffM | not shot data |
| 18:02.44 | JeffM | then on radar if a player's lock target == you highlight all GM shots in the air they own |
| 18:02.56 | Pimpinella | it IS in MsgGMUpdate, just packed outside |
| 18:03.02 | Pimpinella | and i wonder why that is |
| 18:03.05 | JeffM | I don't think it should be |
| 18:03.15 | blast007 | probably cuz it's not a per shot thing |
| 18:03.19 | JeffM | should be part of player data |
| 18:03.23 | Pimpinella | looks like somebody wanted to break the protocol without breaking it |
| 18:03.27 | JeffM | then a player update would send it |
| 18:03.35 | JeffM | and you can know who's the lock target with out any shots |
| 18:05.30 | Pimpinella | personally i think it's fine in shot update |
| 18:05.52 | blast007 | I think the gm update is already sent when you first lock on, or at least I thought that the alarm goes when someone locks on to you |
| 18:06.16 | JeffM | Pimpinella, how does the lockon message get sent before the shot is fired? |
| 18:06.23 | JeffM | yeah |
| 18:06.28 | JeffM | no need for 2 messages for that |
| 18:06.49 | JeffM | if you put it as player data then it works for both the alarm and the shots |
| 18:08.20 | Pimpinella | no, the alarm is triggered by shot update |
| 18:08.50 | JeffM | hmmm I'd rather know when the lock on before they shoot :) |
| 18:08.52 | JeffM | more warning |
| 18:09.56 | Pimpinella | maybe it's sent in more than just one places |
| 18:17.50 | Pimpinella | no other hit for SFX_LOCK, so it must be a gm update that trigers the alarm sound. maybe blast007 is right a gm update is sent already on lock |
| 18:18.30 | JeffM | see I'm not a fan of that |
| 18:18.34 | Pimpinella | however i havn't seen something like that when i tested tupones GM checks and i guess i would have seen them there |
| 18:18.59 | JeffM | I really think it should be player data |
| 18:19.30 | JeffM | then when we move the shot logic server side, a player will just change there lock target and the server will update the shots |
| 18:20.14 | Pimpinella | thats true |
| 18:21.52 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust241.1-4.cable.virginmedia.com) |
| 18:21.52 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 18:59.35 | *** join/#bzflag jh` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 19:20.32 | *** join/#bzflag meeba (~lamer@c-24-8-181-169.hsd1.co.comcast.net) |
| 19:21.55 | *** join/#bzflag jcp|alive (~boydam@155-99-194-168.uconnect.utah.edu) |
| 19:34.39 | trepan | http://trepan.bzflag.bz/noshow/bzworld.lua -- think it'll work out, could make procedurally generated maps extremely lightweight over the wire |
| 19:44.18 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 20:13.02 | KTL | is that going to work in 2.4?? |
| 20:13.20 | JeffM | lua is 3.0 |
| 20:13.20 | trepan | nope |
| 20:13.26 | KTL | ok |
| 20:13.38 | JeffM | trepan's been working in a 2.99 branch |
| 20:16.07 | CIA-103 | BZFlag: 03trepan * r21845 10/branches/experimental/v2_99continuing/bzflag/src/ (bzflag/CommandsImplementation.cpp game/global.cpp): * added the '_forbidSaveWorld' feature |
| 20:17.26 | trepan | _forbidSaveWorld -- not ultra-secure, but should but enough |
| 20:17.44 | trepan | if a hackster really wants to save the world, it's going to happen |
| 20:17.50 | JeffM | yeah |
| 20:20.17 | trepan | one cool part with the bzworld.lua setup is that the bzflag.org controllers could add new primitive types (like arc, cone, sphere, etc...) whenever they wanted to, no need for a release |
| 20:20.49 | trepan | could also set it up for native .obj loading, etc... |
| 20:21.03 | KTL | and make world-generating code modular -> lua libs |
| 20:21.09 | KTL | reusable |
| 20:21.34 | trepan | ya, there'll have to be at least one library to do the bzw->lua conversions |
| 20:21.51 | KTL | with the text-stuff you could even put the latest news on the map-walls |
| 20:22.12 | trepan | but that'll be fast, i did something similar for SpringRTS, and it ended up being twice as fast as the boost parser they were using |
| 20:22.54 | KTL | ah? i'm using boost spirit and ... i barely dare touch it, it's fragile and every recompile takes ages |
| 20:23.18 | trepan | which reminds me, you'll have to add walls using raw lua code -- forget a couple of other items too |
| 20:23.31 | trepan | SetWorldSize(), etc... |
| 20:24.18 | JeffM | just read blender files |
| 20:24.36 | trepan | have much does their file format shift? |
| 20:24.42 | trepan | s/shift/change/ |
| 20:24.49 | JeffM | dunno, they have a lib to read em IIRC |
| 20:24.49 | trepan | s/have/how/ |
| 20:25.58 | JeffM | but at that point it may depend on if we pick third party graphics engine |
| 20:26.42 | trepan | collada may be a better format |
| 20:26.47 | JeffM | yeah |
| 20:26.55 | trepan | a lot of modellers support it these days |
| 20:26.55 | JeffM | lots of things render and generate that |
| 20:27.12 | trepan | and it has good OGL support, and simulation stuff in it |
| 20:27.22 | trepan | friction, etc... |
| 20:33.56 | *** part/#bzflag Upsetter (~er@i59F6A140.versanet.de) |
| 20:35.43 | CIA-103 | BZFlag: 03trepan * r21846 10/branches/experimental/v2_99continuing/bzflag/src/ (bzflag/CommandsImplementation.cpp game/global.cpp): |
| 20:35.43 | CIA-103 | BZFlag: * fixed the tense |
| 20:35.43 | CIA-103 | BZFlag: * bent the indentation a little |
| 20:45.29 | trepan | fwiw, _forbidSaveWorld would be dead easy to add to 2.4, want it? |
| 20:45.43 | JeffM | nope |
| 21:47.21 | CIA-103 | BZFlag: 03bthansen * r21847 10/trunk/bzflag/TODO: Merge in TODO changes from r21383 |
| 21:56.48 | Thumper_ | blast007 / Pimpinella: are either of your doing r12467 (Flags hiding (from cheat) works even with identify flag now., 2006-02-03) [removing the isIdentifyFlagIn boolean and check] |
| 21:57.14 | Thumper_ | s/your/you/ |
| 22:20.55 | *** join/#bzflag Anxuiz (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |
| 22:20.55 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 22:21.12 | blast007 | is that still relevent? |
| 22:21.32 | blast007 | the ID flag is supposed to be handled server-side now, afaik |
| 22:22.04 | blast007 | though I do see that the isIdentifyFlagIn flag is still in bzfs. |
| 22:26.59 | Thumper_ | I think it should go |
| 22:27.34 | Thumper_ | just wondering if you on Pimpi are planning to do it - if not I was going to rip it out |
| 22:29.16 | Thumper_ | s/on/or/ |
| 22:31.22 | *** join/#bzflag dcat (~dcat@c-98-249-63-154.hsd1.va.comcast.net) |
| 22:43.59 | *** join/#bzflag jh`` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 22:59.45 | blast007 | wonder if that's all that's necessary or if there's more that were missed |
| 23:06.50 | Pimpi | Thumper_, i don't port that commit. It heavily relies on massive refactoring Jeff made before and though that looks sexy it doesn't (as far as i found while i overlooked it roughly) it doesn't really add any features |
| 23:07.14 | blast007 | no, it reallly doesn't rely heavily on that |
| 23:07.19 | blast007 | I'm testing it here |
| 23:07.37 | Pimpi | really? |
| 23:07.42 | blast007 | without removing that we were still sending players that flag types if there was an ID flag on the field |
| 23:07.56 | blast007 | (one not specified inside a zone, at least) |
| 23:08.16 | Pimpi | oh |
| 23:08.41 | blast007 | mostly the changes here still apply: http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/bzfs/bzfs.cxx?r1=12467&r2=12466&pathrev=12467 |
| 23:08.51 | blast007 | it's just ditching the isIdentifyFlagIn stuff |
| 23:09.00 | Pimpi | well, the commit was direcly into Jeff's newly introduced code |
| 23:09.08 | Pimpi | ic |
| 23:09.24 | JeffM | I know nothing! |
| 23:09.27 | blast007 | I should say, ALL of those still apply |
| 23:09.44 | blast007 | there's just one additional spot in 2.3 that references isIdentifyFlagIn (in bzfs.cxx) |
| 23:11.28 | Pimpi | yay for reviewing it once more then :) |
| 23:12.42 | Pimpi | seems i forgot a lot about how things work over the last few years |
| 23:22.28 | blast007 | JeffM: do we need EvdevJoystick.cxx in the VC platform project? Seems like it's only a linux thing. |
| 23:27.18 | trepan | evdev is linux specific |
| 23:28.49 | trepan | blast007: i use it instead of xkb/xmodmap for doing keyboard layouts :) |
| 23:29.16 | JeffM | it should be set to not compile |
| 23:29.36 | blast007 | it threw a warning about no methods, so maybe not ;) |
| 23:30.05 | blast007 | Excluded from build: no |
| 23:31.58 | JeffM | exclude it |
| 23:32.21 | JeffM | DTRemenak uses vc to edit the thing when he's working on all sticks |
| 23:32.36 | blast007 | I'm doing the same for SDLJoystick.cxx |
| 23:32.44 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 23:32.45 | JeffM | sounds like a plan |
| 23:36.59 | blast007 | think we should only send a "Closest flag is: blah" message when it was different than the last time or if it was after X amount of time? |
| 23:37.42 | blast007 | (granted, the flag buffet map has several of the same flag in the same spot, so maybe that's why I'm getting multiple) |
| 23:38.44 | a_meteorite | mmmm flag buffet, tasty |
| 23:41.02 | blast007 | Pimpi: 2.99.x has an actual MsgNearFlag for handling server-side ID |
| 23:41.18 | blast007 | seems that we just have an early version of the server-side ID backported right now |
| 23:41.31 | blast007 | (the one in 2.3 just sends chat messages) |
| 23:44.28 | CIA-103 | BZFlag: 03blast007 * r21848 10/trunk/bzflag/src/bzfs/bzfs.cxx: We can do without the isIdentifyFlagIn check now. (Backported from r12467) |
| 23:50.56 | JeffM | oh yeah send the real message |
| 23:51.03 | JeffM | do it all proppa |
| 23:59.21 | moiree | Cannot pick up flags on bzexcess.com:15154. client is at r21848 |