IRC logs for #openttd on OFTC at 2021-05-26
⏴ go to previous day
00:10:57 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:12:17 *** WormnestAndroid has joined #openttd
00:17:28 *** ericnoan has quit IRC (Ping timeout: 480 seconds)
00:22:16 *** snail_UES_ has quit IRC (Quit: snail_UES_)
00:30:16 *** tokai|noir has joined #openttd
00:30:16 *** ChanServ sets mode: +v tokai|noir
00:37:03 *** tokai has quit IRC (Ping timeout: 480 seconds)
00:50:25 *** Wormnest has quit IRC (Quit: Leaving)
00:59:13 *** ChanServ sets mode: +v tokai
01:06:13 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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 (Ping timeout: 480 seconds)
02:34:52 *** snail_UES_ has joined #openttd
05:01:09 *** snail_UES_ has quit IRC (Quit: snail_UES_)
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
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
09:45:37 <TrueBrain> The drama isn't over yet
09:45:54 <andythenorth> discord for everyone?
09:46:20 <TrueBrain> nothing wrong with IRC; just anything with wanna-be-heroes :)
09:46:37 <andythenorth> oh the problem is the people? :o
09:46:41 * andythenorth falls over in surprise
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:49:22 <TrueBrain> Ubuntu has an IRC council
09:49:35 * andythenorth is too mean with money to hire a web developer
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 (Quit: andythenorth)
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:49 <TrueBrain> drama-free for how many years now? :)
09:53:24 <TrueBrain> hahahaha, that last URL
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 *** ChanServ sets mode: +v tokai
10:29:34 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
10:50:39 *** tokai|noir has joined #openttd
10:50:39 *** ChanServ sets mode: +v tokai|noir
10:57:38 *** tokai has quit IRC (Ping timeout: 480 seconds)
11:09:13 *** peter1138 has quit IRC (Quit: reboooooooot)
11:09:58 <Speeder> freenode hijacked #allegro channel today
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: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:26 <orudge> I will get both of those things sorted after lunch
11:18:32 <orudge> not sure why that appeared
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:15 <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: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: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: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:33 <TrueBrain> in a few days we had as many people idling on OFTC as we did on freenode
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 <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 <DorpsGek> TrueBrain: I have not seen 42.
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 <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 <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:33 <peter1138> It's good. I keep eating it :/
11:55:48 *** snail_UES_ 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: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:20 <TrueBrain> but yeah, they should write a blog about it :)
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: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: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: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:27 <peter1138> I guess they are 1.12.
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:35 <TrueBrain> otherwise I am sure we forget :P
12:51:29 <glx> btw I still don't understand #9291
12:51:55 <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: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 (Remote host closed the connection)
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:35:03 <TrueBrain> okay, so now to send some extra server info ..
13:35:23 <TrueBrain> "socket.accept() out of system resource"
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 (Quit: Stay safe!)
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:40:29 <TrueBrain> @calc (41076 - 21656) / 100
13:40:53 <TrueBrain> it should be / 1000, but I can do that myself :P
13:43:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:43:57 *** WormnestAndroid has joined #openttd
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: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: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: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 (Ping timeout: 480 seconds)
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: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:01 <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:23 <TrueBrain> but okay .. didn't want to rebuild Rome in 1 PR :D
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: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: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:14:07 <TrueBrain> oops, fork-bombed my WSL2 again
14:17:33 *** Speeder has quit IRC (Read error: Connection reset by peer)
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: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: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: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:15 <TrueBrain> which is .. honestly .. though-love for that person
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:02 <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: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: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: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
15:29:26 *** Soni has quit IRC (Ping timeout: 480 seconds)
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!
16:05:27 *** Progman has joined #openttd
16:08:47 *** EER has quit IRC (Remote host closed the connection)
16:12:31 *** Speeder has joined #openttd
16:22:51 *** peter1138 has quit IRC (Remote host closed the connection)
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: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: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 (Read error: Connection reset by peer)
17:50:26 <andythenorth> should I write html + css?
17:54:57 <TrueBrain> You are not doing it for us so you should for nobody
17:55:25 <TrueBrain> Whatever .. English hard
18:01:02 *** ChanServ sets mode: +v tokai
18:07:54 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
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: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 (Read error: Connection reset by peer)
19:09:25 * andythenorth cheese and pasta
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 (Remote host closed the connection)
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:12 <DorpsGek> - Update: Translations from eints (by translators)
19:32:31 * andythenorth looks at issue count
19:32:37 <andythenorth> random dice roll for closing some?
19:32:48 <TrueBrain> we closed one today, jobs done
19:33:00 <andythenorth> keeps the doctor away
19:33:09 <TrueBrain> keeps the andy away, you ment
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: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 (Quit: andythenorth)
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: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 <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: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: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 <Speeder> it is I want to write a GUI nml editor with Godot
20:00:32 <TrueBrain> I can imagine people putting their join-key on their webpage
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: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:38 <frosch123> kate, notepad++, visualstudio (really?)
20:02:46 <frosch123> for syntax highlighting
20:03:30 <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: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:14 *** hryniuk has joined #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: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: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: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:18 <Speeder> peopel would just edit t heir project, and send straight to bananas
20:09:30 <_dp_> don't servers already have a somewhat secret id they send?
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: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:33 <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: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:05 <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: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: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: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:23 <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:47:02 <TrueBrain> like ... not even in the ballpark to give a remark on it now
20:47:21 <TrueBrain> you had an oppurtinity
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 (Quit: jottyfan)
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: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:59:19 *** Samu has quit IRC (Quit: Leaving)
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: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: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: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 (Quit: Stay safe!)
21:11:21 <peter1138> cat /etc/debian_version
21:14:49 <TrueBrain> hmm, no, that is still a stupid idea :D Codes look really similar that way :P
21:15:17 *** ChanServ sets mode: +v peter1138
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: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: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: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: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: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:17 *** andythenorth has quit IRC (Quit: andythenorth)
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: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:24 <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:32 <TrueBrain> my editor is playing tricks on me
21:44:40 <TrueBrain> but I do not follow what your idea is
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: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: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 (Quit: G'luck)
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: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: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: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: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: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: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:30 <TrueBrain> but .. very quickly I found out that a lot of those passwords
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 (Quit: Once again the world is quick to bury me.)
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:10 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
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: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 (Remote host closed the connection)
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:25:28 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:25:49 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵