IRC logs for #openttd on OFTC at 2021-10-27
⏴ go to previous day
00:10:52 *** WormnestAndroid has joined #openttd
01:40:19 *** snail_UES_ has joined #openttd
01:53:36 *** Wormnest has quit IRC (Quit: Leaving)
02:26:33 *** tokai has quit IRC (Quit: c('~' )o)
04:32:00 *** snail_UES_ has quit IRC (Quit: snail_UES_)
04:48:41 *** _aD has quit IRC (Ping timeout: 480 seconds)
06:25:08 *** sla_ro|master has joined #openttd
06:30:43 <DorpsGek> [OpenTTD/OpenTTD] jirislaby opened issue #9659: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji0L9
06:45:26 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9658: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji053
06:47:02 <DorpsGek> [OpenTTD/OpenTTD] jirislaby commented on issue #9658: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji053
06:47:05 <DorpsGek> [OpenTTD/OpenTTD] jirislaby closed issue #9658: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji053
07:23:47 *** WormnestAndroid has quit IRC (Remote host closed the connection)
07:34:15 *** Montana_ has joined #openttd
07:46:25 *** _aD has quit IRC (Ping timeout: 480 seconds)
07:59:46 *** andythenorth has joined #openttd
10:35:51 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9659: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji0L9
10:40:07 <DorpsGek> [OpenTTD/OpenTTD] jirislaby commented on issue #9659: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji0L9
10:40:10 <DorpsGek> [OpenTTD/OpenTTD] jirislaby closed issue #9659: [Crash]: in Blitter_32bppAnim::Draw<(BlitterMode)0> https://git.io/Ji0L9
10:59:59 <DorpsGek> [OpenTTD/OpenTTD] swetr77 opened issue #9660: [Crash]: OpenTTD crashes about 30 seconds after launch. https://git.io/JioGp
11:02:16 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #9660: [Crash]: OpenTTD crashes about 30 seconds after launch. https://git.io/JioGp
11:02:19 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #9660: [Crash]: OpenTTD crashes about 30 seconds after launch. https://git.io/JioGp
11:54:02 *** Etua has quit IRC (Quit: Etua)
12:05:22 *** WormnestAndroid has joined #openttd
12:16:39 *** server01 has joined #openttd
12:18:26 *** server01 is now known as Frank-BTPro
12:23:38 *** Frank-BTPro has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
13:11:24 <DorpsGek> [OpenTTD/OpenTTD] TowkeyMeriam opened issue #9661: [Crash]: Crashed on startup in both Steam and standalone versions https://git.io/JiPj1
13:14:00 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9661: [Crash]: Crashed on startup in both Steam and standalone versions https://git.io/JiPj1
13:16:57 <glx> yeah 12.1 is really needed
13:21:50 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #9661: [Crash]: Crashed on startup in both Steam and standalone versions https://git.io/JiPj1
13:21:53 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #9661: [Crash]: Crashed on startup in both Steam and standalone versions https://git.io/JiPj1
13:44:12 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on pull request #9034: Don't complain that you cannot remove rail/road if it doesn't exist. https://git.io/Ji1Lo
14:22:33 *** andythenorth has quit IRC (Quit: andythenorth)
14:30:03 *** sla_ro|master has quit IRC ()
15:14:47 <_aD> Someone started posting a video tutorial series to the subreddit. Tutorials about all of the different types of signals.
15:22:11 *** Wormnest has joined #openttd
15:29:50 <Timberwolf> They seemed pretty decent and detailed from a cursory inspection. At least they didn't do the usual, "you need these backward-facing signals in front of the station for reasons" thing and explained what the pathfinder is actually doing.
15:29:54 <_aD> Yes. With timing better than any of my schedules!
15:38:33 *** gelignite has joined #openttd
16:11:53 *** Montana_ has quit IRC (Quit: Leaving)
16:33:05 <Eddi|zuHause> currently trying to figure out the signals in satisfactory... they're a bit weird
16:43:08 *** ioangogo has joined #openttd
17:01:19 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:07:10 *** HerzogDeXtEr has joined #openttd
17:14:32 *** sla_ro|master has joined #openttd
17:49:06 *** jottyfan has joined #openttd
17:56:10 *** frosch123 has joined #openttd
18:50:33 <DorpsGek> - Update: Translations from eints (by translators)
18:56:15 *** nielsm has quit IRC (Ping timeout: 480 seconds)
18:58:11 *** andythenorth has joined #openttd
19:01:40 <TrueBrain> "keys" in redis is really expensive; you only want to run it when you really need to
19:01:46 <TrueBrain> so no, that is meant to only run once on startup :)
19:04:05 <andythenorth> lol I'm playing a game to test new Iron Horse
19:04:22 <LordAro> people who are more experienced with docker than me - how do you decide which build dependencies go in the image, and which are downloaded/built/installed when using the image?
19:04:27 <andythenorth> 12 years in I just noticed I'm using an older Horse release :P
19:04:36 * andythenorth wondered why stuff was missing
19:05:05 <frosch123> TrueBrain: yes, but when i read redis docs correctly, it randomly checks 200 keys per second
19:05:22 <TrueBrain> LordAro: your question is a bit hard to parse :P Building deps shouldn't go in an image at all .. as you only need them during building? :)
19:05:34 <frosch123> so the number of expired keys which are not expired has some exponential decay
19:06:21 <frosch123> so, if there are 5k keys in the database, i wonder how many expired keys can be missed for how long
19:06:35 <TrueBrain> not for the time we saw the servers still have shadows ;)
19:10:06 <TrueBrain> btw frosch123 , not sure how far you understand the code, but expiring should almost never happen. It is only useful during crashes and other unexpected events
19:10:52 <frosch123> i assumed it also handles direct servers disconnecting
19:11:43 <LordAro> TrueBrain: docker image is used for building things, not running things
19:11:44 <TrueBrain> there is a disconnect() path that should handle that
19:11:45 <TrueBrain> TCP disconnect, mostly
19:12:16 <TrueBrain> LordAro: ah; well, we lack a bit of context to answer your question really :)
19:12:54 <TrueBrain> but to give examples, emscripten (docker) downloads+installs dependencies when it needs them. Really annoying for us, as it does that every time the CI runs
19:13:13 <TrueBrain> but in their ideology, not everyone needs the same dependencies
19:13:18 <TrueBrain> so on-demand is "better"
19:13:28 <TrueBrain> depends greatly on how you look at it if that is true :)
19:14:57 <frosch123> huh? direct servers have a permanent connection to the gc? i assumed they would only announce every now and then
19:15:10 <TrueBrain> that would be rather expensive :)
19:15:35 <TrueBrain> also, you have to remember that servers that can use direct IP
19:15:39 <TrueBrain> doesn't mean that everyone can make use of that
19:15:45 <TrueBrain> for example, an IPv6-only direct IP server
19:15:57 <TrueBrain> IPv4 users will just try STUN first, TURN after
19:16:50 <TrueBrain> but I also see with IPv4 direct IP servers, that not all IPv4 connections can connect to it .. firewalls blocking it etc
19:18:49 <LordAro> TrueBrain: mm, it works ok for pulling in dependencies that are reasonably quick, but my particular usecase has a very long build/test cycle, so wouls like to minimise as much as possible. so my options are 1) shove as much as possible in the image, and deal with the pain of rebuilding the image to make changes to the dependencies, or 2) acquire dependencies while running the image (prior to software
19:18:55 <LordAro> build) and cache it as much as possible, and deal with the pain of cache misses & broken invalidation
19:19:20 <TrueBrain> it really depends on your use-case. There is no perfect answer :)
19:19:26 <TrueBrain> if your dependencies change rarely, the first might be ideal
19:19:40 <TrueBrain> if developers that use the product constantly change dependencies, strong caching can already do a lot of good
19:20:03 <TrueBrain> for example, I once made a system for Python that created whls out of every dependency that product used, and put that on an internal repository
19:20:09 <TrueBrain> that made "pip install" really really quick
19:20:18 <TrueBrain> just new dependencies were slow .. but that was picked up the next night
19:21:37 <TrueBrain> having really fat docker images is also annoying, as you need to prune regular :P
19:22:09 <LordAro> i have to use msys with docker-windows, there's not a lot i can do about that :)
19:22:16 <andythenorth> deps management is one of the less interesting hard problems
19:22:25 <andythenorth> it's really kinda dull
19:23:40 *** gelignite has quit IRC (Quit: Stay safe!)
19:29:11 <_aD> andythenorth: NPM supply chain exploits are rather exciting, though. In the "keep you up at night" way.
19:31:40 <andythenorth> one security requirement obliges updates of all deps within 14 days
19:31:56 <andythenorth> another requires defence against supply chain attacks by verification and pinning of deps
19:32:15 <andythenorth> not incompatible, but GG
19:32:18 <TrueBrain> I hope the first statement is about "critical security updates"
19:32:23 <TrueBrain> not about any other ;)
19:36:42 <frosch123> did you check whether all you npm deps' authors use 2FA on github?
19:37:52 <frosch123> i like the idea of having a open source library, but publishing binaries with different content :)
19:38:40 <andythenorth> TrueBrain welcome to government frameworks written by external third parties, on lowest-bid basis :)
19:39:51 <TrueBrain> that is idiotic and very insecure
19:40:50 <andythenorth> TBH it got rewritten after a year or so
19:41:05 <andythenorth> I was doing lolz
19:43:42 <frosch123> TrueBrain: i can trigger duplicate entries by starting two servers with the same invite code
19:44:05 <TrueBrain> with a single instance?
19:44:12 <TrueBrain> and you get the GC running locally? :P
19:44:42 <frosch123> no, i just used the real one
19:44:48 <TrueBrain> not even the staging one? :P
19:45:03 <TrueBrain> anyway, two invite codes, that should disconnect one of the two, rightr?
19:45:13 <frosch123> i start two servers, the first one complains "someone stole my code, i am switching to 'local'" and then i just switch back to 'invite only'
19:45:42 <TrueBrain> that kicks off the other again :P
19:45:53 <TrueBrain> hmm, yeah, that only removes the server locally
19:45:55 <TrueBrain> not for any of the other instances
19:46:07 <frosch123> oops, i may be testing incorrectly
19:46:28 <frosch123> i did not epxect "search internet" to still show localhost :p
19:52:21 <frosch123> sorry, i was testing incorrectly
19:52:43 <TrueBrain> no worries; I do that a lot :D
19:53:43 <frosch123> i am not sure whether servers are disconnected correctly when i set one to "public" and the other one to "invite only"
19:53:55 <frosch123> at least neither says "local" now
19:54:02 <TrueBrain> if you see an invite code, the server is registered
19:54:09 <TrueBrain> it bumps it back to "local" when there is an issue
19:59:38 <frosch123> if i try hard enough i can get both servers to think they got a valid invite code
20:01:01 <TrueBrain> guess when you make them rather quickly to be published?
20:02:32 <frosch123> when i select public/invite code it takes about 2 seconds until the invite code is shown
20:02:55 <frosch123> it seems like i can do that for multiple servers in that time window
20:03:14 <TrueBrain> owh, yeah, you are right, the window is like 2 seconds
20:03:22 <TrueBrain> but you can only do it for 2 servers, I think
20:03:25 <TrueBrain> one on each instance
20:05:35 <TrueBrain> (the check for duplicated server is local, instead of global)
20:05:51 <TrueBrain> I think this weekend I will rewrite the core logic of the GC to always bounce via redis, even if the server is local
20:05:54 <TrueBrain> just to remove all this
20:06:01 <TrueBrain> now I know how redis performance, I can do that :D
20:16:11 *** Montana_ has joined #openttd
20:16:33 <frosch123> haha, at least i managed to trigger sentry once
20:16:54 <TrueBrain> as long as you give me clear instructions how to duplicate it :P
20:17:54 <frosch123> i killed the server with signal 9, restarted it with same invite code
20:18:02 <frosch123> now the in-game list show it
20:18:05 <frosch123> but the website is confused
20:20:53 *** Montana_ has joined #openttd
20:21:06 <TrueBrain> if you can put it in a gist, that would be nice for my memory :D
20:23:41 <frosch123> how does the website work?
20:24:23 <frosch123> does it also connect to the gc? or different?
20:24:53 *** jottyfan has quit IRC (Quit: jottyfan)
20:24:54 <TrueBrain> it fetches every N minutes the data from redis directly
20:25:38 <frosch123> ok, so i cannot trigger an exception in the gc by using the website
20:26:04 *** Montana_ has joined #openttd
20:26:15 <frosch123> (i need to separate causality and correlation)
20:26:30 <TrueBrain> website is read-only
20:32:39 <frosch123> hmm, i guess the gc instances can also fight for deregistering a server
20:33:24 <TrueBrain> don't go too far down this rabbit hole .. double invite-codes should be rare :P
20:34:08 <TrueBrain> and I will add stats how often this happens this weekend or something :D
20:40:45 <frosch123> hmm, all of the duplicates are still 1.11.2 servers, and one jgrpp, which i do not know how old it is
20:41:39 <frosch123> i also found one 1.11.2 server, which is twice in the in-game list, but not at all on the website
20:41:52 <frosch123> so both entries refer to offline servers
20:43:23 <glx> any stored server in config ?
20:43:56 <frosch123> it gets "current year" from masterserver
20:49:04 <TrueBrain> the master-server code to act like a GC is a bit complex
20:49:16 <TrueBrain> well, all GC code is rather complex :P
20:50:14 <frosch123> ah, but the 1.11 servers rely on the redit expire, don't they?
20:51:51 <TrueBrain> servers normally unregister on exit
20:53:01 <frosch123> i don't think the 1.11 direct servers exit normally ever
20:53:12 <frosch123> if they were maintained, they would use 12.0
20:53:25 <frosch123> so, i think 1.11 servers only exit abnormally
20:53:41 <TrueBrain> unless they crash, the game sends out an unregister just before exit
20:53:56 <TrueBrain> but the exceptions to that rule as captured by redis, yes
20:53:58 <frosch123> hypervisor/vm crash, not ottd crash
20:54:01 <TrueBrain> as with all exceptions to the "normal" :)
20:55:21 <TrueBrain> on any crash, it doesn't send unregister
20:55:28 <TrueBrain> not sure why you mention hypervisor/vm :P
21:04:11 <frosch123> server_id differs between ipv4 and ipv6, and one gets forgotten
21:04:58 <glx> first ip to get a session_id transfer it to the other ip IIRC
21:05:01 <TrueBrain> if it can race (which I have to look into), it would only happen if IPv4 and IPv6 arrive in ~2ms from each other
21:06:10 <frosch123> i would assume aio lags in that range :p
21:06:48 <TrueBrain> traces show it is somewhere between 0.8ms and 2.2ms
21:08:02 <frosch123> assuming ipv4/6 registraion arrive in random order, line 68 is not that useful
21:08:09 <TrueBrain> either way, if it would race (still don't know if it can; too sleepy to validate that :D), 15 minutes later it will deduplicate itself
21:08:15 <TrueBrain> 15 minutes after that, the duplicate will be removed
21:08:31 <TrueBrain> line 67 is a comment
21:09:10 <frosch123> yes, the comment is about "why use ip as server-id instead of session-key"
21:09:27 <TrueBrain> no no, it doesn't say "instead"
21:10:54 <TrueBrain> the comment merely states the assumption is most servers are either IPv4 only, or either of the two wins in 90% of the cases
21:12:06 <frosch123> can you see from tracer, whether _monitor_Expire triggers?
21:12:16 <TrueBrain> I do not have a trace on that, no
21:12:24 <frosch123> there is "tracer.add_trace_field("command", "expire.gc-server")"
21:12:32 <TrueBrain> but for your information, we use server-id to mostly get the URL on servers.openttd.org stable
21:12:36 <frosch123> i wonder whether we can try to trigger that
21:12:39 <TrueBrain> server-key is unusable for that
21:12:45 <frosch123> (i can't, i can't run an 1.11 server :p)
21:13:15 <TrueBrain> so you want to know the trace for expire.gc-server, not for the whole monitor :P let me see
21:13:22 <frosch123> TrueBrain: isn't server-id used to deduplicate ipv4/ipv6?
21:13:43 <TrueBrain> no, server-key is used for that
21:13:58 <TrueBrain> server-id is used for the website
21:14:22 <frosch123> TrueBrain: basically, i want to know whether _monitor_expire actually recvies events, or whether that is just an untested codepath :)
21:14:48 <TrueBrain> for sure it used to work ;)
21:14:52 <TrueBrain> I tend to test my codepaths :P
21:15:02 <TrueBrain> but tnx for the vote of confidence :D :D
21:16:26 <TrueBrain> I have no trace of any of those 3 possible traces; that doesn't mean they didn't happen, as they should happen rarely.
21:16:45 <TrueBrain> (and there is only a ... 5% chance it is send to honeycomb)
21:18:02 <TrueBrain> but, I have some draft code to validate TTL actually works on startup, instead of saying: hey, I cannot set this setting, please make sure you did it yourself!
21:18:14 <TrueBrain> on AWS you cannot runtime enable notifications .. which is silly :)
21:21:50 <frosch123> are there both "expire" and "expired" events?
21:23:07 <frosch123> half of the docs say the event is named "expire", the other half says "expired" :/
21:23:30 <TrueBrain> again, I did test that code :) So it at least once was functional ;)
21:23:51 <TrueBrain> (as that syntax for what channel to listen to is weird as fuck :P)
21:24:18 <frosch123> it's still my best guess :p you keep mentioning that it is rarely needed, while my impression is that 1.11 uses it all the time :p
21:24:38 <TrueBrain> why do you think 1.11 servers crash "all the time"?
21:24:46 <TrueBrain> there would be something seriously wrong in that case :D
21:25:22 <frosch123> i think 1.11 servers run forever, unmaintained
21:25:37 <frosch123> the only reason they exit, if the vm crashes, like coop does every 20 minutes :p
21:25:49 <TrueBrain> so your and mine definition of "all the time" widely differ ;)
21:26:10 <TrueBrain> no, that you are confused is not weird :P Took me a full day to get it working
21:26:17 <TrueBrain> lot of implicit things involved :)
21:28:09 *** sla_ro|master has quit IRC ()
21:28:21 <TrueBrain> as I forgot it during setup .. which annoyed me :D
21:28:32 <frosch123> ah "expire" is the event for setting an expiration time
21:29:12 <TrueBrain> they also "recently" changed how expiring works
21:29:21 <TrueBrain> which was also fun to figure out from what into what :)
21:34:16 <TrueBrain> Either way, will debug some in the weekend or something.. few more things that require attention, like a 140ms registration time because of 20+ NewGRFs .. they are send one by one :D
21:34:23 <TrueBrain> Should be bulky .. oops
21:38:15 *** Samu has quit IRC (Ping timeout: 480 seconds)
21:39:33 <TrueBrain> Come to think of it .. if your hypothesis is correct, we should have far more duplicated servers, not? As that would mean none of them get removed? (Honestly wondering)
21:40:13 <TrueBrain> Maybe it doesn't see all expire events?
21:40:28 <TrueBrain> Well, needs debugging :D
21:41:03 <frosch123> if it sends the disconnect message, it does not rely on expire
21:41:36 <frosch123> however the ipv4/ipv6 issue, which we see by far the most, relies on the expire
21:44:26 *** Montana_ has quit IRC (Quit: Leaving)
21:48:48 <frosch123> ottd 1.11 sends the udp packets in a loop to all sockets, so ipv4/6 should arrive pretty close
21:49:25 <frosch123> and probably in random order
21:57:36 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:18:19 <TrueBrain> Lol, yeah, expire notifications for sure doesn't work how it should .. it is listening for events on db 0 while productions runs on db 1 :D
22:18:19 *** andythenorth has quit IRC (Quit: andythenorth)
22:26:56 *** andythenorth has joined #openttd
22:32:11 *** andythenorth has quit IRC (Quit: andythenorth)
23:21:04 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:48:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:49:19 *** WormnestAndroid has joined #openttd
23:57:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵