| 00:03.48 | McSpider | yep, and it is calling isKillable so it must be going wrong somewhere else. |
| 00:32.37 | moiree | This line in isKillable() |
| 00:32.41 | moiree | if (World::getWorld()->allowTeamKills() && target->getTeam() != myTank->getTeam()) |
| 00:33.48 | JeffM | does allowTeamKills check the game type? |
| 00:34.02 | McSpider | nope |
| 00:34.03 | moiree | Perhaps || instead of && would be better? |
| 00:34.11 | JeffM | yeah probably |
| 00:34.32 | JeffM | tho it should easy out for openFFA, everyone is killable ;) |
| 00:46.44 | CIA-103 | BZFlag: 03trepan * r21873 10/branches/experimental/v2_99continuing/bzflag/misc/indent.sh: * using a custom astyle exec, no need to version check it |
| 00:50.15 | trepan | JeffM: you still ok with moving *.h's next to their *.cpp's (and out of include when applicable?) |
| 01:06.12 | JeffM | yeah I think that's a good idea |
| 01:06.49 | trepan | i'll setup a script to do it, and what'll be left in include/ |
| 01:07.29 | trepan | would use TOP/src as an include dir, so you'd do #include "common/TextUtils.h" in 3.0 |
| 01:08.23 | trepan | s/and what'll/and see what'll/ |
| 01:28.09 | CIA-103 | BZFlag: 03trepan * r21874 10/branches/experimental/v2_99continuing/bzflag/ (41 files in 2 dirs): |
| 01:28.09 | CIA-103 | BZFlag: * removed all the 'using std::' from src/lua |
| 01:28.09 | CIA-103 | BZFlag: * removed the LuaParser files |
| 01:29.02 | trepan | there is an ulterior motive to that grindage ;) |
| 01:50.12 | *** join/#bzflag bwd (~me@pdpc/supporter/student/bdotson) |
| 02:10.54 | *** join/#bzflag BlasterWisconsin (~blasterwi@CPE-72-131-125-36.wi.res.rr.com) |
| 02:10.54 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 02:19.29 | *** part/#bzflag bwd (~me@pdpc/supporter/student/bdotson) |
| 02:34.45 | *** join/#bzflag JeffM1 (~Jeff@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
| 02:46.00 | TD-Linux | trepan is converting bzflag to pure C, the language of the gods |
| 02:46.39 | trepan | is actually going the other way |
| 02:53.30 | *** join/#bzflag GransRemedy (~john@121-79-204-29.sta.inspire.net.nz) |
| 03:01.01 | JeffM | bzflag started in pure c |
| 03:13.49 | CIA-103 | BZFlag: 03trepan * r21875 10/branches/experimental/v2_99continuing/bzflag/src/ (10 files in 2 dirs): |
| 03:13.49 | CIA-103 | BZFlag: * initial files for scripted worlds |
| 03:13.49 | CIA-103 | BZFlag: (not wired into the build system, still pretty rough) |
| 03:14.50 | trepan | once done, all the bzfs/Custom*, bzfs/WorldFile*, and ObstacleM* files disappear |
| 03:14.58 | trepan | that's a large chunk from bzfs/ |
| 03:15.59 | trepan | also, box, base, pyramid, teleporter, arc, cone, sphere, and tetra files go away |
| 03:17.12 | TD-Linux | are you actually getting rid of bzw format now? |
| 03:17.36 | trepan | no, but the native format will be a lua script (see src/world/bzworld.lua) |
| 03:18.04 | TD-Linux | oh can you use a lua script to interpret bzw? |
| 03:18.45 | trepan | easily |
| 03:19.08 | trepan | http://lua-users.org/wiki/LpegRecipes -- I've already included the lpeg code in bz's lua library |
| 03:19.12 | JeffM | the idea is to have the game treat everything the same |
| 03:19.28 | TD-Linux | could do OBJ parsers etc too I suppose |
| 03:19.35 | trepan | JeffM: that's the side benefit of doing the rewrite |
| 03:19.36 | JeffM | anything that generates faces |
| 03:19.58 | JeffM | trepan, for you a side benifit for the rest of the project a huge simplification |
| 03:19.58 | TD-Linux | "treating everything the same" == always use meshes, yes? |
| 03:20.05 | JeffM | faces are faces |
| 03:20.19 | trepan | note the new WorldManager file, it'll be used for server and client, and will refactor some of the collision stuff |
| 03:20.37 | JeffM | as it should |
| 03:20.54 | TD-Linux | do you plan to do all collisions like meshes, or still have simplified box / sphere / etc models? |
| 03:21.06 | trepan | also, box, base, pyramid, teleporter, arc, cone, sphere, and tetra files go away <<-- |
| 03:21.12 | JeffM | why would you want or need to do things different for boxes? |
| 03:21.23 | JeffM | if you can do it for a mesh face you can do it for anything |
| 03:21.25 | TD-Linux | simpler / faster collision code |
| 03:21.36 | JeffM | not nessisarly simpler |
| 03:21.40 | trepan | that's true, but not terribly important |
| 03:21.45 | JeffM | yeah |
| 03:21.53 | TD-Linux | that's the reason bullet / ode have all sorts of collision objects |
| 03:21.57 | trepan | the octree is a _major_ factor for coldet testing |
| 03:22.01 | TD-Linux | but they also do much more complex math than bz |
| 03:22.08 | JeffM | TD-Linux, but quake does not ;) |
| 03:22.30 | trepan | TD-Linux: bz's sim is also fairly simplistic at the moment, low object counts |
| 03:22.43 | trepan | RTS's have thousands of objects, so there it matters |
| 03:22.44 | TD-Linux | yup, and the only moving objects are user controlled tanks |
| 03:22.52 | TD-Linux | just not going through things is sufficient |
| 03:22.54 | trepan | bz has 10 tanks, and a few shots :) |
| 03:23.05 | TD-Linux | bullet and ode have to do full rigid body dymanics, something bzflag tanks do not follow :P |
| 03:23.23 | TD-Linux | e.g. torque |
| 03:23.30 | trepan | well down the road, bullet or ODE could be plugged in |
| 03:23.51 | trepan | but that'll be easier if bz's code is simpler |
| 03:24.28 | TD-Linux | are you going to want all data included in lua file, or have a world that's a lua file + other data bundled in a container? |
| 03:25.01 | trepan | my plan allows for URL's to be included |
| 03:25.27 | trepan | this does not include bundled textures, just source code (lua or bzw or obj or xml or ...) |
| 03:26.56 | TD-Linux | why not make it the same as URLs? |
| 03:26.58 | trepan | of course a .blender file or a collaba binary could be torn apart as well :) |
| 03:26.59 | TD-Linux | err |
| 03:27.02 | TD-Linux | same as images? |
| 03:27.10 | TD-Linux | and use the image cache system? |
| 03:27.23 | trepan | part of the caching will be the same |
| 03:27.56 | trepan | but there are more stringent requirements as to how a script has to be setup so that it always generates the same calls |
| 03:28.18 | trepan | plugin objects and the like are going to bit of a pain |
| 03:28.39 | JeffM | or just have the server generate the map and send the meshed up version compressed to the clients |
| 03:28.51 | JeffM | no big whup if the clients don't have the script |
| 03:29.17 | trepan | na, i'm doing split script fetches to minimize transfers |
| 03:29.38 | TD-Linux | can you then use the same script continuously running client side to implement magic features? |
| 03:29.46 | trepan | you could have multiple folks using a large mesh, but only altering their top level script |
| 03:29.56 | JeffM | curous how much time that would save if the world wasn't sent over the in game message system |
| 03:30.17 | trepan | TD-Linux: huh? |
| 03:30.33 | TD-Linux | like don't have the script generate the world on the client, and then stop |
| 03:30.44 | JeffM | huh? |
| 03:30.50 | trepan | that's what LuaWorld is for |
| 03:31.04 | TD-Linux | different script for runtime stuff? |
| 03:31.08 | TD-Linux | why not use the same one? |
| 03:31.30 | trepan | because i like the separation of script and world definition |
| 03:31.44 | JeffM | scrips are actions worlds are things ;) |
| 03:31.54 | JeffM | scripts may happen for a number of actions or events |
| 03:31.59 | JeffM | and modify worlds |
| 03:32.14 | JeffM | one action just happens to be "fill out empty world" |
| 03:32.47 | trepan | fwiw, .bzw can already contain LuaServer plugins in 3.0 |
| 03:32.59 | trepan | it could forward that to LuaWorld (althouh I haven't tried it) |
| 03:33.42 | trepan | but i don't want to see OpenGL calls in most .lua worlds, keep it separate, keep it simple |
| 03:37.32 | CIA-103 | BZFlag: 03bthansen * r21876 10/trunk/bzflag/misc/bzfquery.py: Update python query script for new protocol |
| 03:37.41 | CIA-103 | BZFlag: 03bthansen * r21877 10/trunk/bzflag/misc/bzfquery.pl: Update perl query script for new protocol |
| 03:44.00 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 03:55.34 | CIA-103 | BZFlag: 03bthansen * r21878 10/trunk/bzflag/misc/ (bzfquery.pl bzfquery.py): Fix game style reporting for query scripts |
| 04:17.53 | *** join/#bzflag bleach (bleach@osama.destroyislam.org) |
| 04:41.13 | CIA-103 | BZFlag: 03trepan * r21879 10/branches/experimental/v2_99continuing/bzflag/src/world/ (LuaTable.cpp LuaTable.h WorldScript.cpp bzworld.lua): * fixed the LuaTable member templates |
| 04:42.24 | CIA-103 | BZFlag: 03trepan * r21880 10/branches/experimental/v2_99continuing/bzflag/src/game/BzMaterial.cpp: * prepend 'indent' to printColor() output for materials |
| 04:51.02 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 05:17.48 | *** join/#bzflag jcp|alive (~boydam@bzflag/contributor/javawizard2539) |
| 05:39.10 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 05:40.15 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 05:40.15 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 06:06.22 | *** join/#bzflag Marzipan- (~Marzipan@p5B227EDF.dip.t-dialin.net) |
| 06:07.56 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:30.10 | *** join/#bzflag ts_ (~ts@BZ.BZFLAG.BZ) |
| 07:43.10 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 07:43.10 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 07:43.10 | *** join/#bzflag Gilly (~btw@about/essy/ilkimys/gilly) |
| 07:43.10 | *** join/#bzflag Manu (~jujibo@BZ.BZFLAG.BZ) |
| 07:43.10 | *** join/#bzflag jcp|alive (~boydam@bzflag/contributor/javawizard2539) |
| 07:43.10 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:43.11 | *** join/#bzflag bleach (bleach@osama.destroyislam.org) |
| 07:43.11 | *** mode/#bzflag [+vvv joevano trepan Manu] by anthony.freenode.net |
| 07:43.21 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 07:43.21 | *** join/#bzflag Gabe_G23 (u557@bzflag/player/GabrielG) |
| 07:43.32 | *** join/#bzflag BlasterWisconsin (~blasterwi@unaffiliated/blaster-wisconsi/x-3628685) |
| 07:43.32 | *** join/#bzflag sam (sam@poulet.zoy.org) |
| 07:43.50 | *** join/#bzflag nhOmega (ruskie@goatse.co.uk) |
| 07:43.50 | *** join/#bzflag brad`_ (~brad@uk.moooo.org) |
| 07:43.50 | *** join/#bzflag zomane (~zarine@zumane.pppoe.fiber-lan.eu) |
| 07:43.50 | *** join/#bzflag sirquine (~quine@adsl-75-37-33-191.dsl.pltn13.sbcglobal.net) |
| 07:43.50 | *** join/#bzflag brad (~brad@stupid.h-o-s-t.name) |
| 07:43.50 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 07:43.52 | *** join/#bzflag Constitution (~const@bzflag/developer/Constitution) |
| 07:43.52 | *** join/#bzflag ahs3- (~ahs3@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 07:43.52 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
| 07:43.52 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 07:44.14 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 07:44.14 | *** join/#bzflag delusional (~delusiona@unaffiliated/delusional) |
| 07:44.14 | *** join/#bzflag dcat (~dcat@c-98-249-63-154.hsd1.va.comcast.net) |
| 07:44.14 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 07:44.14 | *** join/#bzflag fahadsadah (fahad@unaffiliated/fahadsadah) |
| 07:44.14 | *** join/#bzflag cygal (~cygal@wtf.awesom.eu) |
| 07:44.14 | *** join/#bzflag DarkCalf (DC@173.231.40.98) |
| 07:44.14 | *** join/#bzflag Nitroxis (~nitroxis@2a01:4f8:7d:200:0:4e2f:b550:3) |
| 07:44.30 | *** join/#bzflag Chestal (thilo@141.99.42.43) |
| 07:44.30 | *** join/#bzflag Quol_away (~Quol@69.90.0.146) |
| 07:44.30 | *** mode/#bzflag [+o Chestal] by anthony.freenode.net |
| 07:44.50 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 07:46.01 | *** join/#bzflag cods (~cods@tuxee.net) |
| 07:47.25 | *** join/#bzflag cods (~cods@rsbac/developer/cods) |
| 07:49.01 | *** join/#bzflag meeba_ (~lamer@c-24-8-181-169.hsd1.co.comcast.net) |
| 07:49.01 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 07:49.01 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 07:49.01 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 07:49.01 | *** mode/#bzflag [+o GvzEvxre] by anthony.freenode.net |
| 07:49.40 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 07:49.40 | *** join/#bzflag Gabe_G23 (u557@bzflag/player/GabrielG) |
| 07:49.53 | *** join/#bzflag nhOmega (ruskie@goatse.co.uk) |
| 07:49.53 | *** join/#bzflag brad`_ (~brad@uk.moooo.org) |
| 07:49.54 | *** join/#bzflag zomane (~zarine@zumane.pppoe.fiber-lan.eu) |
| 07:49.54 | *** join/#bzflag sirquine (~quine@adsl-75-37-33-191.dsl.pltn13.sbcglobal.net) |
| 07:49.54 | *** join/#bzflag brad (~brad@stupid.h-o-s-t.name) |
| 07:49.54 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 07:50.20 | *** join/#bzflag jcp|alive (~boydam@bzflag/contributor/javawizard2539) |
| 07:50.46 | *** join/#bzflag nhOmega (ruskie@sourcemage/mage/ruskie) |
| 08:18.29 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:19.24 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:26.37 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 09:04.27 | *** join/#bzflag Upsetter (~er@88.130.189.135) |
| 12:01.22 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 13:01.28 | *** join/#bzflag Marzipan- (~Marzipan@p5B227EDF.dip.t-dialin.net) |
| 13:10.10 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 13:31.03 | delusional | are we still staying with SDL 1.2.14? or should I upgrade to 1.3 or above? |
| 13:31.13 | delusional | {mac} |
| 13:42.58 | blast007 | looks like it just needs at least 1.2.10, but should also work with 1.3 (I see checks for that too) |
| 13:44.12 | blast007 | unless I'm not reading the configure.ac logic right |
| 14:20.17 | delusional | last time I tried 1.3 it didnt work, had to revert.. |
| 14:32.48 | *** join/#bzflag bier (~bier@p54A5B150.dip.t-dialin.net) |
| 14:33.20 | *** join/#bzflag bier|tp (~bier@p54A5B150.dip.t-dialin.net) |
| 15:16.20 | *** join/#bzflag moiree (~moiree@dslb-084-059-050-135.pools.arcor-ip.net) |
| 15:43.46 | *** join/#bzflag ts (~ts@bzflag/developer/ts) |
| 15:44.05 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 16:23.29 | *** join/#bzflag ahs3- (~ahs3@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 16:56.52 | CIA-103 | BZFlag: 03trepan * r21881 10/branches/experimental/v2_99continuing/bzflag/other_src/premake4_ftgl.lua: * stripped the '-debug' suffix from libftgl-debug.a |
| 17:15.11 | *** join/#bzflag meeba (~lamer@c-24-8-181-169.hsd1.co.comcast.net) |
| 17:18.06 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 17:26.59 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 17:26.59 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 17:28.11 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 17:31.09 | CIA-103 | BZFlag: 03trepan * r21882 10/branches/experimental/v2_99continuing/bzflag/src/ (14 files in 6 dirs): |
| 17:31.09 | CIA-103 | BZFlag: * in WorldManager.h, renamed WORLD_OBJECTS_H to WORLD_MANAGER_H |
| 17:31.09 | CIA-103 | BZFlag: * added the 'struct ZoneData' to MeshFace::SpecialData |
| 17:31.09 | CIA-103 | BZFlag: * added the 'struct WeaponData' to MeshObstacle |
| 17:31.10 | CIA-103 | BZFlag: * started to parse drawInfos in WorldScript.cpp |
| 17:31.10 | CIA-103 | BZFlag: * added 'libWorld' to the bzfs premake4.lua, and some test code |
| 17:31.11 | CIA-103 | BZFlag: (autotools build is probably broken at the moment) |
| 17:31.46 | *** join/#bzflag Anxuiz (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |
| 17:31.46 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 17:32.34 | CIA-103 | BZFlag: 03trepan * r21883 10/branches/experimental/v2_99continuing/bzflag/src/bzfs/bzfs.cpp: * removed the WorldScript test code from bzfs.cpp |
| 17:43.42 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 17:43.42 | *** mode/#bzflag [+o GvzEvxre] by anthony.freenode.net |
| 17:52.46 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 18:04.49 | blast007 | JeffM: on windows, should the configuration files be stored under the roaming app profile location instead of local settings? afaik, only stuff like temporary files/cache goes into the local settings normally, while persistent configuration goes into the roaming (non-local) location |
| 18:05.09 | JeffM | we mix the 2 |
| 18:05.20 | JeffM | I can put it in roaming if you want |
| 18:05.34 | JeffM | think anyone actualy roams? |
| 18:05.44 | JeffM | and if they did would they want the same graphics settings? |
| 18:07.26 | blast007 | not sure |
| 18:07.41 | blast007 | maybe that could just remain the way it is for now |
| 18:07.47 | blast007 | wasn't thinking about the graphics settings |
| 18:08.01 | JeffM | yeah to do it windows "proper" we should split stuff up |
| 18:08.04 | blast007 | might make sense to split the configuration files later |
| 18:08.05 | blast007 | yeah |
| 18:08.18 | JeffM | I don't think many if any people roam |
| 18:08.25 | JeffM | so local is good enough untill we split it out |
| 18:08.39 | blast007 | ok |
| 18:09.20 | JeffM | even on linux or a mac some settings like graphics should be machine wide I'd think |
| 18:09.40 | blast007 | I suppose the roaming stuff only applies when in a domain? or is there other times it would get synced across systems? |
| 18:09.52 | JeffM | it's a domain thing |
| 18:09.59 | JeffM | for going from one computer to another |
| 18:10.16 | JeffM | if the domain admin allows it |
| 18:10.25 | JeffM | roaming is off in default domain setups |
| 18:22.33 | CIA-103 | BZFlag: 03trepan * r21884 10/branches/experimental/v2_99continuing/bzflag/src/premake4.lua: * added TOPDIR/src to the bzlib_project() includedirs |
| 18:22.41 | trepan | and now for the fun part :) |
| 19:05.24 | trepan | JeffM: would you want bzfsAPI.h to stay in include/, or change the plugins to use bzfs/bzfsAPI.h ? |
| 19:07.13 | trepan | (or have them use the bzfs/ dir as an include path) |
| 19:09.06 | JeffM | optimaly I'd like both bzfs and the plugins to use src/api :) |
| 19:09.13 | JeffM | then all the API stuff is in one place |
| 19:09.37 | JeffM | but I could deal with the bzfs dir if need be |
| 19:09.54 | trepan | as an include path, or bzfs/bzfsAPI.h? |
| 19:10.21 | JeffM | has to be include path |
| 19:10.31 | trepan | backwards compat? |
| 19:10.32 | JeffM | on windows we ship the headers |
| 19:10.41 | JeffM | they don't have source but can still build plugins |
| 19:10.52 | JeffM | there are multiple search paths including an environ var in the VC projects |
| 19:11.14 | JeffM | all you need is the headers and the libs |
| 19:11.18 | JeffM | and we ship those |
| 19:11.28 | trepan | could put the header in bzfs/bzfsAPI.h and still have them use bzfs/bzfsAPI.h |
| 19:11.37 | JeffM | they don't have that folder ;) |
| 19:11.40 | JeffM | cus they don't have source |
| 19:11.43 | trepan | mkdir :) |
| 19:11.52 | JeffM | I still prefer include paths |
| 19:12.15 | trepan | and so shall it be |
| 19:12.35 | JeffM | code should just say what it needs and not care where it is ;) |
| 19:12.45 | trepan | file goes into bzfs/bzfsAPI.h, plugins -Isrc/bzfs, and they still use #include "bzfsAPI.h" |
| 19:13.38 | JeffM | yep I can make that work on windows |
| 19:16.53 | trepan | does bzfio.h ship too? bzfscron/CronJob.cpp uses it |
| 19:18.03 | trepan | hm, but apparently doesn't need it |
| 19:18.43 | blast007 | plugins probably shouldn't be dependant on non-API parts of the bzflag code anyway |
| 19:18.53 | trepan | exactly |
| 19:20.09 | JeffM | for 2.4 we'll ship bzfsapi.h and pluginuits |
| 19:20.11 | JeffM | utils |
| 19:20.17 | JeffM | that should be the only things plugins need |
| 19:20.31 | JeffM | for 2.4.2 we'll add the bzfsHTTPAPI.h |
| 19:24.08 | TD-Linux | on *nix you can have a bzfs-devel package for building out of tree plugins |
| 19:25.10 | blast007 | TD-Linux: as of yet, I don't think (m)any distros have shipped binary packages with plugins since they were not turned on by default |
| 19:25.27 | blast007 | (so most/all have not even had plugin support in the bzfs binary) |
| 19:25.45 | TD-Linux | well that should be fixed too |
| 19:25.57 | TD-Linux | trunk has plugins on by default |
| 19:26.38 | TD-Linux | so 2.4 contains no new map features as far as I can tell ? |
| 19:27.20 | blast007 | there's per object ricochet, but I think that's all |
| 19:28.05 | trepan | yall backported that one, cool |
| 19:28.43 | TD-Linux | oh neat |
| 19:29.16 | TD-Linux | no more shot-trapping faces? :p |
| 19:29.44 | trepan | "Add ricochet on a per object basis for .bzw files - David Anderson" -- s/Add/backported/ |
| 19:35.41 | blast007 | TD-Linux: well, not sure if you can disabled it for a single object - might have to specify it for every object on the map |
| 19:35.55 | blast007 | (except the ones you don't want to rico) |
| 19:36.50 | trepan | yup, that's the way it works -- consistent with the rest of the .bzw format |
| 19:37.20 | trepan | .lua format does not suffer from that problem |
| 19:38.39 | trepan | should revisit the HG situation |
| 19:39.03 | trepan | SF+svn+crap-link = fail |
| 19:40.31 | CIA-103 | BZFlag: 03trepan * r21885 10/branches/experimental/v2_99continuing/bzflag/ (881 files in 47 dirs): |
| 19:40.32 | CIA-103 | BZFlag: * moved .h files next to their .cpp implementations |
| 19:40.32 | CIA-103 | BZFlag: - MSVC files were adjusted, would be nice if they still worked |
| 19:40.32 | CIA-103 | BZFlag: - autotools are probably not very happy, Makefile.am were not changed |
| 20:22.07 | *** join/#bzflag Upsetter1 (~er@i59F6A3B0.versanet.de) |
| 20:26.21 | blast007 | JeffM: well, I think I found the cause of the HTTP crash. It happens in the nethandler |
| 20:26.41 | blast007 | I think 'info' (which is a PlayerInfo object) is null |
| 20:26.50 | blast007 | so info->getCallSign() crashes and burns |
| 20:27.07 | blast007 | since HTTP instances would have a player associated with them |
| 20:27.12 | blast007 | wouldn't* |
| 20:38.21 | TD-Linux | there is currently no way to multitexture in bzflag, correct? |
| 20:40.32 | trepan | not in 2.4 -- but you can multipass, poorly |
| 20:43.56 | TD-Linux | how? |
| 20:44.37 | trepan | stack translucent faces |
| 20:45.00 | TD-Linux | ehh, it's hard to prevent z fighting then |
| 20:45.14 | trepan | yup, especially without polygonOffset |
| 20:45.35 | JeffM | blast007, ok cool you want to fix it? |
| 20:45.49 | trepan | TD-Linux: (something else that 3.0 has) |
| 20:46.16 | TD-Linux | just trying to figure out a clever way to bake AO |
| 20:46.55 | trepan | heh, lots of textures |
| 20:47.05 | TD-Linux | and huge textures |
| 20:47.45 | TD-Linux | AO always needs lots of textures, you can't really reuse them on multiple objects well, but they can be very low res |
| 20:49.25 | trepan | http://en.wikipedia.org/wiki/Screen_Space_Ambient_Occlusion |
| 20:51.55 | trepan | iirc, "jK" from SpringRTS wrote a piece of lua to do it, could port it to bz in a matter of minutes |
| 21:00.30 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 21:00.30 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 21:01.58 | TD-Linux | whoa that's an interesting method for doing it in real time |
| 21:02.16 | TD-Linux | it's completely incorrect of course, but AO is incorrect anyway |
| 21:02.41 | trepan | and we all know that two wrongs make a right, so it's a wash |
| 21:02.47 | JeffM | all computer graphics are tricks |
| 21:07.15 | TD-Linux | oh also, I know this has been brought up before, but: http://img689.imageshack.us/img689/5481/stdgroundmontage.png |
| 21:12.22 | CIA-103 | BZFlag: 03trepan * r21886 10/branches/experimental/v2_99continuing/bzflag/src/ (game/global.h include/global.h): * moved global.h back into include/ |
| 21:25.23 | JeffM | yeah.. that's a picture of the ground |
| 21:29.40 | TD-Linux | JeffM: one is 669kb the other is 150kb |
| 21:30.10 | JeffM | so |
| 21:30.48 | TD-Linux | PNG is not always the best solution |
| 21:31.00 | JeffM | the file isn't transfered |
| 21:31.15 | TD-Linux | no but map specific textures are |
| 21:31.20 | blast007 | TD-Linux: um, that's just PNG you gave |
| 21:31.21 | TD-Linux | I used that as an example |
| 21:31.22 | JeffM | now is not the time to be talking about changing image formats :) |
| 21:31.25 | blast007 | just a* |
| 21:31.34 | TD-Linux | blast007: I montaged it back into png for side by side |
| 21:31.40 | TD-Linux | yeah I know it's too late |
| 21:31.42 | JeffM | most of the PNGs came from my machine and PS dosn't do a good job of compression |
| 21:31.50 | JeffM | there is a tool to optimize them |
| 21:31.52 | blast007 | we could compress the PNGs further |
| 21:31.57 | blast007 | pngcrush and the like |
| 21:32.00 | TD-Linux | you aren't going to get 5x compression |
| 21:32.01 | JeffM | yeah |
| 21:32.02 | TD-Linux | maybe 5% |
| 21:32.05 | TD-Linux | less |
| 21:32.11 | JeffM | we don't need it ;) |
| 21:32.25 | TD-Linux | not for the game provided stuff |
| 21:32.32 | JeffM | but maybe we'll pick up other formats if/when we move to another engine |
| 21:32.38 | TD-Linux | but it'd be nice to make textures download a lot faster for maps |
| 21:32.52 | JeffM | it would be nice if clients could not ignore being shot |
| 21:33.03 | JeffM | but sure I understand your point |
| 21:33.24 | blast007 | TD-Linux: we're an online FPS game - we're not targeting people on dialup |
| 21:33.59 | trepan | and they are cached |
| 21:34.01 | blast007 | a typical youtube video would use more bandwidth than the typical bzflag map |
| 21:34.35 | TD-Linux | but given any particular target map size, I can basically do twice the horizontal and vertical resolution |
| 21:34.40 | TD-Linux | for images like that |
| 21:34.40 | JeffM | at least the images are sent over HTTP it's a lot faster then the map itself |
| 21:35.36 | TD-Linux | of course I imagine another option for that grass image is to do it 8bit :> |
| 21:35.40 | JeffM | jpeg can't do alpha IIRC |
| 21:36.03 | TD-Linux | no it can't |
| 21:36.12 | trepan | nor webp, yet (also, iirc) |
| 21:36.21 | TD-Linux | hence why you don't make jpeg the only format |
| 21:36.27 | trepan | the dx's can though |
| 21:36.34 | blast007 | I shaved off 8% by just running std_ground.png through some cheesy online PNG optimizer |
| 21:36.39 | trepan | and their compression is actually useful for GL |
| 21:36.43 | TD-Linux | I picked jpeg because the decoder library is small and fast |
| 21:36.55 | JeffM | yeah doing them all in card based formats would not be bad |
| 21:37.02 | blast007 | TD-Linux: and how large is our PNG decoder? :) |
| 21:37.02 | JeffM | most games ship em like that with imbeded mips |
| 21:37.03 | TD-Linux | S3TC etc? |
| 21:37.07 | JeffM | yeah |
| 21:37.32 | JeffM | still not something we should spend time on right now |
| 21:37.53 | blast007 | I don't see a point to spending time on it at all |
| 21:38.01 | trepan | most bz maps still tend to be box and pyr |
| 21:38.03 | blast007 | I'd rather not have a mix of image formats |
| 21:38.03 | JeffM | it is a minor thing |
| 21:38.09 | JeffM | yeah |
| 21:38.19 | blast007 | it would be the same if we supported multiple audio formats |
| 21:38.20 | JeffM | but there are other formats then PNG as trepan pointed out |
| 21:38.25 | blast007 | we'd have .ogg and .wav and whatever else |
| 21:38.33 | blast007 | just keep it simple |
| 21:38.51 | JeffM | if we go with openAL it gives you some formats for free |
| 21:38.52 | blast007 | we used to do the SGI .rgb format, and then moved to PNG in one swoop - we didn't keep a mix |
| 21:38.59 | JeffM | yep |
| 21:39.03 | trepan | hm, i saw some OGG stuff in 3.0, wonder if it works |
| 21:39.22 | TD-Linux | is OGG low enough latency for sound effects? |
| 21:39.23 | JeffM | 1.8 has a full ogg decoder for the old sound engine |
| 21:39.35 | JeffM | TD-Linux, you can cache them uncomparessed |
| 21:39.38 | JeffM | if it's an issue |
| 21:39.57 | blast007 | I know of other games that use OGG for audio |
| 21:39.58 | JeffM | effects aren't really long :) |
| 21:40.02 | JeffM | yeah many do |
| 21:40.53 | TD-Linux | I just checked, ogg supports gapless (mp3 actually needs the decoder to insert small unknown blank time at beginning) |
| 21:41.09 | *** part/#bzflag Upsetter1 (~er@i59F6A3B0.versanet.de) |
| 21:41.48 | blast007 | in any case, I see any change like that happening much later |
| 21:42.10 | JeffM | engine work is on the roadmap after getting sim fixed up |
| 21:42.15 | TD-Linux | so with the big protocol changes, 2.4 doesn't really address the whole shots-physics-etc on server does it? |
| 21:42.15 | blast007 | doubt it really has an impact on our package sizes since .wav probably compresses nicely with our installer file and source archives |
| 21:42.26 | JeffM | sim and networking are the big priorities for rewrites |
| 21:42.28 | blast007 | and .png, oh well. we don't have that much data. |
| 21:42.38 | JeffM | TD-Linux, god no |
| 21:42.48 | JeffM | that's part of the sim rewrite |
| 21:42.55 | JeffM | that's a huge project |
| 21:42.57 | blast007 | 2.4 is meant to be a low-risk release |
| 21:43.08 | JeffM | it is meant to save bzflag from death |
| 21:43.16 | JeffM | the project may not even survive it |
| 21:43.24 | JeffM | it was this or close up shop |
| 21:44.33 | JeffM | I do think we'll get this release out, the question will be is how motivated everyone will be for 2.4.2 and 2.4.4 |
| 21:44.44 | JeffM | if those fail then 3.0 is pointless |
| 21:45.31 | *** join/#bzflag KTL (~KTL@85.234.201.192) |
| 21:46.03 | blast007 | JeffM: as for fixing that problem, I'll probably just wrap that debug message in a null check - or should I be doing something more? |
| 21:46.10 | blast007 | the http problem |
| 21:46.13 | JeffM | naw that's fine |
| 21:46.17 | blast007 | ok |
| 21:46.27 | JeffM | I put other null checks in other places I guess I just missed one |
| 21:46.37 | blast007 | I'd still say we could probably wait until 2.4.2 to actually have HTTP plugins |
| 21:46.38 | JeffM | nethandler dosn't really NEED the player to do it's job |
| 21:46.41 | JeffM | yes |
| 21:46.56 | JeffM | or 2.4.4 if we have to push out a 2.4.2 for critial fixes |
| 21:47.10 | blast007 | yeah |
| 21:47.22 | JeffM | isn't planing fun :) |
| 21:53.56 | blast007 | yeah, fastmap doesn't even seem to work quite right. My map stops loading at 11516 bytes (2.5%) |
| 21:54.20 | blast007 | though I should make sure it's fastmap's fault, I suppose :) |
| 21:54.30 | JeffM | worry about it after release |
| 21:54.53 | blast007 | ah, there it finally finished. Seems like the client froze up while downloading the map file via HTTP. |
| 21:55.29 | blast007 | I'll test with just a normal -cacheout to my apache |
| 21:59.00 | blast007 | bleh, SF's SVN is sucking right now. Getting random SSL handshake errors. |
| 21:59.44 | trepan | yup, my latest commit been going for an hour or more |
| 22:07.40 | CIA-103 | BZFlag: 03blast007 * r21887 10/trunk/bzflag/src/game/NetHandler.cxx: Throw in a NULL check to prevent possible crashes when the debug level is set to 2 or higher. |
| 22:09.10 | trepan | after more than an hour: "SSL handshake failed: Secure connection truncated" |
| 22:09.45 | trepan | lovely, thank you SF |
| 22:20.17 | blast007 | yay, having the cache on apache with -cache works fine :) |
| 22:20.35 | blast007 | so just something with fastmap or the HTTP stuff in bzfs at that time |
| 22:53.55 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 22:57.24 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 23:17.09 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 23:45.16 | *** join/#bzflag smoooth (~smoooth@cpe-098-024-240-002.ec.res.rr.com) |
