| 00:01.01 | *** join/#bzflag Flak18 (~Flak@2601:58b:c400:4681:e46c:2dc3:2f84:14cd) |
| 01:25.37 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 02:06.53 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 04:44.57 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 06:43.14 | the_map | not all of us use F12 for rage quits |
| 06:43.37 | the_map | I use it for normal quits, because it's faster than esc-up-enter-enter |
| 06:43.50 | allejo | who's idea was it to have F12 bound to quit anyways? |
| 06:43.52 | allejo | whose* |
| 06:44.19 | the_map | F1 should open the help file in the user's web browser |
| 06:58.37 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 13:17.04 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 13:17.04 | *** mode/#bzflag [+o ChanServ] by tepper.freenode.net |
| 15:34.45 | JeffM | allejo: probably bzflag's author. |
| 15:51.45 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 16:01.01 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 16:04.04 | *** join/#bzflag mich431_ (~mike@ip72-196-103-75.ga.at.cox.net) |
| 16:11.13 | *** join/#bzflag Void7 (~NULL@205.157.147.198) |
| 16:52.48 | the_map | because it was written that way |
| 16:53.16 | JeffM | this is the "why" for most everything in bzflag |
| 16:53.52 | the_map | "why is there a typo in the readme?" |
| 16:56.17 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
| 17:23.49 | JeffM | yup |
| 17:23.59 | JeffM | well that's probalby "because JeffM wrote it" |
| 17:25.59 | blast007 | so, GCC6 doesn't like this in src/obstacle/Teleporter.cxx: p.yz() *= dimsScale; // note the .yz() |
| 17:26.10 | blast007 | http://paste.debian.net/hidden/7497218e/ |
| 17:26.32 | JeffM | that's the entire line? |
| 17:27.10 | JeffM | yz() returns a vector& ? a reference or a vector by value? |
| 17:28.43 | JeffM | what does yz do? |
| 17:29.25 | blast007 | inline vec2<T>& yz() { return *(new((void*)&y) vec2<T>(false)); } |
| 17:29.27 | JeffM | does it construct a new vec2<float> out of compoenents of the full scale and return a reference to it? |
| 17:29.30 | JeffM | oh yeah... |
| 17:29.44 | JeffM | ok, so the returned reference is to a temporary |
| 17:29.48 | blast007 | vectors.h is in our includes/ |
| 17:30.04 | *** join/#bzflag FastLizard4 (fastlizard@ridley.fastlizard4.org) |
| 17:30.07 | JeffM | it's scaling something that was just created then never used |
| 17:30.08 | JeffM | that code does nothing |
| 17:30.15 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 17:30.18 | JeffM | I bet removing it doesn't effect the game at all |
| 17:30.19 | blast007 | https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/ |
| 17:30.46 | JeffM | oh I see what it's doing, man that is some janky code |
| 17:31.02 | JeffM | so the 3d vector keeps X, Y, Z |
| 17:31.04 | JeffM | in that order |
| 17:31.24 | JeffM | it inits a vector 2 with the pointer to Y, so that it gets Y and Z, because it knows they are in order |
| 17:32.46 | blast007 | if I replace it with this, that does the same thingm right? |
| 17:32.51 | blast007 | p.y = p.y * dimsScale.x; |
| 17:32.51 | blast007 | p.z = p.z * dimsScale.y; |
| 17:32.58 | JeffM | yeah |
| 17:33.22 | JeffM | tho I think that actualy does the scale, I'm still not sure the old code actualy applied the scale |
| 17:33.30 | JeffM | so you may also fix a bug |
| 17:33.31 | blast007 | guess I can use *= |
| 17:33.40 | JeffM | sure |
| 17:33.51 | JeffM | tring to see if vec2 has it's own storage |
| 17:34.44 | JeffM | yeah it does |
| 17:34.55 | JeffM | so that new would have copied the values |
| 17:35.13 | JeffM | unless I read it wrong |
| 17:35.21 | JeffM | your code looks to be the intnent of what that code was doing |
| 17:35.27 | blast007 | k |
| 17:35.56 | blast007 | am I changing game behavior though? |
| 17:36.47 | JeffM | maybe |
| 17:37.01 | JeffM | if that changes it, then try just removing it :) |
| 17:37.13 | JeffM | it's one of those 2 fixes |
| 17:39.43 | JeffM | it must do something, or all the porters would be the same size |
| 17:40.30 | JeffM | oh, no that's just in get point |
| 17:40.53 | JeffM | I think that affects porters of different sizes |
| 17:41.18 | JeffM | so going in a small one, and coming out a large one |
| 17:44.50 | blast007 | ah, okay, so it should be easy to test then |
| 17:45.16 | JeffM | yeah, make a narrow TP, and a wide TP and link them. Go in near the edge of each, and you should come out near the edge of the other |
| 18:14.54 | blast007 | k, seems like it does actually do something, and behaves the same when I use the above fix |
| 18:17.58 | JeffM | ok, then it does init the temp vector with a pointer to the origonal memory |
| 18:18.03 | JeffM | template stuff is hard to read sometimes |
| 19:12.25 | *** join/#bzflag Flak18 (~Flak@2601:58b:c400:4681:e46c:2dc3:2f84:14cd) |
| 20:26.41 | *** join/#bzflag FastLizard4|away (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 21:23.16 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 22:42.46 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |