IRC logs for #openttd on OFTC at 2021-05-06
⏴ go to previous day
00:00:38 <peter1138> "Hello, I'll just clean up this code quickly." 5 hours later, code now affects lots of other places and is 5x the original size... "Shit"
00:02:41 *** Guest3080 has quit IRC (Ping timeout: 480 seconds)
00:27:53 *** EER has quit IRC (Ping timeout: 480 seconds)
00:32:29 *** lobstarooo has joined #openttd
00:38:16 *** lobster has quit IRC (Ping timeout: 480 seconds)
00:38:20 *** lobstarooo is now known as lobster
00:59:26 <DorpsGek> [OpenTTD/nml] glx22 opened pull request #217: Fix c65b5f98: Missing reference to intermediate proc call created for action3 https://git.io/J36a9
01:22:01 *** supermop_Home_ has quit IRC (Ping timeout: 480 seconds)
02:34:46 *** Wormnest has quit IRC (Quit: Leaving)
02:59:33 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:56:22 *** arikover` has quit IRC (Quit: ERC (IRC client for Emacs 27.1))
04:30:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
04:34:45 *** WormnestAndroid has joined #openttd
05:04:56 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
05:28:38 *** Speedy` has quit IRC (Read error: No route to host)
06:11:04 *** WormnestAndroid has joined #openttd
06:30:37 *** sla_ro|master has joined #openttd
06:46:21 *** andythenorth has joined #openttd
06:57:11 <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
06:58:50 <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
06:59:03 *** didac has quit IRC (Remote host closed the connection)
07:04:52 <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
07:11:36 <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3irA
07:17:47 *** HerzogDeXtEr has joined #openttd
08:05:10 *** Speedy` has joined #openttd
08:10:05 *** lobstarooo has joined #openttd
08:12:39 <LordAro> "I have banned IPv6 for a long time"
08:13:29 <dwfreed> "Get with the program, you're part of the problem"
08:13:54 <LordAro> i can understand disliking IPv6 for various reasons
08:13:59 <LordAro> but actually "banning" it?
08:14:30 *** lobster has quit IRC (Read error: Connection reset by peer)
08:14:36 *** lobstarooo is now known as lobster
08:20:12 <TrueBrain> and reading the ticket, I am guessing IPv6 is enabled but failing
08:20:18 <TrueBrain> so possibly his banning wasn't sufficient :)
08:20:45 <TrueBrain> (as code-wise nothing happens when you close and open the window :P)
08:24:13 <TrueBrain> "Well yeah, I don't actually care much about the ornaments feature, it was more like a joke." <- and now it is a joke? Could have fouled me :)
08:25:39 *** andythenorth has quit IRC (Quit: andythenorth)
08:26:28 <TrueBrain> right, time to fix the monster of merge conflicts ...
08:45:16 <TrueBrain> well, that does make a lot of code a lot more readable, so there is that
09:00:30 <TrueBrain> awh, done rebasing .. but it now crashes the client :P
09:07:20 <TrueBrain> and there we go .. IPv6 :)
09:07:39 <LordAro> "dbg: [net] 1) 25.255.255.255"
09:08:28 <peter1138> me: Just to let you know I am currently working on designing and implementing this new feature.
09:08:39 <peter1138> them: Please give a timescale for the fix.
09:09:32 <peter1138> 2) stop calling new features a "fix"
09:09:48 <peter1138> 3) i've now spent more time moaning about it on irc that working on it
09:11:48 <dwfreed> LordAro: 25.255.255.0/24 is totally a valid network; odd that he has 2 addresses, though
09:12:15 <TrueBrain> org-name: UK Ministry of Defence
09:12:23 <TrueBrain> either he really should not be playing OpenTTD, or .... :P
09:13:01 <TrueBrain> it is a very odd broadcast indeed
09:13:05 <TrueBrain> just not part of the issue :)
09:13:44 <peter1138> Some of those "VPN" programs use random IP ranges like that.
09:13:54 <peter1138> Hamachi was one offender.
09:14:02 <dwfreed> yeah, Hamachi used 5/8
09:14:07 <TrueBrain> sounds more plausible :D
09:14:11 <peter1138> Every Hamachi client has one virtual IPv4 (IP) address in the 25. x.x.x range and one IPv6 address
09:14:29 <TrueBrain> very very nasty of them to do that, but okay ..
09:14:51 <TrueBrain> I understand they need an IP in the public routing space for it to work
09:15:16 <FLHerne> TrueBrain: You don't think MoD people should be interested in logistics?
09:15:17 <peter1138> They don't need an IP the public routing space.
09:15:37 <FLHerne> For all we know, all the military's transport planning is simulated in OTTD
09:15:40 <TrueBrain> peter1138: lot of games detect if it is a local IP or not, sadly
09:15:41 <peter1138> They need an IP that doesn't conflict with RFC1918.
09:16:10 <peter1138> The correct way for them to do that is to actually have their own allocation and use them, so it will never conflict with anything.
09:16:27 <TrueBrain> which costs money these days :P
09:16:31 <TrueBrain> but I fully agree with you :)
09:16:32 <peter1138> That's their problem.
09:16:36 <TrueBrain> it is really bad to just steal IP ranges
09:16:40 <TrueBrain> "they aren't used anyway" argument
09:16:51 <TrueBrain> well, soon, nobody needs that crap for OpenTTD anyway
09:17:13 <peter1138> How big can hamachi networks be anyway?
09:17:29 <peter1138> And can you connect to multiple concurrently...
09:26:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9017: WIP: allow multiplayer without port forwarding https://git.io/J3Pfr
09:27:09 <dwfreed> peter1138: I mean, they could use a class E block
09:27:19 <dwfreed> since those are bogons
09:32:04 <TrueBrain> saying you have something disabled while you clearly haven't, is really hard to debug :P
09:33:13 <TrueBrain> my WSL doesn't have IPv6, and it sure doesn't try IPv6 first :P
09:34:17 <TrueBrain> sadly, it is surprisingly common that IPv6 is being routed to a /dev/null .. no clue why
09:34:23 <TrueBrain> haven't found any machine that does it where I have access to
09:35:47 <LordAro> i've seen systems that resolve DNS to AAAA, but doesn't actually have a AAAA of its own
09:36:04 <LordAro> can't remember what i did to cause/fix it
09:36:16 <TrueBrain> that ideal already shouldn't happen; but after that, OpenTTD would try to connect via IPv6
09:36:29 <TrueBrain> which should result in the OS should immediately saying: NO
09:39:16 *** WormnestAndroid has quit IRC (Remote host closed the connection)
09:39:29 *** WormnestAndroid has joined #openttd
09:40:13 <TrueBrain> lol :) Guess we should extend our service to Linux-support too :P
09:48:58 <TrueBrain> it can also be "wine" ofc, completely fucking up IPv6 :P
09:49:14 <LordAro> plausible, but unlikely
09:49:29 <TrueBrain> I have no idea how they emulate their IP-stack
09:49:40 <TrueBrain> Windows has this thing to generate IPv6s for non-IPv6 systems
09:49:46 <TrueBrain> maybe wine adapted that :P
09:50:05 <TrueBrain> either way .. not our problem really :)
10:08:36 <TrueBrain> lol .. reason my rebase crashes
10:08:44 <TrueBrain> because this-> is not mandatory in C++
10:08:48 <TrueBrain> and I confused 2 variable names
10:09:04 <TrueBrain> so it picked an unitialised this-> variable instead of showing an error :D
10:10:12 <TrueBrain> I should learn to program :D
10:19:35 <TrueBrain> so now I am the bad guy, lol :D
10:20:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9017: WIP: allow multiplayer without port forwarding https://git.io/JOk7C
10:20:10 <TrueBrain> okay .. that works again .. now to figure out IPv6 ..
10:26:02 <dwfreed> LordAro: any Linux system will resolve a name to an AAAA without a local IPv6 address if you don't give AI_ADDRCONFIG in your hints flags when calling getaddrinfo
10:27:01 <dwfreed> Also I believe it was a recent fix to glibc to not consider link-local IPv6 addresses as valid for AI_ADDRCONFIG
10:35:44 <TrueBrain> Luckily we use ADDRCONFIG :D but I know there are some cases it doesn't appear to work .. might indeed be due toe linklocal I guess
10:36:07 <TrueBrain> But what remains odd, even if it finds an IPv6 address, the connect should instafail
10:36:39 <TrueBrain> So something is routing IPv6 at some level for him.. shrug
10:37:18 <TrueBrain> Worst thing IPv6 did honestly is RA
10:38:41 <TrueBrain> Or Windows with Teredo
10:38:52 <TrueBrain> All this forcing IPv6 on people..
10:43:11 <dwfreed> RA also allows you to know that you need to do DHCP, without user input
10:44:02 <dwfreed> (RA contains a "managed" bit in the flags field for the subnet; if set, SLAAC is skipped, and DHCPv6 is required to be performed to obtain an address)
10:44:56 <TrueBrain> fair, but that is a bit what I mean .. there is only 1 good setting in a sea of bad settings :P
10:45:55 <TrueBrain> the times I have seen DC networks where all servers are reachable by public IPv6s, because someone enabled RA without thinking about it
10:46:03 <TrueBrain> makes breaking in a lot easier, I have to admit ;)
10:46:17 <dwfreed> That's an admin problem, not an IPv6 problem
10:46:32 <TrueBrain> sure, but isn't everything in the end? :)
10:46:45 <TrueBrain> I just don't understand why RA has a mode to push IPv6 to clients, and that it is the default
10:46:59 <TrueBrain> "easier for admins", was the idea I guess
10:47:12 <dwfreed> greatly simplifies deployment, yes
10:47:23 <TrueBrain> also a huge security risk :(
10:47:32 <TrueBrain> but I guess that is always a balance .. security vs user friendlyness
10:47:48 <dwfreed> Turn one thing on and all your devices now have a v6 address, no additional setup required
10:47:49 <TrueBrain> it wouldn't be such a problem if we were already used to IPv6, so people had firewalls etc in place for them
10:48:23 <dwfreed> consumer routers that push v6 apply basically the same firewall rules they do over v4
10:48:33 <TrueBrain> nowedays I see that a bit more
10:48:37 <TrueBrain> early days ... not so much :(
10:48:43 <TrueBrain> they fell in the same trap, basically
10:48:49 <dwfreed> the LAN subnet is not accessible except for established connections
10:48:56 <TrueBrain> I even had an argument with a supplier where he said: guessing the IPv6 is impossible, so it is fine
10:49:02 <TrueBrain> which was a pro-way to approach security, ofc :)
10:49:20 <dwfreed> "Guessing the address you tell everyone when you connect to their servers"
10:49:21 <TrueBrain> but recent modems indeed apply IPv6 firewalling in a sane way
10:49:30 <TrueBrain> dwfreed: yeah .. I didn't even know how to respond honestly
10:49:41 <TrueBrain> I think IPv6 tried to fix too much at once
10:49:48 <TrueBrain> making people without experience do stupid shit
10:49:51 <dwfreed> also it's pretty predictable if you know their computer manufacturer
10:50:08 <TrueBrain> "but IPv6 changes the address every N minutes"
10:50:16 <dwfreed> no, that's privacy extensions
10:50:20 <dwfreed> not everything uses that
10:50:31 <TrueBrain> I have heard so many stupid arguments ..
10:50:41 <TrueBrain> mostly because people don't understand it, and refuse to read up to it
10:50:46 <TrueBrain> as it is "just an upgrade from IPv4"
10:51:01 <TrueBrain> just applying the old world onto a new one
10:51:09 <TrueBrain> anyway, I am ranting .. sorry :P
10:51:23 <TrueBrain> I really like IPv6, just not the way it is often rolled out :P
10:51:34 <TrueBrain> Teredo is also one of those things .. who is Microsoft to force an IPv6 on my connection?
10:53:08 <Timberwolf> Such a nice feeling when you change two lines of code and it's like, "oh hang on, I just resolved 6 tickets doing that"
10:53:22 <TrueBrain> lol .. that is impressive
10:54:19 <TrueBrain> now I need to find a way to connect over all available families .. hmm .. how am I going to do that properly in our code ..
10:54:52 <Timberwolf> Mostly because I had a previous task which was to add a core library function, then when I picked up the next one I looked at it and went... "hang on, this result is used in this way, the errors are handled like this... hang on, this does everything it's supposed to now"
10:59:21 <dwfreed> TrueBrain: happy eyeballs as threads
11:00:18 <TrueBrain> who came up with that :D
11:00:28 <dwfreed> make a thread for v4 and a thread for v6 on first request; whichever thread wins gets to live
11:00:51 <dwfreed> hunger games for IP families
11:01:06 <TrueBrain> yeah .. we do want something like that eventually
11:01:12 <TrueBrain> but the code makes that kinda hard atm :P
11:01:28 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J3Vcy
11:01:45 <dwfreed> "The name "happy eyeballs" derives from the term "eyeball" to describe endpoints which represent human Internet end-users, as opposed to servers."
11:02:10 <TrueBrain> but maybe I should stop trying to make this work in the current object we have
11:02:20 <TrueBrain> and just rebuild it
11:02:59 <dwfreed> yeah, write a new implementation of TCPConnecter with a mostly compatible interface, and then just switch things to use it
11:03:57 <TrueBrain> I am just always a bit scared ... NetworkAddress worked for 15 years now, and contains a lot of things that fixes quirks of OSes
11:04:06 <TrueBrain> doing it again has the risk of reintroducing past resolved issues
11:04:16 <TrueBrain> so I was somewhat trying to avoid that
11:04:59 <Rubidium> you mean for quirks of win9x, ancient linux, etc? ;)
11:05:00 <TrueBrain> but now I really need to connect to both IPv4 and IPv6 (if available), and keep the connection even .. which is not far off from "Happy Eyeballs", so maybe might as well tackle that issue ..
11:05:09 <TrueBrain> Rubidium: who knows what quirks they solved :P
11:06:28 <TrueBrain> what does still surprise me, that all OSes (we support) use sockaddr :P
11:06:38 <TrueBrain> for some reason I keep expecting some OS to use something completely different :D
11:08:38 <Rubidium> as long as there is enough time to get things tested, why not implement that RFC? Though the biggest problem is ofcourse resolving bind addresses compared to connect addresses, though maybe those should become different types addresses? Or at least bind's weird "creates multiple sockets/addresses" behaviour needs to be split off? Moar rabbit holes!
11:09:16 <TrueBrain> yeah .. I have some ideas, so I will thinker with this for a bit
11:09:28 <TrueBrain> moving NetworkAddress further into the network code really does help here
11:09:37 <TrueBrain> at the very least for my sanity :D
11:13:13 <peter1138> Urgh, I have 42 issues open :(
11:13:40 <peter1138> All of them raised by myself of course, becuase otherwise they are lost a random conversations or emails...
11:14:41 <TrueBrain> so close them without solving, get mad at yourself for doing that, and call it a day!
11:15:14 <peter1138> I should just go home.
11:19:23 *** Flygon_ has joined #openttd
11:21:22 *** Flygon__ has joined #openttd
11:26:14 *** Flygon has quit IRC (Ping timeout: 480 seconds)
11:28:14 *** Flygon_ has quit IRC (Ping timeout: 480 seconds)
11:41:06 <TrueBrain> owh, ugh, OpenTTD still supports non-thread builds .. eeuuhh .. hmm
11:45:15 <orudge> When I resurrect the DOS port, we might still need that... no, only joking ;)
11:46:28 <TrueBrain> you still want to support OS/2, what can I say :P
11:46:40 <TrueBrain> but no, Emscripten currently builds without threads
11:49:17 <Rubidium> though... isn't threading required for C++17 support?
11:50:43 <peter1138> "As of Sep 2019, some browsers have disabled SharedArrayBuffer due to the Spectre set of vulnerabilities."
11:51:13 <TrueBrain> Rubidium: not really relevant tbh; Emscripten has "beta" support for threads, but it is very difficult
11:51:28 <TrueBrain> they are not really classic threads atm
11:51:49 <TrueBrain> so till someone invests time into making Emscripten works with threads, it would be nice if OpenTTD can work without threads too ;)
11:52:42 <TrueBrain> and yes, what peter1138 says plays a role in that too :)
11:57:34 <TrueBrain> okay, funny, despite the fact I only have a link-local IPv6 (and no function IPv6), even with AI_ADDRCONFIG, getaddrinfo returns IPv6 addresses .. but .. they are sorted at the bottom
11:58:09 <TrueBrain> man suggests it shouldn't show up
12:00:05 <TrueBrain> owh, misread link-local for loopback
12:02:24 <TrueBrain> RFC3484 defines the order, which can be overwritten by gai.conf, which has a comment stating they no longer follow RFC3484 :D
12:10:13 <TrueBrain> funny, Teredo tunnels are given a very low priority :P Makes sense :)
12:22:57 <TrueBrain> okay, on Linux getaddrinfo is clever enough to not prefer IPv6 addresses as long as there is not a route for it
12:24:05 *** andythenorth has joined #openttd
12:29:58 <TrueBrain> your lunches are getting later and later
12:30:47 <andythenorth> if it's a compliance day I lunch early
12:30:54 <andythenorth> but writing code....always another line to change
12:31:08 <andythenorth> when I used to code Flash games, I wouldn't eat all day
12:31:22 <andythenorth> OpenTTD Flash port when?
12:33:17 *** supermop_Home_ has joined #openttd
12:38:42 <peter1138> rocky coastal tiles?
12:50:22 <TrueBrain> std::deque pop_front() doesn't return the elemant it is poping?
12:53:48 <TrueBrain> makes for very pointless lines of code now ..
12:54:05 <peter1138> Hmm, apparently not. oops.
12:54:19 <TrueBrain> pop_NNN are void return values
12:54:25 <peter1138> Yeah, that's... interesting
12:54:29 <TrueBrain> but I am happy I am not the only one who assumed it wasn't :)
12:54:33 *** andythenorth has quit IRC (Quit: andythenorth)
12:55:12 <Rubidium> TrueBrain: I have battled with that concept for a deque too :( first you need front() and then pop_front() or something alike
12:55:20 <TrueBrain> yeah ... it is really stupid
12:55:29 <peter1138> You'd hope pop_front() was atomic, etc...
12:55:54 <TrueBrain> basically, indeed, there now isn't any thread-safe way to do this without extending on it yourself
12:56:19 <TrueBrain> C++20 does fix it for std::vector
12:56:26 <TrueBrain> but not for std::deque? Lol
12:56:31 <Rubidium> they should just break ABI stability for the next major C++ release and fix things like that
12:57:19 <peter1138> "exception safety" apparently
12:57:33 <TrueBrain> but but .. std::vector does gain the ability in C++20
12:57:39 <TrueBrain> yeah, what-ever, C++ being C++
12:58:31 <peter1138> *** Player#1 has started a new company
12:58:42 <TrueBrain> soon peter1138 , soon
12:58:54 <TrueBrain> found another rabbit hole ..
12:59:34 <peter1138> Damned rabbits keep breeding.
12:59:56 <Rubidium> that client name will still live quite long I fear, after all we're not straight out banning Player just not using it as default when the player failed to enter something
13:00:34 <Rubidium> so any configuration with "Player" as client name will keep using that, and I guess some servers might because of that think the change does not work
13:01:14 <Rubidium> TrueBrain: where do you see such a change for std::vector in C++20?
13:01:55 <TrueBrain> so the bullshit continues even with C++20 :P
13:05:06 <LordAro> just get compile-time vectors instead ;)
13:06:48 <Rubidium> TrueBrain: fun question, how long does std::this_thread::sleep_for(std::chrono::milliseconds(100)); sleep for on Windows?
13:07:01 <TrueBrain> Rubidium: you really want an answer? "it depends"
13:07:13 <TrueBrain> but with OpenTTD currently, it is accurate within a few ms
13:07:39 <Rubidium> + whatever time the clock gets set back...
13:07:54 <TrueBrain> similar as with Linux btw .. context-switch seems to be ~4ms
13:08:10 <TrueBrain> so with OpenTTD, between 100 and 104ms, give or take
13:08:53 <peter1138> Oh, that's not Windows :)
13:09:50 <TrueBrain> most important thing on Windows, is that with recent Win10, every application can set its own "resolution"
13:10:10 <TrueBrain> which was the original issue the win32 video driver was not reaching 33fps :)
13:10:57 <TrueBrain> but I wonder what rabbit hole Rubidium found now :)
13:12:02 <LordAro> surprised we haven't had any reports yet tbh
13:12:16 <TrueBrain> LordAro: wasn't it you that mentioned this weeks ago? :)
13:12:29 <peter1138> So I implemented this new feature (the not a "fix" one)
13:12:30 <TrueBrain> around the summer-time blabla :P
13:12:56 <TrueBrain> Rubidium: in general I think it is safe to assume std::chrono is one big shit-show, especially cross-platform :)
13:13:26 <peter1138> Response "so will the fix enable me to do this thing?" (said thing being the sole purpose and functionality of the feature)
13:13:48 <TrueBrain> but it works surprisingly well for us atm, no complaints there so far .. well, except for SerenityOS :P
13:14:02 <LordAro> peter1138: sounds like you should just directly correct them, rather than dancing around it
13:14:21 <LordAro> or, "why do you keep calling it a 'fix'?"
13:14:43 <peter1138> It's not just "fix" this time. It's... this work you did. to do this thing. does it do this thing?
13:16:21 <Rubidium> though probably we're not getting reports as it converts to UTC, so in practice DST should go fine. Even then, how many would be playing in the middle of the night? The only moment it's really an issue is when NTP sets your time back by a lot
13:16:49 <TrueBrain> "middle of the night" UTC-wise is easy
13:16:54 <TrueBrain> we also have players in non-Europe countries ;)
13:17:24 <Rubidium> dedicated servers will likely not be Windows
13:17:30 <peter1138> So does std::chrono need to be... undone?
13:17:49 <LordAro> peter1138: not until it provably causes any issues, imo
13:18:12 <TrueBrain> we have been over this before; I believe worst case the game "hangs", someone saves it, reloads it, and continues
13:18:32 <LordAro> and even then, just provide our own (fixed) implementation for windows for whichever clock is used
13:18:58 <peter1138> does it hang in a way that lets you save? :D
13:19:24 <peter1138> I remember all the faff we had when the original 32 bit counter wrapped :D
13:19:36 <TrueBrain> fair point; can't remember, but basically we concluded it is such a minimal issue
13:19:44 <peter1138> Except of course that was all slightly different code depending on the platform, instead of the unified nice stuff now.
13:20:13 <peter1138> LordAro, the issue is it doesn't REALLY matter that it's feature/fix.
13:20:42 <peter1138> LordAro, it's my brain telling me that a fix implies I broke something :p
13:21:20 <peter1138> I do prefer to reserve "fix" for things that are not working rather than something new.
13:21:35 <LordAro> in which case, just go full passive-agressive "you're asking if the feature that adds <x> allows you to do <x>? Yes, it does"
13:21:37 <peter1138> Fix: STUN networking support?
13:21:50 <TrueBrain> peter1138: don't drag me into your hell :P
13:22:14 <Rubidium> TrueBrain: CE(S)T DST change is at 01:00 UTC, Brittish DST change is at 01:00 UTC (yay Europe syncing them), East coast US has a DST change at 06:00 UTC, West coast US has a DST change at 09:00 UTC
13:22:33 <peter1138> "Yes, the <b>feature</b> to do X allows X to be done."
13:22:39 <Rubidium> so effectively, the DST change is everywhere around 02:00/03:00 local time
13:22:41 <TrueBrain> Rubidium: you just said midnight in UTC! Don't go all detail now to back down on that :P
13:23:24 <peter1138> As we used to say in the day... Bloody Time Zones!
13:23:31 <peter1138> That might've been something else
13:23:47 <TrueBrain> lets hope they cancel summer time soon :P
13:23:51 <TrueBrain> solves many issues :D
13:25:04 <Rubidium> TrueBrain: I said that it (i.e. sleep_for) converts to UTC so a DST change should not affect that. The next was just referring to those that would be playing in the middle of the night when their DST happens
13:25:36 <TrueBrain> like I said, you are now adding details to back down on it! Tssk :)
13:25:47 <TrueBrain> (and if it isn't clear, I am trolling, I am sorry :D)
13:29:24 <Rubidium> peter1138: no, rather a "Fix: network server hosting did not work correctly when user has NAT or firewall"
13:29:35 <Rubidium> now... backport it quickly! ;)
13:29:54 <Rubidium> it's one of those bugs that has plagued OpenTTD for years
13:30:31 <TrueBrain> if you cannot CVE it, it is not a bug :P
13:31:06 <peter1138> Bug: cannot rotate view
13:35:39 <TrueBrain> error: no matching function for call to ‘std::vector<int>::erase(const int&)’
13:36:44 <peter1138> Bug: peter1138 writes crap code
13:36:53 <peter1138> Wait, no, that one is real
13:51:30 <TrueBrain> right, happy eyeballs seems to work at least
13:52:45 <Rubidium> well, depending on where you are in India, it's either before 20:00 (as restaurants close that early in some places) or after 19:00 (as restaurants open that late in some other places). And now it's almost 19:30 there. So perfect timing
13:53:09 <TrueBrain> how does this helps me, at all? :(
13:53:54 <Rubidium> well, you didn't believe my answer on whether it's dinner time, so I provided some proof why it is dinner time
14:13:34 * Rubidium ponders on which PR to build the change so I can keep rebasing it for a while
14:21:06 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
14:21:12 <TrueBrain> still a draft, as I need to clean up the code, but something like this should do
14:22:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
14:22:04 <TrueBrain> mostly curious if this helps frosch123's IPv6 issues too :)
14:24:59 <TrueBrain> lol, we have 1 (!) place in our code where connect() has to be sync, instead of async: debug-log redirect :D
14:25:22 <TrueBrain> can't I just remove that code? :P
14:28:57 <Rubidium> does it really need to be, or it is just tough luck if you do not accept quickly enough?
14:29:22 <TrueBrain> otherwise it would be a but undeterministic on startup
14:29:33 <TrueBrain> people will complain :P
14:40:49 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
14:41:00 <TrueBrain> right .. need to add a thread for DNS resolving, and figure out the IP used for some debugging ..
14:41:16 <TrueBrain> otherwise it seems to work in all weird ways I have been testing it :D
14:41:23 <LordAro> hope you're testing all this stuff with thread-sanitizer :p
14:41:33 <TrueBrain> so far, I have removed threads
14:41:35 <TrueBrain> so that should be fine :P
14:41:40 <TrueBrain> but good point nevertheless :)
14:41:43 <peter1138> Before? Why not let him be our automated tool? :D
14:42:09 <TrueBrain> I do tend to run valgrind on such changes, but not the thread-sanitizer yet :)
14:45:31 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9200: Codechange: [Network] Use std::string for network game info https://git.io/J3XOj
14:50:17 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
14:50:59 <TrueBrain> hmm ... now I broke it \o/
14:51:38 <Rubidium> shouldn't you set aborted to true in those failure cases?
14:52:04 <TrueBrain> which one do you mean?
14:52:27 <TrueBrain> yeah, still no clue
14:52:33 <TrueBrain> you have to give me a line number or something
14:52:40 <TrueBrain> as "failure cases" is a bit to broad :D
14:52:57 <Rubidium> tcp_connect.cpp 183, 219 and 240
14:53:29 <TrueBrain> owh, I set them to false instead of true, yeah, that is weird
14:53:37 <TrueBrain> not the reason it is no longer working, but weird nevertheless
14:59:39 *** Gustavo6046_ has joined #openttd
15:00:52 <TrueBrain> ugh, I hate when that happens .. you cleanup your code, and it breaks .. :P
15:00:59 <TrueBrain> it says it is connected, the socket is handed over correctly
15:02:00 <TrueBrain> [2021-05-06 17:01:40] dbg: [net] send failed with error Destination address required <- might be unrelated, but that is also a fine error :P
15:03:58 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
15:03:58 *** Gustavo6046_ is now known as Gustavo6046
15:06:51 <TrueBrain> lol, yeah, I am stupid, lalala
15:08:36 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
15:08:53 *** Flygon_ has joined #openttd
15:15:43 *** Flygon__ has quit IRC (Ping timeout: 480 seconds)
15:16:19 *** Flygon_ has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:19:26 *** gelignite has joined #openttd
15:31:08 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
15:32:42 *** Progman has joined #openttd
15:36:40 *** frosch123 has joined #openttd
15:46:48 <frosch123> though i learned that openrct2 uses js for gui modding...
15:46:51 <TrueBrain> did you spot that "TT" version used? :D
15:47:04 <frosch123> i also spotted some trailer
15:47:17 *** lobstarooo has joined #openttd
15:47:34 <TrueBrain> LordAro: I am happy you mentioned thread analyzer ..
15:47:44 <TrueBrain> it went ballistic on my code :D
15:47:49 <TrueBrain> despite it being "correct", but what-ever :P
15:49:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
15:49:36 <TrueBrain> right, that should be the last TODO ..
15:49:43 <TrueBrain> frosch123: if your IPv6 is still broken, would you mind testing 9199?
15:51:04 <TrueBrain> owh, one more TODO, for the stupid debug logger .. guess I could make something for that ...
15:52:23 <glx> queue log lines until fully connected ?
15:52:31 <frosch123> it's broken randomly every know and then
15:52:48 <frosch123> i know i can fix it by rebooting my router, but i don't know how to break it on purpose :p
15:52:49 *** lobster has quit IRC (Ping timeout: 480 seconds)
15:52:58 *** lobstarooo is now known as lobster
15:53:22 <glx> ha yeah, sometimes I lose ipv6 too, but it returns without a reboot
15:53:57 <glx> it's silly as I have native IPv6 and fake IPv4
15:54:05 <TrueBrain> Well, it works if I break IPv6 myself
16:03:26 <frosch123> or does it use port 443 only to look cool? :p
16:04:18 <glx> it doesn't support it yet I think
16:04:38 <frosch123> oh, it fails with status 400
16:04:46 <frosch123> and then reverts to using 3978
16:05:17 <frosch123> is that how it is supposed to work?
16:05:53 <Rubidium> probably someone overzealously migrating all HTTP traffic to HTTPS
16:06:29 <Rubidium> so it looks like the mirrors (or that mirror at least) is useless for OpenTTD
16:08:18 <TrueBrain> frosch123: most unusual .. let me see
16:08:34 <TrueBrain> most likely my PR btw, but I am happy you caught it :D
16:09:35 <TrueBrain> yeah, the hostname is a bit wrong .. I was cheating
16:09:38 <TrueBrain> but clearly my cheat didn't work :D
16:09:54 <TrueBrain> "[binaries.openttd.org]:80/bananas" <- those [] are send as Host too :D
16:11:08 <TrueBrain> that was not really what I meant it to do :P
16:13:36 <TrueBrain> (and AWS redirects all traffic to HTTPS, with 1 exception .. "binaries.openttd.org" :P)
16:16:41 <frosch123> so you add [binaries.openttd.org] now as well? :p
16:17:05 <TrueBrain> no, I actually fix the bug :P
16:17:35 <frosch123> you would make a bad php programmer
16:18:26 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
16:18:29 <TrueBrain> not "perfect" yet, but at least better .. still need to find a cleaner way to do this
16:19:08 <TrueBrain> at least it is "unbroken" now :P
16:30:33 <frosch123> now we only need keep-connection-open :p
16:38:21 <didac> I am struggling sooooo much with sprite sorting and bounding boxes in #9043 that I am adding a button in the sprite aligner to hide sprites x-)
16:38:48 *** Wormnest has joined #openttd
16:39:25 <frosch123> do you know "ctrl+b" ?
16:40:34 *** EER has quit IRC (Ping timeout: 480 seconds)
16:43:16 <frosch123> yeah.... i can see why you want to hide sprites :p
16:44:35 <didac> yeaah it gets pretty messy with bridge bounding boxes, good news is I am learning tons
16:45:21 <FLHerne> didac: Sprite sorting seems to be a bit of a no-win game in OTTD
16:45:49 <didac> it's basically placing the train wagon on top of the above bridge middle floor
16:46:18 <FLHerne> Even if you fix all the sane cases, there's a long history of NewGRFs that use strange bounding boxes and overlapping sprites to achieve ???
16:46:25 <didac> but I don't understand *yet* why it doesn't happen when the train is not on a bridge,
16:47:06 <didac> FLHerne: I get ya, I know that this is pretty much a big challenge
16:47:07 <Rubidium> probably some logic checking whether the bridge is 1 unit of the ground and the vehicle going under or so
16:47:38 <Rubidium> like how it's not drawing catenary under 1 unit high bridges IIRC
16:48:33 <didac> that's the kind of stuff I was trying, I just don't know which approach to go with
16:48:54 <Rubidium> just start with... at least two units of height between bridges ;)
16:49:04 *** andythenorth has joined #openttd
16:49:05 <andythenorth> "Core game data itself is created and loaded using the tools available to all modders, and includes a detailed asset editor for making new buildings, vehicles, or any of the assets in game." :)
16:49:08 <andythenorth> imagine such a world :)
16:49:14 <didac> yes I tried that actually, I think I will keep going into that direction for nwo
16:49:21 <didac> (I mean at least 2 tile diff)
16:51:41 <Rubidium> although people might complain about that, so at least put it in the limitations and some reaons why; e.g. that the current bridges already need all kinds of hacks, and put things higher than they should be to get the sprites in the right order, so stacking bridges only makes that problem worse
16:52:25 <frosch123> FLHerne: luckily newgrf cannot change bb of bridges and vehicles
16:52:45 <frosch123> and i am tempted to remove the option from industries and houses as well, and just "simulate" them
16:53:15 <Rubidium> that'd be fun with the higher bounding boxes... sorry, your train can go under this bridge as it's too high
16:53:20 <andythenorth> frosch123 pls :P
16:53:36 <andythenorth> I think I just set some arbitrary defaults in FIRS
16:53:43 <andythenorth> as I gave up on the idea there are correct values
16:53:50 <andythenorth> but this might make it even worse
16:54:04 <andythenorth> some parts of FIRS flicker horribly
16:54:16 <FLHerne> Rubidium: NA sets will need that for double-stack containers
16:54:58 <frosch123> ah, we need refit-at-bridges: double-stack -> single-stack
16:55:30 *** andythenorth has quit IRC (Quit: andythenorth)
16:55:44 <Rubidium> if the load of all wagons <= 50%, it will fit under the bridge, otherwise not ;)
16:56:03 <glx> just remove some air from tires ;)
16:58:37 <FLHerne> didac: You mean the overhead wires?
16:59:31 <didac> not just that, but also things appear and disappear, let me try making a video
17:00:17 <FLHerne> I don't think there can be a right solution for those giant girders :p
17:00:47 <FLHerne> need to add 'height above rail level' to bridges and/or individual bridge tiles really?
17:01:40 <didac> for the tile that has the two bridge middles I already solved some of the issues, smaller bb depending on height diff, subsprite to not render over the bridge above, etc
17:03:41 <_dp_> so would be nice to test if anyone knows some flickery cases
17:04:22 <didac> thanks for sharing that _dp_, I think you mentioned that in Discord, I tried but unfortunately it didn't solve the issue, in fact it seemed to make it worse
17:06:07 <didac> anyways I gotta to back to my 'real' job, which funny thing is also about maps
17:06:39 <didac> thanks for the help, if anyone interested in helping out it's #9043
17:06:53 <_dp_> well, it won't magically fix all sprite ordering, just make them preserve their creation order more
17:25:01 *** EER has quit IRC (Ping timeout: 480 seconds)
17:35:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9201: Add: [[nodiscard]] to std::string str_validate https://git.io/J3XxV
17:35:56 <frosch123> sure i can look, but i never used std::from_chars myself :p
17:36:43 * Rubidium neither until a few days ago ;)
17:37:17 <TrueBrain> well, we can YOLO it ofc :)
17:37:38 <Rubidium> the code would be even nicer if P2007R1 ever lands in C++, but alas that is not going to happen soon enough for that PR
17:40:18 <frosch123> i would promote using more default-member-initializers though
17:40:57 <frosch123> i.e. "NetworkGameList *next = nullptr", instead of the "next(nullptr)" in the ctor list
17:41:25 <TrueBrain> does that work?! :o
17:41:36 <TrueBrain> does that work for anything, or only PODs?
17:42:04 <frosch123> it works for everything. it means "add this to all ctor lists, unless they already have a different initialiser"
17:42:15 <TrueBrain> why don't we use that more? :D
17:42:18 <frosch123> it makes it easier to initialise everything, and to not miss a constructor
17:42:31 <TrueBrain> yeah ... that also solves some weird shit I have in my stun PR :P
17:42:31 <Rubidium> because C++<11 did not support it I guess
17:42:37 <TrueBrain> I made an empty ctor just to do that :P
17:42:55 <TrueBrain> Rubidium: a lot of things weren't supported in the old days .. but we are also not actively doing it now, that is my point ;)
17:43:03 <frosch123> TrueBrain: we already talked about it some week ago, when considering removing zeroedmemoryinitaliser
17:43:18 <TrueBrain> I have to admit, sometimes I zone out when you guys talk C++ :P
17:43:25 <Rubidium> TrueBrain: yeah, like you still have a C brain, mine is still C++<11 ;)
17:43:58 <TrueBrain> at least yours is upgraded :P
17:44:16 <rexxars> are there any stats on how many people play openttd on different platforms?
17:44:57 <Rubidium> I usually didn't play it on the platform, but rather in the train ;)
17:45:01 <frosch123> rexxars: citymania tracks stats for online servers, steam tracks stream users
17:47:19 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
17:47:25 <frosch123> your habit of forward-declaring structs in-place scares me though :p
17:47:53 <TrueBrain> yeah, let me remove that ..
17:47:59 <TrueBrain> that was code already there for most parts ..
17:48:13 <TrueBrain> in a header I can accept it .. but it is everywhere :P
17:48:17 <TrueBrain> old C-style manual shit
17:49:40 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
17:49:47 <TrueBrain> with less "struct" :P
17:49:54 <Rubidium> though I'm wondering how that'd work for info; or is that just info = {}?
17:50:24 <TrueBrain> isn't any non-POD already done via their default ctor?
17:50:47 <Rubidium> but info isn't non-POD (yet)
17:50:58 <frosch123> yes, but you can also use {} for non-default initialisation
17:50:59 <TrueBrain> then I have no clue what it does :D
17:51:36 <TrueBrain> frosch123 is learning us new things today :D \o/
17:51:43 <TrueBrain> I seriously appreciate it btw
17:52:20 <frosch123> if it wasn't for msvc, you could also use designated initialisers, but we have to wait for c++20 instead
17:52:21 <frosch123> TrueBrain: do you want a c++ developer job? there are 3 open positions at my place :p
17:52:29 <TrueBrain> too far from mine, sorry :P
17:52:45 <frosch123> though argueably in the less interesting teams
17:55:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
17:56:21 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J3Vcy
18:00:02 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
18:00:31 <TrueBrain> right, done fiddling with the details .. lol :)
18:00:53 <TrueBrain> pretty happy with the result; absolutely not what I planned to do today, but what-ever
18:10:10 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J31JX
18:11:05 <frosch123> i am not used to remove_prefix/postfix :) erase/substr feel easier to me, but well
18:13:31 <frosch123> also, that "remove = nullptr" scared me, but it was a useless assignment before :)
18:13:48 <Rubidium> frosch123: though erase needs to move all elements in the vector, right? and substr needs to make a new std::string, right? Whereas string_view is just a { *begin; *last; } and remove_prefix does a begin += n, and remove_suffix a last -= n; The whole goal was to not have to create a copy of the string
18:14:05 <frosch123> Rubidium: string_view also has substr
18:15:19 <Rubidium> then I would have had to do math ;)
18:15:35 <frosch123> you did more math now :p
18:16:21 *** arikover has joined #openttd
18:16:55 <frosch123> "company_string = ip.substr(offset+1); ip = ip.substr(0, offset);" is less math than "remove_suffix(company.size() + 1)", isn't it?
18:18:07 <Rubidium> oh, different place than I was looking at ;)
18:19:45 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J31T0
18:21:50 <Rubidium> but yes, there it makes sense to the use substr
18:24:47 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 dismissed a review for pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J31JX
18:24:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J3Vcy
18:24:59 <Rubidium> now using substr instead in the last commit
18:27:34 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J31LJ
18:28:08 <frosch123> tb told me some months ago, that "force-pushed" is a link :)
18:29:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31Lo
18:30:06 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9201: Add: [[nodiscard]] to std::string str_validate https://git.io/J31LX
18:31:06 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9201: Add: [[nodiscard]] to std::string str_validate https://git.io/J3XxV
18:33:30 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9192: Codechange: [Network] More std::string with less code https://git.io/J3Vcy
18:35:54 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9200: Codechange: [Network] Use std::string for network game info https://git.io/J3XOj
18:40:07 <TrueBrain> hmm ... in network/core we don't really have a place to leave wrapper functions around getpeername for example .. eeeuuuuhhhhh
18:46:12 <Rubidium> os_abstraction.cpp? ;)
18:47:24 <TrueBrain> doesn't fit there (at all), sadly :(
18:47:32 <TrueBrain> it needs NetworkAddress
18:47:37 <TrueBrain> and os_abstraction should be on top
18:47:48 <TrueBrain> we have more of such functions now lingering around somewhere :P
18:47:59 *** supermop_Home_ has quit IRC (Read error: Connection reset by peer)
18:50:25 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
18:50:26 <TrueBrain> for now, lets put it with the other odd ducks
18:51:40 <TrueBrain> seems we missed a few warnings in one of those PRs you just merged Rubidium :)
18:51:50 <TrueBrain> or 9200 triggers them
18:51:57 <TrueBrain> not always easiest to read :P
18:52:29 <TrueBrain> ah, no, sorry, it is the PR doing it
18:52:42 <TrueBrain> can't add a comment to a line that is not changed .. lovely :P
18:57:16 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
18:57:19 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9039: Codechange: refactor File I/O slot functions to be object oriented and pass references instead of indices https://git.io/JOGDX
18:59:57 <DorpsGek> - Update: Translations from eints (by translators)
19:00:09 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
19:01:27 <frosch123> did you drop the timezone thing? or is it now off by 1.5 hours?
19:01:40 <TrueBrain> it is now running at 1900 UTC
19:01:45 <TrueBrain> well, 1830 UTC for eints
19:01:51 <TrueBrain> 1900 UTC for nightly
19:03:16 <TrueBrain> either GHA really has resources issues, or they are limiting organizations (which would be completely fair)
19:04:13 <frosch123> i was wondering whether there is a limit for the number of members in an organization, when using the free plan
19:04:53 <TrueBrain> ah, Free plan is limited to 20 concurrent jobs
19:05:00 <TrueBrain> member limit? Not that I have ever read
19:16:12 <TrueBrain> argh .. so I have multiple build-folders .. and I was doing a new experiment .. and threw away the wrong build folder .. grr :P Nothing bad, just annoying
19:16:14 <TrueBrain> (config-files mostly)
19:16:16 *** Speedy` has quit IRC (Read error: Connection reset by peer)
19:16:36 <glx> the 20 limit had a nice effect with deadlocked regression test ;)
19:17:41 <TrueBrain> I am looking at making warnings into errors, but that is tricky
19:17:49 <TrueBrain> as with -Werror it stops compiling at the first warning
19:17:52 <TrueBrain> which would be very annoying
19:18:10 <Rubidium> use it with make -k?
19:18:38 <TrueBrain> Rubidium: assumes make; for GHA we moved away from that assumption and use "cmake --build"
19:18:45 <TrueBrain> which doesn't support a "-k" variant
19:19:56 <TrueBrain> yeah, but assumes "make" again
19:20:09 <TrueBrain> and ideal we also do the same with MSVC
19:20:33 <glx> I think I used "--" for some ubuntu targets
19:20:41 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9200: Codechange: [Network] Use std::string for network game info https://git.io/J3XOj
19:21:29 <TrueBrain> what CodeQL does, which is not a bad idea, is to have another task report "status"
19:21:32 <TrueBrain> and goes red on warning
19:26:50 <TrueBrain> anyway, by the looks concurrency wasn't really working till recently :P
19:26:54 <TrueBrain> guess they finally finished it :D
19:28:13 <TrueBrain> but yeah, I think warnings should be a separate result in the Checks; that makes it more clear that everything build (as seeing green is nice), but that are some things to address
19:28:14 *** EER has quit IRC (Ping timeout: 480 seconds)
19:28:20 <TrueBrain> rather than showing red on builds because there was a warning
19:28:36 <TrueBrain> but like with the commit-checker
19:28:45 <TrueBrain> CodeQL does that, so it should be possible ..
19:29:10 <TrueBrain> just a matter of after the job check the API for warnings
19:29:39 <TrueBrain> I think something like that should be possible .. but I would have to try it :D
19:29:45 <TrueBrain> you never really know till you try with GitHub :P
19:32:32 <frosch123> is there a yellow state like in jenkins?
19:32:45 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9200: Codechange: [Network] Use std::string for network game info https://git.io/J31Wo
19:33:01 <TrueBrain> frosch123: not sure, I think that is used for pending states
19:34:36 <glx> oh run.id is available in the workflow
19:37:20 <frosch123> "action required" looks scary
19:43:07 <peter1138> How many desyncs can we cause if we really let re-randomisation happen during any call?
19:45:01 <frosch123> stop reading forums/discord :p
19:45:13 *** blathijs has quit IRC (Quit: restart)
19:45:38 *** blathijs has joined #openttd
19:45:41 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9200: Codechange: [Network] Use std::string for network game info https://git.io/J3XOj
19:45:47 <frosch123> remove triggers, always roll random on every evaluation :p
19:45:55 *** andythenorth has joined #openttd
20:14:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31Ee
20:15:00 *** lobster has quit IRC (Read error: Connection reset by peer)
20:16:31 *** lobster has joined #openttd
20:19:13 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31EQ
20:20:48 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31uk
20:23:31 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31zr
20:23:40 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
20:24:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31zQ
20:26:33 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
20:27:08 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
20:27:21 *** gelignite has quit IRC (Quit: Stay safe!)
20:52:24 *** Samu has quit IRC (Quit: Leaving)
20:53:34 *** arikover has quit IRC (Quit: ERC (IRC client for Emacs 27.1))
21:01:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
21:03:14 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:09:19 <andythenorth> how about tomorrow?
21:09:25 <andythenorth> multipart dox yes
21:09:38 <peter1138> Oh we already have multi stop docks
21:09:41 <peter1138> Another bad feature.
21:10:25 <andythenorth> it's in the top 10 best 3 features
21:10:47 <andythenorth> group liveries, multi-stop docks, and the fixes to ship turning at docks
21:12:56 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J31KY
21:13:39 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only) https://git.io/J3XIG
21:13:44 <peter1138> Oh right they used to flip instantly.
21:13:45 <TrueBrain> exciting! Now tomorrow I can fix all merge conflicts in my STUN PR again! \o/
21:15:06 <peter1138> I also had a patch to allow you to dock on the sides of the default docks.
21:15:26 <peter1138> In fact I added extra code to make that not the default behaviour :/
21:16:17 <_dp_> andythenorth, more dock features are definitely great seeing that ships still can't leave them without getting lost :p
21:16:18 <andythenorth> there was 3 point docking I remember
21:16:28 <andythenorth> _dp_ I have nothing
21:16:39 <andythenorth> you turned 90 degree turns off again?
21:16:56 <peter1138> They still find their way, they just complain that they're lost.
21:17:58 <_dp_> yeah, buoy, I, buoy, just, buoy, don't buoy, fancy, buoy, puttiing buoys every, buoy, tile :p
21:18:03 <andythenorth> I don't get a lot of lost ships
21:18:07 <andythenorth> I am not everyone
21:19:18 <_dp_> peter1138, you sure they can? last time I checked they kinda went by direction rather than actually pathfinding
21:23:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
21:25:23 *** Progman has quit IRC (Remote host closed the connection)
21:32:02 <peter1138> They follow their cached path, and the cached path only exists if the pathfinder succeeded.
21:35:49 <peter1138> It was but it's not any more.
21:53:32 <andythenorth> git rebase not-sleepy
21:56:08 <peter1138> Rebuild. Chunky. Bevels.
21:59:54 *** lobstarooo has joined #openttd
22:00:50 *** lobstarooo_ has joined #openttd
22:03:12 <peter1138> I need a 4K or maybe 5K screen to properly test quad size.
22:03:57 <peter1138> I spent all this money so that I can test a feature nobody needs.
22:04:36 *** lobster has quit IRC (Ping timeout: 480 seconds)
22:04:42 *** lobstarooo_ is now known as lobster
22:04:46 <peter1138> That was it. The £3500 8K UltraSharp.
22:04:54 <peter1138> Quad size might be too small.
22:08:08 *** lobstarooo has quit IRC (Ping timeout: 480 seconds)
22:09:32 *** Tirili has quit IRC (Remote host closed the connection)
22:11:03 <peter1138> Hmm, so how is it possible that partially finished frames are visible?
22:14:47 *** andythenorth has quit IRC (Quit: andythenorth)
22:28:03 *** sla_ro|master has quit IRC ()
22:28:49 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:08:09 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:26:14 <DorpsGek> [OpenTTD/OpenTTD] FLHerne updated pull request #8996: Fix #8987: Display 'modified version' error when failing to load JGRPP savegames https://git.io/JOJ98
23:26:17 <DorpsGek> [OpenTTD/OpenTTD] FLHerne closed pull request #8996: Fix #8987: Display 'modified version' error when failing to load JGRPP savegames https://git.io/JOJ98
23:26:55 <FLHerne> oops, didn't mean to do that
23:35:20 *** lobstarooo has joined #openttd
23:35:28 *** lobster has quit IRC (Ping timeout: 480 seconds)
23:35:31 *** lobstarooo is now known as lobster
23:56:14 *** didac has quit IRC (Remote host closed the connection)
continue to next day ⏵
