| 00:02.43 | BulletCatcher | How big is that file, blast007? |
| 00:02.56 | blast007 | 178MB |
| 00:03.12 | BulletCatcher | That's not bad at all. |
| 00:07.04 | blast007 | svnsync on our repo take several hours |
| 00:07.07 | BulletCatcher | Got it. Thanks. |
| 00:07.12 | blast007 | :) |
| 00:07.22 | blast007 | sha1sum is 55a55b89b7ea5d0057302ce852c095cc2f994e9d if you want to verify |
| 00:07.50 | BulletCatcher | That matches. |
| 00:08.13 | blast007 | yay :) |
| 00:08.25 | BulletCatcher | gzip files include a 32-bit CRC for integrity checking, so I wasn't worried. |
| 00:08.51 | blast007 | ah |
| 00:09.13 | BulletCatcher | Run "gzip -lv" on the file to see it. |
| 00:13.35 | blast007 | syncing that once extracted is as simple as: svnsync sync file:///home/whatevs/bzflag-svn-sync |
| 00:28.57 | BulletCatcher | It looks good. Thanks again. |
| 00:58.22 | *** join/#bzflag _lmnop (~lmnop@p5DC4FEFC.dip0.t-ipconnect.de) |
| 01:07.24 | *** join/#bzflag Zac_ (ca59b013@gateway/web/freenode/ip.202.89.176.19) |
| 01:07.54 | *** join/#bzflag apeman (~Victor@214.241.69.111.dynamic.snap.net.nz) |
| 01:13.34 | *** join/#bzflag Notify (~notify@66-118-151-70.static.sagonet.net) |
| 01:15.52 | Zac_ | hi, i'm trying to establish a link between 2 teleporters |
| 01:16.10 | Zac_ | i have them in a group so they fit exactly with the walls but when i try to link them, it doesn't work |
| 01:22.41 | BulletCatcher | IIRC, links cannot be grouped. |
| 01:22.42 | BulletCatcher | That probably implies that you can't link grouped teleporters. |
| 01:24.38 | Zac_ | and links can't be established within groups |
| 01:24.51 | Zac_ | so, my teleporters just can't sit perfectly with the wall of the object? |
| 01:25.20 | BulletCatcher | You'll have to manually compute the teleporter locations. |
| 01:32.31 | JeffM_ | the issue is that a link can not be 'instanced' when you call the group |
| 01:32.45 | JeffM_ | putting a porter in the group would duplicate the name for each instance of the group |
| 01:32.51 | JeffM_ | and porter names need to be unique |
| 01:33.41 | JeffM_ | the 3d location of the teleporter is not the reason you can not link it |
| 03:01.23 | Zac_ | the problem is that i have a grouped object, and then i have rotated it 45 degrees |
| 03:01.34 | Zac_ | i want to place the teleporter in the archway |
| 03:01.45 | JeffM_ | then you get to do some math :) |
| 03:01.51 | Zac_ | >.< |
| 03:01.53 | JeffM_ | the postion is computable |
| 03:01.54 | Zac_ | never liked maths :p |
| 03:02.10 | JeffM_ | then computer science is not where you should be doing work :) |
| 03:02.56 | JeffM_ | 45 is pretty easy, the angle works out to .707 for both components of the vector |
| 03:03.31 | blast007 | carry the one.... it's over nine thousand! |
| 03:03.53 | JeffM_ | so if your teleporter was over in X 1 unit from the pivot point, it'd be at 0.707, 0.707 after rotation |
| 03:05.53 | JeffM_ | it could be possible to make links in the group work, as long as they didn't link to a teleporter in another group, we'd have to do some name fudgin |
| 03:06.25 | JeffM_ | basicly assume that the porter name is prefixed with the group name and instance ID, |
| 03:06.36 | JeffM_ | then you could even link to non grouped porteres |
| 03:06.45 | BulletCatcher | It might work if you put each named teleporter in a group by itself and duplicatate the position and rotation of the real group. |
| 03:06.55 | JeffM_ | but you could not link into a group from a porter since there could be multiple targets to choose from |
| 03:07.17 | JeffM_ | BulletCatcher, no you can't instance the porters and still reference them by name |
| 03:07.35 | JeffM_ | I belive we prevent that at the code level, even if there is only one instance |
| 03:07.59 | BulletCatcher | Do not duplicate the teleporter groups. Put each tele into its own "define" block. |
| 03:08.09 | BulletCatcher | Oh, ok. |
| 03:08.22 | JeffM_ | yeah you still have to instance it :) |
| 03:08.40 | JeffM_ | Zac_, http://www.siggraph.org/education/materials/HyperGraph/modeling/mod_tran/2drota.htm |
| 03:08.41 | BulletCatcher | It's worth a shot in case the code isn't that clever. |
| 03:08.47 | blast007 | or don't use name |
| 03:08.50 | JeffM_ | that's a very basic rundown of 2 rotation |
| 03:09.01 | JeffM_ | blast007, then it's by ID, and we have the same problem |
| 03:09.07 | JeffM_ | the IDs can't dupe |
| 03:09.23 | blast007 | wouldn't it make new IDs for each group? |
| 03:09.34 | JeffM_ | yeah and the links would not know the new IDs |
| 03:09.45 | blast007 | have the links outside of the define |
| 03:09.55 | JeffM_ | that's even worse |
| 03:10.05 | JeffM_ | they won't know the ID that gets created on instancing |
| 03:10.24 | blast007 | should be predictable though, no? |
| 03:10.29 | JeffM_ | BulletCatcher, if it dosn't work now, it wont' work with just porters in the group, it's not how many things in the group, it's the fact that the porters are grouped |
| 03:10.48 | Zac_ | hey, Jeff, thanks for working that for me :p |
| 03:10.49 | BulletCatcher | k |
| 03:10.52 | Zac_ | fits perfectly |
| 03:10.53 | blast007 | if you have four teleporters in the define, and you create four instances of that, wouldn't the first instance have 0 through 3, the second 4 through 7 and so on? |
| 03:10.57 | JeffM_ | blast007, maybe if we instance in the same order as they are called |
| 03:11.09 | JeffM_ | but again I think we prevent that in code |
| 03:11.18 | JeffM_ | as he found out, it's just math :) |
| 03:12.12 | blast007 | (and actually I'd be wrong anyways, because I think each side gets an index) |
| 03:12.23 | JeffM_ | yeah it'd get wierd |
| 03:16.38 | JeffM_ | I guess since we have random porter destinations now, it could be possible that links into a grouped porter would hit one of the random instances |
| 03:17.10 | JeffM_ | so, yeah I could conceive of a way to make grouped porters work in a consitent manner |
| 03:17.22 | JeffM_ | just would need more processing on the server side |
| 03:17.35 | JeffM_ | would probably even be binary compatable |
| 03:19.50 | blast007 | didn't 2.99.x have some improvement for grouped teleporters? |
| 03:20.22 | blast007 | besides the other awesome teleporter enhancements :) |
| 03:20.35 | JeffM_ | probably |
| 03:21.19 | BulletCatcher | 2.99.x is totally awesome, except for being unplayable. :-) |
| 03:21.45 | blast007 | the 2.99.x teleporter system could totally be used to recreate some portal like maps :P |
| 03:22.15 | blast007 | I had a simple world that launched you out of an angled box |
| 03:22.58 | blast007 | and another where two upward facing mesh faces were linked, so you'd fall down one and pop up out the second, then fall back down into that one ;) |
| 03:23.15 | blast007 | found out that there was a slight reduction in momentum over time |
| 03:23.31 | JeffM_ | yeah we apply a small resistance |
| 03:23.54 | BulletCatcher | Resistance is futile! |
| 03:24.33 | JeffM_ | for values less then 1 ohm |
| 03:24.45 | BulletCatcher | BTW, I was mistaken about Mercurial changesets. |
| 03:24.46 | BulletCatcher | They are simply called "commits" in Git. |
| 03:28.17 | Zac_ | jeff, how did you work out 0.707? |
| 03:28.28 | JeffM_ | it's the sine of 45 |
| 03:28.31 | Zac_ | how did you figure it out. |
| 03:28.32 | Zac_ | ok |
| 03:28.37 | JeffM_ | it's also the cosine of 45 |
| 03:28.45 | Zac_ | thanks |
| 03:28.47 | JeffM_ | trig is wierd that way ;) |
| 03:29.02 | JeffM_ | thats why I said 45 is easy, the components are the same |
| 03:29.23 | BulletCatcher | It's also one half of the square root of 2. |
| 03:29.26 | JeffM_ | other angles require you to get the sig and cosine set with the correct axis |
| 03:29.30 | Zac_ | ^_^ |
| 03:29.40 | JeffM_ | showing that physics is just applied math |
| 03:30.38 | JeffM_ | it's actualy, 0.70710678118654752440084436210485 |
| 03:30.49 | JeffM_ | but for BZs use 3 decimal places is fine |
| 03:31.35 | JeffM_ | that gets you below 1 mm tolerance |
| 03:31.53 | JeffM_ | if you assume 1wu = 1 meter |
| 03:31.59 | BulletCatcher | Not at the edge of a large map. :-) |
| 03:32.12 | JeffM_ | true there is error due to how we do stuff |
| 03:32.29 | JeffM_ | hence bsp's in cells:) |
| 03:32.35 | JeffM_ | fix all that right up |
| 03:37.27 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 07:44.32 | apeman | should bugs be posted on git or svn ? |
| 10:28.51 | *** join/#bzflag brad (~brad@cdn.v4.net) |
| 10:28.52 | *** join/#bzflag brad (~brad@unaffiliated/brad) |
| 11:07.36 | *** join/#bzflag _lmnop (~lmnop@p5DC4FEFC.dip0.t-ipconnect.de) |
| 11:19.11 | *** join/#bzflag Chestal (~thilo@141.99.42.43) |
| 11:19.11 | *** mode/#bzflag [+o Chestal] by ChanServ |
| 11:20.19 | *** join/#bzflag _lmnop (~lmnop@p5DC4E492.dip0.t-ipconnect.de) |
| 13:20.04 | *** join/#bzflag Zac_ (ca59b013@gateway/web/freenode/ip.202.89.176.19) |
| 13:20.32 | Zac_ | when a pyramid is raised of the ground, you can no longer slide around the base of it |
| 13:20.46 | Zac_ | is there some way to get around this? |
| 13:20.55 | Zac_ | i've got a raised map floor because of the water |
| 13:21.11 | Zac_ | so now tanks stick to the pyra's instead of sliding around the edge |
| 13:42.08 | blast007 | Zac_: tried placing an invisible box below it or around the bottom edge of it? |
| 13:49.12 | Zac_ | yeah ok |
| 13:49.14 | Zac_ | thanks blast |
| 14:00.11 | Zac_ | any other way? |
| 14:00.20 | Zac_ | because you can still get stuck on the corner |
| 14:08.08 | *** join/#bzflag JeffM_ (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 14:15.51 | BulletCatcher | Make the invisible box slightly larger than the base of the pyramid, Zac_. |
| 14:16.01 | Zac_ | i did |
| 14:16.12 | Zac_ | when you slide around the corner, you can still go through it and stick to the pyra. |
| 14:18.58 | BulletCatcher | How much larger did you make it? Somthing like +0.125 in each direction should be enough to avoid rounding problems. |
| 14:51.29 | Zac_ | i made it 0.1 |
| 14:51.32 | Zac_ | not enough? |
| 15:11.05 | *** join/#bzflag JeffM (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 15:11.05 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:11.05 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 15:14.40 | *** join/#bzflag _lmnop (~lmnop@p5B3FF9BA.dip0.t-ipconnect.de) |
| 15:29.00 | BulletCatcher | If the pyramid base is 10x10, make the box under it 10.25x10.25 so the difference on each side is 0.125. |
| 15:29.02 | BulletCatcher | Players shouldn't be able to detect that small of a difference, but it should be enough to keep the tank away from the pyramid in the computer's view. |
| 15:29.28 | BulletCatcher | And just to be sure: don't make the box drivethrough. :-) |
| 15:30.46 | BulletCatcher | (shootthrough is okay) |
| 15:33.42 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:33.42 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:36.42 | Zac_ | haha, thanks bc :) |
| 15:37.05 | Zac_ | and wouldn't the box be 10.125 rather than 10.25 because it extends both sides |
| 15:37.15 | Zac_ | aaaaa |
| 15:38.17 | Zac_ | because it extends 1 unit in both directions |
| 15:38.34 | Zac_ | or, o.125 of a unit in both directions. |
| 15:48.45 | JeffM | it'd be .125 for x and y |
| 15:48.59 | JeffM | since they are diamater values |
| 15:49.02 | JeffM | z is not |
| 15:51.23 | *** join/#bzflag unclelightning (~chatzilla@70.16.73.47) |
| 16:11.54 | blast007 | well would you look at that.. software from Sony that doesn't work right.. wonder how many rootkits I have now though. |
| 18:18.41 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 19:16.20 | *** join/#bzflag apeman (~Victor@214.241.69.111.dynamic.snap.net.nz) |
| 19:21.21 | apeman | will svn stuff like tickets be migrated to git, or cant that be done? |
| 19:25.08 | *** join/#bzflag apeman1 (~Victor@94.240.69.111.dynamic.snap.net.nz) |
| 20:08.21 | JeffM | apeman1, we will probably do them manualy |
| 20:08.29 | JeffM | the git ticket system is much better |
| 20:08.38 | JeffM | github I mean |
| 20:14.57 | blast007 | should new ones go straight to github though? |
| 20:34.40 | JeffM | I'd think so |
| 20:35.00 | JeffM | unless you convinced BulletCatcher to change to bitbucket |
| 20:37.08 | *** join/#bzflag mebigfatguy (~dave@128.177.74.185) |
| 21:29.56 | *** join/#bzflag Erroneous (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 21:29.56 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 21:45.09 | *** join/#bzflag Snake12534 (630ed9fa@gateway/web/freenode/ip.99.14.217.250) |
| 21:46.12 | Snake12534 | Zac_: May I have a link to your GU ELO system please? |
| 23:07.49 | Zac_ | what would be an optimal height for the invisible pyramid |
| 23:07.53 | Zac_ | block* |
| 23:20.11 | JeffM | what do you want it to do? |
| 23:21.03 | allejo | 0 height |
| 23:24.06 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 23:32.27 | Zac_ | well, earlier i mentioned that the ground level of my map has been raised |
| 23:32.53 | Zac_ | so all pyramids which you'd normally be able to slide around the base of |
| 23:32.58 | Zac_ | you get stuck on instead. |
| 23:33.07 | Zac_ | bullet catcher suggested an invisible block at the base of each one |
| 23:33.30 | JeffM | the wiki shows the "bump height" so you probalby want to be less then that |
| 23:33.41 | JeffM | that height is what a tank can drive up on with out jumping |
| 23:33.53 | Zac_ | i have it at 0.5 atm |
| 23:34.04 | JeffM | I belive that is higher then the default |
| 23:34.15 | Zac_ | yep |
| 23:34.21 | JeffM | so if you want to prevent people from driving on them you should be fine |
| 23:34.32 | JeffM | but really anything over the bump height will do |
| 23:34.37 | Zac_ | well, i just want tanks to be able to slide around the outside |
| 23:34.59 | JeffM | do you want them to have to jump to get onto the pyramid and slide? |
| 23:35.00 | Zac_ | and once you've raised the pyra from the z 0 coordinate, you can't, |
| 23:35.01 | JeffM | or just drive up? |
| 23:35.41 | Zac_ | no, i want them to be able to climb on the pyramids normally |
| 23:35.55 | JeffM | what is "normaly", by pressing the jump key? |
| 23:36.05 | Zac_ | i just want a tank at ground level, driving around the edge, not to catch on the edge |
| 23:36.07 | Zac_ | yes ^ |
| 23:36.07 | JeffM | the default bump height is 0.33 |
| 23:36.21 | JeffM | ok, then yeah you want a value over 0.33 |
| 23:36.29 | Zac_ | 0.5 :) |
| 23:36.42 | JeffM | because if it was less then a tank woudl automaticly pop up to that height when they hit the box |
| 23:36.51 | Zac_ | yeah |
| 23:37.07 | JeffM | it does mean that tanks around the "edge" will seem to be floating off the ground |
| 23:37.23 | Zac_ | the very edge yes |
| 23:37.37 | Zac_ | but then they would stick, which is what i'm trying to avoid in the first place |
| 23:37.55 | JeffM | yeah our physics sucks |
| 23:44.51 | Zac_ | they do ^ |
| 23:45.04 | Zac_ | that should be a fix in the new version |