| 00:24.17 | I_Died_Once | joins Pentex and the Technocracy |
| 00:30.37 | khonkhortisan | Mr. Plugin says you cannot pause in an odd minute. |
| 00:32.10 | Notify | 03BZFlag:Khonkhortisan * 8487 /Bz_eShotRicochetEven: /* Data */ whos(e) |
| 00:34.20 | Notify | 03BZFlag:Khonkhortisan * 8488 /Ricoche: spelling of pass, change laser to ray to include thief, one less rico requirement, one more rico requirement |
| 01:30.41 | *** join/#bzflag Detrimental (~james@h169.46.191.173.dynamic.ip.windstream.net) |
| 01:47.35 | *** join/#bzflag JeffM (~JeffM@cl211204.wl.callutheran.edu) |
| 01:47.35 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 01:47.35 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:17.28 | *** join/#bzflag macsforme (~josh@bzflag/developer/Constitution) |
| 03:35.45 | *** join/#bzflag JeffM (~JeffM@cl211204.wl.callutheran.edu) |
| 03:35.46 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 03:35.46 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 03:41.08 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 03:52.11 | JeffM | loves sitting in the back of classes that have comptuers to see who's screwing around on the interwebs |
| 03:55.41 | khonkhortisan | I should've done that, it's exactly the opposite to sit in front. |
| 03:56.03 | JeffM | you were the person being watched :) |
| 03:56.06 | khonkhortisan | yep |
| 03:56.33 | JeffM | Second to last row is where it's at |
| 03:56.42 | khonkhortisan | I have the pleasure of tracking a setting from the .bzw file all the way to shot rules in the client. |
| 03:57.23 | JeffM | welcome to development :) |
| 04:04.22 | JeffM | WTF... slashdot has a postive article about Microsoft? |
| 04:04.45 | khonkhortisan | Is that unusual there? |
| 04:05.09 | JeffM | very |
| 04:19.26 | khonkhortisan | I've gone from newObject to object to groupDef before leaving a function. And in a while loop, no less. |
| 04:19.54 | JeffM | arn't debugers fun? |
| 04:20.08 | khonkhortisan | not using one after getting rid of the segfault I caused |
| 04:20.14 | khonkhortisan | I'm actually reading |
| 04:20.55 | JeffM | debuggers are your friend |
| 04:28.52 | khonkhortisan | hey, wallSides! |
| 04:33.39 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 04:36.09 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 04:50.39 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 05:07.02 | khonkhortisan | A: Because it messes up the order in which people normally read text. |
| 05:07.03 | khonkhortisan | Q: Why is it such a bad thing? |
| 05:07.03 | khonkhortisan | A: Top-posting. |
| 05:07.03 | khonkhortisan | Q: What is the most annoying thing on usenet and in e-mail? |
| 05:22.47 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 05:43.36 | *** join/#bzflag Bambino (~Bambino@d204-191-92-33.abhsia.telus.net) |
| 05:44.24 | *** join/#bzflag Bambino (~Bambino@unaffiliated/sniper15) |
| 05:56.10 | khonkhortisan | I have a +r map with two boxes in it, one of which is noricochet. I have it working enough so that one box ricochets and the other doesn't, but the world wall and ground (and anything other than boxes) don't ricochet. |
| 05:56.29 | khonkhortisan | I'm saving a diff while I'm ahead |
| 05:58.21 | khonkhortisan | I moved the allShotsRicochet from SegmentedShotStrategy all the way to when it first sets ricochet when loading objects. |
| 06:32.06 | *** join/#bzflag ahs3- (~ahss-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 08:35.08 | *** join/#bzflag rathis (~rathis@b01bd9ce.bb.sky.com) |
| 15:17.11 | *** join/#bzflag Bambino (~Bambino@d204-191-92-33.abhsia.telus.net) |
| 15:30.11 | khonkhortisan | It works! And of course, is incompatible with current versions. |
| 15:31.31 | alezakos | Did you make a plugin for 2.0? |
| 15:31.44 | khonkhortisan | no, I started with a plugin and ended with a patch |
| 15:31.55 | khonkhortisan | noricochet |
| 15:35.39 | khonkhortisan | If you want half of the objects to ricochet, you can either add "ricochet" to half of them, or add +r and then add "noricochet" to the other half of them. |
| 15:35.54 | khonkhortisan | +r still affects the world walls and ground, though. |
| 15:35.56 | alezakos | Is this a server-only patch? |
| 15:36.09 | khonkhortisan | it's in both the client and server |
| 15:36.46 | alezakos | Another reason why you should expect a proto break :) |
| 15:36.55 | khonkhortisan | Normally, each object has a ricochet boolean that either says "Yes, I ricochet", or "No, I don't know if I ricochet" where no means check for +r |
| 15:37.14 | khonkhortisan | Instead of the client adding together the object and global ricochets, I made the server do that. |
| 15:37.33 | khonkhortisan | Then I made the client almost completely ignore the global ricochet policy and use the objects' settings |
| 15:37.53 | alezakos | That's nice, moving logic to the server |
| 15:38.04 | alezakos | Can't you do this to the walls? |
| 15:38.07 | khonkhortisan | only way to do it without using a three-way boolean |
| 15:38.27 | khonkhortisan | It's possible, but the walls and ground use the global setting for now, as there's no objects for them. |
| 15:39.07 | khonkhortisan | And no ricochet variable for them that would disagree with the global setting |
| 15:41.13 | alezakos | Another option for the boolean would be to make it stick to the defaults if 0 or do the opposite if true |
| 15:41.28 | alezakos | So, if you provide +r, false means ricochet and true noRicochet |
| 15:41.41 | alezakos | If you don't provide +r, false means noRicochet and true Ricochet |
| 15:41.45 | khonkhortisan | oh, opposite! |
| 15:42.04 | khonkhortisan | It would still break the protocol |
| 15:42.08 | alezakos | Sure |
| 15:42.40 | khonkhortisan | I think your way is faster |
| 15:43.14 | khonkhortisan | no wait |
| 15:43.41 | khonkhortisan | it sets each object's ricochet to global, then when it sees "ricochet" it goes true, when it sees "noricochet" it goes false |
| 15:44.13 | khonkhortisan | I'd have to check global a second time when I set for (no)ricochet |
| 15:46.35 | khonkhortisan | and not set it the first time. huh. |
| 15:48.45 | alezakos | You don't need to write an if block to check these two variables. Provided you have a globalRicochet boolean and a stickToGlobal one for every object, you can just xor them |
| 15:50.03 | khonkhortisan | but then for every object I check both the map's ricochet and the global ricochet, instead of checking the global ricohcet once and checking the map ricochet for every object |
| 15:50.31 | alezakos | Depends on whether you want the client or the server to do all the job |
| 15:50.31 | khonkhortisan | global + (local * numobjects) vs. (local + global) * numobjects |
| 15:50.35 | alezakos | (all the work) |
| 15:51.00 | alezakos | Apart from that, I don't think that checking ricos takes so much time on today's CPUs |
| 15:51.17 | *** join/#bzflag spldart (~spldart2@c-98-199-190-28.hsd1.tx.comcast.net) |
| 15:51.17 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 15:51.17 | *** mode/#bzflag [+v spldart] by ChanServ |
| 15:51.58 | khonkhortisan | I would rather have the server do it because it has to do with the way the map is loaded |
| 15:52.51 | alezakos | Yeah, my way is just faster to code |
| 15:53.12 | alezakos | Or not? |
| 15:53.27 | khonkhortisan | My way takes 145 lines of diff |
| 15:54.44 | khonkhortisan | Is it bad to include bzfs.h in CustomBox.cxx and WorldFileObstacle.cxx? That's how I'm getting the global ricochet. |
| 15:55.47 | alezakos | What do you need from bzfs.h? |
| 15:56.39 | khonkhortisan | I need CmdLineOptions *clOptions; from bzfs.cxx so I can do ricochet = (clOptions->gameOptions & RicochetGameStyle); in WorldFileObstacle.cxx |
| 15:57.08 | khonkhortisan | I'm sure there's some other way of getting that variable |
| 16:03.18 | khonkhortisan | Should I give some kind of error if I see both ricochet and noricochet or just use the last one in the object like I'm doing now? |
| 16:04.00 | alezakos | What's the default behaviour on options like noradar? |
| 16:04.42 | alezakos | Forget it |
| 16:04.56 | khonkhortisan | okay |
| 16:05.12 | alezakos | I mean, forget what I said, not the error :) |
| 16:05.46 | khonkhortisan | If I see "box ricochet noricochet ricochet noricochet end" it'll be "noricochet" |
| 16:10.38 | alezakos | Well, if you provide a material with many `noradar`s or you give it a texture and then you say `notextures` it doesn't complain, so you should probably do the same |
| 16:10.54 | alezakos | As far as bzfs.h is concerned, I don't think there is another way to do this |
| 16:10.57 | khonkhortisan | Sounds good. |
| 16:11.12 | khonkhortisan | global.h only gives me the type, not whether it's set |
| 16:12.13 | alezakos | commands.cxx needs to check for the game mode and does this through clOptions and bzfs.h |
| 16:13.27 | khonkhortisan | it seems silly to load network, votingarbiter and shotmanager just to check for rico |
| 16:19.13 | khonkhortisan | world ricochet end doesn't work |
| 16:21.07 | khonkhortisan | I keep forgetting I can resize the sourceforge tracker description text box |
| 16:22.17 | alezakos | Are you submitting the patch? |
| 16:22.29 | khonkhortisan | Yes, in feature requests, where it goes. |
| 16:23.02 | khonkhortisan | with a warning about use on public servers and protocol changes |
| 16:27.02 | alezakos | wait a bit |
| 16:27.07 | khonkhortisan | Yes? |
| 16:27.13 | alezakos | Your wings patch |
| 16:27.19 | alezakos | Added the -w option, right? |
| 16:27.26 | khonkhortisan | it conflicts with -world |
| 16:27.38 | alezakos | yep, -w is an alias for -world |
| 16:28.35 | khonkhortisan | I'm making a map with three rows of objects. One ricochet, one regular, one noricochet. So all someone has to do is take out +r to change the middle row |
| 16:34.29 | khonkhortisan | the wings patch is missing some design (burrow especially), I'm not expecting its eventual inclusion |
| 16:34.44 | khonkhortisan | But I am expecting -noSelfKills and noricochet to get in. |
| 16:49.22 | *** join/#bzflag Detrimental (~james@h66.213.28.71.dynamic.ip.windstream.net) |
| 17:08.38 | khonkhortisan | I think world weapons can hold ricochet flags |
| 17:08.52 | alezakos | Why not? |
| 17:10.32 | khonkhortisan | I can throw those into the test world |
| 17:18.59 | khonkhortisan | Meshes and mesh faces don't support noricochet yet |
| 17:20.37 | khonkhortisan | It looks like they don't support per-face ricochet? |
| 17:21.07 | khonkhortisan | oh. Missed a file. |
| 17:24.22 | khonkhortisan | And that's why we make test cases. |
| 17:31.38 | *** join/#bzflag JeffM (~JeffM@69.36.85.131) |
| 17:31.38 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 17:31.38 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 17:39.12 | *** join/#bzflag TimRiker (TimRiker@bzflag/projectlead/TimRiker) |
| 17:39.12 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 18:17.34 | khonkhortisan | Now meshes accept noricochet, but it doesn't stick yet |
| 18:20.19 | *** join/#bzflag JeffM (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 18:20.19 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 18:20.19 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 19:00.20 | khonkhortisan | That was odd. I was looking for where to put the cursor so that by hitting backspace I could glue the _left_ side of one line with the _right_ side of the _next_. |
| 19:02.59 | alezakos | thinks you should take a break |
| 19:03.33 | khonkhortisan | Meshes have three ricochet variables: global, mesh, and face. A face's ricochet is global+mesh+face. |
| 19:04.29 | khonkhortisan | The new way of doing ricochet will be something like face=mesh=global, where you can set face, and setting mesh getting set resets the faces, and face is the final ricochet. |
| 19:04.32 | blast007 | that's probably not needed |
| 19:04.51 | khonkhortisan | having three makes it harder to cancel |
| 19:05.46 | khonkhortisan | All I have left to do are meshes and groups. And I probably should take a break |
| 19:06.22 | *** join/#bzflag Detrimental (~james@h66.213.28.71.dynamic.ip.windstream.net) |
| 19:09.11 | blast007 | khonkhortisan: for CustomMeshFace, are you passing a new bool to the constructor to set the ricochet variable? |
| 19:11.26 | khonkhortisan | With every object the ricochet bool starts off equaling the global ricochet bool, then reading the file can set it otherwise. |
| 19:12.06 | khonkhortisan | with my patch, not normally |
| 19:12.42 | JeffM | and what does this all do for us? |
| 19:13.20 | khonkhortisan | You can either have an object that ricochets while everything else doesn't, or you can have an object that doesn't ricochet while everything else does. |
| 19:13.46 | JeffM | and that can't be defined now? |
| 19:13.50 | khonkhortisan | nope |
| 19:13.56 | JeffM | why not? |
| 19:14.04 | khonkhortisan | allShotsRicochet takes over |
| 19:14.05 | JeffM | we don't have the flags or it's just a pain to set them? |
| 19:14.22 | blast007 | currently we just have a 'ricochet' map item, but not a 'noricochet' |
| 19:14.29 | JeffM | ahh |
| 19:14.34 | khonkhortisan | If global ricochet didn't take over, bzfs would have to set ricochet per-object, which is what I'm doing |
| 19:14.41 | blast007 | and you can't make the ground or the walls ricochet without +r |
| 19:15.02 | JeffM | k |
| 19:15.03 | khonkhortisan | true, and I'm going to leave it that way for now |
| 19:15.09 | JeffM | understands |
| 19:15.33 | blast007 | and in order to make everything except a handful of objects rick, you *can* make a define and have it specified in the group - and then have the other stuff outside of the define |
| 19:16.01 | blast007 | but that doesn't work if you want part of a mesh to not have ricochet |
| 19:16.09 | khonkhortisan | tried "world ricochet end" to no avail |
| 19:16.32 | JeffM | does this require changes to the compiled map object that is sent to the client? |
| 19:16.39 | blast007 | khonkhortisan: do teleporters support the 'ricochet' item? |
| 19:16.47 | khonkhortisan | blast007, yes, suprisingly. |
| 19:17.11 | khonkhortisan | JeffM, it requires a patched client and server so all tanks ricochet the same |
| 19:17.20 | JeffM | then it's after proto break |
| 19:17.22 | khonkhortisan | yep |
| 19:17.38 | blast007 | khonkhortisan: does it *have* to require a changed client, or is that just the way you're doing it right now? |
| 19:17.55 | JeffM | and you are testing this on your own proto version right? |
| 19:18.16 | blast007 | cuz stuff currently has a 'ricochet' bit. So can we not just set those up correctly based on the input? |
| 19:18.17 | khonkhortisan | not yet, I'm testing it locally and planning on submitting a patch |
| 19:19.07 | khonkhortisan | A client that ignores global ricochet will not ricochet on an unpatched client. A patched server will make no difference to a patched client. |
| 19:19.15 | blast007 | as in, if +r is specified, but the map has a 'noricochet' attribute, couldn't we just loop through and default rico to on for all items, disable the RicochetGameStyle, and then turn off the rico bit for objects that specify 'noricochet'? |
| 19:19.34 | khonkhortisan | that's pretty much exactly what I'm doing |
| 19:19.42 | blast007 | then I don't see why that needs a modified client |
| 19:19.48 | JeffM | but you are saying the client ignores that bit if +R is set? |
| 19:20.16 | blast007 | if +r is set, then all objects probably rico regardless of the object rico bit |
| 19:20.28 | khonkhortisan | For the server to specify per-object ricochets, the client must ignore +r on objects. |
| 19:20.30 | JeffM | and that's what he wants to change |
| 19:20.42 | blast007 | my point is that the server can handle that |
| 19:20.43 | khonkhortisan | It still uses +r on world walls and ground |
| 19:20.53 | blast007 | yeah, walls/ground would still be an issue |
| 19:20.56 | JeffM | he wants to do +r AND have an object not rico, so that he gets rico on the ground |
| 19:21.19 | JeffM | thats all his patch is realy supporting, we can do the other cases now |
| 19:21.22 | blast007 | JeffM: right, but like I said, the server could look at the map, see a 'noricochet' option, and turn off the +r option |
| 19:21.32 | JeffM | but then the ground and walls won't work |
| 19:21.33 | khonkhortisan | and I have that, except my tests haven't passed meshes and groups yet |
| 19:21.39 | blast007 | yeah, only side effect |
| 19:21.50 | JeffM | an owner that wanted that behavor could do it now with the correct settings |
| 19:22.21 | JeffM | I don't see that a slightly easier way to do that is a "feature" worth implementing in this version |
| 19:23.14 | JeffM | foods |
| 19:34.07 | khonkhortisan | define group
end group group
end |
| 19:42.50 | khonkhortisan | That's why I didn't know about <censored>, it was intentionally undocumented. |
| 19:43.16 | alezakos | What's <censored>? |
| 19:44.17 | khonkhortisan | bzw includes |
| 19:45.04 | alezakos | Ah, those ones |
| 19:49.50 | khonkhortisan | global rico, group rico, mesh rico, face rico. I found four. |
| 20:04.43 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 20:10.55 | *** join/#bzflag Delusional (~delusiona@pool-108-17-117-49.pitbpa.fios.verizon.net) |
| 20:10.56 | *** join/#bzflag Delusional (~delusiona@unaffiliated/delusional) |
| 20:18.31 | *** join/#bzflag TimRiker (TimRiker@bzflag/projectlead/TimRiker) |
| 20:18.31 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 20:33.10 | khonkhortisan | face ricochet = global or group or mesh or face |
| 20:37.24 | blast007 | not quite |
| 20:37.37 | khonkhortisan | no? |
| 20:37.51 | blast007 | it should simply default to the parent unless it is set at that level |
| 20:38.41 | khonkhortisan | It defaults to false so far |
| 20:38.43 | blast007 | so if global is on, then everything will default to 'ricochet = true'. And that will not be set again unless 'ricochet' or 'norichcet' is set. |
| 20:39.02 | blast007 | right, I'm saying it *should* default to the parent's setting |
| 20:39.09 | khonkhortisan | I don't want to turn global off when I turn a face off |
| 20:39.20 | khonkhortisan | I want to go the other direction, have the setting in the face |
| 20:39.24 | blast007 | .. you wouldn't |
| 20:39.48 | khonkhortisan | oh "will default to" |
| 20:39.56 | blast007 | inheritence |
| 20:40.37 | blast007 | 'ricochet' or 'noricochet' are just modifiers. So just inherit from the parent unless either of those are set on the current level. |
| 20:40.54 | khonkhortisan | With a mesh, you have the mesh ricochet (parent) and the face ricochet (child(ren)). |
| 20:41.07 | blast007 | And if set, then pass that down to the children as their default (which again, they will inherit unless they have an override) |
| 20:41.14 | khonkhortisan | What happens if you set the parent after setting the children? Are the children reset? |
| 20:41.49 | blast007 | when would you set the parent afterwords? |
| 20:42.05 | khonkhortisan | mesh face noricochet end ricochet end |
| 20:42.09 | blast007 | you have to grab the entire mesh from the world prior to creating the faces, no? |
| 20:42.11 | khonkhortisan | it's possible |
| 20:42.19 | blast007 | world file* |
| 20:42.59 | blast007 | perhaps not |
| 20:45.26 | blast007 | there are ways to solve that, though |
| 20:45.55 | blast007 | You could run an initial pass through the mesh object, checking it for validity, but also checking for noricochet |
| 20:46.13 | blast007 | or you could push creating the mesh faces until the entire mesh has been read |
| 20:49.03 | blast007 | might be easier to just have an 'inheritRico' bool though ;) |
| 20:49.36 | khonkhortisan | so inherit | false | true |
| 20:49.46 | blast007 | yeah |
| 20:50.07 | blast007 | or instead of two bools, have an enum |
| 20:50.38 | blast007 | eRicoInherit = 0, eRicoEnabled = 1, eRicoDisabled = 2 |
| 20:55.21 | blast007 | that certainly involved more testing, of course.. |
| 20:56.20 | blast007 | meh.. and then you'd probably have to have a pointer to the parent stored as well.. and mabye a doesRicochet method.. ;) |
| 20:56.37 | khonkhortisan | I'd have a central enum somewhere |
| 20:57.25 | khonkhortisan | I don't need any parent pointers, that's already taken care of by the group/mesh/face structure |
| 20:57.29 | khonkhortisan | I think |
| 21:01.39 | blast007 | then how do you know if a mesh face has rico enabled? are you checking within CustomMesh instead of within CustomMeshFace? |
| 21:02.12 | khonkhortisan | I don't know yet. I just know both the mesh and face affect the face |
| 21:04.42 | *** join/#bzflag AAA_awright (~aaa@69.72.216.27) |
| 21:11.41 | blast007 | yeah, currently, in MeshObstacle::addFace, the mesh's ricochet setting takes precidence - but that's only because there's not a 'noricochet' option |
| 21:11.58 | khonkhortisan | I just found that file before you said that |
| 21:12.55 | khonkhortisan | but how can there be precedence? Setting the face's ricochet turns it on too |
| 21:12.56 | blast007 | and now this begs a question.. should we also add nodrivethrough/noshootthrough/nopassable? ;) |
| 21:13.07 | khonkhortisan | uhh... |
| 21:13.25 | blast007 | (only to mesh faces) |
| 21:13.48 | khonkhortisan | every object has those WorldFileObstacle.cxx |
| 21:14.22 | JeffM | TimRiker, had any time to catch up and ponder things? |
| 21:14.46 | khonkhortisan | groups would have it too |
| 21:16.20 | blast007 | khonkhortisan: nah, you'd just parse it within CustomMeshFace.cxx's CustomMeshFace::read method |
| 21:17.18 | blast007 | it already parses the existing obstacle stuff there for faces |
| 21:17.55 | blast007 | (though it probably doesn't need to) |
| 21:38.35 | *** join/#bzflag FastLizard4|zZzZ (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 21:39.35 | khonkhortisan | It's not just a simple one-line change, it grows as I work on it |
| 21:42.14 | alezakos | Did you take breaks? |
| 21:44.24 | khonkhortisan | no, not really |
| 22:01.47 | *** join/#bzflag Fira (artix@unaffiliated/fira) |
| 22:41.25 | *** join/#bzflag contempt (~contempt@unaffiliated/contempt) |
| 22:50.37 | *** join/#bzflag contempt (~contempt@unaffiliated/contempt) |
| 23:44.23 | khonkhortisan | uhhh MeshObstacle::addFace has a problem |
| 23:45.08 | khonkhortisan | Not only are the variables not named the same between the .cxx and .h (bzMaterial vs. _material) but the booleans rico and triangulate are swapped! |
| 23:48.17 | blast007 | fun |