IRC logs for #openttd on OFTC at 2023-06-11
⏴ go to previous day
01:29:06 *** supermop_Home has joined #openttd
01:53:33 *** supermop_Home has quit IRC (Ping timeout: 480 seconds)
02:43:54 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
02:54:21 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:19:56 *** Flygon has quit IRC (Read error: Connection reset by peer)
05:37:21 <Merni> glx22viaGitHub: Time for 13.2.1?
07:22:35 *** gelignite has joined #openttd
07:29:46 <TrueBrain> Silly fullscreen code
07:35:41 *** Heiki has quit IRC (Quit: bullseye → bookworm)
07:41:19 <TrueBrain> never have I ever I would have expected that it would be remotely possible to change the window size in fullscreen mode .. Windows is weird 🙂
07:50:48 <TrueBrain> I still don't know how to fetch another remote in MSVC .. I never get that to work ..
07:51:58 <TrueBrain> as right click -> "fetch" isn't good enough on the remote ..
07:58:05 <TrueBrain> ugh, such an old way of doing fullscreen etc, but okay ..
08:09:18 <TrueBrain> approve, merge, backport, release? 🙂
08:11:52 *** D-HUND is now known as debdog
08:12:00 <TrueBrain> very tempted to build borderless mode, as it is really simple on Windows I found out by accident ... but adding it for MacOS .. I wouldn't know 😛
08:25:07 *** HerzogDeXtEr has joined #openttd
08:34:01 <TrueBrain> one of the two game-coordinator instances has it difficult .. high CPU usage .. not sure what is going on, but it is acting up 😛 Something to figure out next week 🙂
08:45:44 <TrueBrain> we don't show those big red warnings for nothing 😦
09:09:07 *** Kuhnovic has joined #openttd
09:09:07 <Kuhnovic> Finally managed to drag myself out of bed. It was a fun meetup yesterday!
09:35:09 <jfs-> TrueBrain: borderless window instead of exclusive fullscreen would at least make sense to use in OpenGL mode where the stretching is accelerated
09:36:09 <jfs-> but I don't think macOS allows true exclusive fullscreen mode anyway, but it's always equivalent to borderless window there anyway
10:01:23 <TrueBrain> Do we make a 13.3? Or give it a few more days to find others?
10:02:29 <TrueBrain> Or add code to make a 13.2.1 that acts like 13.2 🙂
10:02:55 <TrueBrain> Might be easier than we think, let me check that after lunch
10:06:31 <jfs-> when I suggested making a mechanism for "hotfix" releases a short while ago it was rejected as unnecessary
10:06:56 <michi_cc[d]> I don't know how often I've read a "This update was re-released on X to fix Y" on the Steam launcher update notifcation, so we'd definitely not be alone with this 🙂
10:08:39 <Rubidium_> TrueBrain: you kinda oversold the "bug" I supposed made with the gamelog
10:09:33 <TrueBrain> And I apologise Rubidium
10:09:40 <TrueBrain> It was even more silly 😛
10:10:34 <michi_cc[d]> sinas128: We're expecting your bug report, BTW 🙂
10:12:02 <Kuhnovic> Has anyone seen these before? Upgraded my visual studio the other day, pulled in the latest stuff from master, now I get this...
10:13:01 <Rubidium_> I've seen them before
10:13:19 <michi_cc[d]> Yeah, seens as them as well, and ignored them. I'm assuming right now it might some mismatch with vcpkg and VS.
10:13:22 <Rubidium_> ... in the noughties
10:14:38 <michi_cc[d]> I.e. something isn't properly compiled as static (as libcmtd is the runtime lib for the dll c runtime).
10:15:24 <michi_cc[d]> Or debug/release.
10:17:48 <Kuhnovic> Alright, I'll ignore them for now 🙂
10:20:35 <glx[d]> Often clearing cmake cache is enough
10:21:38 <sinas128> michi_cc[d]: as of right now, 2 mosquitos in the house
10:21:38 <sinas128> but havent had time to test the stuff
10:23:23 <TrueBrain> only 2? I think you underestimate where they are hiding 😄
10:24:14 <TrueBrain> jfs-: it is unnecessary in 99% of the cases; but this is an unique case, I hope you agree. A single commit with a single fix for a single OS, not related to any of the gameplay code 🙂
10:26:05 <glx[d]> There's also the sneaky re-release like I did with a previous nml failing to run the workflow
10:26:28 <glx[d]> Should be similar to nightlies for steam
10:26:40 <TrueBrain> yeah, that works for something like that; but people have manually downloaded 13.2 already .. so rereleasing 13.2 would be a bit annoying for them
10:26:53 <TrueBrain> so I am not worried about Steam users; I am about the others 😄
10:28:49 <glx[d]> Wouldn't 13.2.1 already considered as 13.2 internally ?
10:28:57 <TrueBrain> that is the thing I was checking
10:29:39 <TrueBrain> and the answer seems to be: it is complicated
10:29:56 <jfs-> TrueBrain: that's exactly what I was proposing it for too, being able to release fixes for dumb non-gameplay bugs that affects compatibility and UI
10:30:01 <TrueBrain> for BaNaNaS and NewGRFs we are
10:30:30 <TrueBrain> jfs-: and I guess that is my point; we never had a release this small 🙂 So I guess now is also the time to figure out if we can 🙂
10:30:47 <TrueBrain> well, not true, 0.4.0.1 was also this small 😛
10:31:15 <jfs-> but we have had UI/compat bugs that warranted a hotfix before
10:31:31 <TrueBrain> did you know we have a file called `svn_version.cmd`? In `os/os2` folder 😄
10:35:24 <Rubidium_> I already wondered what parts in os/os2 still actually work
10:37:23 <TrueBrain> I send orudge an email asking if he wants to still support it or not 🙂
10:40:39 <TrueBrain> meh; there isn't a simple way to have the game consider a patch-release compatible, multiplayer-wise
10:41:10 <TrueBrain> this is mostly as it would need a redefinition of what a patch-version is .. as in, it -has- to be multiplayer compatible, but that is very hard to define, write down, make everyone aware of
10:41:24 <TrueBrain> so that seems like the wrong way to go (I came to this conclusion before; but going circles is always nice :P)
10:41:40 <TrueBrain> but .. we can be a bit cheeky in another way if we want to, and just hardcode release/13 to be like this 🙂
10:42:24 <TrueBrain> so it comes down to the same old question we always ask: do we just do a 13.3, and let the few multiplayer servers that updated, update again? Or do we be a bit cheeky? 😄
10:45:03 <TrueBrain> added a commit there how cheeky looks like
10:50:22 <TrueBrain> only an issue for NewGRF and BaNaNaS, so not actually a problem
10:50:35 <TrueBrain> owh, and Windows meta-data
10:52:18 <TrueBrain> added that commit; I thought we deduced this information from the tag already, but clearly we do not 🙂
10:53:46 <TrueBrain> tested 13.2.1, and with my commit, it shows up as 13.2 for network games and I can join servers just fine
10:55:49 <glx[d]> Another option could be to handle X.Y.Z -> X.Y in version script
10:55:56 <TrueBrain> yeah, that is what I wrote above
10:56:03 <TrueBrain> but it is just asking for trouble, honestly
10:56:14 <TrueBrain> in a year, in two years, in N years .. we forgot it needs to be network compatible
10:56:24 <TrueBrain> and we make an X.Y.Z to fix a stupid game-logic bug we made
10:56:57 <TrueBrain> so I am not in favour of such solution
10:58:09 <TrueBrain> so personally, I rather make a commit as in the PR above, which makes an exception for a single version we know 100% sure doesn't influence game-logic 🙂 But, that is one mans opinion; we are with more here 🙂
11:00:04 <jfs-> well releases aren't made and approved by a person working alone
11:00:42 <jfs-> if everyone simultaneously forgets about the rules that's a much bigger structural problem
11:00:48 <glx[d]> Still we often forget a step 🙂
11:01:08 <TrueBrain> Yup. I have seen it many releases .. we are like terrible in following instructions 😄
11:01:27 <TrueBrain> there is even a wiki-page telling how to do a release to prevent it .. but we just don't read 😦
11:01:39 <TrueBrain> I wish the release-page on GitHub could ask questions; that would be useful 🙂
11:01:43 <glx[d]> That's why we automate as much as possible
11:02:09 <TrueBrain> "Does this release break network compatibility with the last release?"
11:02:09 <TrueBrain> "Let another developer sign off on this questions"
11:06:59 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
11:07:12 <jfs-> it really isn't much different from the Semantic Versioning idea which I think everyone should at least be passingly familiar with
11:07:12 <jfs-> major versions do major changes and break all sorts of compatibility (usually where savegame upgrades happen here), minor versions are source-compatible but not binary compatible (may fix gameplay bugs but should not do things that risk breaking savegames), patch versions are entirely drop-in compatible (can play together in multiplayer, you only really need to get the patch if it fixes something
11:07:12 <jfs-> that affects your system)
11:07:50 <TrueBrain> it is really easy to confuse a commit that looks like it doesn't influence game-logic
11:07:55 <TrueBrain> it can be so subtle
11:09:19 <TrueBrain> either way, this happens now once in .. many years. Not sure it is worth setting a policy for a one-off. Maybe we should monitor this during the 14.0 release, and see if it is worth making a policy out, see if we would want to do a 14.0.1 that only contains non-game-logic-breaking commits?
11:10:15 *** Kitrana has joined #openttd
11:10:24 <TrueBrain> (another way to putting: I am not unwilling to change my mind on this; I just haven't the atmost faith in our ability to do it correct 😄 But that can only taken away in practice)
11:12:38 <TrueBrain> and we really need to find a way to automate asserts on/off and cmake project version 😄 Maybe a workflow to create a release, instead of via GitHub releases?
11:12:49 <TrueBrain> so it can push a commit or two before actually creating the GitHub release?
11:13:21 <TallTyler> That would be nice 🙂
11:14:36 <michi_cc[d]> So a github release app?
11:14:57 <TrueBrain> could even be a complete HTML form if we would like
11:15:27 <dP> a lot of changes can be included in a network-compatible release if there is a way to do it
11:15:27 <TrueBrain> what I just wrote in #10722, could help with changelogs .. could even help with writing the news-posts etc
11:15:42 <dP> at a quick glance only about 1/3 of changes in 13.2 are incompatible
11:16:20 <TallTyler> HTML form would be nice for manually editing changelog entries for readability 🙂
11:17:54 <TrueBrain> if nobody took on that job before I am doing with the infra migration, I will give that a look. I have some ideas. If anyone else does want to pick it up, feel free to poke me for those ideas 😛
11:21:07 <michi_cc[d]> Stuff is fine by me. But then, I apparently didn't properly look at stuff on the go either 🙂
11:21:44 <TrueBrain> Rubidium: orudge says he will check out OS/2 soon, see if he still wants to maintain it or not (and if it builds or not) 🙂 As a FYI
11:23:12 <jfs-> as far as i remember several of these changes were ready long before the release, and almost all of them are compatible (i.e. a "1.9.2a" release would have been appropriate)
11:25:57 *** gelignite has quit IRC (Ping timeout: 480 seconds)
11:26:03 <TrueBrain> I am now very curious if we will get questions like: I am running 13.2.1, but my server shows 13.2 🙂
11:29:09 <jfs-> would it be easier to explain if the version is called like 13.2-fix1 or 13.2a ?
11:29:36 <TrueBrain> jfs-: I think nobody is debating that there are commits that could be done in a network-compatible release. What I argue is that they happen very very rarely. Like 1.9.3, that last commit, is not compatible. But I guess it was one of the triggers to make a release 🙂
11:29:36 <TrueBrain> So what I am afraid of, is that we will have a very hard time judging if a commit is safe, and whether we have again a release with only commits that are safe in the next few years. Or that it always contains a commit like the last one to fix some actual gameplay issues.
11:29:52 <TrueBrain> jfs-: not semver, so very unsure how some of our scripts deal with that, honestly
11:31:47 <TrueBrain> 90% sure 13.2a for sure break things. 13.2-fix1 might work, but won't be seen as a stable-release, I think
11:31:58 <TrueBrain> (as a `-` indicates a beta / RC, in the scripting logic, I think)
11:32:28 <TrueBrain> yeah, I am right about both, sadly 😦
11:37:05 <TrueBrain> I forgot how slow mingw was on release/13 ... happy it is a bit faster, but BRRRRRRRR (sorry, I keep saying it, I know .. it is just terribly slow! 😛 )
11:42:24 <TrueBrain> meh; by lack of better .. let's go with 13.2.1, and we will just see if it was a mistake or not afterwards?
11:53:11 *** nielsm has quit IRC (Ping timeout: 480 seconds)
12:08:34 <frosch> Are you sure the bananas version validation allows 3 numbers for >12?
12:09:25 <frosch> Iirc it was quite complicated already
12:10:12 <TrueBrain> frosch: Yup, it only gets 2 🙂
12:10:59 <frosch> Though i guess there is no need to allow entering it. 13.2is enough
12:15:33 <TrueBrain> Yeah, a grf with >=13.2.1 would be weird 😄
12:22:35 <glx[d]> often >=13 is more than enough (we tend to not add newgrf features in minor releases 🙂 )
12:36:50 <TrueBrain> glx[d]: `The "set-output" command is deprecated and will be disabled soon. Please upgrade to using Environment Files` clearly the deadline was a lie 😛 But our MacOS release build still uses it .. stupid signing of certs 😛
12:38:56 <michi_cc[d]> glx[d]: You picked the exact conter-example version for this 😛
12:42:32 <TrueBrain> clickyclick approval for 263? 😄
12:43:46 <TrueBrain> hmm .. CDN failed to update .. let's see ...
12:49:48 <glx[d]> TrueBrain: we fixed that in nightlies
12:50:03 <TrueBrain> ah; and not backported of course. good! Tnx 🙂
12:50:36 <TrueBrain> guess we should have backported that, but what-ever 🙂
12:51:11 <glx[d]> added the label for next time
12:53:46 <glx[d]> it's very hard to spot backportable stuff with the huge amount of not backportable PRs we had recently 🙂
12:54:54 <glx[d]> and nobody's following the checklist 🙂
12:57:24 <TrueBrain> fixed the issue for 13.2.1 manually
12:57:40 <glx[d]> lot of manual stuff for 13.2.1 😉
12:57:47 <TrueBrain> yeah ... system was not designed for this 😄
12:58:05 <TrueBrain> now let's annoy Discord users even more
12:59:28 <frosch> glx[d]: I vote against a 13.2.1.1 for fixing more :p
12:59:44 <TrueBrain> that not how it works you silly!! 😛
12:59:48 <TrueBrain> 13.2.1.1.1.1.1.1.1.1.1.1.1 😄
12:59:53 <TrueBrain> Title: yes, we fucked up
13:00:37 <frosch> Do kids still post 11eleventyone these days?
13:00:47 <glx[d]> "someone felt asleep on '.1' key"
13:03:52 <michi_cc[d]> We switch to TeX version scheme? Successively more decimal places of pi? 🤣
13:13:46 <Rubidium_> sorry, but if 13.2.1 is broken, then next one's undoubtedly 13.13.13 :D
13:18:07 <petern> I'm late to the party but I say 13.3
13:18:29 <TrueBrain> late is an understatement 🙂
13:31:20 <glx[d]> hmm seems network compatibility is not fully working
13:32:08 <glx[d]> I can join some 13.2, but not all
13:32:22 <TrueBrain> that sounds weird .. sure it has to do with 13.2.1?
13:32:51 <glx[d]> it says version mismatch
13:36:20 <TrueBrain> and if you go to 13.2, it does work?
13:36:37 <TrueBrain> as why I am a bit surprised, it hardcoded returns `13.2` for `13.2.1` clients .. there is no if-case or what-ever 😛
13:39:02 <glx[d]> and steam doesn't return to 13.2 in 13.2 branch, it still goes 13.2.1
13:39:31 <TrueBrain> owh, yeah, I did that 😄
13:39:51 <glx[d]> well I'll manually download 13.2 then
13:40:31 <Rubidium_> might it be worth to reconsider releasing it as 13.3?
13:42:34 <glx[d]> haha and with 13.2 client I can't connect to BULL90
13:42:56 <glx[d]> so 13.2.1 reports as 13.2 but not fully
13:42:56 <TrueBrain> so this was a horrible idea 😛
13:43:31 <TrueBrain> bit weird, as during testing I could join a server just fine
13:43:50 <TrueBrain> debug also shows it identifies as 13.2
13:45:17 <TrueBrain> no, it is the CMake Project version
13:45:20 <TrueBrain> it has nothing to do with 13.2.1
13:45:31 <TrueBrain> ffs ... we really have to fix that some parts come from the git-detection
13:45:34 <TrueBrain> some parts from the cmake project file
13:45:42 <TrueBrain> that is just asking for issues in so many ways
13:45:51 <TrueBrain> what is happening, the network version validates, but the newgrf-version is different
13:45:57 <TrueBrain> because newgrf-version is based on the cmake project major/minor
13:46:03 <glx[d]> oh your test was before the cmake change
13:46:04 <TrueBrain> and the network version is based on the git tag
13:46:19 <TrueBrain> this is so terribly designed of us .... why did we do it like this? 😄
13:47:00 <TrueBrain> so yeah, 13.3 AFTER A project version bump would be the way to go, I say 🙂
13:47:20 <glx[d]> because nightlies all share the same cmake version
13:48:02 <TrueBrain> yeah, but this is just bad 😛
13:48:23 <TrueBrain> guess we should just leave it on .0
13:48:29 <TrueBrain> or I shouldn't have made it .2 😄
13:49:34 <TrueBrain> glx[d]: mind making the PR etc? I am scared to touch this now 😄
13:50:17 <glx[d]> revert the hack and bump cmake ?
13:50:29 <TrueBrain> yup .. at least, that would be my advise
13:51:40 <glx[d]> at least we tried to be nice for users
13:52:06 <TrueBrain> yup, but sadly, case and point we are terrible at that 😄
13:55:25 <TrueBrain> maybe we should change the workflow for now to detect a tagged release with a mismatching cmake project version?
13:56:54 <glx[d]> FindVersion.cmake could fail the build in this case
13:58:04 <glx[d]> on top it forces REV_MAJOR and REV_MINOR to 0 if they are not set though
13:58:23 <TrueBrain> I say, let's get 13.3 out ASAP, and work on improving this in 14.0 🙂
14:04:22 <TrueBrain> wow, you don't see such reply often 🙂 How nice: )
14:07:44 <TrueBrain> I like LordAro's idea
14:07:52 <TrueBrain> we just wipe 13.2.1 from the face of the earth 😛
14:11:36 <glx[d]> we should learn to not try last moment fixes 😉
14:12:04 <glx[d]> but we surely will do this kind of mistakes again
14:14:11 <glx[d]> oh let's do a backport run too
16:21:49 *** tokai|noir has joined #openttd
16:21:49 *** ChanServ sets mode: +v tokai|noir
16:25:11 *** tokai has quit IRC (Ping timeout: 480 seconds)
16:35:52 <TrueBrain> something like that? 🙂
16:38:44 <michi_cc[d]> Soo apologetic, you are setting a hight bar for the next time 😛
16:40:24 <TrueBrain> only shows petern shouldn't be slacking with his opinion so much 😛
16:40:48 <TrueBrain> glx[d]: shall I create 13.3, or was there anything else pending?
16:42:10 <TrueBrain> removed the 13.2.1 release, but left the 13.2.1 tag
16:43:52 <TrueBrain> and tnx glx[d] for fixing the code 🙂
17:48:26 <Rubidium_> glx[d], or anybody with a native language that uses genders: can you check whether the genders still function as expected in #10994? And there are no warnings written on the console
17:57:03 <Brickblock1> I could check but I would need a .exe
17:58:16 <glx[d]> I'll check after dinner
20:00:26 <glx[d]> Rubidium_: genders seem to work fine (I tested funding 2 industries and the news titles were correct)
20:03:48 <discord_user_03329cf> OpenTTD has genders?
20:05:37 <JGR> It is part of the grammar of various languages
20:06:46 <discord_user_03329cf> Ohh i thought it was meant like how chairperson used to be chairman etc
20:20:49 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:27:37 *** geli has quit IRC (Quit: Stay safe!)
20:44:19 <andythenorth> not sure what goes on here 🙂
20:44:47 <andythenorth> removing the station tiles cleared it
20:54:41 <TrueBrain> glx[d]: more bugs in 13.2/3? 😄
20:55:28 <glx[d]> I'd say this one might be annoying, but also minor compared to 13.2 windows issue
20:56:14 <glx[d]> but being in 13.2/3 means it should be easy to find the breaking commit
20:56:35 <TrueBrain> One of the dropdown commits? But yeah, smaller list 🙂
20:57:07 <glx[d]> it's strange only this dropdown is affected though
20:57:29 <TrueBrain> Welcome to the game: find what is different!
20:58:21 <glx[d]> the usual "one handler had to do it differently to any others"
20:58:45 <TrueBrain> Why be consistent if you can .. not 😄
21:08:31 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:19:28 <petern> Ahh, other people keep adding backport requested :p
21:23:25 <glx[d]> oh sign tool is probably affected too (uses the same behaviour)
21:24:22 <glx[d]> ah no, this one is not the default action
21:27:51 <petern> Basically when the dropdown is closed, it loses focus, which then closes the window again...
21:28:53 <petern> Seems easy enough to fix but whether that is the right fix is another matter.
21:29:13 <Eddi|zuHause> hey, i manged to only be late by like 3:30h
21:30:27 <glx[d]> but toolbar only handles OnDropdownSelect
21:31:51 <glx[d]> oh generic OnDropdownClose triggers OnDropdownSelect
21:34:56 <frosch> i leveled up my train intuition. i thought 13 minutes transfer is cologne is too short for average delays. so i took a train earlier. look what happened to the original connection :p
21:37:26 <Eddi|zuHause> it's even weirder for me... i took a train later, and the train i was originally meant to be on was cancelled halfway throug, which poured a full train worth of people into the full train i was already on, which made that train delayed and miss the next connection. so the next train after that now had to take on three trains worth of people... which obviously was impossible
21:38:10 <Eddi|zuHause> i decided that i instead take the long way round...
21:38:34 <frosch> i got notifications for 31, 42, 52, 63, 73 minutes delay, the delay is longer than the whole travel, and finally the train is cancelled
21:39:28 <frosch> the "your connecting train cannot be reached anymore" message is particulary funny
21:40:09 <frosch> it kind of implies that the system thought 1 minute travel time would be enough to catch up 60 minutes of delay
21:41:06 <glx[d]> it was possible until the other train moved
21:42:10 <Eddi|zuHause> so anyway, how can a train that runs every 60 minutes be 73 minutes delayed?
21:42:46 <glx[d]> oh I often seen a train running every 15 minutes delayed by 15 minutes
21:43:10 <frosch> in aachen several trains were canceled with bus substitutes, because there was a concert by bruce springsteen
21:43:16 <glx[d]> quite regular on RER B
21:43:32 <frosch> never heard that excuse before :p
21:43:45 <frosch> maybe the train track goes just past the concert place
21:43:50 <frosch> or he is playing on the tracks?
21:43:55 <glx[d]> usually they add trains here for concerts
21:44:37 <glx[d]> they even delay premature line closing in this case
21:44:48 <Eddi|zuHause> dunno, but when i left aachen, the next train was already listed as cancelled
21:45:42 <glx[d]> like for Beyonce in Stade de France the line was supposed to close at 2230 for track work, but that was delayed
21:46:52 <TrueBrain> Random Discord DMs with "yo" .. what are the odds it is a spambot? 😛
21:47:24 <glx[d]> sometimes it's a real user
21:47:35 <glx[d]> just randomly pinging a dev
21:50:19 <TrueBrain> If only there was a place to do so .... 😄
21:50:22 <frosch> 13.2.0 wasn't that bad, it got the 5 stars award for high quality software again
21:50:32 <glx[d]> I'll need to contact ISP (I hate doing that) but it's doing that since tuesday or wednesday, and it's annoying
21:50:51 <TrueBrain> Oof, painful connection
21:51:59 <glx[d]> I only see the deconnections with twich
21:52:16 <glx[d]> with netflix or youtube it's unnoticable
21:53:31 <glx[d]> most likely it's the ONU starting to die
21:54:32 <glx[d]> had similar effects (but even more frequent) with the previous one which was dead on arrival
22:09:30 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:16:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:51:13 *** ChanServ sets mode: +v tokai
23:58:14 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
