| 00:13.35 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 00:36.40 | *** join/#bzflag xaver__ (~xaver@pD9ED4503.dip.t-dialin.net) |
| 01:32.31 | *** join/#bzflag me1 (~ausom@bzflag/player/Me1) |
| 01:47.27 | *** join/#bzflag mrapple_ (~mrappleco@c-69-180-173-220.hsd1.mn.comcast.net) |
| 01:51.13 | *** join/#bzflag R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 01:53.57 | *** join/#bzflag R0b0t1 (~Enigma@64.126.35.185) |
| 01:54.00 | *** join/#bzflag R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 02:05.31 | *** join/#bzflag sigonasr2 (~Joshua_Si@119.215.228.208) |
| 02:18.38 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 02:50.47 | *** join/#bzflag McSpider (~McSpider@xplr-ts-v10-208-114-184-180.barrettxplore.com) |
| 04:00.28 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 04:00.29 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 04:24.30 | *** join/#bzflag darklust (~darklust@ool-43576d09.dyn.optonline.net) |
| 04:31.11 | BulletCatcher | JeffM: plugin Makefile.am files are set up to create the plugins as libraries that a program can dynamically link to. |
| 04:31.16 | BulletCatcher | When a program does so, that is the time that any undefined symbols must be resolved. |
| 04:31.18 | BulletCatcher | In the case of bzfs and plugins, it is the bzfs executable itself that provides the code called by process(bz_EventData *eventData). |
| 04:33.09 | trepan | class::process() should be provided by the plugin .so |
| 04:33.36 | BulletCatcher | Ah, you're right. |
| 04:34.25 | trepan | mrapple probably just forgot to implement the method |
| 04:34.40 | BulletCatcher | He said his plugin was split into multiple files. Perhaps he just wasn't putting them together correctly. |
| 04:37.33 | *** join/#bzflag BugsPray (BugsPray@c-76-102-255-190.hsd1.ca.comcast.net) |
| 04:40.13 | *** join/#bzflag bryjen (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 04:40.13 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 04:44.03 | BulletCatcher | The most direct answer to your question, JeffM, is that Linux knows a function must be linked at runtime if it remains undefined at the end of the compilation process. |
| 04:44.04 | BulletCatcher | To be successfully run an executable will have a list of libraries that, when dynamically loaded, will resolve all of the undefined symbols. |
| 04:44.50 | BulletCatcher | Those libraries may, in turn, require other libraries to resolve their own undefined symbols. |
| 04:45.25 | *** join/#bzflag darklust (~darklust@ool-43576d09.dyn.optonline.net) |
| 05:07.59 | BugsPray | a vicious cycle of mistrust |
| 06:13.48 | JeffM | BulletCatcher: ahh so it just assumes that all undefined calls at compile/link time will be met at load |
| 06:14.14 | JeffM | windows has a list of what will be provided at runtime so it can give errors at compile time if you missed something |
| 06:14.22 | JeffM | but at least I understand now, thanks |
| 06:24.35 | *** join/#bzflag darklust (~darklust@ool-43576d09.dyn.optonline.net) |
| 08:37.26 | *** join/#bzflag bier|tp (~bier@p54A54E5A.dip.t-dialin.net) |
| 08:38.46 | *** join/#bzflag bier (~bier@p54A54E5A.dip.t-dialin.net) |
| 08:52.35 | *** join/#bzflag sigonasr2 (~Joshua_Si@180.68.244.178) |
| 09:34.55 | *** join/#bzflag ibot (~ibot@rikers.org) |
| 09:34.55 | *** topic/#bzflag is http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || http://ohloh.net/p/bzflag || 2.0.16 is the current release, use it wisely |
| 09:34.55 | *** mode/#bzflag [+o ibot] by ChanServ |
| 09:50.24 | *** join/#bzflag Wyk3d (~Wyk3d@cl-86-125-167-18.cablelink.mures.rdsnet.ro) |
| 10:10.42 | *** join/#bzflag xaver (~xaver@pD9ED4503.dip.t-dialin.net) |
| 10:47.49 | *** join/#bzflag short_circuit (~spldart2@216.231.125.123) |
| 11:13.56 | *** join/#bzflag Atluxity (~atluxity@wikipedia/Atluxity) |
| 11:30.36 | Atluxity | how does one change modes in observer? I see mentions of "roaming" on the forum, but cant seem to change it from following the leader |
| 11:33.41 | Atluxity | ah, found the wiki-page |
| 12:25.37 | CIA-87 | BZFlag: 0392.78.243.178 07http://my.bzflag.org * r7096 10/w/Category:Leagues: |
| 12:50.43 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 12:50.43 | *** mode/#bzflag [+v trepan] by ChanServ |
| 13:01.25 | *** join/#bzflag dhouthoo (~dhouthoo@2002:54c5:7a99:0:9227:e4ff:feea:516d) |
| 13:38.37 | *** join/#bzflag SpazzyMcGee (~SpazzyMcG@bzflag/contributor/SpazzyMcGee) |
| 14:09.56 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 14:55.12 | *** join/#bzflag BugsPray (BugsPray@c-76-102-255-190.hsd1.ca.comcast.net) |
| 15:44.18 | CIA-87 | BZFlag: 03trepan * r21254 10/trunk/bzflag/src/clientbase/ (LocalPlayer.cxx Player.cxx): * add the (oldLocation != InAir) check for _maxBumpHeight |
| 16:13.02 | trepan | for the 3rd regression listed in BUGS, are the @/+/- symbols now working? |
| 16:13.15 | trepan | already fixed the mottos |
| 17:29.08 | *** join/#bzflag bryjen (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 17:29.08 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 17:39.38 | Runic | fyi, I do not agree that the bumping up should be block just because that tank is in the air |
| 17:41.12 | Runic | *blocked |
| 17:45.04 | BulletCatcher | The bumping feature exists to allow tanks to drive over low obstacles without jumping. |
| 17:45.10 | BulletCatcher | Bumping and jumping together can give a very odd landing experience. |
| 17:45.11 | BulletCatcher | The idea is that when jumping, one must in fact jump to the full height of the landing area, not merely almost to the height. |
| 17:46.13 | Runic | I still don't agree, but do what you guys want |
| 17:46.50 | BulletCatcher | We will. :-) |
| 17:46.51 | BulletCatcher | And we really do appreciate your contribution. |
| 17:47.11 | blast007 | Runic: could you put up that one map of yours again? |
| 17:47.21 | Runic | I had more changes in the works such as no more infinity and beyond |
| 17:48.34 | BulletCatcher | You mean the way ground currently seems to go off (almost) to infinity? |
| 17:48.37 | Runic | sure, also not the first bumpObstalce has one var wrong in it the first bumpPos should be tmpPos, I just haven't commited that yet |
| 17:48.42 | *** join/#bzflag thyri0n (~thyrion@unaffiliated/thyri0n) |
| 17:48.44 | Runic | *note |
| 17:50.00 | Runic | no I mean if you have a large _maxBumpHeight such as 10.0001 and a block that is 10 the tank will warp to the top of the box, breaking light speed |
| 17:51.18 | BulletCatcher | I don't think we want to challenge nature in that way. :-) |
| 17:51.48 | BulletCatcher | How do you plan to solve that problem? |
| 17:52.07 | Runic | it has always been that way, I have a fix so that the tank climbs the box instead of warping |
| 17:52.22 | Runic | with the right speed |
| 17:52.28 | BulletCatcher | That sounds good. |
| 17:52.44 | Runic | if you let off the gas you fall back to the ground |
| 17:53.14 | Runic | but the INAir thing stops all that |
| 17:53.33 | BulletCatcher | I see. |
| 17:53.45 | Runic | as during a bump up the tank may at time be inAir |
| 17:54.40 | Runic | I have also solved bumping up a sheared face but I'm guessing you guys will shoot that one down |
| 17:55.16 | Runic | as it would allow the tank to drive up a sheared face |
| 17:55.42 | *** join/#bzflag JeffM2501 (~JeffM@unaffiliated/jeffm2501) |
| 17:55.42 | *** mode/#bzflag [+v JeffM2501] by ChanServ |
| 17:55.48 | BulletCatcher | But only one less than _maxBumpHeight, right? |
| 17:55.54 | Runic | yes |
| 17:56.27 | Runic | but with a large _maxBump you could climb the mountains in Rain'n Frogs |
| 17:56.33 | BulletCatcher | Then the map designer would be in full control of how that works, and I don't see it as a problem. |
| 17:56.45 | Runic | I still have a few thing to work out with it though |
| 17:57.16 | Runic | I would also like to see each object be able to override the main _maxBump |
| 17:57.38 | Runic | could do latters ramps and such |
| 17:58.08 | JeffM2501 | no ramps |
| 17:58.27 | Runic | what if it is configurable by the mapper |
| 17:58.36 | JeffM2501 | it's a design choice per Tim |
| 17:58.42 | JeffM2501 | simple gameplay |
| 17:58.49 | blast007 | depends what you mean by ramps, I suppose |
| 17:59.04 | Runic | driving up a sheared face |
| 17:59.10 | JeffM2501 | ramps that keep the tank flat were discussed as well |
| 17:59.25 | JeffM2501 | after a certain angle they will not be fun |
| 17:59.37 | BulletCatcher | I think Runic's proposal will keep the tanks flat. |
| 17:59.40 | JeffM2501 | you want the tank to "pop" up a flat wall? |
| 17:59.51 | JeffM2501 | how would a player know they could do that? |
| 18:00.11 | Runic | it does at present and I had no plans to make the tank change it's angle |
| 18:00.23 | JeffM2501 | I think that's the main issue, some walls would be "special" and there is no clear indication that they'd be different |
| 18:00.42 | BulletCatcher | That is already the case with drivethrough & shootthrough. |
| 18:00.42 | JeffM2501 | personaly I think max bump is even an abbuse of that |
| 18:00.46 | JeffM2501 | yeah |
| 18:00.53 | Runic | you can not tell a wall is drivethru either |
| 18:01.04 | JeffM2501 | I think those should show different as well |
| 18:01.18 | Runic | that should be up to the map maker |
| 18:01.31 | JeffM2501 | not all choices in the past were good choices :) |
| 18:01.50 | JeffM2501 | perhaps display them slightly different on radar to help |
| 18:01.57 | Runic | making them visible would hurt maps that want it to be a severt |
| 18:02.07 | *** join/#bzflag MindstormsKid (~msk@Wikipedia/MindstormsKid) |
| 18:02.15 | Runic | *secert |
| 18:02.34 | JeffM2501 | as with all things, the grand plan never matters |
| 18:02.41 | JeffM2501 | people will implement what they want |
| 18:03.01 | blast007 | JeffM2501: that's the point - he wants to implement it ;) |
| 18:03.06 | Runic | If my changes are not wanted, I'm fine with that |
| 18:03.07 | JeffM2501 | now? |
| 18:03.12 | JeffM2501 | good lord that'd be stupid to do now |
| 18:03.20 | JeffM2501 | no offsense, but ship the friggin game |
| 18:04.08 | JeffM2501 | I don't think they are bad ideas, and as you say there are other places that have similar effects. |
| 18:04.16 | JeffM2501 | it's probably a good idea to review ALL movement based rules |
| 18:04.18 | Runic | I would suggest maxBUmp either be made to work right or be removed completely |
| 18:04.21 | JeffM2501 | but I'd wait till after 3 shipps |
| 18:04.41 | JeffM2501 | making an existing feature work consistently is a bug fix and that should be done in 3 |
| 18:05.00 | JeffM2501 | but adding new maping features is a bit late for this release IMHO |
| 18:05.19 | JeffM2501 | if the bump height is busted, then fix it |
| 18:05.30 | Runic | 6 years, what another 6 months |
| 18:05.46 | JeffM2501 | in 6 months you'll hav something else to add ;) |
| 18:05.54 | JeffM2501 | feature creep must be killed early |
| 18:06.05 | JeffM2501 | if you do want it shipped |
| 18:06.18 | JeffM2501 | if ya all don't care then go for it |
| 18:07.55 | JeffM2501 | in the end blast007 is a project admin, it woudl be his call :) |
| 18:08.24 | blast007 | >.< |
| 18:08.38 | BulletCatcher | I would prefer to see Runic and other devs focused on shipping 3.0, but until we are ready to make v3_0branch we don't have a better place to put these features that people want to implement. |
| 18:08.58 | JeffM2501 | sure you do, make them make there own branches for each feature |
| 18:09.04 | JeffM2501 | I did that for shots |
| 18:09.24 | Runic | a branch usually means it will never happen |
| 18:09.24 | JeffM2501 | have him make a "new map physics" branch |
| 18:09.30 | JeffM2501 | no, not always |
| 18:09.52 | JeffM2501 | it just means you have to make sure to merge it after shipping |
| 18:10.45 | JeffM2501 | if it dosn't happen after that then ether you gave up, or the project didn't release again |
| 18:12.03 | BulletCatcher | I see feature branches mostly as places to develop things that are at high risk of failure. |
| 18:12.12 | JeffM2501 | that is one reason |
| 18:12.34 | Runic | all I have let to do that I know of, is clean up my recent code changes and also need to make sure Physics will still happen on sheared faces |
| 18:12.39 | JeffM2501 | it is rare to get someone who wants to make new features near a release and dosn't want to work on the release |
| 18:13.19 | JeffM2501 | what else is left for the rest of the release? |
| 18:13.29 | BulletCatcher | Bugs, bugs, bugs. |
| 18:13.45 | BulletCatcher | And testing. |
| 18:13.58 | blast007 | well, right now I'm checking if /reset works right. seems like it's not resetting to the bzfs's -set or the world's -set values. |
| 18:14.12 | Runic | what do you mean Jeff, which bug would you like me to look at |
| 18:14.20 | JeffM2501 | Runic, I don't know |
| 18:14.32 | JeffM2501 | I don't know what is preventing the release |
| 18:14.42 | JeffM2501 | and I can not tell you what to do |
| 18:14.45 | Runic | to me mx bump has always been broken, aka a bug |
| 18:15.01 | JeffM2501 | yeah and I agreed that it should be fixed |
| 18:15.15 | JeffM2501 | the feature of adding bump height per object is what I am saying is a new feature |
| 18:15.24 | JeffM2501 | and that should be held off. |
| 18:15.37 | Runic | yes, and I haven't looked at doing that at all |
| 18:15.48 | JeffM2501 | e4k |
| 18:16.02 | JeffM2501 | ok |
| 18:16.10 | JeffM2501 | sorry, sillycat :) |
| 18:16.46 | Runic | no point in doing that until max bump works |
| 18:16.57 | JeffM2501 | that is agreed |
| 18:17.04 | BulletCatcher | http://my.bzflag.org/w/V3RCChecklist is still the best list we have for things to do before the release. |
| 18:17.12 | JeffM2501 | I think there is no point in doing that untill after V3 shipps :) |
| 18:22.14 | BulletCatcher | The TODO file lists other important things as well. |
| 18:24.22 | JeffM2501 | I just think that getting something out should be your main goal now |
| 18:27.30 | BulletCatcher | My main goal is to release a 3.0 that has a reasonable chance of enticing most players to upgrade from 2.0. I don't want to risk splitting the player community. |
| 18:27.49 | JeffM2501 | then you have another 6 years of work IMHO |
| 18:28.33 | JeffM2501 | the expectation of V3 was that it was going to be "cheat proof" and little was done on that front |
| 18:28.48 | JeffM2501 | so unless a lot more is done you won't satisfy that requrement |
| 18:29.07 | JeffM2501 | if you are ok with dispaointng them on that front you have enough in there now to get most people to swap |
| 18:29.17 | JeffM2501 | at least the server owners will and the rest will follow. |
| 18:29.31 | JeffM2501 | there will always be some split, it happens at major releases |
| 18:29.50 | JeffM2501 | usualy the old version peteres out after some months |
| 18:30.35 | BulletCatcher | We still have some gameplay problems that make *me* prefer 2.0, so I don't expect others to be content with the current trunk state. |
| 18:30.58 | JeffM2501 | sure those are bugs |
| 18:31.07 | JeffM2501 | and it should be at least as playable as v2 |
| 18:31.21 | BulletCatcher | But I do understand that there will be some community splitting during even the best post-release transition. |
| 18:31.34 | JeffM2501 | the -a thing will be the biggest deal for em |
| 18:32.00 | BulletCatcher | -a really only affects server ops. They'll deal with it quickly. |
| 18:32.23 | JeffM2501 | no, it affects ow tanks move |
| 18:32.30 | JeffM2501 | it's on by default now |
| 18:32.37 | JeffM2501 | most server ops won't change the default |
| 18:32.47 | JeffM2501 | that means that how tanks "feel" on every server will change |
| 18:32.54 | JeffM2501 | and that they will be unhappy about |
| 18:33.07 | BulletCatcher | Server ops will change it if they want their maps to be popular. :-) |
| 18:33.26 | JeffM2501 | leaving it on actualy makes for a more consistent game |
| 18:33.41 | JeffM2501 | helps smooth out the advantage of having a supper twitchy mouse |
| 18:33.52 | BulletCatcher | I don't think we can stuff that genie back into the bottle. |
| 18:33.53 | JeffM2501 | but time will tell |
| 18:33.57 | JeffM2501 | nope |
| 18:33.59 | JeffM2501 | nor should we |
| 18:34.04 | JeffM2501 | tanks should have acceleration |
| 18:34.08 | JeffM2501 | it just makes sense |
| 18:34.36 | BulletCatcher | Our tanks can jump, even though it doesn't make sense. |
| 18:34.42 | blast007 | and fly |
| 18:34.44 | blast007 | ;) |
| 18:34.46 | JeffM2501 | rockets ;) |
| 18:34.55 | blast007 | although Wings is a bit more sane now |
| 18:34.58 | JeffM2501 | at least they do so with non instantanious physics |
| 18:35.11 | blast007 | no more jumping off tall buildings and jumping just before you hit the ground |
| 18:35.24 | blast007 | flapping just* |
| 18:35.54 | BulletCatcher | Even that is a server option. |
| 18:36.02 | blast007 | no |
| 18:36.14 | blast007 | they can increase the flaps |
| 18:36.19 | blast007 | but they can't make it work like it used to |
| 18:36.42 | JeffM2501 | some ammount of gameplay should be designed into bzflag, not left up to the server owner ;) |
| 18:36.48 | JeffM2501 | bzflag is not a sandbox |
| 18:36.50 | BulletCatcher | I thought the minimum number of frames on the ground could be set to zero. |
| 18:36.51 | blast007 | the client itself was changed so that the wings jump speed was added to the current Z velocity, not just set |
| 18:37.08 | BulletCatcher | Oh, *that* change. |
| 18:37.11 | JeffM2501 | BulletCatcher, I belive that makes it go after the next frame, before it could go on the same frame |
| 18:38.18 | blast007 | Runic: regarding the InAir stuff - why does bumping up cause the tank to be "in the air"? |
| 18:38.26 | blast007 | cuz I would think *that* would be a bug |
| 18:38.28 | JeffM2501 | my problem with letting the server owner/mapper do anything is that a player does not know what to expect when they join |
| 18:38.38 | JeffM2501 | and bzflag dosn't help you play itself |
| 18:38.42 | blast007 | JeffM2501: *cough*lua*cough* |
| 18:38.45 | blast007 | so kinda moot now ;) |
| 18:38.56 | JeffM2501 | no it just means that there is yet another abbuse |
| 18:39.01 | blast007 | hehe |
| 18:39.03 | JeffM2501 | I mean the API could do a lot of odd things |
| 18:39.26 | BulletCatcher | blast007, he want's to add non-instantaneous large bumps (for a height of 10, say). |
| 18:39.26 | JeffM2501 | I think the advantages of lua can outweight it's confusions |
| 18:39.29 | JeffM2501 | just like the API |
| 18:39.53 | blast007 | BulletCatcher: no, I'm talking about the fact that he doesn't like the InAir check because now it doesn't work as well |
| 18:40.13 | JeffM2501 | but putting a bunch of stuff as command line options is just telling the server owner "yeah do this, it's cool" |
| 18:40.14 | blast007 | seems like when you bump up you might be set to "in air" |
| 18:40.28 | blast007 | and then it delays the driving up of another bump |
| 18:40.55 | Runic | if you want me to be able to correct the warp speed bump to top of obstacle the tank maybe be inAir during this bump to top |
| 18:41.12 | blast007 | Runic: not necessarily |
| 18:41.19 | blast007 | nothing says you can't add another state |
| 18:41.30 | blast007 | as in, "Climbing" instead of "InAir" ;) |
| 18:41.51 | Runic | true, I haven't look at add a state |
| 18:42.02 | *** join/#bzflag R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 18:42.02 | Runic | *adding |
| 18:42.17 | BulletCatcher | wants a "pwning" state |
| 18:42.20 | JeffM2501 | protocoll breaking time is the time to add states |
| 18:43.44 | BulletCatcher | Yeah, so if we are going to go that way then do it now or wait until 3.1. |
| 18:43.55 | JeffM2501 | nope, 4.0 |
| 18:44.08 | JeffM2501 | proto breaks == major v change in the new system :) |
| 18:44.48 | BulletCatcher | Are there any cirsumstances where we would have a .1 release? Or will we relase a compatible 3.1 instead of 3.0.1? |
| 18:45.01 | JeffM2501 | nothing says you can't ship v4 way after v3 |
| 18:45.09 | JeffM2501 | you should NEVER have a .1 release of anything |
| 18:45.14 | JeffM2501 | odds are dev |
| 18:45.26 | JeffM2501 | a maint release for 3.0.0 would be 3.0.2 |
| 18:45.36 | JeffM2501 | a compatable release with new features would be 3.2.0 |
| 18:45.44 | JeffM2501 | an incompatable release would be 4.0.4 |
| 18:45.58 | blast007 | 4.0.4 BZFlag Not Found |
| 18:46.08 | JeffM2501 | 3.0.2 would be like for little critical bugs, or packaging issues |
| 18:46.29 | BulletCatcher | The webmaster at work used to be in room 404. |
| 18:46.41 | JeffM2501 | new graphics or hud, or auto reg and stuff like that would go into 3.2.0 |
| 18:47.09 | JeffM2501 | but a new message, one where you could not play unless you had the same procoll would be a major version change. |
| 18:47.23 | JeffM2501 | at least that was the plan with the new numbering system |
| 18:47.33 | JeffM2501 | the one that took 2.2 to 3.0 |
| 18:52.10 | BulletCatcher | I'll update the DEVINFO file with those details. |
| 18:52.31 | JeffM2501 | it should be on the wiki |
| 18:52.37 | trepan | <+blast007> JeffM2501: *cough*lua*cough* -- at least you tell if server's supply lua scripts (in the server list) |
| 18:52.45 | JeffM2501 | yeah that's a good thing |
| 18:52.51 | JeffM2501 | I think it'd be nice to do the same thing for plugins |
| 18:53.06 | JeffM2501 | or just remove the C API |
| 18:53.09 | trepan | always allow /listplugins ? |
| 18:53.23 | JeffM2501 | users should not have to run a command |
| 18:53.33 | JeffM2501 | the list server should just have a "moded" flag |
| 18:53.40 | trepan | have a UsingPlugins bit? |
| 18:53.43 | JeffM2501 | then something when they join to list the mods if they want |
| 18:53.46 | JeffM2501 | sure |
| 18:53.50 | trepan | basically every server would have it |
| 18:54.02 | JeffM2501 | yeah I'm not sure if that is enough granularity |
| 18:54.21 | JeffM2501 | really you want to tell them "some crap is going to be different here and it affects you" |
| 18:54.32 | JeffM2501 | not sure how to go about that |
| 18:54.42 | BulletCatcher | Would it be enough to automatically show the output of /listplugins at join time? |
| 18:54.47 | JeffM2501 | kinda like how UT had it's set of plugins that were "mutilators" |
| 18:55.03 | trepan | BulletCatcher: as a client-side option? |
| 18:55.16 | BulletCatcher | No, just have the server always do it. |
| 18:55.30 | JeffM2501 | BulletCatcher, http://my.bzflag.org/w/Versions that was updated to the new versioing system IIRC |
| 18:56.00 | trepan | BulletCatcher: again, with luaServer, that becomes a moot point |
| 18:56.48 | trepan | the bzfs C side doesn't really know (or care), what plugins/modules are being run in lua space |
| 18:59.56 | BulletCatcher | In other words, in trunk there are even more ways than in 2.0.x to change gameplay. |
| 18:59.57 | BulletCatcher | The question seems to be: how do we inform players of those changes without overloading them with too much data? |
| 19:00.44 | BulletCatcher | I admit that I was very frustrated on one map until I figured out that shotsKeepVerticalVelocity was enabled. |
| 19:02.35 | JeffM2501 | most games don't have as many options as bzflag ;) |
| 19:03.01 | JeffM2501 | for a simple FPS it can be made rather complex |
| 19:04.50 | trepan | BulletCatcher: worst yet, LuaRules (sourced from the server, executed on the clients), provides yet another mechanism for adjusting game play |
| 19:05.28 | JeffM2501 | can it haxorz the boxorz? |
| 19:05.59 | trepan | it's in its own script boxorz, no haxorz to the hwz |
| 19:06.11 | JeffM2501 | no file access? |
| 19:06.24 | trepan | limited VFS file access |
| 19:06.41 | JeffM2501 | can it access the client config? |
| 19:06.45 | trepan | the default lua `io' library has been removed |
| 19:06.49 | JeffM2501 | that's good |
| 19:08.22 | JeffM2501 | it would suck to have a password stealin server :) |
| 19:08.34 | trepan | ya, BZDB access is also limited |
| 19:14.29 | BulletCatcher | Group membership can also affect the player experience. |
| 19:14.31 | BulletCatcher | Since it would be impractical to give a complete picture of server customizations, I think we just need to carefully choose the few that we will shove in player faces. |
| 19:16.10 | BulletCatcher | Making it possible for an educated player to list most of the other customizations would finish the job. |
| 19:30.22 | Runic | blast007: I have a few maps up now |
| 19:31.48 | Runic | know that these map expose bugs still in the current trunk |
| 19:33.41 | *** join/#bzflag me1 (~ausom@bzflag/player/Me1) |
| 19:40.00 | blast007 | k |
| 19:41.28 | *** join/#bzflag bryjen (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 19:41.28 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 19:44.23 | *** join/#bzflag bryjen_ (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 19:45.17 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 20:03.53 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-125-36.wi.res.rr.com) |
| 20:03.53 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 21:08.05 | CIA-87 | BZFlag: 03Bullet Catcher 07http://my.bzflag.org * r7097 10/w/Versions: /* Released versions of BZFlag */ add 2.0.16 to the list |
| 21:31.20 | *** join/#bzflag temporalD (~ATD@bzflag/serverop/TemporalDistraction) |
| 21:52.30 | *** join/#bzflag Atluxity (~atluxity@wikipedia/Atluxity) |
| 22:00.05 | *** join/#bzflag xaver__ (~xaver@pD9ED3FBE.dip.t-dialin.net) |
| 22:53.18 | *** join/#bzflag bryjen (~bryjen@cpe-75-81-201-131.we.res.rr.com) |
| 22:53.18 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 23:37.18 | *** join/#bzflag xwissen (~xaver@pD9ED5775.dip.t-dialin.net) |