| SpringTank | I have a small but really annoying problem. In bzflag, if a pyr is on another box and you drive up to the PYR while on said box, you will get stuck on it without jumping... | 02:21 |
|---|---|---|
| SpringTank | I've tried _noClimb 1/0 | 02:21 |
| SpringTank | I've tried making the Pyr's a little higher/lower than the top of the box... | 02:21 |
| SpringTank | nothing has fixed this so far... | 02:21 |
| blast007 | yeah, think that's just how the collision is set up for pyramids | 02:23 |
| blast007 | there's probably special logic when you're on the ground so that you don't "stick" to a pyramid | 02:23 |
| SpringTank | hmmm | 02:27 |
| JeffM[m] | All the collision logic is “special” | 02:29 |
| SpringTank | JeffM[m], I guess that's what makes bzflag... bzflag. | 02:31 |
| JeffM[m] | Most of it is just some code that Chris came up with | 02:31 |
| SpringTank | Who is this Chris, and can we ask him to fix the pyramids? | 02:33 |
| blast007 | original creator of BZFlag, and no | 02:35 |
| JeffM[m] | yeah, he's long gone | 02:38 |
| JeffM[m] | I wonder if he still works at pixar | 02:38 |
| JeffM[m] | the collisions should be converted to a universal system that just uses arbitrary geometry, not specific objects. | 02:39 |
| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has joined #bzflag | 02:46 | |
| SpringTank | Never knew he worked at pixar. Thats pretty cool! | 02:56 |
| JeffM[m] | he went off to do that after he made bzflag and turned it over to tim | 02:57 |
| SpringTank | I wonder if he would have any interest in the project, or if he even knows its still around... | 02:59 |
| JeffM[m] | oh he knows, and no he has never expressed any interest | 02:59 |
| JeffM[m] | it's probably changed a lot since he did it | 03:00 |
| JeffM[m] | that's part of the problem with the codebase, inconsistent changes. | 03:02 |
| JeffM[m] | IMHO | 03:02 |
| SpringTank | I agree. | 03:31 |
| OkinaMatara | I believe a lot of the issues are caused by both how easy it is to "hack in" any feature, while at the same time writing it in as a proper feature is extremely difficult and/or tedious. | 03:53 |
| OkinaMatara | The lack of standardization is to a bit of an issue, but likely plays a bit of a lesser role, although it may be part of the cause of the above. | 03:55 |
| JeffM[m] | there is also a lot of "this is the way it has always worked in bzflag". | 03:57 |
| JeffM[m] | most of the 'problems' in bzflag have all be solved many times over now. It's no longer a unique thing that is 'hard' to solve, it's just not elegant in the codebase as it is. | 03:58 |
| OkinaMatara | off the shelf solutions aren't a readily available option due to how tightly coupled the code is, or if not, simply the part of it being in multiple fields making any such changes non-trivial. | 04:01 |
| JeffM[m] | that's what I mean, the codebase doens't allow those kinds of changes | 04:02 |
| JeffM[m] | it's holding itself back | 04:02 |
| OkinaMatara | the other part is exactly what changes can and will be made in the long term, since options ranging from rewrites to evolution have been put on the table. | 04:07 |
| OkinaMatara | I'm not entirely sure, but quite a bit seems to now lay on how 2.5.x goes along/is handled. | 04:08 |
| OkinaMatara | Part of my thoughts on this were written on the thread "BZ - What's the future for it?", mostly on my second post, with the first one having been misread. | 04:10 |
| JeffM[m] | tale as old as time | 04:11 |
| OkinaMatara | true, but the question of if current and past efforts having been a concorde fallacy remains to be seen or if the hope for a "miracle rewrite" is simply a delusion. | 04:14 |
| OkinaMatara | imo, it's both, but depending on the frame of time perspective is the answer. | 04:16 |
| JeffM[m] | you don't want to look at timeframes, the lifetime of 2.2 is a bit long, if you extrapolate that out to the time to make 2.5..... | 04:17 |
| JeffM[m] | I hope it works out | 04:18 |
| OkinaMatara | same | 04:19 |
| JeffM[m] | it just takes effort | 04:20 |
| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 04:48 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has quit IRC (Ping timeout: 252 seconds) | 07:26 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:49 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 08:50 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 09:07 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 10:42 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 15:50 | |
| *** DTRemenak <DTRemenak!~DTRemenak@c-76-120-133-82.hsd1.wv.comcast.net> has joined #bzflag | 17:41 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 20:27 | |
| *** disco <disco!~disco@81.187.95.100> has quit IRC (Ping timeout: 256 seconds) | 20:45 | |
| *** allejo <allejo!~allejo@user/allejo> has quit IRC (Ping timeout: 256 seconds) | 20:45 | |
| *** allejo <allejo!~allejo@104.243.40.186> has joined #bzflag | 20:45 | |
| *** ChanServ sets mode: +v allejo | 20:45 | |
| *** disco <disco!~disco@81.187.95.100> has joined #bzflag | 20:45 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!