| 00:15.44 | blast007 | super_kami_guru_branch |
| 00:16.34 | blast007 | so we're going for the moving target that will break stuff. awesome ..... |
| 00:19.53 | blast007 | that's just going to hurt everyone and help noone... |
| 00:20.37 | Patlabor | blast007, depends on what we put in master |
| 00:20.49 | Patlabor | if we make people do dev on 2.4.x in a branch then we don't break anything |
| 00:20.57 | blast007 | which will be the flavor of the day |
| 00:21.17 | Patlabor | the commits are so rare, it shold be easy to maintain |
| 00:21.29 | Patlabor | then when we are sure that the maint branch is good, we push to master |
| 00:21.38 | Patlabor | master means "we think this is not broken" |
| 00:21.52 | blast007 | I don't think you're grasping my complaint... if master is our stable, that means that when we release 2.6, then master becomes 2.6 |
| 00:22.00 | Patlabor | ahh |
| 00:22.09 | blast007 | so it won't just be a few commits... it will be the hundreds of commits that led up to the creation of 2.6 |
| 00:22.16 | Patlabor | sure sure |
| 00:22.24 | blast007 | commits that will remove files, move code around, etc |
| 00:22.27 | Patlabor | then stick with master being breakind dev |
| 00:22.43 | Patlabor | who didn't like that as a sugestion? |
| 00:23.17 | Patlabor | we just have to pick one method and stick wiht it ;) |
| 00:23.40 | Patlabor | master as breaking dev is what we had in SVN, it should be fine |
| 00:23.45 | blast007 | I do think having master be bleeding edge and branches be used for the stable releases will help provide more expected updates for everyone... the stable branch should be bug fixes, the bleeding edge should be major changes |
| 00:23.51 | Patlabor | it's master as readme that is confusing people |
| 00:23.55 | blast007 | yeah |
| 00:24.22 | blast007 | so again, I really think that the only thing that needs to happen is getting rid of our "master", and making v2_6_x the master |
| 00:24.23 | Patlabor | BulletCatcher, master as dev, 2_4_maint for compatable work |
| 00:24.26 | blast007 | done. |
| 00:24.30 | Patlabor | yeah |
| 00:24.44 | Patlabor | just do that |
| 00:24.53 | Patlabor | it's at least explainable |
| 00:24.53 | blast007 | I don't think we even need the "maint" bit. just call it v2_4_x |
| 00:25.00 | Patlabor | k |
| 00:25.13 | Patlabor | it's bikeshed |
| 00:25.39 | blast007 | just consistent with what we've been doing in git thus far |
| 00:25.45 | Patlabor | sure sure |
| 00:27.42 | Patlabor | wanna see a worse argument then this? |
| 00:27.50 | Patlabor | Do you have a moment to talk about whitespace? |
| 00:27.54 | Patlabor | :) |
| 00:33.08 | blast007 | :) |
| 00:33.59 | blast007 | anyways, I think the main argument against the convention I suggested was that users will get confused and build the bleeding edge code instead of stable, but I think some of them will get confused regardless of what we do ;) |
| 00:35.41 | Patlabor | again, it's what we used to do, and they weren't as confused as they are now |
| 00:35.45 | Patlabor | EVEYRONE asks where the code is |
| 00:49.46 | *** join/#bzflag Snake12534 (uid45641@gateway/web/irccloud.com/x-dwbyhhqjmbokabsz) |
| 01:12.37 | allejo | where's the code? |
| 01:12.47 | Patlabor | with the beef |
| 01:14.06 | allejo | yum |
| 02:26.11 | BulletCatcher | Okay, then the repo I post tomorrow will have the 2.5 branch be master. |
| 02:54.56 | blast007 | BulletCatcher: thanks :) |
| 03:10.54 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:1806:9274:880:f636) |
| 05:19.36 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:1806:9274:880:f636) |
| 05:46.53 | Flash | just make sure to update ~bzgit so I know what to change :) |
| 06:16.27 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 06:16.27 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 06:28.07 | *** join/#bzflag Snake12534 (uid45641@gateway/web/irccloud.com/x-jkthsthgnybqilux) |
| 06:53.29 | Flash | So, I have some ideas about dealing with the DoS at mofo ... are those appropriate to include in the baseline? |
| 06:53.52 | Flash | more precisely, the 2.4 baseline |
| 06:54.06 | Flash | (since who knows what the branches will be called tomorrow) |
| 07:25.09 | Constitution | not to add more confusion to the topic, but isn't the idea of branches in git that you add new features in a separate branch (in order to not break the main branch too much), and then merge them back onto the main branch? |
| 07:26.34 | Constitution | so then the "stable" code would be in master, and separate "feature" branches (like unstable next generation release branches) would be developed separatedly, then merged back into the main (or "master") branch when done |
| 07:26.55 | Constitution | so following that paradigm, it makes most sense to me for master to be stable code |
| 07:27.17 | Flash | longs for the SVN days |
| 07:27.54 | *** join/#bzflag mahem1 (~mahem1@216.249.42.52) |
| 07:28.34 | Constitution | yes, when 2.6 is released, there would be a slew of changes merged back into the master branch? that's the whole point of branches, right? it would be a lot of changes, but that code is now STABLE, so it is what people should be using anyway |
| 07:30.29 | Constitution | pities BulletCatcher, who must by now be hopelessly confused |
| 07:46.19 | BulletCatcher | I think the plan is to make a 2.6 branch off master at release time. |
| 07:48.09 | BulletCatcher | That will eliminate the need for massive merging or renaming of branches. |
| 08:25.53 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 08:37.08 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:b800:dfa4:c482:569c) |
| 11:48.05 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:4ddc:212:86a6:db3f) |
| 13:10.45 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 14:50.58 | *** join/#bzflag mahem1_ (~mahem1@206.188.159.156) |
| 14:59.03 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:b8b0:6a02:d353:2724) |
| 16:05.11 | Patlabor221 | Constitution: there are many ways to manage the code, the way you say is not the only way. We can use branches to develop features for dev then merge them into any branch. Master will be for new dev. And we Will have a branch for comparable maintenance. |
| 16:15.46 | therealtbe | rename everything. |
| 16:15.54 | therealtbe | that is the only way |
| 16:18.51 | therealtbe | everyone will be confused; thus ensuring fairness. |
| 16:23.15 | BulletCatcher | Henceforth, the game shall be known as Darth BZFlag. |
| 16:23.36 | therealtbe | I think I almost made a haiku there |
| 16:39.45 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:fd7a:8c96:2c97:2807) |
| 16:40.45 | Patlabor221 | I'm going to make my own bzflag, with call girls and blackjack |
| 16:42.25 | Patlabor221 | And oculus rift support ð |
| 17:21.45 | kierra | call girls and blackjack.....interesting |
| 17:25.50 | Patlabor221 | thinks kierra should watch more futurama |
| 17:29.30 | Patlabor221 | Ok it'll just have blackjack and oculus rift support |
| 17:30.26 | Patlabor221 | and maybe a buffet on sunday |
| 17:30.38 | kierra | lol, for a min I thought Patlabor221 was joevano and that callgirl/blackjack seemed out of character. Now it makes sense, JeffM :D |
| 17:30.51 | Patlabor221 | :) |
| 17:31.21 | Patlabor221 | it's a line from a tv show, where a character gets degjected and says he'll go off and make his own "INSERT THING HERE" with those items |
| 17:31.40 | Patlabor221 | inidicating similar ideas to the formation of las vegas |
| 17:32.48 | Patlabor221 | Well selling graphic only tank items is kind of "selling yourself out" |
| 17:32.56 | Patlabor221 | it's all about hats |
| 17:45.42 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 17:56.36 | zuii | hi!can you tell me something about this "IP/Host/callsign (not perm base) mute" (DevRoadmap) |
| 17:57.39 | zuii | A wants to mute B, but A is not an admin, so server blocks message from B to A? or to everyone? |
| 18:00.41 | Patlabor221 | just B to A |
| 18:00.50 | Patlabor221 | a non admin should not affect anyone else |
| 18:01.08 | Patlabor221 | but then it could also be done ENTIRELY client side |
| 18:01.15 | Patlabor221 | well I guess not by IP |
| 18:01.47 | Patlabor221 | yeah it's a client telling the server "Please do not send me any messages from these people" |
| 18:01.56 | Patlabor221 | the interesting thing is the data storage |
| 18:01.58 | zuii | yep, thats why i dont really get why perm based is not enough |
| 18:02.24 | Patlabor221 | because player B may be saying things that are acceptable to everyone BUT player A |
| 18:02.32 | Patlabor221 | and player A never wants to hear from player B |
| 18:02.33 | Patlabor221 | ever |
| 18:02.48 | Patlabor221 | but they don't want to reslilence every time |
| 18:02.57 | Patlabor221 | so they are asking the server to store data and do it for htem |
| 18:02.58 | Patlabor221 | them |
| 18:03.12 | Patlabor221 | but since it ONLY affects them there is no admin or "perms" needed |
| 18:03.22 | Flash | I thought the client already stored silence info |
| 18:03.32 | Patlabor221 | it does, but the client doesn't know the other person's IP |
| 18:03.48 | Patlabor221 | so it can't work if the offender changes callsigns |
| 18:03.53 | Patlabor221 | I don't think it's a good idea to do |
| 18:05.38 | Patlabor221 | it becomes very complicated on the server |
| 18:05.57 | Patlabor221 | do you store the data using the requesters IP, BZID? some arbitary number? |
| 18:06.31 | Flash | Require global registration and use PKI for everything |
| 18:06.32 | Patlabor221 | you don't want the requester to see the offenders host or IP address |
| 18:06.38 | Patlabor221 | PKI? |
| 18:06.46 | Flash | public key infrastructure |
| 18:06.52 | Patlabor221 | we don't have one of those |
| 18:06.57 | Flash | yet |
| 18:07.11 | Patlabor221 | I don't think we need one of those |
| 18:07.23 | Flash | I agree, it is overkill |
| 18:07.28 | Patlabor221 | and I'd not make that change just for this |
| 18:07.34 | Patlabor221 | auth should be HTTPS, that's about all we need |
| 18:07.36 | Flash | but much harder to spoof |
| 18:07.42 | Patlabor221 | BZID is an acceptable ID |
| 18:07.51 | Patlabor221 | but it means that you HAVE to register to use the feature |
| 18:08.00 | Patlabor221 | I think that's fine but it may be limiting to some |
| 18:08.01 | Flash | that seems fair |
| 18:08.16 | Patlabor221 | another option is to have the server give back a "Silence GUID" |
| 18:08.22 | Patlabor221 | and the client stores that with the server name |
| 18:08.41 | Patlabor221 | then on connect it says "I want to enforce these Silence IDs" |
| 18:08.52 | Patlabor221 | then users could share silence IDs |
| 18:10.47 | Patlabor221 | if you are going to do it on BZID, you can do it all right now in a plug-in |
| 18:11.00 | Patlabor221 | since there is a chat event that can be moded |
| 18:11.31 | Patlabor221 | and that may be best, since I'm not sure this is something that we want to force every server to implement, since it has inherent data storage |
| 18:14.52 | Patlabor221 | yeah that item is on the compatible list, I'd do it as a plug-in, adding API features as needed |
| 18:15.22 | Patlabor221 | then if it's SUPER popular and everyone uses it, it can be rolled into the base server in 2.6 |
| 18:16.05 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 18:17.27 | Patlabor221 | points at the "HTTP Management plugins" item and suggests that it is something that would be super useful for someone to work on if they are looking for stuff to do :) |
| 18:20.27 | zuii | why not create a "mastermute" list if i go to another computer playing bzflag i want that dude still silent, masterban could be extended with type of bans |
| 18:21.05 | Patlabor221 | how do you identify that dude? |
| 18:21.20 | zuii | ip, mac address, bzid |
| 18:21.30 | Patlabor221 | you are on the client, you don't have any of those |
| 18:21.33 | Patlabor221 | he did not connect to you |
| 18:21.36 | zuii | bzid<ip<macaddress |
| 18:21.39 | Patlabor221 | he connected to the server |
| 18:22.07 | Patlabor221 | we do not want to send someone's IP address to you |
| 18:22.10 | Patlabor221 | you may abbuse that |
| 18:22.14 | zuii | masterban list is not on the central list server? |
| 18:22.35 | Patlabor221 | oh you mean at a services level |
| 18:22.44 | Patlabor221 | yeah no, we ain't doing ANY more of that sillyness |
| 18:22.49 | Patlabor221 | masterban was the worst idea ever |
| 18:22.54 | Patlabor221 | I'll be removing it in 2.6 |
| 18:23.11 | Patlabor221 | the project doesn't run servers, we should not say who can and can not use them |
| 18:23.27 | zuii | caused too many administration issues? |
| 18:23.47 | Patlabor221 | it causes players to have an expectation that we are cops on all servers |
| 18:23.49 | Patlabor221 | we are not |
| 18:24.04 | Patlabor221 | it'd be like if Mozilla or Appache kept a list of people who could see webpages |
| 18:24.12 | Patlabor221 | for everyone that used mozilla or appache |
| 18:24.49 | Patlabor221 | if the project is going to go that far, then 1) it should be Opt in at the server level, or 2) we should run all servers |
| 18:25.06 | Patlabor221 | but what you are really saying is you'd want the chat data stored with a user's auth info |
| 18:25.09 | Patlabor221 | not a masterban list |
| 18:25.15 | Patlabor221 | since it is user to user |
| 18:25.19 | Patlabor221 | and that's still a bad idea |
| 18:27.50 | Patlabor221 | A plug-in with local data storage is a decent enough way to see how this kind of feature would be used/abused |
| 18:33.13 | zuii | okay, then i would store on the server's memory a list of [(ip,mac,bzid):muter - (ip.mac.bzid):muted] (and optionally could be saved to text file); this list would be populated if /mute Troll or a new /silent Troll would be caught |
| 18:34.09 | zuii | i guess there is callback function or something in bzfs api that i can monitor commands?! |
| 18:35.23 | zuii | ahh..noo |
| 18:35.46 | Patlabor221 | yeah you can install custom commands |
| 18:36.10 | Patlabor221 | I'd make a new command /AlwaysMute or something |
| 18:37.00 | Patlabor221 | then have the plugin read a user's data when they join and authenticate |
| 18:37.35 | zuii | but can i stop a message to be sent to anyone in a plugin? |
| 18:37.50 | Patlabor221 | yeah there is an event that lets you edit a message before it's sent |
| 18:38.00 | Patlabor221 | set the text to nothing, or change the recipient |
| 18:38.08 | zuii | <PROTECTED> |
| 18:38.24 | Patlabor221 | oh god no |
| 18:38.29 | Patlabor221 | that's too low level |
| 18:38.30 | zuii | oopps |
| 18:38.34 | Patlabor221 | there are chat message events |
| 18:38.45 | Patlabor221 | before and after filtring |
| 18:38.46 | zuii | bz_eMessageFilteredEvent |
| 18:38.55 | Patlabor221 | yeah that's after it's been filtered for content |
| 18:39.14 | Patlabor221 | you should be able to kill it there |
| 18:39.34 | Patlabor221 | if not, and that event won't work, add a new event for bz_eAllowChatMessageEvent |
| 18:39.38 | Patlabor221 | or something like that |
| 18:39.52 | Patlabor221 | packet level would be very bad |
| 18:40.02 | Constitution | doubles tournament starts in 20 minutes |
| 18:40.30 | zuii | more lines i guess casts... |
| 18:40.56 | Patlabor221 | no, at the packet level the plugin has to know the data format over the wire |
| 18:41.05 | Patlabor221 | if we change that format, then the plug-in has to change |
| 18:41.16 | Patlabor221 | with the high level message the plug-in doesn't have to change |
| 18:41.25 | zuii | aham |
| 18:41.31 | Patlabor221 | it's about maintenance :) |
| 18:41.38 | zuii | i get it:) |
| 18:42.07 | zuii | i wont tourture myself low level things if its not neccessary |
| 18:42.38 | Patlabor221 | it's not just you that would be tortured, it'd be the person who had to fix it next year when it breaks :) |
| 18:42.40 | zuii | i will look for a plugin made by someone else to bee a "template" |
| 18:42.55 | zuii | myself and anyelse |
| 18:42.56 | Patlabor221 | we have many samples in the plug-ins folder |
| 18:42.57 | Flash | zuii: the initiator should only identify/be identified by bzid |
| 18:43.03 | Patlabor221 | including a template to make new plug-ins from |
| 18:43.19 | Patlabor221 | BZID makes sense to me |
| 18:43.32 | Patlabor221 | IP could be too confusing if 2 players ended up on the same dynamic IP |
| 18:43.47 | Flash | plus, a benefit to registering |
| 18:44.13 | Patlabor221 | once we get registration built into the client, then we'll proably require registration |
| 18:44.18 | Patlabor221 | or at least strongly push it |
| 18:45.00 | Patlabor221 | my sugestion is that if they have not registered, or have not verified an email address from registration, only let them play one one or two servers that the project runs |
| 18:45.10 | Patlabor221 | full registration gives you access to the full community of servers |
| 18:45.37 | Patlabor221 | but also allow people to type in an address unregistred, and if that server is configured to allow unregistered it does, to allow Lan play, etc.. |
| 18:45.46 | Patlabor221 | then we make the default server require registration |
| 18:46.10 | Flash | I think this is where I first started thinking about PKI ... |
| 18:46.35 | Flash | it's as much as anything about authentication |
| 18:46.35 | Patlabor221 | again, the BZID is easy enough |
| 18:46.51 | Patlabor221 | we have a verification step via the token |
| 18:47.21 | Patlabor221 | we don't need a crypto channel |
| 18:47.40 | Flash | as long as the list server is up ... |
| 18:48.00 | Patlabor221 | there is no need or desire to do authentication with out a central service |
| 18:48.06 | Flash | if we require auth and one server goes down, the whole game is broken |
| 18:49.21 | Flash | a digital signature allows central management, but not central authentication |
| 18:49.34 | Patlabor221 | sure, so we have 2 or 3 servers |
| 18:49.40 | Patlabor221 | at present it's not a big concern |
| 18:50.01 | Patlabor221 | when bzflag has thousands of players, then we'll talk :) |
| 18:50.17 | Flash | that ship has sailed |
| 18:50.29 | Patlabor221 | yeah so we are talking about tens of players |
| 18:50.48 | Patlabor221 | the list server woes of old have pretty much passed, it's on a much more stable system |
| 18:53.05 | BulletCatcher | https://github.com/BZFlag-Dev/bzflag-import-4 is ready for perusal. |
| 18:53.06 | BulletCatcher | Don't change it, but please do provide constructive criticism. |
| 18:53.27 | Patlabor221 | honestly I'd like to see the majority of the game servers run by the project, and allow a single "server" to run more then one game |
| 18:54.43 | Patlabor221 | BulletCatcher: initaly it looks good to me, do you have any feelings about maybe renaming some of the other branches to maybe make the branch list cleaner? |
| 18:55.17 | BulletCatcher | I have already cleaned up the branches quite a bit. |
| 18:55.18 | BulletCatcher | Do you have specific suggestions? |
| 18:56.21 | Patlabor221 | maybe make sure they are all preifixed with a version number, so the lion rebuild starts with 2_4_ |
| 18:56.30 | Patlabor221 | and the SOC ones whatever version they are based on |
| 18:56.34 | Patlabor221 | that may sort better |
| 18:57.12 | BulletCatcher | That is easily doable. |
| 18:58.01 | Patlabor221 | that'd be my only sugestion |
| 18:58.08 | Patlabor221 | then the only thing with out a number is master |
| 18:58.18 | Patlabor221 | and that is the one we are least sure about a number on :) |
| 18:58.29 | BulletCatcher | I think the gsoc_server_listing branch can be merged and then removed from the list, but haven't tried to make that happen. |
| 18:59.20 | BulletCatcher | Note that I made the 2.4 branch the default. |
| 18:59.21 | BulletCatcher | That's easy to change whenever we want. |
| 19:00.03 | Patlabor221 | yeah |
| 19:00.13 | Patlabor221 | I do not mind the web interface having 2.4 as default |
| 19:00.31 | Patlabor221 | that makes sense to me and will not have the problem blast007 was worried about |
| 19:01.25 | Patlabor221 | any other comments I'd have all relate to just how our repo is structured, not the import itself |
| 19:03.10 | BulletCatcher | My SVN->Git process creates 14 different repos. Others are bzedit, bzworkbench, pybzflag, etc. |
| 19:03.20 | Patlabor221 | wow |
| 19:03.34 | Patlabor221 | should we have a "tools" repo |
| 19:03.40 | Patlabor221 | or just move over the indivual ones we want |
| 19:03.43 | BulletCatcher | There is one already. :-) |
| 19:03.44 | Patlabor221 | and leave them seperate |
| 19:03.55 | Patlabor221 | they'd still be grouped by the "BZFlag-Dev" org |
| 19:04.44 | Patlabor221 | yeah workbench is seprate |
| 19:04.49 | Patlabor221 | I kinda like it that way |
| 19:04.58 | Patlabor221 | we don't need to move over many of those others |
| 19:05.16 | BulletCatcher | I think all of the other Git repos all have a single branch. |
| 19:05.17 | BulletCatcher | If we wanted we could merge them into a single repo, with an independent branch for each. |
| 19:05.32 | BulletCatcher | That would reduce repo clutter. |
| 19:05.45 | Patlabor221 | and replace it with branch clutter, but it would be nested |
| 19:05.58 | Patlabor221 | honestly leaving many of them on SF is fine |
| 19:06.05 | Patlabor221 | we can't delete the SF archive |
| 19:06.22 | Patlabor221 | and if new dev started on them we could add them to github at that time |
| 19:06.57 | Patlabor221 | the only other one that MAY need to be added now is website, but I don't know how much of the old repo is still used, I know blast007 made a new repo for the new web stuff |
| 19:08.51 | BulletCatcher | Although the SVN->Git process is fully automated, I'd rather not have to revisit it in a couple of years just to do bzworkbench or something. |
| 19:08.52 | BulletCatcher | I'd rather save the results now in a safe place (e.g., GitHub). |
| 19:09.13 | Patlabor221 | ok, then yeah I'd combine them into sub repos |
| 19:09.18 | Patlabor221 | Tools, Web, Archive |
| 19:09.41 | Patlabor221 | or heck, Tools, Web, Archive, GSOC |
| 19:10.03 | BulletCatcher | Here are all of the current repo names: admin bzauthd bzedit bzeditw32 bzflag bzstats bzview bzwgen bzworkbench custom_plugins db pybzflag tools web. |
| 19:10.45 | Patlabor221 | Tools == bzedit, bzeditw32, bzworkblench, bzview, tools |
| 19:11.00 | Patlabor221 | Web = admin, bzauthd,web, db, bzstats |
| 19:11.21 | Patlabor221 | Archive = pybzflag, custom_plugins |
| 19:11.26 | Patlabor221 | oh and add bzwgen to tools |
| 19:11.34 | Patlabor221 | thats my thoughts |
| 19:39.38 | blast007 | zuii: MAC address is not send to the server and will not be send to the server (as it is a meaningless number as far as identification goes) |
| 19:40.50 | zuii | bzid will be the only thing that i check and optionally store |
| 19:45.41 | zuii | so /keepquiet command will only help registered users, and thats alright |
| 19:50.39 | Patlabor221 | It's a good start |
| 19:52.47 | zuii | Im looking at plugins webreports.cpp/webStats.cpp and there is "std::string templatesDir;" on top of the cpp file. whats this? |
| 19:53.08 | blast007 | the directory where their HTML template files are stored |
| 19:54.30 | zuii | ow okay nothing to do with general plugin. thanks |
| 19:55.03 | swigg | zuii: Sounds like something I was soapboxing a few years ago. |
| 19:55.21 | swigg | The devs will always say: "Never trust anything the client sends to you" |
| 19:56.23 | swigg | I thought some sort of tongue in cheek ID could be made by MAC, computer profile (ram, CPUID, graphics card, etc) would be a good start |
| 19:56.42 | swigg | but since it can be faked, the devs said "no" |
| 19:57.01 | Flash | tongue in cheek? |
| 19:57.24 | swigg | "off the cuff", proposed, ad hoc, etc |
| 19:57.31 | Flash | better |
| 19:57.49 | Flash | anything hardware based is actually a bad idea |
| 19:57.58 | swigg | linguistics/ettymology, vernacular, yadda yadda ya |
| 19:58.04 | Flash | most of us go through a fair number of machines |
| 19:58.20 | swigg | Yes, but it would be a good start as it would catch all but the most tenacious |
| 19:58.34 | Flash | I mean, it would hurt the innocent |
| 19:58.45 | Flash | "Why doesn't BZFlag work on my new computer?" |
| 19:59.06 | swigg | I saw an implementation on won.net, flipside.com that did pretty well |
| 19:59.43 | blast007 | zuii: in order to make the server only send a broadcasted message to a limited subset of players, you'd have to cancel sending the message, and then send the message individually to each player that will be getting it. |
| 19:59.48 | swigg | You could factor it in with IP address and latency for more accuracy |
| 19:59.50 | blast007 | which is what you're trying to do, right? |
| 20:01.10 | zuii | yes, Im just getting to understand bzfs api |
| 20:01.25 | zuii | filtering message... |
| 20:02.00 | zuii | there will be a public repo on github |
| 20:02.03 | blast007 | zuii: keep in mind that I think messages sent via the API also trigger chat events, so if a message broadcasted to everyone (say, 20 players) and 1 person has silenced them, you would trigger 19 chat events.. |
| 20:02.19 | blast007 | and plugins like logDetail would write out 19 chat messages for that |
| 20:02.28 | swigg | zuii: Talk to Thumper_ aka BerntH |
| 20:02.40 | blast007 | swigg: and yes, hardware based checks are silly |
| 20:02.52 | swigg | he did stuff like that with his "overseer" plugin |
| 20:03.08 | blast007 | hardware checks would take literally one line of code to evade :P |
| 20:03.15 | swigg | granted, his was for bans, but the concept could be modified |
| 20:03.25 | blast007 | heck, the MAC address of a computer can be changed at will |
| 20:03.31 | swigg | blast007: Not everyone is Blast007 |
| 20:03.43 | blast007 | it's a trivial change... |
| 20:03.53 | Patlabor221 | The client is always lying |
| 20:04.02 | blast007 | even by novice programmer standards it's an easy change |
| 20:04.34 | swigg | It would be more accurate than a hostban |
| 20:04.40 | zuii | yeah mac can be easily changed but most of clients arenot hackers |
| 20:04.56 | swigg | and, over time, a log file would show the perpetrator via statistics |
| 20:05.08 | blast007 | yeah, most are normal people that want to play fair and would get screwed over by hardware identification.. |
| 20:05.11 | zuii | but bizid is easier |
| 20:05.24 | Patlabor221 | We've used Mac at my work, it is highly problematic, even in closed source |
| 20:05.42 | blast007 | take this for instance.. bad guy runs a server, collects hardware information from players that join... now he spoofs that information in his client and joins servers and cheats |
| 20:05.42 | Patlabor221 | Bzid is verified by list server |
| 20:05.48 | swigg | zuii: I think what they will tell you is to do it you would have to go to a "registered players only" server. |
| 20:05.56 | blast007 | now legit players are banned because of your crappy hardware identification |
| 20:06.03 | swigg | and the server owners simply will not do that |
| 20:06.09 | alezakos | BTW, you can't change the contents of the message using bz_eFilteredChatMessageEvent, you'll have to catch a bz_eRawChatMessageEvent (and set its 'message' param to an empty string if you don't want the message to be sent at all) |
| 20:06.20 | Patlabor221 | Swigg, no if you read it all, it's for an optional feature |
| 20:06.52 | swigg | I skimmed, but it's a parallel concept |
| 20:07.08 | swigg | scalable for many purposes |
| 20:07.18 | swigg | impossible to be 100% |
| 20:08.11 | blast007 | swigg: read what I wrote though.. |
| 20:08.41 | swigg | blast007: I usually do. How far up? |
| 20:08.53 | blast007 | like 4 minutes ago |
| 20:12.41 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 20:13.04 | Patlabor221 | nothing is ever 100% |
| 20:13.36 | swigg | By what I gather, yes, pinpoint precicsion is impossible... but... people that evade detection will slip up at least once.. kinda like using an email address or cell phone. Once they use it they are burned |
| 20:13.43 | Patlabor221 | using BZID for the requster is fine, it just means you need to be registered to use that feature, just like a BUNCH of other features we have |
| 20:13.44 | swigg | *precision |
| 20:13.51 | Patlabor221 | nobody wanted pinpoint |
| 20:13.58 | Patlabor221 | it's just the requester |
| 20:15.49 | blast007 | swigg: are you still talking about hardware identification? |
| 20:16.28 | swigg | blast007: no. I mean general statistics |
| 20:16.31 | Patlabor221 | the server can store host, bzID, and IP range for the person being blocked |
| 20:17.22 | swigg | a searchable database, like the old norang database was my tool of choice. RIP norang. :( |
| 20:17.26 | blast007 | it's a game, not a political campaign.. we don't need statistical analysis for player behavior... |
| 20:17.53 | Patlabor221 | but I need to know how every player feels about offshore drilling!!!!! |
| 20:18.06 | swigg | blast007: yeah, but you once banned all of Hungary! :P |
| 20:18.13 | Patlabor221 | they lived |
| 20:18.16 | blast007 | so? |
| 20:18.25 | swigg | Humorous, man. |
| 20:18.27 | blast007 | what does that have to do with anything? |
| 20:18.49 | Patlabor221 | bzflag's playerbase is measured in the TENS of people, it's just not important |
| 20:19.32 | Patlabor221 | BulletCatcher: should we remove import 1? |
| 20:19.40 | swigg | Patlabor221: Yes, because it's not being marketed |
| 20:19.57 | blast007 | yeah, because marketing is the problem that we have |
| 20:19.59 | Patlabor221 | swigg: because it's not a user friendly game :) |
| 20:20.14 | swigg | circular logic problem |
| 20:20.15 | Patlabor221 | we have stats on how many people try it, it's way more then those that play it |
| 20:20.23 | Patlabor221 | no I have data |
| 20:20.43 | Patlabor221 | the people that hit the site is measured in the hundreds and thousands, they don't stick |
| 20:20.53 | Patlabor221 | it's not a problem of getting people to know about the game |
| 20:20.55 | swigg | Yes... but they COULD |
| 20:20.59 | Patlabor221 | it's about getting them to stick |
| 20:21.08 | gnu-sense | Is that a long tail I see? |
| 20:21.33 | swigg | The devs won't market the game because it's not user friendly, but won't improve the game because so few play |
| 20:21.38 | blast007 | swigg: here's some stats for ya. In September, we had 1025 downloads of the Windows 2.4.2 installer alone. |
| 20:21.44 | blast007 | So where are those players? |
| 20:21.48 | Patlabor221 | getting moreplayers by finding the ones willing to deal with a bad gui is not really a good method, better to fix the game and get more people to stick |
| 20:21.51 | Patlabor221 | THEN market it |
| 20:22.00 | blast007 | obviously, marketing isn't an issue... people are downloading the game |
| 20:22.04 | blast007 | they just aren't playing it |
| 20:22.09 | blast007 | or they stop |
| 20:22.15 | Patlabor221 | yeah we won't improve it because NOBODY WILL DEVELOP FOR IT |
| 20:22.30 | swigg | I always thought it would be great on steam, or have a Roblox port, but all I get in response is "Write it yourself" |
| 20:22.42 | swigg | and if I could, I would |
| 20:23.17 | Patlabor221 | higher player counts are a motivator, but can never be the sole motivation |
| 20:23.21 | swigg | Even something to automatically map a game controller |
| 20:23.31 | Patlabor221 | steam would mean a closed source version of the game |
| 20:23.32 | swigg | or a clickable GUI |
| 20:23.34 | blast007 | Roblox is a different game, or am I missing something? |
| 20:23.34 | Patlabor221 | you can't open source steamworks |
| 20:23.52 | swigg | blast007: yes, but the concept could be ported |
| 20:24.03 | blast007 | why? |
| 20:24.11 | swigg | they do stuff on Roblox that is mind blowing |
| 20:24.16 | Patlabor221 | I think there is value in steam as a platform but we'd have to really fix the game first |
| 20:24.20 | swigg | and they have a player base |
| 20:24.21 | blast007 | great, then play Roblox |
| 20:24.24 | swigg | I do |
| 20:24.46 | swigg | blast007: have you tried roblox? |
| 20:24.46 | Patlabor221 | you were told to do it yourself because it's not a direction we want to go right now |
| 20:24.52 | blast007 | no |
| 20:25.02 | Patlabor221 | just like console ports |
| 20:25.08 | blast007 | s/right now/ever/ |
| 20:25.09 | Patlabor221 | a console port will not "save" bzflag |
| 20:25.18 | swigg | You might like it. They have FPS games and simulation games |
| 20:25.37 | gnu-sense | "Angry Tanks" coming to iOS |
| 20:25.47 | Patlabor221 | there are MANY tank games on iOS |
| 20:25.57 | swigg | basically they provide the game engine, you provide the maps and game concept |
| 20:26.07 | Patlabor221 | sounds like unity |
| 20:26.16 | swigg | or worldbuilder |
| 20:26.24 | swigg | quake, etc |
| 20:26.41 | Patlabor221 | bzflag would take about 2 weeks to do in unity |
| 20:27.05 | swigg | why not do a crowdfunding campaign? |
| 20:27.21 | Patlabor221 | because we don't have a company to receive the money |
| 20:27.36 | Patlabor221 | or a plan strong enough to spend it well |
| 20:27.56 | swigg | Yeah I forgot "He who not be mentioned" |
| 20:28.17 | blast007 | he wouldn't be part of the equation anyway |
| 20:28.19 | Patlabor221 | for a crowdfunded you wouldn't need him |
| 20:28.26 | Patlabor221 | anyone can use the code |
| 20:28.51 | blast007 | plus if we're doing it in something else, we could start with clean code that doesn't have his copyright |
| 20:29.12 | Patlabor221 | yeah if you are going that far you are simply making a new game inspired by bzflag |
| 20:29.22 | Patlabor221 | with blackjack |
| 20:29.44 | blast007 | actually, forget the blackjack.. awww, screw it all.... |
| 20:30.41 | Patlabor221 | then we can just use facebook for auth |
| 20:30.50 | Patlabor221 | no problem with auth going down then :) |
| 20:31.33 | gnu-sense | News flash: FB hacked millions of bzid's stolen |
| 20:31.38 | Patlabor221 | The day auth goes down then is the day that the world has become a better place :) |
| 20:32.42 | Patlabor221 | goes back to writing a TorpedoFactory |
| 22:01.54 | *** join/#bzflag zuii (~akos@BC06BD4B.catv.pool.telekom.hu) |
| 22:31.37 | *** join/#bzflag short_circuit (ac380ed4@gateway/web/freenode/ip.172.56.14.212) |
| 23:41.18 | *** join/#bzflag TheRedBaron (~ZeeBaronR@c-69-254-178-47.hsd1.fl.comcast.net) |