Times are UTC Toggle Colours
00:10:57 *** WormnestAndroid has quit IRC 00:12:17 *** WormnestAndroid has joined #openttd 00:17:28 *** ericnoan has quit IRC 00:22:16 *** snail_UES_ has quit IRC 00:30:16 *** tokai|noir has joined #openttd 00:30:16 *** ChanServ sets mode: +v tokai|noir 00:37:03 *** tokai has quit IRC 00:50:25 *** Wormnest has quit IRC 00:59:13 *** tokai has joined #openttd 00:59:13 *** ChanServ sets mode: +v tokai 01:06:13 *** tokai|noir has quit IRC 01:26:32 *** ericnoan has joined #openttd 01:34:41 *** tokai|noir has joined #openttd 01:34:41 *** ChanServ sets mode: +v tokai|noir 01:41:33 *** tokai has quit IRC 02:34:52 *** snail_UES_ has joined #openttd 03:22:06 *** glx has quit IRC 04:43:49 *** Flygon has joined #openttd 05:01:09 *** snail_UES_ has quit IRC 06:17:36 *** sla_ro|master has joined #openttd 07:47:58 *** HerzogDeXtEr has joined #openttd 07:50:09 <TrueBrain> seems GOG enabled cloud saves for OpenTTD .. no clue how they deduced if that is save and what to save :P 07:50:21 <TrueBrain> but it seems they only do "saves" folder in the OpenTTD in Documents, on Windows at least 07:50:49 <TrueBrain> cannot really find the configuration for it; just my deduction :P 07:52:18 <peter1138> Download zbase, see if it syncs that. 07:52:42 <TrueBrain> well, I don't need to download it to know it doesn't appear to be syncing anything but the "saves" folder :P 07:53:02 <TrueBrain> I just don't know if there are any other conditions 07:53:14 <TrueBrain> "save" folder, lol, it is singular 07:54:27 <TrueBrain> it is a bit like: I did not configure this, but magically it is doing stuff .. let's hope it is doing the right thing, situation :) 07:54:45 <TrueBrain> ugh, someone should still work out for Steam how to enable Cloud Saves 07:59:47 <peter1138> https://partner.steamgames.com/doc/features/cloud Looks a bit fiddly. 08:02:23 <TrueBrain> well, basically, we can globally say: this folder should be sync'd in the cloud 08:02:51 <TrueBrain> but someone needs to find out what folders we want to sync, and if that is working as expected :P 08:02:57 <TrueBrain> mainly there was a discussion about openttd.cfg yes/no, etc 08:03:42 <TrueBrain> it does not need any modification to our binary btw 08:13:33 <orudge> That's going to be fun, OneDrive and Steam and GOG all trying to sync the same folder :P 08:14:42 <TrueBrain> GOG and Steam only do it on game-start, so at least that won't be an issue :P 08:26:08 *** andythenorth has joined #openttd 08:49:16 *** EER has joined #openttd 09:45:28 <TrueBrain> https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacked.html 09:45:37 <TrueBrain> The drama isn't over yet 09:45:50 <andythenorth> super 09:45:54 <andythenorth> discord for everyone? 09:46:20 <TrueBrain> nothing wrong with IRC; just anything with wanna-be-heroes :) 09:46:36 <andythenorth> oh the problem is the people? :o 09:46:41 * andythenorth falls over in surprise 09:46:46 <TrueBrain> no, 1 person :) 09:46:48 <TrueBrain> just 1 .. 09:46:58 <TrueBrain> which is hilarious :) 09:47:26 <TrueBrain> a leader that is incapable to calm a situation is not a leader worth following :) 09:47:54 <TrueBrain> (who is to blame is irrelevant at that point btw :P) 09:48:44 <peter1138> The guy writing a text-based Discord client got banned from Discord, so that project is dead now... 09:48:56 <andythenorth> ouch 09:49:05 <TrueBrain> peter1138: :o 09:49:06 <TrueBrain> lame 09:49:14 * andythenorth back to css 09:49:17 <andythenorth> FMFML 09:49:22 <TrueBrain> Ubuntu has an IRC council 09:49:22 <TrueBrain> lolz 09:49:24 <TrueBrain> wuth? 09:49:25 <TrueBrain> haha 09:49:35 * andythenorth is too mean with money to hire a web developer 09:49:38 <andythenorth> hate the idea 09:50:09 <andythenorth> salary would be 1/3 of mine, but I'd have to talk to them 09:50:17 *** andythenorth has quit IRC 09:50:30 <TrueBrain> https://fridge.ubuntu.com/2021/05/26/announcing-ubuntus-move-to-libera-chat/ 09:50:33 <LordAro> TrueBrain: yeah, freenode has entirely shit the bed now 09:50:36 <TrueBrain> well, seems it is just going around :) 09:50:44 <LordAro> got kicked out of a few of my channels this morning too 09:50:44 <TrueBrain> it is so idiotic .. 09:50:51 <TrueBrain> nobody likes it when people move away from you 09:50:54 <TrueBrain> but don't be a dick about it 09:51:28 <TrueBrain> but yeah .. that happens if you stayed on freenode back in .. what .. 2007? and 2014? :P 09:51:36 <TrueBrain> <3 OFTC :) 09:51:38 <TrueBrain> hihihihi 09:51:49 <TrueBrain> drama-free for how many years now? :) 09:52:09 <LordAro> https://twitter.com/endrift/status/1397410356935282689?s=20 https://freenode.net/#to-the-few-projects-leaving-based-on-falsehoods 09:52:12 <LordAro> etc 09:53:24 <TrueBrain> hahahaha, that last URL 09:53:25 <TrueBrain> omg 09:53:32 <LordAro> the text is even better 09:53:48 <TrueBrain> how is flaming people ever a solution to any problem? 09:53:58 <TrueBrain> someone needs to take some management courses quickly 09:54:02 <LordAro> classic power-mad narcissist 09:54:21 <TrueBrain> WHY ARE YOU LEAVING ME I AM NOTHING BUT GOOD TO YOU SEE I SHOW YOU goes kicking a lot of people 09:54:38 <TrueBrain> its so retarded it is funny again :) 09:57:06 <TrueBrain> I love good popcorn moments :) 10:22:43 *** tokai has joined #openttd 10:22:43 *** ChanServ sets mode: +v tokai 10:29:34 *** tokai|noir has quit IRC 10:50:39 *** tokai|noir has joined #openttd 10:50:39 *** ChanServ sets mode: +v tokai|noir 10:57:38 *** tokai has quit IRC 11:09:13 *** peter1138 has quit IRC 11:09:49 <Speeder> https://twitter.com/CriadorDeJogos/status/1397504457114636292 11:09:51 <Speeder> wtf freenode 11:09:58 <Speeder> freenode hijacked #allegro channel today 11:11:13 <DorpsGek> [OpenTTD/OpenTTD] orudge updated pull request #9294: Feature: Sign Windows builds https://git.io/JsjzE 11:11:33 <LordAro> they did a lot 11:11:55 <LordAro> apparently #python only escaped because its topic mentions "libera" rather than "libera chat" or "libera.chat" 11:14:05 *** peter1138 has joined #openttd 11:14:05 *** ChanServ sets mode: +o peter1138 11:14:15 <Speeder> #allegro I believe didn't even had mentioned libera 11:14:44 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9294: Feature: Sign Windows builds https://git.io/JGUsZ 11:14:52 <TrueBrain> orudge: I assume you put the regular stuff in 1Password too? 11:16:46 <TrueBrain> orudge: and in case you forgot, the secrets in the OpenTTD repo needs updating too :) 11:17:08 <Rubidium> though is the bot changing the channels because of libera, or because they sincerely do not follow the policy? As marking a channel as secret might not quite comply with it having to be open to be in #<name> instead of ##<name>. It might as well have been something left over from the previous admin team 11:18:15 <orudge> TrueBrain: I haven't yet (but will), and yes, I did forget :) 11:18:24 * orudge is currently listening to Not running 11:18:25 <TrueBrain> :D 11:18:26 <orudge> I will get both of those things sorted after lunch 11:18:29 <orudge> eh 11:18:32 <orudge> not sure why that appeared 11:18:38 <TrueBrain> haha 11:18:39 <TrueBrain> magic :) 11:20:18 <TrueBrain> Rubidium: I think perception is the important thing here. Even if it violates all your policies .. maybe go about it differently ;) 11:20:31 <TrueBrain> either way, what makes me giggle, is that the text suggests they do this because the TOPIC violates the policy 11:20:45 <TrueBrain> it is like: I remove your channel now because some text that can easily be changed is in violation of our policy :P 11:20:51 <TrueBrain> the wording is just bad :P 11:22:23 <LordAro> also the policy was changed 2 days ago 11:22:27 <Rubidium> oh, they definitely got the perception against them and doing it this way might not be the best to handle this delicate situation 11:23:16 <Speeder> Rubidium, I have no idea why #allegro was taken over. maybe because I had created an unnoficial #allegro on libera just in case it was needed and a bot checked there? dunno. 11:23:33 <TrueBrain> normally, if people violate your policy, you contact them and say: yo, this is not okay here, what are we going to do about it? But you know .. you can also go scourged earth on people :) 11:23:50 <Speeder> it was out of the blue, wake up, and see #allegro channel was taken over, and in retaliation the opts set +m on ##allegro and put on the topic that now they were actually moving. 11:24:34 <milek7> "[rasengan] [Global Notice] In the recent policy enforcement, some channels were erroneously included. We greatly apologize for the inconvenience. Please contact us " 11:24:36 <milek7> lol 11:25:14 <TrueBrain> one thing I do not miss here on OFTC .. the constant flood of global notices 11:25:19 <TrueBrain> that alone I remember of freenode for ever :P 11:25:34 <TrueBrain> it was like a daily mail .. mostly totally not relevant for 99% of the people ... 11:25:48 <Rubidium> wasn't that the reason to leave? 11:25:52 <TrueBrain> yuupppppp 11:25:56 <Rubidium> people just got fed up with the pointless spam 11:26:08 <TrueBrain> and we were not alone :) 11:26:26 <peter1138> I don't even remember that. 11:26:39 <TrueBrain> I do; as I was one of those people that got really annoyed by it :P 11:26:42 <peter1138> 2006. 11:26:59 <peter1138> Not the spam. I don't remember #openttd moving. 11:27:01 <TrueBrain> like: "dude, you are not that important you know" :P 11:27:11 <TrueBrain> owh, it was relative painless 11:27:13 <TrueBrain> bit of QQ of some people 11:27:19 <TrueBrain> but nothing big 11:27:33 <TrueBrain> in a few days we had as many people idling on OFTC as we did on freenode 11:27:39 <peter1138> :D 11:27:42 <TrueBrain> sadly, the number of people in this channel never really changed 11:28:15 <peter1138> Mostly matrix lurkers 11:28:35 <TrueBrain> I think if you check the logs, you find the most people in here never said anything :P 11:29:04 <peter1138> @seen bjarni 11:29:04 <DorpsGek> peter1138: bjarni was last seen in #openttd 9 years, 33 weeks, 3 days, 11 hours, 9 minutes, and 57 seconds ago: <Bjarni> heh 11:29:26 <TrueBrain> @seen 42 11:29:26 <DorpsGek> TrueBrain: I have not seen 42. 11:29:29 <TrueBrain> aawwwhhh 11:29:39 <Rubidium> @seen me 11:29:39 <DorpsGek> Rubidium: I have not seen me. 11:29:48 <TrueBrain> I still need to recover the Seen DB 11:29:57 <TrueBrain> a big portion is missing :P 11:30:00 <Rubidium> @seen Darkvater 11:30:00 <DorpsGek> Rubidium: Darkvater was last seen in #openttd 1 year, 24 weeks, 0 days, 2 hours, 6 minutes, and 36 seconds ago: <Darkvater> so, what did I miss? 11:30:09 <peter1138> Does it matter by now? 11:30:09 <Rubidium> @seen ludde 11:30:10 <DorpsGek> Rubidium: I have not seen ludde. 11:30:20 <TrueBrain> yeah, I believe the first 10 letters of the alphabet are there 11:30:27 <TrueBrain> after that .. it becomes a bit weird 11:30:48 <TrueBrain> need to replay all the logs to recover it .. ugh :P 11:33:11 <TrueBrain> peter1138: some people think it does :P 11:52:15 <peter1138> bah, fresh bread 11:52:25 <TrueBrain> you are weird :P 11:52:33 <peter1138> It's good. I keep eating it :/ 11:55:48 *** snail_UES_ has joined #openttd 11:58:38 *** Beer has joined #openttd 12:11:43 *** glx has joined #openttd 12:11:43 *** ChanServ sets mode: +v glx 12:16:34 *** Samu has joined #openttd 12:31:07 <TrueBrain> top 3 stories on Hacker News are about Freenode / Libera Chat :) Libera did something right at least :P 12:38:33 <EER> I think it's quite impressive that they were able to spin up as much capacity as they did in such a short time (16500 concurrent connections?), clearly the admins know what they're doing :) 12:38:53 <TrueBrain> they ... have been doing it for a few years :P 12:39:20 *** gelignite has joined #openttd 12:39:27 <EER> Sure, but making sure an existing network doesn't go down vs setting up a new one is not always the same :) 12:39:29 <LordAro> one thing i'm not clear on is how they're funding the whole thing 12:39:50 <EER> I wonder the same 12:39:51 <LordAro> i hope the whole thing doesn't disappear overnight due to unpaid server bills :p 12:39:58 <LordAro> or indeed how many servers they have 12:40:00 <milek7> for text chat? 16k doesn't sound like much 12:40:03 <TrueBrain> IRC is pretty low bandwidth I would guess .. and I am sure there are many people willing to donate their free CPU/bandwidth to help out :P 12:40:17 <LordAro> likely 12:40:20 <TrueBrain> but yeah, they should write a blog about it :) 12:40:48 <DorpsGek> [OpenTTD/OpenTTD] orudge closed issue #8056: OpenTTD's Windows installer should be signed https://git.io/Jvbkk 12:40:51 <DorpsGek> [OpenTTD/OpenTTD] orudge merged pull request #9294: Feature: Sign Windows builds https://git.io/JsjzE 12:40:56 <TrueBrain> \o/ \o/ 12:40:56 <TrueBrain> party 12:42:22 <TrueBrain> orudge: you can add custom fields in 1Password :D Makes it less bloaty :P I will fix that in a bit :) 12:42:48 <orudge> TrueBrain: ah, yes, probably, sorry 12:42:53 <TrueBrain> no worries :) 12:44:06 <TrueBrain> there :) Pretty! 12:44:35 <TrueBrain> tnx for putting it in 1Password btw :) 12:44:54 <TrueBrain> and now we wait for a nightly 12:45:02 <TrueBrain> very curious how long it takes for the score to train properly :) 12:45:34 <peter1138> Is there anything to warrant to a (signed) 1.11.3? 12:45:55 <TrueBrain> personally, I would say no. Just a release for all platforms because we have signed binaries for 1, doesn't sound like a good move 12:46:04 <TrueBrain> re-releasing 1.11.2 also feels a bit dirty 12:46:19 <peter1138> Ah yes, it's Windows only :p 12:46:22 <TrueBrain> yup 12:46:29 <TrueBrain> I do, however, thing we shouldn't wait till 2022 for 1.12 12:46:40 <TrueBrain> but that has to do with the STUN PR :) 12:46:46 <peter1138> I did mean anything worth backporting to make it a release, rather that JUST signing it. 12:46:51 <peter1138> *than 12:47:00 <LordAro> there's a few things that could be backported with relative ease 12:47:15 <peter1138> STUN PR, Frosch's cargo PR, etc etc. 12:47:25 <TrueBrain> yeah, all things that shouldn't be backported :P 12:47:26 <peter1138> I guess they are 1.12. 12:48:13 <milek7> d3d driver? :P 12:48:16 <TrueBrain> what is currently marked as "backport requested" would make a fine 1.11.2.1 :) 12:48:25 <TrueBrain> but it is nothing really worth releasing, in my opinion 12:49:26 <glx> just added signing to the list :) 12:50:27 <TrueBrain> smart ;) 12:50:35 <TrueBrain> otherwise I am sure we forget :P 12:51:29 <glx> btw I still don't understand #9291 12:51:54 <TrueBrain> we will have to wait till anyone else complains about the same thing honestly :) 12:52:15 <TrueBrain> it sounds like "one of those crashes" :) 12:54:28 <TrueBrain> https://github.com/JGRennison/OpenTTD-patches/commit/30409192f03665880a301e96cd74fa192317566a <- hihi, "extra large maps" :) 12:54:34 <glx> yeah 1.11.2 works way better than any other 1.11 version 13:05:38 <TrueBrain> how am I going to test how many clients the Game Coordinator can handle .. hmm 13:05:41 <TrueBrain> it has to be somewhat realistic 13:06:14 <TrueBrain> not going to start 1000 OpenTTD servers locally :P 13:06:32 <glx> test branch on steam and an announcement ? 13:06:49 <TrueBrain> I rather know beforehand what memory and CPU will be doing :) 13:07:14 <TrueBrain> hmm, I guess, Python scales linear 13:07:23 <TrueBrain> so if I know the gradient 13:07:31 <TrueBrain> my calculator can do the rest 13:07:41 <TrueBrain> maybe I should check in with my DHCP server for the numbers, but .. I rather use my calculator 13:07:54 <TrueBrain> (sorry, bad reference back to a really weird way of gatekeeping the other day :P) 13:28:45 *** WormnestAndroid has quit IRC 13:28:58 *** WormnestAndroid has joined #openttd 13:30:19 <TrueBrain> turns out I am good in making fork-bombs 13:32:20 <TrueBrain> @calc (26020 - 21956) / 45 13:32:20 <DorpsGek> TrueBrain: 90.31111111111112 13:32:29 <TrueBrain> 90KB per server in memory 13:32:43 <TrueBrain> excluding server info 13:34:52 <TrueBrain> @calc (24672 - 21656) / 100 13:34:52 <DorpsGek> TrueBrain: 30.16 13:35:03 <TrueBrain> okay, so now to send some extra server info .. 13:35:23 <TrueBrain> "socket.accept() out of system resource" 13:35:24 <TrueBrain> awh 13:36:21 <peter1138> 13:54 < TrueBrain> https://github.com/JGRennison/OpenTTD-patches/commit/30409192f03665880a301e96cd74fa192317566a <- hihi, "extra large maps" :) 13:36:37 <peter1138> Yeah, that's why the static_assert was put in :) 13:36:47 <TrueBrain> it clearly helped :) 13:38:03 <peter1138> @calc 86400 - DHCP-lease 13:38:03 <DorpsGek> peter1138: Error: DHCP is not a defined function. 13:38:16 <TrueBrain> would be funny if it returned a value :) 13:38:35 <TrueBrain> okay, by default I can only have 1024 open sockets 13:38:37 <TrueBrain> that is a bit low :P 13:38:39 <peter1138> My DHCP leases are specified as "4w", nothing about minutes. 13:38:49 *** gelignite has quit IRC 13:38:57 <TrueBrain> ah, I see, he wanted to tell me his ban should been 4w 13:39:04 <TrueBrain> well .. infinite is closer to 4w than 1d 13:39:06 <TrueBrain> so I guess he wins 13:40:29 <TrueBrain> @calc (41076 - 21656) / 100 13:40:30 <DorpsGek> TrueBrain: 194.2 13:40:43 <TrueBrain> oops 13:40:53 <TrueBrain> it should be / 1000, but I can do that myself :P 13:43:43 *** WormnestAndroid has quit IRC 13:43:57 *** WormnestAndroid has joined #openttd 13:47:38 <peter1138> Heh 13:48:22 <TrueBrain> okay, bringing 1000 servers online takes far less memory than I expected :P Lol 13:48:35 <TrueBrain> the server peeks at 42MB RAM :P 13:48:50 <peter1138> My first harddrive was 42MB. 13:49:50 <TrueBrain> takes 12 seconds for the 1000 servers to report their status 13:49:57 <TrueBrain> they do it every 30 seconds 13:50:13 <peter1138> That is alarming. 13:50:45 <TrueBrain> well, depends .. I need to figure out if it is the client or the server :D 13:50:53 <TrueBrain> creating 1000 clients is not easy :P 13:52:01 <TrueBrain> so now 2 processes make 2000 clients .. see what that does 13:52:24 <TrueBrain> 14 seconds 13:52:28 <TrueBrain> so it is not so much the server :P 13:52:54 *** y2kboy23_ has joined #openttd 13:53:18 <TrueBrain> max CPU on the server reaches 2% 13:53:19 <TrueBrain> lol 13:53:31 <TrueBrain> okay .. so now I need to check if the server is responsive during those 14 seconds .. 13:57:33 *** y2kboy23 has quit IRC 14:00:15 <TrueBrain> okay, rewriting the client-fork-bomb helped .. now it is done with all servers in a fraction of a second :D 14:00:16 <TrueBrain> lol 14:00:31 <TrueBrain> always amazing how good Python can scale when used properly 14:01:36 <TrueBrain> right ... now .. can 5000 clients request the server-listing with this many servers online :P 14:04:57 <TrueBrain> takes the server 0.1msec to send the list out 14:05:03 <TrueBrain> but .. the GUI takes for-ever to add all entries :P 14:05:42 <peter1138> Resorting every time? 14:06:00 <TrueBrain> and it seems adding 1 server per tick 14:06:11 <TrueBrain> well, the coordinator sends 1 packet per server 14:06:17 <TrueBrain> so there might be a relation between those two :) 14:06:50 <peter1138> Is it a json web api yet? 14:06:50 <TrueBrain> static const int MAX_PACKETS_TO_RECEIVE = 4; 14:06:52 <TrueBrain> 4 servers per tick :P 14:07:02 <TrueBrain> no .... wish we could do HTTPS calls from OpenTTD :P 14:07:16 <TrueBrain> I know frosch would like that :) Would allow more advanced filtering etc 14:07:22 <peter1138> Me too. 14:07:23 <TrueBrain> but okay .. didn't want to rebuild Rome in 1 PR :D 14:07:34 <peter1138> Sorry :( 14:07:48 <TrueBrain> we really should add libcurl or what-ever in the client 14:07:54 <TrueBrain> also means we can do telemetry, via Google ofc 14:07:54 <TrueBrain> :P 14:08:29 <peter1138> I'd also be able to Google for settings from inside the game. 14:08:39 <TrueBrain> solves the nickname issue too! 14:08:46 <TrueBrain> I only see epic wins here :D 14:08:54 <TrueBrain> well, without kidding, adding libcurl would really help 14:10:30 <peter1138> bananas morphs into a web api 14:10:40 <TrueBrain> coordinator too 14:10:49 <TrueBrain> would simplify the whole infrastructure by a lot 14:10:59 <TrueBrain> and a lot of issues we are now solving, are already solved :P 14:11:07 <peter1138> Ok so... 14:14:07 <TrueBrain> oops, fork-bombed my WSL2 again 14:14:08 <TrueBrain> lalala 14:14:32 <TrueBrain> WSL2 crashed :D 14:14:36 <TrueBrain> Windows OOM :P 14:14:56 <TrueBrain> "oops"? :D 14:17:33 *** Speeder has quit IRC 14:18:49 <TrueBrain> 2 seconds for 2048 clients to get the full server-list 14:19:04 <TrueBrain> and all that in 40MB RAM :P (512 servers online) 14:21:28 <peter1138> Nice 14:21:46 <peter1138> So it's really low usage, apart from fork bombing it :D 14:22:07 <TrueBrain> yeah, the limits seem to be because of the way I do the testing 14:22:27 <TrueBrain> I did find a nasty bug in how I read packets 14:22:30 <TrueBrain> which can hang the server :P 14:22:34 <TrueBrain> but that a normal client doesn't do :D 14:22:56 <TrueBrain> okay, I am really surprised by these results, did not expect Python's asyncio to be this performant, honestly 14:27:46 <LordAro> very nice 14:27:56 <peter1138> 38 hosts in my DHCP lease list. Oops? 14:28:02 <peter1138> That's normal right? 14:28:13 <TrueBrain> few things left to figure out .. what is the open-file limit on AWS ECS :P 14:28:23 <TrueBrain> and .. do we want the server to be a single instance .. easy to code etc 14:28:29 <TrueBrain> or multiple instance .. good for scaling up 14:28:42 <TrueBrain> the first has a few downsides .. if it crashes for what-ever-reason, all servers disconnect, and have to reconnect 14:28:43 <peter1138> Actually... phone, watch, scales, another phone, another watch, washing machine, laptop... okay, that's still nowhere near 38. 14:29:15 <peter1138> central heating controller, another 1 :p 14:29:31 <TrueBrain> multiple instances .. means there needs to be some queue between them so they all know what is going on 14:29:33 <TrueBrain> like, redis 14:29:42 <peter1138> Maybe I need an IoT wifi SSID. 14:29:49 <TrueBrain> peter1138: exactly what I did :P 14:29:54 <TrueBrain> they are also in a vlan 14:30:22 <peter1138> Problem with that is most such devices are "connect with your phone to configure" and then you need your phone on that SSID too. 14:30:28 <TrueBrain> means if someone exploits any of the IoT devices in my house, they cannot jump to my computer etc :) 14:30:46 <TrueBrain> well, cannot jump -easily- 14:30:59 <peter1138> Yeah, I'm mostly too lazy. Hmm. 14:31:15 <TrueBrain> so, okay, single instance has another downside .. every time we upgrade, all servers are disconnected too 14:31:25 <TrueBrain> this currently is true for bananas-server and master-server too 14:31:39 <TrueBrain> but the latter stores data in a database, which it recovers from 14:31:52 <TrueBrain> as it is UDP, nobody noticed it was gone 14:32:07 <TrueBrain> for the first, it only hurts if someone happens to be uploading a new entry 14:32:09 <peter1138> Redis again? 14:32:15 <TrueBrain> which is .. honestly .. though-love for that person 14:32:23 <TrueBrain> no, DynamoDB 14:32:51 <peter1138> I use redis for sharing state between instances, and... also way too much more :p 14:32:54 <TrueBrain> I am rather tempted to launch with a single instance, just as that is drastically easier to make 14:33:15 <TrueBrain> yeah, redis is good for that 14:33:29 <peter1138> Cached data that is expensive in SQL, a message queue system, and also Hangfire for scheduled tasks. 14:33:45 <peter1138> Oh, also session state and authentication state. 14:33:56 <TrueBrain> the only thing is .. with redis .. you just moved the problem 1 layer up, as in, if the redis restarts, all data is lost again anyway 14:34:01 <peter1138> Otherwise it stores a giant JWT inside browser cookies which fails 14:34:04 <TrueBrain> (We cannot afford storing the redis data on disk on AWS :P) 14:34:17 <peter1138> Ah. 14:34:24 <peter1138> Yeah, I store on disk as it's no issue. 14:34:38 <TrueBrain> well, depends how you configure redis 14:34:43 <TrueBrain> you can make it store on disk every 5 minutes 14:34:55 <TrueBrain> which means in the worst case it has to recover a 4 minutes 59 seconds old snapshot 14:35:55 <peter1138> Actually I need to move some of my Hangfire tasks to a real database. 14:36:16 <TrueBrain> hmm .. is the pub/sub in redis still not guaranteed? 14:36:18 <TrueBrain> I guess it is .. 14:36:26 <TrueBrain> did they add anything else in place that is guaranteed? 14:36:31 <peter1138> The regular schedule stuff can be set up with 1 API call, the rest is transient. 14:36:52 <TrueBrain> what we would need to have multi-instance support, is some way for all instances to be in sync with each other 14:37:02 <TrueBrain> so, a pub/sub would be ideal 14:37:13 <peter1138> Yeah, I didn't get that far. It seems to need a lot of instances and weird config. 14:37:33 <TrueBrain> I could use a blpop, but that would require all instances to know all other instances :P 14:37:37 <TrueBrain> which is .. slightly less ideal 14:39:46 <TrueBrain> ironically, adding multiple-instance support would require more CPU to run :D 14:42:13 <TrueBrain> Redis Streams seems a proper solution 14:42:47 <TrueBrain> either way, I think I first make the current code PR-able, so we can merge everything and get some real testing done, on a single-instance 14:42:54 <TrueBrain> in the meantime we can work on multiple-instance support 14:48:59 <TrueBrain> pretty happy with the benchmark results like this .. makes me comfortable enough to at least release it for nightlies, honestly :) 14:51:52 <TrueBrain> https://atheme.github.io/atheme-open-letter/ <- the story continues ... 14:54:35 *** ChanServ sets mode: +v peter1138 14:54:35 *** ChanServ sets mode: +v DorpsGek 14:54:35 *** ChanServ sets mode: +v orudge 14:54:35 *** ChanServ sets mode: +v michi_cc 14:54:35 *** ChanServ sets mode: +v Terkhen 14:54:35 *** ChanServ sets mode: +v planetmaker 14:54:35 *** ChanServ sets mode: +v Rubidium 14:58:46 * LordAro raises eyebrow 15:26:32 <milek7> huh 15:26:33 <milek7> https://github.com/audacity/audacity/discussions/932 15:29:26 *** Soni has quit IRC 15:32:01 *** nielsm has joined #openttd 15:40:46 *** Wormnest has joined #openttd 15:41:58 <TrueBrain> Some reactions are priceless .. you don't hear those on CPython :p 15:42:07 <TrueBrain> People love their pitchforks! 15:46:52 *** Soni has joined #openttd 16:00:51 *** ZirconiumX has quit IRC 16:05:27 *** Progman has joined #openttd 16:08:47 *** EER has quit IRC 16:12:31 *** Speeder has joined #openttd 16:22:51 *** peter1138 has quit IRC 16:27:58 *** peter1138 has joined #openttd 16:27:58 *** ChanServ sets mode: +o peter1138 16:28:09 *** frosch123 has joined #openttd 16:44:44 <frosch123> freenode and audacity seem to be reoccuring themes lately :) 16:49:35 *** andythenorth has joined #openttd 16:51:21 *** gelignite has joined #openttd 16:53:23 *** Wolf01 has joined #openttd 16:54:58 <peter1138> Disappointing, my chocolate bar ran out :( 16:55:19 <dwfreed> buy more chocolate bars 16:55:35 <peter1138> This seems good advice. 16:55:47 <peter1138> So after I upgraded my Pi, mpd can longer output to Alsa :/ 16:58:53 <Wolf01> Shitty day, tomorrow shittier because I'll get words from my boss 17:02:16 <TrueBrain> what did you do ...... 17:05:46 <peter1138> Uh oh 17:20:52 <andythenorth> yo 17:32:43 <TrueBrain> this dude again :P 17:43:24 <Wolf01> Oh, i did many things but resolved nothing... and I must wait more days again... we are trying to publish an app to AppStore and it gets refused constantly every time with a different problem 17:43:39 *** Flygon has quit IRC 17:50:26 <andythenorth> should I write html + css? 17:54:42 <TrueBrain> No 17:54:57 <TrueBrain> You are not doing it for us so you should for nobody 17:55:00 <TrueBrain> :p 17:55:10 <TrueBrain> +not 17:55:25 <TrueBrain> Whatever .. English hard 18:01:02 *** tokai has joined #openttd 18:01:02 *** ChanServ sets mode: +v tokai 18:07:54 *** tokai|noir has quit IRC 18:15:56 <andythenorth> I am not doing it for us because I am doing it for other us 18:16:03 <andythenorth> my us not your us 18:48:11 <Wolf01> Ok, enough VR for today, I feel better now 18:48:18 <andythenorth> maybe I have stopped doing css now 18:51:29 <Wolf01> I could trade some development for some css 18:56:19 <peter1138> css in VR? 18:58:25 <andythenorth> ideal 18:59:19 <peter1138> Hmm, maybe I should VLAN my other services too. 18:59:23 <peter1138> Now that I know it works. 19:01:03 *** HerzogDeXtEr has quit IRC 19:09:25 * andythenorth cheese and pasta 19:09:29 <andythenorth> such news 19:10:12 <Rubidium> michi_cc: can you confirm whether line 401 of newgrf_text can be removed? You changed the type of 'd' and for this type ++ is defined as a no-op, so it is practically pointless. What I am wondering is whether it has been left by mistake, or something else might be wrong there 19:12:27 *** Wolf01 has quit IRC 19:13:09 *** Wolf01 has joined #openttd 19:13:59 <Wolf01> <peter1138> css in VR? <- firefox had that 3D visualization for css iirc, it would be cool to use it in VR 19:15:11 <michi_cc> Rubidium: I think it can be removed. I think I just tried to not touch more lines than necessary. 19:21:57 *** jottyfan has joined #openttd 19:32:11 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JGTAT 19:32:12 <DorpsGek> - Update: Translations from eints (by translators) 19:32:18 <TrueBrain> thank you eints!!! 19:32:31 * andythenorth looks at issue count 19:32:36 <TrueBrain> stop doing that 19:32:37 <andythenorth> random dice roll for closing some? 19:32:48 <TrueBrain> we closed one today, jobs done 19:32:56 <andythenorth> one a day 19:33:00 <andythenorth> keeps the doctor away 19:33:09 <TrueBrain> keeps the andy away, you ment 19:33:10 <TrueBrain> :P 19:33:11 <TrueBrain> meant 19:33:13 <TrueBrain> grr, typing 19:35:22 <TrueBrain> okay, using redis for the game coordinator is not even that difficult .. the main thing is when one instance of the gc receives a packet that should be handled by another .. that is just a matter of putting it on a queue 19:35:27 <TrueBrain> for another to pick up and process instead 19:35:51 <TrueBrain> basically only happens for packets < 50 bytes, so that is easily done 19:36:57 <TrueBrain> the other "big" thing is that all instances need to know all the join-keys and meta-data 19:37:48 <TrueBrain> so horizontal scaling mostly works based on the amount of clients .. the amount of servers is limited .. there just is a breaking point after which it cannot handle the traffic 19:38:02 <TrueBrain> but we are talking 10k servers here, at least 19:38:10 <TrueBrain> (haven't looked at the upper limit after 10k :P) 19:38:36 <TrueBrain> pretty sure if we need to send 10k servers to the client, we have another issue to fix first :D 19:38:36 <TrueBrain> lol 19:38:56 <TrueBrain> the current 500 servers is already a bit meh :) 19:42:05 <frosch123> i would expect plenty will become friends-only. 19:42:29 <frosch123> so maybe 2k servers, but only 200 public ones, which are sent to all clients 19:42:36 <peter1138> dbg: [net] [udp] removing advertise from master server 19:42:49 <peter1138> Hangs if it can't reach the server, hmm. 19:44:32 <frosch123> oh, i think i forgot to mention, the other day my ipv6 was broken again. and ottd content+server switched to ipv4 instantly :) 19:45:01 *** andythenorth has quit IRC 19:46:09 *** andythenorth has joined #openttd 19:47:04 <TrueBrain> frosch123: nice :D That is good to hear :) 19:47:49 <TrueBrain> okay, non-NewGRF servers are only 50 bytes of data 19:47:57 <TrueBrain> and after the first update, NewGRF info is never send again 19:48:05 <TrueBrain> syncing 50 bytes of data, even for 10k servers, isn't an issue 19:48:23 <TrueBrain> now the next problem .. how to recover a crashed instance .. 19:48:30 <TrueBrain> mainly: are join-keys sticky or not :P 19:49:38 <peter1138> How often does it crash? 19:49:41 *** sla_ro|master has quit IRC 19:51:00 *** andythenorth has quit IRC 19:51:00 <TrueBrain> in theory, never 19:51:32 <TrueBrain> (if it does, Sentry notifies me, and I mostly fix the reason it crashes quickly .. so in a few weeks, it is a rare event) 19:51:45 <TrueBrain> but, it can happen :) 19:52:13 <TrueBrain> everything is self-healing atm :) 19:53:31 <TrueBrain> I think the easiest way is that a server that is reconnecting doesn't reset his join-key, and if the join-key and the public IP are the same, the server keeps it 19:53:47 <frosch123> hmm... stupid idea: can you make the join-key an encrypted version of the data? 19:53:53 <TrueBrain> that way even a TCP reset, for what-ever reason, would recover 19:54:00 <TrueBrain> frosch123: of what data? 19:54:03 <frosch123> then you can recover all data with your private key from the join key 19:54:27 <frosch123> i mean: could join keys be like browser cookies. they contain all the info 19:54:31 <frosch123> no storage on server 19:55:02 <TrueBrain> there is no data to store, basically 19:55:15 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9296: Lgtm2 https://git.io/JGThL 19:55:15 <peter1138> The join key is the data. It's not a crypto key. 19:55:32 <Speeder> anyone ever made an nml parser that is not the official nml project? 19:55:42 <TrueBrain> the only information we get is the server-info; but that we cannot use as join-key ofc, as it changes all the time :) 19:55:43 <Speeder> and if not... can the official nml project be used to somehow parse nml? 19:55:44 <frosch123> i thought there was some mapping: join key -> server ip/port 19:56:10 <TrueBrain> hmm, ish 19:56:23 <frosch123> Speeder: nml uses ply, you can just reuse the grammar 19:56:35 <TrueBrain> for direct-connect, the GC tracks per join-key what the server ip/port is (if direct-connect is possible) 19:56:41 <Speeder> that helps :) 19:56:51 <frosch123> Speeder: https://github.com/OpenTTD/nml/blob/master/nml/parser.py 19:57:14 <TrueBrain> frosch123: but the storing of that data is not really a problem; more what I wonder about, how quickly an "invite code" (read: join-key) should invalidate 19:57:25 <TrueBrain> for a public server I would expect it to stay the same for ever and ever, basically 19:57:29 <peter1138> The join key should usually be quite short too. 19:57:37 <TrueBrain> where for a invite-only server, I might want to rotate it more often 19:58:14 <Speeder> seemly you used the yacc part of it 19:58:25 <Speeder> so... can any yacc implementation read nml? 19:58:33 <Speeder> (assuming I code the grammar) 19:58:34 <frosch123> let the server choose the expiration time? 19:58:51 <TrueBrain> in what form would you imagine that? 19:59:08 <TrueBrain> I was thinking a refresh-icon next to the invite-code, which causes it to change? 19:59:16 <TrueBrain> switching to private and back to invite-only ? 19:59:35 <frosch123> Speeder: it's LL(1) compatible. you do not need dynamic type information like in c++ to parse it 19:59:53 <Speeder> no idea what is LL(1) 20:00:11 <Rubidium> can there be a grace period for which two join keys could be valid? In that case maybe more something akin LetsEncrypt so they are forced to update the join key "somewhat" regularly. Or is that going to be a huge PITA for the server owners? 20:00:32 <TrueBrain> I can imagine people putting their join-key on their webpage 20:00:32 <Speeder> it is I want to write a GUI nml editor with Godot 20:00:44 <Speeder> trying to figure out then how to parse nml with godot 20:00:44 <frosch123> it's a parser strategy. one which lex/yaxx, flex/bison/, ... most other support 20:00:51 <Speeder> ah 20:01:06 <Speeder> so anything that can parse LL(1) can parse nml? 20:01:16 <frosch123> Speeder: nml contains some generators to write look-up tables for reserved words for various editors 20:02:09 <Speeder> what you mean by that? 20:02:20 <frosch123> https://github.com/OpenTTD/nml/tree/master/nml/editors 20:02:38 <frosch123> kate, notepad++, visualstudio (really?) 20:02:46 <frosch123> for syntax highlighting 20:03:29 <Rubidium> TrueBrain: if you want the join-key to be stable, then the server should probably being able to prove that is actually is that server, so it also works with IP changes and the likes, but how would you go about proving that? (Probably some crypto) However, how would you handle sharing that configuration between instances at the same time. That might get messy pretty quickly when people misconfigure their 20:03:35 <Rubidium> servers 20:03:48 <Speeder> I don't want to make a syntax highlighter though 20:03:53 <Speeder> I want to make a GUI editor 20:03:54 <TrueBrain> I think you are greatly overthinking it now :) 20:04:05 <Rubidium> that's my gift ;) 20:04:14 *** hryniuk has joined #openttd 20:04:21 *** hryniuk has left #openttd 20:04:25 <TrueBrain> my initial idea is to do something very simple: you tell us your last join-key, and if your public-ip + local port is on-file with the GC based on that join-key, you can reuse it 20:04:32 <TrueBrain> otherwise, we give you a new one 20:04:43 <TrueBrain> as this is only to bridge short restarts of either the GC or server 20:04:54 <TrueBrain> that will be fine for the public servers 20:05:11 <frosch123> TrueBrain: what is your use-case for invalidating invite codes? i was thinking of the streamer thing 20:05:16 <glx> use blockchain on GC ;) 20:05:27 <TrueBrain> I can imagine you had a game with some friends, lets call them co-developers 20:05:28 <frosch123> let all your friends join before the plebs notice 20:05:35 <TrueBrain> and the one after that, you want to play with your true friend, say, Xaroth 20:05:42 <TrueBrain> in that case I don't want you guys to still be able to join :P 20:05:48 <frosch123> though, i guess stream delays are very low these days. so a simple timeout makes no sense 20:06:56 <frosch123> TrueBrain: oh, in that case: i would expect the invite code to stay when a server autoresets at some year. but otherwise i would expect a new one for every new game 20:07:08 <TrueBrain> for invite-only, yes 20:07:11 <TrueBrain> but also for public servers? 20:07:18 <TrueBrain> or indeed, should this be an option? 20:07:23 <TrueBrain> yet-another-setting :P 20:07:30 <Rubidium> invite code in the (server?) savegame? 20:07:49 <TrueBrain> lets not talk to much on how to implement, more how the user experience is 20:07:52 <TrueBrain> what is expected 20:07:58 <TrueBrain> as that is what I struggle with :) 20:07:59 <Speeder> frosch123, can the parser by called by other python programs? 20:08:07 <Speeder> if nml is available on the system, that is. 20:08:24 <glx> probably, yes 20:08:29 <frosch123> no idea, try it :) 20:08:47 <Speeder> someone made a proejct t hat let you stuff Python in Godot... so I was wondering: I can do that, and shove nml itself entirely within it. 20:09:06 <Speeder> can make the editor not only edit nml but spit out the complete file afterwards 20:09:19 <Speeder> peopel would just edit t heir project, and send straight to bananas 20:09:29 <_dp_> don't servers already have a somewhat secret id they send? 20:09:53 <frosch123> Speeder: https://github.com/OpenTTD/nml/blob/master/nml/main.py#L402 <- there the parser is caleld 20:10:08 <TrueBrain> hmm, I guess for me: I join either a public server, or a friends game, if that makes sense 20:10:12 <frosch123> after that you have the AST. no idea whether the AST is usable for you, or whether it is too compiler-specific 20:10:19 <TrueBrain> so a public server, I don't care what game it is running, I want to join that server, as I liked the people there 20:10:24 <TrueBrain> but for invite-only games, I care about the game 20:10:28 <TrueBrain> when ever the game is running, I want to join it 20:10:36 <Speeder> ok, I will try something quite mad then :D 20:10:56 <TrueBrain> does that make any sense? (might be just in my mind that it does :P) 20:11:12 <Rubidium> TrueBrain: I reckon public like it is now; as long as the IP and port do not change, you can still join it with the last join key. Invite only just reset the key every time the server starts (e.g. NetworkInitGameInfo) 20:11:51 <Rubidium> Though if people keep switching between invite only and public, should the public join key remain valid between a while on invite only? 20:11:51 <frosch123> Speeder: nmlc has an option --debug-parser that may dump something 20:12:36 <TrueBrain> Rubidium: I think it should stay the same, yes. As you want to join the game if you leave 20:12:42 <TrueBrain> you don't care where it is hosted at that point in time, I guess 20:13:18 <Rubidium> Now, if you have last joined a server, it will remain "valid". If the join keys get reset, then the last joined server will become way less useful. So that's something to think about as well 20:13:57 <TrueBrain> the other use-case in my mind: you and I play an invite-only game, call it a night. The next day, we start it back up .. if we had Steam integration, it was simple 20:14:04 <TrueBrain> but as we don't (yet) .. what is expected here? 20:14:10 <TrueBrain> same invite-code? 20:14:18 <TrueBrain> can I just join the last-played-"server"? 20:15:11 <TrueBrain> (just thinking as a player here; what do I expect the system to do for me :D) 20:17:32 <Rubidium> as a player, I would expect the last joined server to just remain valid regardless whether the server owner changed the status from public to invite only. After all, that server is still active, right? Though from the server owner's perspective I could imagine the invite code to be linked to the save game, which can (or cannot) be transfered to another server (so no idea what the default should be for 20:17:35 <TrueBrain> and if you do allow it, how long should we "reserve" such invite code? A day? a week? a month? 20:17:38 <Rubidium> that) 20:17:40 <frosch123> how about: the server keeps it's invite code forever. there is a "reroll code" button in the server gui 20:18:18 <TrueBrain> in the end, what I struggle with .. is an invite-code "computer" bound, or "game" bound, or a combination of both? 20:18:39 <frosch123> the "play with disjunct groups of friends" is weird to me. then you would need profiles to switch fore and back, i.e. different openttd.cfg 20:19:03 <TrueBrain> what do you mean, sorry? 20:19:07 <frosch123> i think openttd.cfg-bound is the most intuitive option 20:19:23 <TrueBrain> for public-servers, yes .. for invite-only games .. not sure :) 20:19:30 <frosch123> when people want to play with different groups of friends, they can start with different openttd.cfg 20:19:52 <frosch123> TrueBrain: i think also for invite-only. by default reuse the code from last time. offer a button to reroll 20:20:18 <frosch123> i would consider it rare, that you want to exclude people you played with before 20:20:35 <TrueBrain> there are always passwords 20:21:25 <frosch123> i am more worried about the privacy nerds :p tracking of ottd servers :p 20:21:57 <frosch123> Speeder: "nmlc -d" prints a tree to console 20:22:11 <TrueBrain> okay, lets go with openttd.cfg-bound .. that leaves one question for me: if your public-ip changes, should the invite-code remain valid? Or is it okay to reset it at that point? 20:22:19 <Speeder> can nlm work aspure python? 20:22:31 <Speeder> just so I can be lazy and avoid figuring out how to compile stuff with godot 20:22:40 <TrueBrain> I am thinking about "a game with my friends every night" use-case again, where I would expect people behind a CGNAT to have a different public IP every night 20:23:04 <frosch123> TrueBrain: i thought the whole point was to keep the invite code valid in that case :) 20:23:25 <TrueBrain> well, that brings me to the next problem .. storing the invite-code in the openttd.cfg alone might not be sufficient 20:23:31 <TrueBrain> as people tend to copy those files left and right 20:23:34 <TrueBrain> our bug-tracker is full with them 20:23:49 <frosch123> and with passwords in them :p 20:24:06 <TrueBrain> so ideal I have something to validate the invite-code, outside openttd.cfg 20:24:12 <TrueBrain> public IP is one of those easy-to-use values 20:24:15 <TrueBrain> but user experience suffer 20:24:23 <TrueBrain> hence the question, what is the expectation here :) 20:24:39 <TrueBrain> but you suggest to just assign an invite-code to a person, and as long as he doesn't hit "change it", keep it that 20:24:50 <TrueBrain> which is very easy to explain to people :P 20:24:58 <frosch123> i would go for: make the positive case as easy as possible. if someone is malicious, people can just reroll their code 20:25:38 <frosch123> something that is easy to explain, and works for 99% of the people 20:25:39 <TrueBrain> what if two servers are online with the same invite-code? 20:26:07 <glx> gc bug I'd say 20:26:16 <TrueBrain> no, we just said it is in the openttd.cfg 20:26:19 <TrueBrain> so that is not a gc bug 20:26:44 <glx> but how gc/openttd can determine the right server then ? 20:26:52 <TrueBrain> my question, yes 20:27:17 <frosch123> can you distinguish the cases "two servers want to register the same code" and "one server got diconnected, switched their mobile connection, and reconnect with new ip"? 20:27:24 <Speeder> alright, maaned to put python in godot 20:27:28 <Speeder> managed* 20:27:31 <frosch123> otherwise the only option is: the last one wins 20:27:32 <TrueBrain> frosch123: depending on timing, yes :) 20:27:49 <TrueBrain> I was more thinking of: I copied someones openttd.cfg and started my server :P 20:28:09 <TrueBrain> to go back to the streamer example: I see the invite-code, so I setup a server with the same one 20:28:10 <frosch123> yes, i know. but user problem :) 20:28:22 <TrueBrain> well, I can avoid that case easily 20:28:27 <TrueBrain> just send a cookie too 20:28:29 <TrueBrain> which is never shown 20:28:32 <TrueBrain> only stored in openttd.cfg 20:28:51 <frosch123> have a "secrets.cfg" next to openttd.cfg? 20:29:12 <frosch123> we already have separate config files for other thigns 20:29:38 <frosch123> would also be smarter for passwords :) 20:29:39 <TrueBrain> would also mean we can move network_id away from it :P 20:29:44 <TrueBrain> and passwords, yes :P 20:30:06 <TrueBrain> it is a dirty solution, but one that might be more clear to many users 20:30:22 <TrueBrain> okay, so that would work .. on first registration, send join-key + cookie to server 20:30:26 <TrueBrain> user only ever sees join-key 20:30:31 <TrueBrain> on next registration, join-key + cookie is given 20:30:36 <TrueBrain> if they match, it is allowed 20:30:39 <TrueBrain> otherwise a new one is assigned 20:30:55 <TrueBrain> if in the unlucky event 2 join-keys with valid cookies register, the last one wins (and the first one gets disconnected) 20:31:04 <TrueBrain> the cookie is just some crypt over the join-key btw 20:31:11 <peter1138> This must be a solved problem already? 20:31:14 <TrueBrain> with some secret only the GC knows, ofc 20:31:25 <TrueBrain> peter1138: it is not a problem; it is choices :) 20:31:37 <TrueBrain> what do we expect the system to do in cases :) 20:31:58 <TrueBrain> the current "a new join-key on every server-start" is really annoying, for example :P 20:32:09 <frosch123> if clients can identify servers, they could also remember server/company passwords 20:41:25 <TrueBrain> okay, yet-another-change-to-the-gc-protocol it is :P 20:41:29 <TrueBrain> I had to make another change anyway too 20:43:05 <TrueBrain> I realised that if the client sends his game-version when requesting the server-listing 20:43:13 <TrueBrain> we can prioritize the one that is matching 20:43:48 *** andythenorth has joined #openttd 20:46:41 <TrueBrain> okay, will implement this tomorrow so we can try it out :) Tnx all, useful conversation :) 20:46:45 <Xaroth> wait, since when are we true friends, TrueBrain? 20:46:51 <TrueBrain> way too late 20:47:02 <TrueBrain> like ... not even in the ballpark to give a remark on it now 20:47:05 <Xaroth> pff 20:47:21 <TrueBrain> you had an oppurtinity 20:47:26 <TrueBrain> but .. nope 20:47:30 <TrueBrain> you had to be busy with other shit 20:49:11 <TrueBrain> owh, hmm .. this openttd.cfg-bound idea does mean invite-codes should never be reused, I guess 20:53:02 *** jottyfan has quit IRC 20:53:12 <orudge> There we go, one nicely signed openttd.exe (well, three actually) 20:53:23 <TrueBrain> oeh, got to try that 20:53:32 <orudge> Though of course it's the installers that may be more interesting 20:54:06 <TrueBrain> takes a while to start ... hello game, are we starting ? 20:54:11 <TrueBrain> ah, still a blue screen :P 20:54:13 *** iSoSyS has joined #openttd 20:54:23 <TrueBrain> at least it has a publisher now :) 20:54:44 <TrueBrain> and in theory, the more people start the game 20:54:50 <TrueBrain> the less it will show up 20:55:33 <TrueBrain> and yes, installer will be fun :D 20:57:05 <TrueBrain> https://www.virustotal.com/gui/file/e889255d88cfa6e513089bd8a33d325fcdb5806f3dbbdb0e67171b7a4d73550d/details <- w00p, cert is recognized :) 20:58:34 <LordAro> woo 20:59:19 *** Samu has quit IRC 21:00:52 <TrueBrain> okay, I guess the join-key can just be the current time in unixtimestamp .. minus some code to avoid the "same server at the same second" issue .. encoded in some nice format to make it look small and special like I do now .. 21:01:02 <TrueBrain> and the secret is a hash over that + a secret only the GC knows 21:01:05 <TrueBrain> should be sufficient .. 21:01:11 <TrueBrain> gives short invite code 21:01:20 <TrueBrain> (roughly 7 characters) 21:01:49 <frosch123> lol, who entered "copyright 2002-..." :p 21:01:51 <TrueBrain> and they can live foreverrrrrrrrr 21:01:55 <frosch123> ottd is from 2004 21:02:12 <TrueBrain> I would guess the project started in 2002? :P 21:02:25 <TrueBrain> its even in our language files 21:02:49 <glx> I only changed it to auto set the current year, didn't touch the 2002 21:02:50 <frosch123> i never read that :p 21:03:26 <glx> well I think it uses commit year for current, but whatever 21:04:47 <TrueBrain> https://github.com/OpenTTD/OpenTTD/blame/efaeb275f78e18d594d9ee8ff04eccd2dc59512c/lang/english.txt#L191 <- as far as we can look back it is the case :) 21:04:57 <TrueBrain> sorry :D 21:05:40 <frosch123> that string is not yet in 0.1.4 21:06:04 <glx> many changes are in the lost history ;) 21:06:12 <TrueBrain> just 900 commits 21:06:15 <TrueBrain> yet we miss them so often :P 21:06:24 <TrueBrain> pretty sure otherwise it was another commit being blamed for it all :D 21:08:19 <frosch123> i like how the string is called "windows_95_conversion_by" :p 21:08:54 <TrueBrain> I like it is already "The OpenTTD team" 21:09:40 <TrueBrain> okay, I didn't like my unixtimestamp idea that much .. so better idea: (time.time() / 3600) to bytes + 3 random bytes, encoded as a string 21:09:59 <TrueBrain> so we need to check for duplicates in that hour, but after that, the code is unique for ever and ever 21:10:22 <TrueBrain> (random bytes will most likely be pid + increasing number :P) 21:10:29 *** gelignite has quit IRC 21:11:21 <peter1138> cat /etc/debian_version 21:11:22 <peter1138> 10.5 21:11:23 <peter1138> uh oh 21:14:49 <TrueBrain> hmm, no, that is still a stupid idea :D Codes look really similar that way :P 21:14:50 <TrueBrain> lol 21:15:17 *** ChanServ sets mode: +v peter1138 21:15:39 <peter1138> oh really 21:15:57 *** iSoSyS has quit IRC 21:16:19 <TrueBrain> using a hash would be simplest, but .. that makes for long invite codes :'( 21:21:09 <frosch123> why is a hash longer than a date? 21:21:22 <frosch123> you can pick an arbitrary size for the hash 21:21:25 <Rubidium> TrueBrain: if they look to much alike, you could also move some bits around... but I guess that's already some sort of hashing 21:21:54 <TrueBrain> Rubidium: yeah, but I am fine with that .. just looking into what I could use for that 21:22:03 <TrueBrain> and I meant common hashes like SHA1 etc frosch123 :) 21:23:07 <TrueBrain> any suggestions are welcome btw 21:23:46 <Rubidium> what about python's hash (for objects) and then base64 encoding that? 21:24:06 <frosch123> you need a implementation in ottd, right? 21:24:10 <TrueBrain> frosch123: no 21:24:17 <TrueBrain> Rubidium: not base64, but something similar 21:24:32 <TrueBrain> and I am not sure hash() is collision-free for such a small space 21:24:35 <TrueBrain> which is a bit my worry 21:24:40 <frosch123> if the server uses it, what is wrong with just using random? :p 21:24:44 <TrueBrain> as these codes live for-ever, they should be somewhat collision-free in that space 21:24:50 <TrueBrain> frosch123: it has to be unique for-ever 21:24:56 <TrueBrain> pretty sure random is not going to do that on its own 21:25:19 <Rubidium> then shake.digest(length-in-bytes-you-want)? 21:25:35 <TrueBrain> Rubidium: yeah, was just looking at shake .. but I am having a hard time finding the module in Python .. which is funny :P 21:25:43 <frosch123> is it important that codes are not predictable? 21:25:52 <frosch123> timestampe are pretty predictable 21:26:00 <Rubidium> isn't it in hashlib? 21:26:01 <frosch123> unless the hash is strong enough 21:26:05 <Beer> TrueBrain: I know I am *very* late to the party, but Redis can combine snapshot and journal, making loss "uncontrolled restarts" minimal 21:26:11 <TrueBrain> frosch123: no, it does not need to be a secret 21:26:15 <Beer> loss on* 21:26:27 <TrueBrain> so it can be very predicitable 21:26:31 <TrueBrain> that is not relevant in this case :) 21:26:50 <TrueBrain> but I just generated 2 servers, one with code Mdvb4kxeJ and one with Ndvb4kxeJ 21:26:55 <TrueBrain> that does sound less optimal to do :P 21:26:56 <Rubidium> TrueBrain: what's the type of the time / 3600 + 3 random bytes, Something uint64-ish (but then the python variant?) 21:27:04 <TrueBrain> bytes 21:27:05 <Beer> https://redis.io/topics/persistence 21:27:11 <TrueBrain> Beer: IO is the issue :) 21:27:36 <TrueBrain> so we cannot constantly write to disk, basically 21:28:08 <TrueBrain> so snapshots-only is basically the only way to go .. the journal is constant disk I/O :) 21:28:21 <Beer> You can batch writes to disk to alleviate that, see what is said about fdisk 21:28:45 <Beer> Meaning you can lose up to *disk write interval* data 21:28:50 <TrueBrain> exactly ;) 21:29:33 <Beer> Redis has the ability to be very lose or very paranoid. It's one of the most flexible tech out there IMHO 21:29:51 <TrueBrain> I was not debating the capabilities of redis 21:30:24 <TrueBrain> Rubidium: shake basically just removes part of the output string 21:30:30 <TrueBrain> that is not .. really .. what we are looking for :D 21:30:31 <TrueBrain> lol 21:30:32 <TrueBrain> funny :) 21:30:40 <TrueBrain> I didn't know shake .. just read it on the Python manual page when you mentioned it :P 21:31:32 <Beer> You just can't beat RAM work + occasional disk sync... unless you go beyond physical reality :D 21:31:59 <frosch123> how about adding reduncancy then. take the timestamp, bit-rotate it by a random amount of bits, and then prefix the whole thing with the amount of bits 21:32:38 <frosch123> that makes the code slightly longer, it appears to be different each time (while it really isn't) 21:32:48 <frosch123> and all the info is still contained 21:33:26 <TrueBrain> blake2b does give more what I expect 21:33:30 <frosch123> basically, obfuscate it, and include the method for obfuscation 21:33:50 <TrueBrain> frosch123: something like that I was looking for, yes :) 21:34:03 <TrueBrain> it just has to look random 21:34:09 <TrueBrain> can be anything otherwise :D 21:34:26 <frosch123> i have no idea how much collission-avoidance all those haslib things guarantee 21:34:27 <Rubidium> though with 32 bits of shifting, you'd still get a 1/32 chance the "high" part looks the same 21:35:09 <TrueBrain> all I want that a user cannot start to guess invite codes, basically, by doing something very silly like changing the first letter 21:35:47 <TrueBrain> anyone that really wants to, yeah, I do not care that much 21:35:53 <TrueBrain> but it shouldn't be obvious :P 21:38:11 <Rubidium> how many input bytes do you need for your (not quite) base64 to give the wanted number of output characters? 21:38:11 <andythenorth> oof sleeping? 21:38:13 <andythenorth> yes 21:38:17 *** andythenorth has quit IRC 21:38:36 <TrueBrain> https://github.com/TrueBrain/game-coordinator/blob/master/game_coordinator/application/helpers/encode.py <- encoder btw 21:38:51 <TrueBrain> basically, the alphabet minus some annoying ones 21:39:28 <Rubidium> and you want 7 output characters? 21:39:29 <TrueBrain> and ... ideal we have somewhere between 6 and 7 output chars 21:39:34 <TrueBrain> which gives ~5 bytes 21:39:45 <TrueBrain> (of input) 21:41:40 <frosch123> hey, if you can make HUMAN_ENCODE_BASE a prime, you can just make sure that the input has the milliseconds has highest bits 21:41:53 <frosch123> so, bit-reverse the input, and then do your // with primes 21:42:20 <frosch123> that way the every-changing milliseconds will change the whole result 21:42:47 <TrueBrain> "has the milliseconds has highest bits" <- what do you mean? 21:43:25 <frosch123> oh wait, you encode it has little-endian 21:43:40 <TrueBrain> your english is not getting better, sorry :P 21:43:58 <frosch123> and you already have 53 chars, which is prime 21:44:04 <TrueBrain> well, they are 54 21:44:08 <TrueBrain> right? 21:44:19 <frosch123> my python said 53 21:44:27 <TrueBrain> you are correct 21:44:32 <TrueBrain> my editor is playing tricks on me 21:44:40 <TrueBrain> but I do not follow what your idea is 21:44:45 <TrueBrain> too much steno :) 21:44:54 <frosch123> so that means, if the lowest bits of "value" contain the milliseconds, the whole result should change with the milliseconds 21:45:06 <frosch123> since they will then rotate all following characters 21:46:02 <Rubidium> also, shuffle the encode chars... then subsequent numbers will not look subsequent ;) 21:46:04 <TrueBrain> well, milliseconds is not ideal, but it is a smart idea 21:46:11 <frosch123> ah, damn, i got it wrong again :p 21:46:21 <TrueBrain> yeah, but I now understood you 21:46:22 <TrueBrain> so it is fine :) 21:46:26 <frosch123> milliseconds has to be the highest bits of "value" 21:46:40 <TrueBrain> there is a clear "big" in that file :P 21:46:47 <TrueBrain> but it is late, so what-ever :) 21:46:50 <TrueBrain> but indeed, if I put the counter in front 21:46:53 <TrueBrain> it changes completely 21:47:02 <TrueBrain> which is sufficient for the goal we have 21:47:55 <TrueBrain> something silly like this: https://gist.github.com/TrueBrain/af43821f1929e558820131d795ec097f 21:48:20 <TrueBrain> counter + pid are just a local-unique value for that hour 21:48:25 <TrueBrain> might replace it for anything else, honestly 21:48:39 <TrueBrain> I just need a way that multiple-instances still create unique values :) 21:48:57 <frosch123> add a comment "put the counter first, and make HUMAN_ENCODE_BASE prime, so the encodings look good", then you can feel smart in some future :p 21:48:59 *** m1cr0man has quit IRC 21:49:23 <TrueBrain> too bad we don't give credits in code .. but yeah, the prime thing is nice 21:49:34 <TrueBrain> did not think of it, silly enough 21:50:10 <frosch123> nah, i studied that. it's standard 21:50:35 <TrueBrain> it generates invite-codes like "JmHmAGb" btw 21:50:45 <TrueBrain> small, yet unique till the end of time 21:50:54 *** m1cr0man has joined #openttd 21:50:57 <TrueBrain> well .. till time.time // 3600 is more than 256**3 21:51:14 <TrueBrain> 1915 years from unixtimestamp-start 21:51:26 <TrueBrain> so .. 21:51:28 <TrueBrain> @calc 1970 + 1915 21:51:29 <DorpsGek> TrueBrain: 3885 21:51:38 <TrueBrain> owh, Artea would have told me to use my DHCP server, I am sorry 21:52:25 <TrueBrain> this btw assumes we never have more than 64k registrations in an hour 21:52:41 <TrueBrain> should be fine, right? Till someones server constantly re-registers ... :P 21:53:15 <TrueBrain> I will add "an IP can only register once every 5 seconds" backoff thing to it, done :) 21:54:02 <TrueBrain> might take a nibble from the time, and use that for server-id instead .. we will never run more than 16 GC-instances at the same time :P 21:54:13 <TrueBrain> means in 119 years it needs to be replaced 21:54:26 <TrueBrain> well, no, not in 119 21:54:29 <TrueBrain> @calc 1970 + 119 21:54:29 <DorpsGek> TrueBrain: 2089 21:54:32 <TrueBrain> in 2089 :) 21:54:59 <TrueBrain> that day invite-codes simply grow by 1 char :P 21:55:07 <frosch123> the old masterserver lasted 16 years 21:55:33 <Rubidium> why then? Won't the keys just grow? Or otherwise, you can just rollover to 1970 and gain another 50 years 21:55:34 <TrueBrain> yeah .. it is the reason I didn't want to do a 32bit unixtimestamp, I have to admit :) 21:55:51 <TrueBrain> (int(time.time()) // 3600).to_bytes(3, "big") <- crashes when it goes over 256**3 :P 21:56:14 <TrueBrain> so before 2089 it needs to be replaced by .. "something" :) 21:56:31 <TrueBrain> given it took us 16 years to replace the master-server, as frosch123 just pointed out, it is something to consider :D 21:56:51 <TrueBrain> if it would break in 2038, for example, I would be a bit worried :P :P 21:57:26 <Rubidium> and even then..., if it rolls over... how likely is it that servers will still remain after 100+ years? 21:57:36 <frosch123> TrueBrain: well, you could live till 2089 21:57:44 <TrueBrain> I might get blamed, you mean? 21:57:48 <TrueBrain> shiiittttttttt 21:57:56 <TrueBrain> Rubidium: it doesn't roll over, it crashes! 21:57:59 <TrueBrain> that is my whole point :) 21:58:11 <Rubidium> so fix that in 2088 ;) 21:58:20 <TrueBrain> glad you caught up with the joke :) 21:58:20 <Rubidium> just a mod 256**3 21:58:39 <TrueBrain> I can make invite codes even 5 chars now :P 21:58:47 <TrueBrain> but that looks "unbelievable" 21:59:13 <Rubidium> that'd almost make brute force somewhat feasible 21:59:24 <TrueBrain> yeah, except the GC would rate-limit those attempts 21:59:34 <TrueBrain> the nice thing about having a centralized component :P 21:59:46 <Rubidium> also for clients trying to join unlisted servers? 21:59:53 <TrueBrain> yes, ofc 21:59:58 <_dp_> are you trying to reinvent uuid? :p 22:00:13 <TrueBrain> klepel .. klok .... 22:00:15 <Rubidium> ah well, my /64 IPv6 should give me plenty of IPs ;) 22:00:16 <_dp_> also thing with string codes is... will you filter out profanities? :p 22:00:19 <TrueBrain> (sorry, the translation is lost on me) 22:00:28 <TrueBrain> Rubidium: yup, it would :) 22:00:34 <TrueBrain> if someone wants to be evil, he really can :) 22:01:22 <frosch123> TrueBrain: they 22:01:32 <frosch123> i will correct you everytime now :p 22:01:33 <Rubidium> _dp_: that sounds unfeasible to me 22:01:38 <TrueBrain> frosch123: ffinnneee 22:01:41 <TrueBrain> mostly as you are right :P 22:02:20 <TrueBrain> hihi, reminds me, for my last job I made a password generator, which picks 3 random dutch words from the dictionary of size 5 and over, concatenates those, and adds a few numbers and chars 22:02:22 <TrueBrain> works really well 22:02:30 <TrueBrain> but .. very quickly I found out that a lot of those passwords 22:02:32 <TrueBrain> are .. euh ... 22:02:34 <TrueBrain> not suitable for customers 22:02:44 <TrueBrain> amazing how random tends to generate really bad things 22:03:01 <TrueBrain> you would almost think that most of the dictionaries are filled with not-so-nice-words 22:03:49 <frosch123> haha, when people added ime support at my old company, they were told to never ever enter random chinese chars for testing 22:04:04 <frosch123> too risky they would mean something 22:05:00 <TrueBrain> ugh, why do I keep forgetting that "a << b + c << d" doesn't do what I expect it to do ... 22:05:05 <TrueBrain> gives very long numbers :P 22:05:50 *** Wolf01 has quit IRC 22:06:39 <Rubidium> although removing vowels would help with in profanity as full words, but... will people's minds just start filling them in? Oh cck 22:07:13 <frosch123> ottd players are used to the townname generators 22:07:13 <Speeder> ok, Python for Godot is broken 22:07:23 <frosch123> so they won't mind offensive words in hashes 22:07:25 <TrueBrain> frosch123: haha, nice example :D 22:07:34 <Speeder> I will attempt instead to rewrite the grammar for C version of Flex + Bison 22:07:40 <_dp_> vovels seem kind of ok solution, at least you can always blame their dirty minds :p 22:08:07 <frosch123> night 22:08:10 *** frosch123 has quit IRC 22:09:42 <_dp_> looking at some town name grfs it may seem players will be happy if it always generated only offensive hashes :p 22:10:00 <_dp_> that also sounds like a more interesting problem actually xD 22:11:33 <TrueBrain> okay, this invite-code-generator seems pretty solid now 22:12:02 <TrueBrain> the secret will just be "sha1(join_key + secret)" :P 22:12:03 <TrueBrain> easy enough 22:12:49 <TrueBrain> just a matter of: how long can secret remain a secret :D 22:15:01 <TrueBrain> but that means this information is "storage free" 22:15:10 <TrueBrain> which is nice, as that means everything can burn down, and we can still recover :) 22:15:19 <TrueBrain> hope it never happens ofc, but you get what I mean :) 22:17:04 *** Progman has quit IRC 22:18:29 <Speeder> how https://github.com/OpenTTD/nml/blob/master/nml/parser.py was written? 22:18:40 <Speeder> the original grammar exists somewhere? 22:18:54 *** tokai|noir has joined #openttd 22:18:54 *** ChanServ sets mode: +v tokai|noir 22:22:01 <TrueBrain> right, enough math for 1 day 22:22:02 <TrueBrain> night all 22:25:28 *** nielsm has quit IRC 22:25:49 *** tokai has quit IRC