| 00:03.41 | *** join/#bzflag RoscoePColtrane (~flash@c-71-205-162-253.hsd1.co.comcast.net) |
| 00:20.57 | BulletCatcher | Working safely in a throwaway repo clone, use "git subtree split" to extract a directory hierarchy and its history into disjoint branch. |
| 00:21.01 | BulletCatcher | Then use "git remote" commands to link that temporary repo to a temporary clone of the target repo (e.g., bzflag-tools) and copy the branch over. |
| 00:21.03 | BulletCatcher | After confirming that the target repo is correct, push upstream. |
| 00:21.33 | BulletCatcher | Finally, remove the hierarchy from the original repo. |
| 00:23.21 | BulletCatcher | One of the awesome things about Git is that it is easy to do complicated unfamiliar tasks like that in repo clones that can be safely discarded if you screw up. |
| 00:24.59 | BulletCatcher | You can script the whole process and put that script into Git, too, for future reference. |
| 00:51.22 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 01:14.40 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 01:39.55 | macsforme | after doing that, do commits that touch files both inside and outside of that directory end up with new SHAs with just the changes within the target directory? |
| 02:22.05 | allejo | was PR #64 tested before it was merged in? |
| 02:25.14 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 02:29.33 | blast007 | allejo: well, it compiled. I didn't write a plugin to test it. |
| 02:29.50 | allejo | meh |
| 02:30.22 | allejo | i probably should have updated the original issue, but clients send a drop flag message before a death message |
| 02:30.52 | allejo | https://github.com/BZFlag-Dev/bzflag/blob/a7f17f522596dabc41f0c3ff6b427502eece1806/src/bzfs/bzfs.cxx#L3187-L3189 |
| 02:48.41 | blast007 | so, then it doesn't do anything? |
| 02:48.51 | allejo | nope |
| 02:49.01 | blast007 | yay |
| 02:51.24 | allejo | the if statement there will always return false since by the time bzfs handles the death, it's already thrown a dropped flag event |
| 02:51.57 | BulletCatcher | macsforme: after that process the original commits would remain unchanged in the source repo, so SHAs wouldn't change there. |
| 02:51.58 | BulletCatcher | The destination branch would have new SHAs for the relevant commits. |
| 02:56.08 | allejo | unless JeffM experienced otherwise, can we revert #64 or fix it? |
| 03:10.50 | macsforme | sounds to me like it should be reverted |
| 03:30.12 | JeffM | allejo: I can fix it, I can use flag history |
| 03:30.36 | allejo | :o |
| 03:30.55 | JeffM | More then than one way to skin a car |
| 03:30.58 | JeffM | Cat |
| 03:31.46 | allejo | would timing be taken into account? i.e. a player drops a flag 30 seconds before they die |
| 03:32.06 | JeffM | Yeah, I have an idea |
| 03:32.20 | JeffM | Last flag drop before an update |
| 03:32.31 | JeffM | If I can't fix it then revert |
| 03:32.43 | allejo | mkay :D |
| 03:34.53 | JeffM | Or revert it and I can redo the entire thing, whatever you want |
| 03:36.58 | allejo | i have no preference either way |
| 03:39.21 | BulletCatcher | We can be patient if you think you can fix it. |
| 03:39.33 | JeffM | Does the client send an update between the drop and the death? |
| 03:40.38 | allejo | that i'm not sure about, i'm not familiar with the client's code |
| 03:40.46 | blast007 | it'd be a mix of TCP and UDP, right? |
| 03:41.06 | blast007 | (the drop/death would be TCP and the player update UDP) |
| 03:41.21 | blast007 | would that make it harder? |
| 03:42.33 | JeffM | Would it send one while dead? |
| 03:43.38 | JeffM | Also, are all flags dropped? Also if the client drops the flag why does the server also drop it? |
| 03:45.15 | allejo | "just to be sure" i think |
| 03:45.55 | JeffM | K |
| 03:46.22 | blast007 | Zombieland rule #2 - the double tap |
| 05:58.03 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 05:58.03 | BZnotify | [13bzflag] 15JeffM2501 opened pull request #66: Better implementation of flag on death PR 64 (062.4...062.4_killedflaghistory) 02https://git.io/vDTlq |
| 05:58.03 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 05:58.22 | JeffM | it checks to see if the last held flag has landed yet, so allejo can try that out to see if it fits his needs. |
| 05:58.51 | JeffM | it may not be prefect in all cases, but the API side will be the same once the proto is fixed, and some people will still have use for it's current behavor. |
| 05:59.05 | JeffM | if not, yank it |
| 06:43.48 | allejo | clones it |
| 06:59.33 | allejo | works for me. should be a nice workaround until the behavior can be changed in 2.6 |
| 07:11.33 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 07:11.34 | BZnotify | [13bzflag] 15allejo pushed 2 new commits to 062.4: 02https://git.io/vDTBd |
| 07:11.34 | BZnotify | 13bzflag/062.4 14ae5fa3d 15JeffM2501: change the lastHeldFlag in the death message to be an ID... |
| 07:11.34 | BZnotify | 13bzflag/062.4 14db0a06e 15Vladimir Jimenez: Merge pull request #66 from JeffM2501/2.4_killedflaghistory... |
| 07:11.34 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.42) |
| 09:56.17 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 13:24.28 | tupone | does premake support Installing file in a directory that is not the final one (aka DESTDIR)? |
| 14:11.38 | macsforme | tupone: if you mean like the --prefix option, yes... but the premake script has to do it... it doesn't get passed onto the generated autotools scripts |
| 14:23.26 | macsforme | https://github.com/macsforme/bzflag/commit/dfad14f5a4e36294405f6ab594f891ff6389df69 |
| 14:34.05 | *** join/#bzflag leny (~zuii@20014C4C1A619B00021E65FFFEDB9BF8.catv.pool.telekom.hu) |
| 16:19.41 | JeffM | allejo: I'm glad it worked out |
| 16:20.51 | JeffM | branch deleted :) |
| 16:41.02 | JeffM | allejo: does that mean you can close issue #1? |
| 16:42.52 | allejo | could close it, i just reopened it to leave it as a note to fix 2.6 unless anyone feels it's unnecessary |
| 16:43.12 | JeffM | it would make sense to make that a different ticket that just talks about events, not the API |
| 16:43.28 | JeffM | since the API will now work wiith ether logic flow |
| 16:43.33 | JeffM | IMHO |
| 16:43.44 | JeffM | someone fixing 2.6 will not have to change the API at all |
| 17:55.34 | *** join/#bzflag Zehra (~Kanone@unaffiliated/zehra) |
| 18:13.16 | tupone | macsforme: it is not prefix. you configure to run in prefix (e.g. /usr), but you install temporary in an empty directory. Then the package manager will get all the files in this temp directory and will packetisize (??) |
| 18:13.35 | tupone | temporary directory is normall DESTDIR |
| 18:41.36 | JeffM | happy birthday tupone :) |
| 18:47.13 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 19:03.56 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 19:26.55 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 19:35.05 | kierra | ~hapbir tupone |
| 19:35.05 | infobot | ACTION sings a variant of Happy Birthday (to avoid royalty fees) to tupone |
| 20:06.23 | blast007 | silly ibot, there are no royalty fees anymore |
| 20:11.27 | kierra | I guess there are more pressing matters to tend to than updating ibot :) |
| 20:42.42 | JeffM | I think singing to a european is terrorism now |
| 20:50.27 | tupone | JeffM: thanks |
| 20:52.25 | kierra | lol |
| 20:53.01 | tupone | thanks kierra too :) |
| 20:54.06 | kierra | you are very welcome, enjoy your special day! |
| 21:01.56 | Zehra | it's actually interesting to note that there was a copyright on happy birthday |
| 21:03.53 | Zehra | it's probably the reason why in many movies another song instead of happy birthday was sung |
| 21:05.16 | JeffM | yes, it was only recently invalidated |
| 21:05.36 | Zehra | a judge ruled it was invalid for copyright iirc |
| 21:06.15 | JeffM | there was a prior book it was published in that has gone into the PD, so the person making the copyright claim had the claim invalidated. |
| 21:06.44 | Zehra | that's good |
| 21:07.56 | Zehra | kind of reminds me of some documents which would be nice to have |
| 21:08.06 | Zehra | but are lost to history |
| 21:47.10 | *** join/#bzflag disco-_ (~disco@unaffiliated/disco-) |
| 22:32.53 | *** join/#bzflag mako (mako@2600:3c03::f03c:91ff:fe70:30aa) |
| 22:42.39 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 23:17.14 | *** join/#bzflag ukiki (ukiki@2600:3c03::f03c:91ff:fe70:30aa) |
| 23:17.19 | *** part/#bzflag mako (mako@2600:3c03::f03c:91ff:fe70:30aa) |
| 23:20.36 | *** part/#bzflag ukiki (ukiki@2600:3c03::f03c:91ff:fe70:30aa) |
| 23:20.50 | *** join/#bzflag ukiki (ukiki@2600:3c03::f03c:91ff:fe70:30aa) |
| 23:58.08 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 23:58.08 | *** mode/#bzflag [+o BulletCatcher] by ChanServ |
| 23:59.20 | *** mode/#bzflag [-o BulletCatcher] by ChanServ |