| 00:20.35 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:20.35 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:20.35 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:56.47 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 01:14.48 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 01:14.48 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
| 01:17.58 | Zehra | Quick question, just to make sure before I add an updated plug-in. If a plug-in was released under GPLv3, does it remain as GPLv3, even though it was modified and not released as such, but stated that it came from a GPLv3 plug-in? |
| 01:19.19 | blast007 | we'd need more context to know the answer to that |
| 01:19.52 | Juesto | Zehra: if it's a fork and it's not gpl it doesn't make it foss regardless |
| 01:20.13 | blast007 | Juesto: I'm not sure what that even means |
| 01:20.20 | Juesto | foss needs src |
| 01:20.33 | Juesto | blast007: which part |
| 01:21.06 | blast007 | he never said the source wasn't available |
| 01:21.20 | Zehra | https://forums.bzflag.org/viewtopic.php?f=79&t=13924 |
| 01:21.36 | Zehra | ""Tag! your it!!!" plug-in" |
| 01:22.22 | blast007 | I don't see a mention of GPL there |
| 01:22.48 | Zehra | https://forums.bzflag.org/viewtopic.php?f=78&t=13262&start=0 |
| 01:23.37 | Zehra | It basically seems to be a derivative of the sample_plugin provided in the tutorial... assuming from words. |
| 01:24.49 | Zehra | flying_popcorn "Those variables look like they were left over from an example in my plugin tutorial." |
| 01:25.15 | Zehra | "The license for the plugin and all the code in the tutorial is GPL." |
| 01:26.26 | blast007 | if you're planning to port it to 2.4, I think that's a silly one to bother with |
| 01:29.47 | Zehra | I've ported a other few plug-ins to 2.4. (That one included.) |
| 01:31.15 | blast007 | I know. I don't think that one is worth porting. |
| 01:31.19 | blast007 | Ignore it. |
| 01:31.56 | Zehra | Will do. |
| 01:38.39 | Juesto | huh didn't know it has touchscreen support |
| 01:38.56 | blast007 | "it"? |
| 01:39.09 | Juesto | bzf |
| 01:39.54 | blast007 | define "support" then. it doesn't have special handling for it. |
| 01:49.16 | Juesto | nvm |
| 03:17.21 | JeffM | Zehra: you canât make the call that a plugin was derived from the template. There is no way that you can not apply a license to a work you are not the author of |
| 03:17.44 | JeffM | The default if no license is provided is âyou canât use itâ |
| 03:18.52 | JeffM | If it was a derivation, and is in violation of the gpl, then only Tim can enforce it, as he is the copyright holder |
| 03:20.00 | JeffM | Sorry, no way you can apply a license to a work you did not make. |
| 03:20.13 | Zehra | Understood. |
| 03:21.00 | Zehra | Could I use the concept of the code, as long as I don't use the code itself? |
| 03:21.23 | JeffM | It would be up to the author to sue you. |
| 03:22.14 | Zehra | Like if I write my own code, but use the general idea of the plug-in/mode? |
| 03:22.41 | JeffM | Thatâs up to you |
| 03:23.13 | JeffM | Any issue would be between you and the author of the thing you are emulating |
| 03:23.40 | JeffM | We canât say yes or no because it does not involve us |
| 03:24.04 | JeffM | I will say that you canât copyright an idea |
| 03:25.01 | Zehra | that's good. |
| 03:25.07 | JeffM | Now as blast said, it sounds like a dumb idea |
| 03:26.23 | Zehra | Makes sense. |
| 03:27.59 | Zehra | goes back to research the API for their plug-in efforts |
| 04:34.23 | *** join/#bzflag RoscoePColtrane (~flash@c-71-205-162-253.hsd1.co.comcast.net) |
| 06:31.48 | *** join/#bzflag short_circuit (~spldart@bzflag/contributor/spldart) |
| 06:31.48 | *** mode/#bzflag [+v short_circuit] by ChanServ |
| 08:05.49 | Juesto | hm |
| 09:15.05 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 09:16.56 | *** join/#bzflag Swant (swant@freenode/staff/ikea) |
| 11:56.06 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 15:34.00 | *** join/#bzflag sam (foobar@poulet.zoy.org) |
| 16:17.53 | JeffM | hmm, commonized shot path stuff is going to be hard. it needs a bunch of stuff from localplayer |
| 16:25.19 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 16:25.19 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
| 16:34.56 | blast007 | JeffM: difficult enough that it should wait until 2.7/2.8 and be a primary focus of that release? |
| 16:35.05 | JeffM | no, just tedious |
| 16:35.14 | JeffM | I think at least part of it can be done now |
| 16:35.42 | JeffM | make a base player class that is useable by the server and client, and make the shot stuff use that |
| 16:35.46 | JeffM | then move the code into Game |
| 16:35.57 | JeffM | then at least it'll be decoupled from the client |
| 16:36.21 | JeffM | then on the server the player list there would need to derive from the base player |
| 16:36.44 | JeffM | the part I think that will be most dificult is initalizing all the player data to be accurate enough for SSPs |
| 16:36.53 | JeffM | like muzzle height and stuff |
| 16:37.21 | JeffM | but getting it setup on the server isn't super dificult |
| 16:37.28 | JeffM | it's just hard :) |
| 16:37.39 | JeffM | becuase of all the little things that link together. |
| 16:38.07 | JeffM | and the exceptionally poor code layout |
| 16:38.40 | JeffM | one of FiringInfos contructors is in ShotUpdate.cxx... the other is in ShotPath.cxx... |
| 16:43.36 | blast007 | o.O |
| 16:43.40 | JeffM | yeah... |
| 16:47.17 | JeffM | I'm seeing what I can do |
| 17:00.12 | JeffM | there is also rendering code INSIDE the shot path code |
| 17:03.15 | JeffM | this would be much easier with events and reflection :) |
| 17:06.54 | JeffM | ugg.. yeah just moving the client shot code is going to a huge pain |
| 17:07.14 | JeffM | what may be better is to implemnt a new shot system seperate from the client, just pulling the physics code as needed |
| 17:07.31 | JeffM | get that working on the server, THEN refactor the client code to use it |
| 17:07.46 | JeffM | then the client can have local derived versions of the paths that do stuff like rendering. |
| 17:08.20 | JeffM | basicly have 2 paralel logics for a little bit |
| 17:09.18 | JeffM | there is just a lot of rendering, local player, and network message code mixed into the current stuff. |
| 17:10.41 | blast007 | is something like the Bullet physics engine overkill for our use or would that be helpful in the refactoring process? |
| 17:11.01 | JeffM | do you want it to keep playing like it does now? |
| 17:12.26 | JeffM | bzflag doesn't do "physics" per say, it mostly does collisions and surface normal computations |
| 17:12.32 | JeffM | bullet is going to do PHYSICS |
| 17:12.40 | JeffM | it will behave quite differently |
| 17:13.08 | JeffM | and there would be the overhead of getting all the geometry INTO bullet |
| 17:13.25 | blast007 | ah |
| 17:13.32 | JeffM | so you'll end up with basically 2 different sceenegraphs you have to keep in sync |
| 17:13.48 | JeffM | if you don't need real physics, I don't see the usefulness of a physics engine |
| 17:13.52 | blast007 | k |
| 17:14.01 | JeffM | I could see use in a unified collision library |
| 17:14.12 | JeffM | just so everything collides consitently |
| 17:14.30 | JeffM | but the collision responce bzflag wants is so simplistic that it can be computed by the game |
| 17:14.53 | JeffM | are you going to ever drop 1000 cubes and have them bounce around a map with real rotatations? :) |
| 17:15.38 | JeffM | all interactions between things that move and the world in bzflag are treated basicly like point/surface collisions |
| 17:16.15 | JeffM | tanks do a geometry offset on the surface to fake a cylinder, but the effective math is that of a point colliding with a surface. |
| 17:17.07 | JeffM | it's super hard to make unity's physics behave like bzflag, and it uses bullet I belive |
| 17:17.29 | JeffM | you have to turn on so many constraints, that is' simpler to just let unity do the collision and you do the responce. |
| 17:21.19 | JeffM | I'm also not sure why there are seperate shot path and strat objects |
| 17:27.01 | JeffM | huh... I actualy implmented shockwave on the server |
| 17:27.04 | JeffM | that'd be an interesting test |
| 17:27.12 | JeffM | have the server compute deaths from shockwave |
| 18:33.49 | JeffM | can I get rid of USE_TR1 ? |
| 18:41.19 | Juesto | hmmm |
| 19:12.39 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 19:12.39 | *** mode/#bzflag [+o ChanServ] by niven.freenode.net |
| 19:21.30 | JeffM | refactors the hell out of shot manager |
| 19:30.33 | *** join/#bzflag ChanServ (ChanServ@services.) |
| 19:30.33 | *** mode/#bzflag [+o ChanServ] by niven.freenode.net |
| 19:36.13 | *** join/#bzflag Juest- (~AndC@186.143.198.116) |
| 19:36.13 | *** join/#bzflag Juest- (~AndC@unaffiliated/juest) |
| 19:47.06 | *** part/#bzflag Guest63501 (~quassel@unaffiliated/kierra) |
| 19:47.54 | *** join/#bzflag moriah (~quassel@unaffiliated/kierra) |
| 19:50.04 | blast007 | yeah, USE_TR1 can go away as we're targeting C++11 compilers for 2.6 |
| 19:50.11 | *** join/#bzflag Juest- (~AndC@186.143.197.89) |
| 19:50.29 | *** join/#bzflag Juest- (~AndC@unaffiliated/juest) |
| 19:58.19 | JeffM | good, because I shared_ptrerd the heck out of this thing :) |
| 20:40.25 | JeffM | ok, shot manager now has it's own version of segmented shot strategy |
| 20:40.58 | Juesto | working on master? |
| 20:41.02 | Juesto | brb |
| 20:42.08 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 20:42.24 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
| 20:42.26 | JeffM | yes, but this could be moved back to legacy if needed |
| 20:42.34 | JeffM | doubt it'd be needed |
| 20:43.13 | Juesto | hm |
| 20:43.16 | JeffM | blast007 / allejo do you want an API event when a shot ricos? |
| 20:43.41 | Juesto | interesting |
| 20:43.45 | JeffM | or ports? |
| 21:04.50 | JeffM | https://github.com/JeffM2501/bzflag/tree/server_shot_tracking |
| 21:06.08 | JeffM | i switched from a an object/controller to a factory style system, it made more sense since shots have to store there own data and shots will never change logic types during there lifetimes. |
| 21:06.14 | allejo | I could think of some uses for a ricochet API event |
| 21:06.23 | JeffM | it's trivial for me to add |
| 21:06.56 | allejo | would allow for stuff like noricochet map properties to be handled by a plugin instead of inside bzfs |
| 21:07.16 | JeffM | wher eyou'd end the shot early? |
| 21:07.30 | JeffM | this isn't a "should I rico this?" it's a "this did a rico" |
| 21:08.42 | JeffM | all the shot segments are pre-computed when the shot is fired. |
| 21:08.50 | JeffM | so the ricos are all computed at once. |
| 21:09.55 | allejo | ah |
| 21:10.12 | allejo | but since this is moving server side, we would be able to prematurely end a shot, no? |
| 21:10.30 | JeffM | yeah you can do that now |
| 21:10.41 | JeffM | what you can't do is change how the client computes it's shot paths |
| 21:10.57 | allejo | right |
| 21:11.02 | JeffM | so between the time the server computes the rico and the time the endshot gets to the players the shot will continue to rico |
| 21:11.05 | JeffM | and could kill someonje |
| 21:11.28 | JeffM | I also can't ensure the accuracy of the server side simulation compared to other players |
| 21:11.36 | JeffM | just like you can't compare one player's state to another. |
| 21:13.01 | allejo | would the server be the authoritative source for shots? |
| 21:13.07 | JeffM | god no |
| 21:13.13 | allejo | ah nvm then |
| 21:13.16 | JeffM | it's more like just another client |
| 21:13.47 | JeffM | now the state on the server IS needed for the server to eventually be authorative |
| 21:13.55 | JeffM | but that's a different problem to solve |
| 21:14.19 | JeffM | I'm not even doing hit detection yet |
| 21:22.50 | JeffM | what you could do is like fir a shockwave at every rico :) |
| 21:26.17 | allejo | that was actually my thought |
| 21:26.36 | allejo | that and firing more shots for each rico |
| 21:31.26 | JeffM | I have the event including the old pos and dir, and the new pos and dir, so for a rico you could compute the normal between the bounce or something. |
| 21:32.50 | JeffM | merge my allman PR then you can have this one too :) |
| 21:33.47 | JeffM | gotta love comments like // this is fugly but it's what we do |
| 21:39.01 | blast007 | would it be better to apply the allman formatting to 2.4 so that it's easier to merge changes forward from 2.4, then merge that onto master, and then run another pass on master to format any remaining code? |
| 21:39.38 | blast007 | I'll take a look at that PR in just a bit here |
| 21:39.55 | blast007 | I didn't yet take the time to see what the formatting difference is |
| 21:40.28 | JeffM | sure if you want |
| 21:40.33 | JeffM | it's all automateable |
| 21:40.38 | JeffM | do you want a PR for 2.4? |
| 21:41.07 | JeffM | the main formating diffs are { on a new line |
| 21:41.32 | JeffM | I had it force spaces not tabs, everyone was quite adimant about that last time. |
| 21:41.43 | JeffM | but I did incease it to 4 from 2 |
| 21:49.00 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 21:49.00 | *** mode/#bzflag [+v spldart] by ChanServ |
| 21:54.54 | JeffM | it's thinking hard about committing 770 files :) |
| 21:55.12 | allejo | no wonder you're the #1 contributor :p |
| 21:55.45 | JeffM | still only counts as a single commit |
| 21:57.13 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-milshyfixgpvmshu) |
| 21:57.13 | BZnotify | [13bzflag] 15JeffM2501 opened pull request #131: Format code to allman sytle (2.4 branch) (062.4...06allman_24) 02https://git.io/vhLTf |
| 21:57.14 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-milshyfixgpvmshu) |
| 21:57.52 | JeffM | that also updates the editor configs, emacs footer info, and DevINFO to match |
| 22:00.19 | JeffM | I am not sure how commit hooks work for git, or how you could run astyle on new commits, but if you could, the styling can be automatically enforced to some degree |
| 22:01.17 | JeffM | or just run it every month and commit or something |
| 22:01.59 | allejo | commit hooks could be used for that, however it's up to individual developers to set them up. it's not something the project can configure for others |
| 22:02.28 | JeffM | so maybe something like a scheduled task that ran on a server and did format commits once a week would be better? |
| 22:02.31 | allejo | there are services out there that check style guides for PRs, so we could look into that |
| 22:03.16 | blast007 | is that only for PRs or do they check on push as well? |
| 22:03.54 | allejo | for services, only PRs |
| 22:04.32 | allejo | for git hooks, that's for commits |
| 22:05.01 | allejo | however, github would allow us to not be able to commit to master directly. eerything would have to be a PR and then we could enforce the style guide checks that way |
| 22:06.14 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:06.24 | allejo | e.g. https://github.com/marketplace/styleci as an example |
| 22:06.32 | allejo | that one doesn't support cpp and is paid |
| 22:08.07 | JeffM | could you not just have a server get a notification of each commit, get the branch, run astyle, and commit whatever was diffrent? |
| 22:08.47 | JeffM | well notification of the push |
| 22:08.56 | allejo | sure |
| 22:09.10 | allejo | just depends on how much effort anyone wants to put in :) |
| 22:09.11 | JeffM | it's a little roll your own, but it doesn't sound hard. |
| 22:09.49 | JeffM | it's not like bzflag as tens of commits a day |
| 22:09.51 | JeffM | or week |
| 22:10.18 | JeffM | hell you could have the same server do a build and look for errors |
| 22:10.53 | blast007 | mmmmm, that would be neat |
| 22:11.07 | JeffM | and it would not have to be fast |
| 22:11.34 | JeffM | run it on a VM somewhere |
| 22:12.10 | JeffM | sorry vps |
| 22:14.56 | allejo | could even explore stuff like this https://github.com/marketplace/codefactor to nag us about shtuff |
| 22:15.51 | blast007 | I could run a Windows and Linux VM on my NAS for build tests |
| 22:17.49 | allejo | JeffM: does allman support configuration files? or should we just have a script somewhere so allman is always run with the same settings |
| 22:18.01 | JeffM | allman is a style |
| 22:18.05 | JeffM | I think you mean astyle |
| 22:18.09 | JeffM | astyle is the tool |
| 22:18.17 | JeffM | and yeah it supports project files |
| 22:18.20 | allejo | ah then yea, that |
| 22:18.40 | JeffM | http://astyle.sourceforge.net/astyle.html |
| 22:19.06 | JeffM | see the section on "option files" |
| 22:19.34 | allejo | ah there we go |
| 22:20.10 | allejo | does your PR include an "option file" with those settings? |
| 22:20.20 | JeffM | no |
| 22:20.27 | JeffM | but I did include the settigns I used |
| 22:20.31 | JeffM | in the PR comments |
| 22:20.42 | JeffM | the problem with the option file is you'll need 2 of them |
| 22:20.53 | JeffM | one for windows and one for linux, since I have it force the line endings to the native platform |
| 22:21.02 | JeffM | so that GIT will convert them properly on commit |
| 22:21.10 | allejo | don't we have git for that? |
| 22:21.23 | JeffM | GIT converts native to the right thing |
| 22:21.30 | JeffM | but GIT will not force non-native to the right thing |
| 22:21.35 | JeffM | so it won't fix screwups |
| 22:21.51 | JeffM | astyle knows what the code is and CAN fix screwups |
| 22:23.04 | JeffM | blast007, here is a side by side of before (left) and after (right) https://usercontent.irccloud-cdn.com/file/jbzaBnnj/image.png |
| 22:24.03 | allejo | that looks beautiful :') |
| 22:24.17 | JeffM | it's a lot easier to read IMHO |
| 22:24.21 | JeffM | not as compacted |
| 22:24.23 | allejo | agrees |
| 22:25.02 | JeffM | astyle won't change split lines as you can see in sendFlagUpdate, but I did set it to split long lines at 120 |
| 22:25.10 | allejo | i'd be fine with the two option files though. just so we don't have to go through the effort or remembering settings or looking through PRs |
| 22:25.12 | JeffM | so there is still room for some manual cleanup |
| 22:25.26 | allejo | yea |
| 22:25.28 | JeffM | allejo: sure, I figured at the least a batch or shell script would be made. |
| 22:25.50 | allejo | :D |
| 22:26.05 | JeffM | atyle SAYS it supports multiple file types at once, but I was unable to get that to work, so I run it 3 times, once with *.h, then *.cxx then *.c |
| 22:26.10 | JeffM | for the ONE c file in there |
| 22:26.22 | allejo | does astyle run on windows? |
| 22:26.31 | JeffM | I think there is a native windows version |
| 22:26.34 | JeffM | I ran it in WSL |
| 22:27.16 | blast007 | yeah, they release a Windows binary package |
| 22:27.56 | JeffM | I figured doing it linux style would help show it's more automateable |
| 22:28.05 | JeffM | I know that was a question last time we talked about formatting |
| 22:28.28 | *** join/#bzflag Juest- (~AndC@rev190-105-167-003.pccp.net.ar) |
| 22:29.10 | JeffM | I've also done fullbuild after the chagnes and nothing got busted as far as I can tell |
| 22:29.33 | allejo | JeffM: for your PR to force alive players to respawn, did you want that against master or 2.4? |
| 22:29.47 | JeffM | it has client changes, so it needs to be master |
| 22:30.03 | allejo | ah didn't notice that |
| 22:30.05 | JeffM | it COULD be implemented in 2.4, but doing it would kill all shots |
| 22:30.38 | JeffM | I changed the client to only zap flags and shots if the player was already dead when they spawn, thus a regular spawn, a spawn message while alive simply moves them |
| 22:30.42 | *** join/#bzflag Zungo (~AndC@190.194.204.95) |
| 22:30.57 | JeffM | resending a spawn message in 2.4 would force drop flags and remove all player shots from the field. |
| 22:31.50 | JeffM | the client code is just a sanity check, since there are other messages that should have handled the shots and the flags anyway on real death. |
| 22:33.55 | blast007 | I'm fine with the allman formatting change. Automated code formatting is real nice. |
| 22:34.22 | JeffM | yeah, keeps it clean |
| 22:35.14 | JeffM | with the editor config in the msvc dir, and 2017, it's automatically keeping the tabs as spaces |
| 22:35.37 | JeffM | so with that change, the default formating in vc fits fine into bz |
| 22:37.02 | allejo | cheers for sane formatting |
| 22:37.07 | *** join/#bzflag Zungo (~AndC@unaffiliated/juest) |
| 22:38.05 | JeffM | then all you need to do is push the shinny green candy-like button |
| 22:39.08 | allejo | since it's targetting 2.4 too, so that be merged in and then that is merged to master? |
| 22:40.10 | blast007 | yeah, I'll merge the 2.4 one and then merge 2.4 into master |
| 22:40.41 | *** join/#bzflag Juesto (~AndC@rev190-105-167-003.pccp.net.ar) |
| 22:40.51 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
| 22:41.00 | *** join/#bzflag 14WAACAVL (BZnotify@gateway/service/github.com/x-nbfswoeujrzqdnbt) |
| 22:41.00 | 14WAACAVL | [13bzflag] 15blast007 pushed 2 new commits to 062.4: 02https://git.io/vhLLs |
| 22:41.00 | 14WAACAVL | 13bzflag/062.4 1495a5a02 15Jeffery Myers: format codebase to allman style... |
| 22:41.00 | 14WAACAVL | 13bzflag/062.4 1402a03c6 15blast007: Merge pull request #131 from JeffM2501/allman_24... |
| 22:41.00 | *** part/#bzflag 14WAACAVL (BZnotify@gateway/service/github.com/x-nbfswoeujrzqdnbt) |
| 22:41.00 | *** join/#bzflag 7GHAAVHPS (BZnotify@gateway/service/github.com/x-xawezwkurliccgep) |
| 22:41.01 | 7GHAAVHPS | [13bzflag] 15blast007 closed pull request #131: Format code to allman sytle (2.4 branch) (062.4...06allman_24) 02https://git.io/vhLTf |
| 22:41.01 | *** part/#bzflag 7GHAAVHPS (BZnotify@gateway/service/github.com/x-xawezwkurliccgep) |
| 22:43.44 | JeffM | https://youtu.be/ljGMhDSSGFU?t=1038 |
| 22:44.02 | allejo | lol |
| 22:44.10 | *** join/#bzflag Juest- (~AndC@190.194.204.95) |
| 22:44.22 | JeffM | like when the vault opened in die hard |
| 22:44.25 | *** join/#bzflag Juest- (~AndC@unaffiliated/juest) |
| 22:44.30 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-bippohfflzwycfgk) |
| 22:44.30 | BZnotify | [13bzflag] 15blast007 pushed 1 new commit to 062.4: 02https://git.io/vhLLV |
| 22:44.30 | BZnotify | 13bzflag/062.4 1467dd925 15Scott Wichser: Fix a few things in the DEVINFO file. |
| 22:44.30 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-bippohfflzwycfgk) |
| 22:45.03 | allejo | seeing the IRC bot, was something decided on what to do for notifications with the bot being killed? |
| 22:45.35 | JeffM | that the PR was deed |
| 22:45.37 | JeffM | added |
| 22:45.42 | JeffM | have you seen die hard? |
| 22:46.25 | allejo | a long time ago when i was young. too young to remember it very well |
| 22:47.12 | JeffM | all throughout the film the bad guys would hum ode to joy, and when the criminals finaly got into the vault, after like 9 layers of secuity, the big part of it played with full orchestra |
| 22:47.20 | JeffM | because they finally got there |
| 22:48.12 | JeffM | then a barefoot crazy man killed them all |
| 22:48.18 | JeffM | but that is bruce's way |
| 22:49.07 | allejo | lol |
| 22:50.19 | JeffM | I like the analysis that the Fifth element is a better Die hard movie than the last Die Hard movie. |
| 22:54.14 | spldart | :) |
| 23:03.44 | Zehra | I'm probably going to misunderstand this: https://forums.bzflag.org/viewtopic.php?f=3&t=16404 |
| 23:04.32 | Zehra | The plug-in is licensed, but the map doesn't seem to be. |
| 23:04.55 | Zehra | I'm not sure if this is just my perception, or if I'm completely wrong. |
| 23:05.23 | Zehra | (I downloaded the latest version of it, fyi.) |
| 23:05.31 | Juesto | facepalms |
| 23:06.10 | JeffM | everyting in that zip is lgpl |
| 23:06.34 | Zehra | ty JeffM. |
| 23:07.08 | JeffM | the license is in the zip, and the readme says "package" so that includes it's contents. |
| 23:10.08 | JeffM | lgpl is a stupid license for a map, but it does allow for reuse and modification |
| 23:11.00 | Zehra | whew |
| 23:11.22 | Zehra | I only was concerned due to this in the readme: "This plugin is distributted under the GNU LGPL v. 3 (see below or lgpl.txt)" |
| 23:11.42 | JeffM | oh they must have changed the readme then |
| 23:11.52 | JeffM | the first readme says the package is LGPL |
| 23:11.55 | Zehra | eek |
| 23:12.46 | JeffM | so I would not use the last map file, it's ambigous |
| 23:12.58 | JeffM | but the map file from the previous zip uses the term package |
| 23:13.11 | JeffM | so it would be hard for the author to sue you for using that one. |
| 23:13.19 | Zehra | oh, okay. |
| 23:31.26 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 23:40.42 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
