Log for #openttd on 6th May 2021:
Times are UTC Toggle Colours
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:01:00  <glx> happens :)
00:02:41  *** Guest3080 has quit IRC
00:05:43  *** EER has joined #openttd
00:27:53  *** EER has quit IRC
00:32:29  *** lobstarooo has joined #openttd
00:38:16  *** lobster has quit IRC
00:38:20  *** lobstarooo is now known as lobster
00:59:27  <DorpsGek> [OpenTTD/nml] glx22 opened pull request #217: Fix c65b5f98: Missing reference to intermediate proc call created for action3
01:22:01  *** supermop_Home_ has quit IRC
02:34:46  *** Wormnest has quit IRC
02:49:07  *** glx has quit IRC
02:56:15  *** D-HUND has joined #openttd
02:59:33  *** debdog has quit IRC
03:30:50  *** didac has joined #openttd
03:36:59  *** Flygon has joined #openttd
03:56:22  *** arikover` has quit IRC
04:26:21  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 opened issue #9198: empty window Check Online Content
04:30:23  *** WormnestAndroid has quit IRC
04:34:45  *** WormnestAndroid has joined #openttd
05:04:56  *** WormnestAndroid has quit IRC
05:09:47  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9198: empty window Check Online Content
05:28:38  *** Speedy` has quit IRC
05:33:50  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #9198: empty window Check Online Content
06:01:31  *** EER has joined #openttd
06:06:38  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
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
06:58:50  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding
06:59:03  *** didac has quit IRC
07:04:52  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding
07:11:36  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding
07:17:47  *** HerzogDeXtEr has joined #openttd
08:05:10  *** Speedy` has joined #openttd
08:10:05  *** lobstarooo has joined #openttd
08:11:28  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9198: empty window Check Online Content
08:12:39  <LordAro> "I have banned IPv6 for a long time"
08:12:40  <LordAro> hmm.
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:05  <LordAro> that's a bit much
08:14:30  *** lobster has quit IRC
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:26  <LordAro> seems so
08:20:45  <TrueBrain> (as code-wise nothing happens when you close and open the window :P)
08:20:59  <TrueBrain> but we will see
08:24:12  <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
08:26:28  <TrueBrain> right, time to fix the monster of merge conflicts ...
08:26:46  <LordAro> yay!
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:00:31  <TrueBrain> darn
09:01:29  <peter1138> ouch
09:03:22  <LordAro> oops
09:06:24  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
09:07:20  <TrueBrain> and there we go .. IPv6 :)
09:07:39  <LordAro> "dbg: [net] 1)"
09:07:41  <LordAro> huh.
09:07:50  <peter1138> oh fuck off
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:08:46  <peter1138> 1) timescales, lol
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:43  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9198: empty window Check Online Content
09:11:46  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #9198: empty window Check Online Content
09:11:48  <dwfreed> LordAro: 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:12:43  <LordAro> indeed
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:12  <LordAro> mm
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:07  <peter1138> Also wine, lol
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:36  <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:30  <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:16:52  <TrueBrain> so there is that
09:17:13  <peter1138> How big can hamachi networks be anyway?
09:17:30  <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
09:27:09  <dwfreed> peter1138: I mean, they could use a class E block
09:27:19  <dwfreed> since those are bogons
09:28:50  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
09:31:03  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9198: empty window Check Online Content
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:36:34  <TrueBrain> not .. timeout
09:39:16  *** WormnestAndroid has quit IRC
09:39:29  *** WormnestAndroid has joined #openttd
09:39:45  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
09:40:13  <TrueBrain> lol :) Guess we should extend our service to Linux-support too :P
09:45:24  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #9198: empty window Check Online Content
09:48:58  <TrueBrain> it can also be "wine" ofc, completely fucking up IPv6 :P
09:49:14  <LordAro> plausible, but unlikely
09:49:18  <LordAro> imo
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:04  <TrueBrain> either way .. not our problem really :)
09:51:55  *** iSoSyS has joined #openttd
09:59:07  *** Samu has joined #openttd
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:08:50  <TrueBrain> w00p :P
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:14:37  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
10:17:46  <DorpsGek> [OpenTTD/OpenTTD] nirasa1957 commented on issue #9198: empty window Check Online Content
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
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:43  <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:41:42  <dwfreed> RA is a good thing
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:19  <TrueBrain> :D
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:21  <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:56:31  <LordAro> Timberwolf: nice
10:59:21  <dwfreed> TrueBrain: happy eyeballs as threads
10:59:35  <TrueBrain> sorry, what? :D
10:59:40  <TrueBrain> happy eyeballs? :P
10:59:51  <dwfreed>
11:00:15  <TrueBrain> lol @ that name
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
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:14:43  <TrueBrain> very productive :D
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
11:28:14  *** Flygon_ has quit IRC
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:50:46  <peter1138> Nice
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:52:44  <TrueBrain> for more info
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
11:58:10  <TrueBrain> odd
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:08:13  *** nielsm has joined #openttd
12:10:12  <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:44  <andythenorth> lunch?
12:29:58  <TrueBrain> your lunches are getting later and later
12:30:38  <andythenorth> been busy
12:30:41  <andythenorth> css and stuff
12:30:46  <andythenorth> if it's a compliance day I lunch early
12:30:54  <andythenorth> but writing code....always another line to change
12:30:59  <TrueBrain> owh, you know CSS?
12:31:02  <TrueBrain> :P :P
12:31:08  <andythenorth> when I used to code Flash games, I wouldn't eat all day
12:31:10  <andythenorth> bad habits
12:31:22  <andythenorth> OpenTTD Flash port when?
12:33:17  *** supermop_Home_ has joined #openttd
12:36:08  <peter1138> flash bevels?
12:37:23  <peter1138> discord presence?
12:38:42  <peter1138> rocky coastal tiles?
12:39:31  <andythenorth> yes
12:50:22  <TrueBrain> std::deque pop_front() doesn't return the elemant it is poping?
12:50:24  <TrueBrain> unexpected
12:53:30  <peter1138> Yes.
12:53:34  <peter1138> It should do
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:27  * andythenorth lunched
12:54:29  <andythenorth> bye
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
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:30  <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:55:55  <TrueBrain> sad
12:55:57  <TrueBrain> owh well
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:14  <peter1138>
12:57:19  <peter1138> "exception safety" apparently
12:57:33  <TrueBrain> but but .. std::vector does gain the ability in C++20
12:57:35  <TrueBrain> so .....
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:45  <peter1138> Hurry hurry :D
12:58:48  <TrueBrain> I KNOW RIGHT
12:58:54  <TrueBrain> found another rabbit hole ..
12:59:34  <peter1138> Damned rabbits keep breeding.
12:59:41  <TrueBrain> :D
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:31  <TrueBrain> in the one true source:
13:01:36  <TrueBrain> owh
13:01:37  <TrueBrain> lol
13:01:38  <TrueBrain> no, misread
13:01:40  <TrueBrain> was too happy
13:01:41  <TrueBrain> nevermind
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:12  <TrueBrain> why you ask? :)
13:08:44  <peter1138> OS X "lag"?
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:11:27  <Rubidium> TrueBrain: <- known for 4 years, solved years ago, won't be released for another two years. I didn't find it though, someone else linked it here
13:11:45  * LordAro 
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:53  <LordAro> yes
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:27  <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:03  <LordAro> servers will be
13:17:06  <LordAro> people, less so
13:17:24  <Rubidium> dedicated servers will likely not be Windows
13:17:31  <peter1138> So does std::chrono need to be... undone?
13:17:34  <LordAro> likely.
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:20:52  <LordAro> i see
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:21:50  <peter1138> LordAro, I... did.
13:21:51  <TrueBrain> :D
13:22:00  <LordAro> :D
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:49  <peter1138> :D
13:29:54  <Rubidium> it's one of those bugs that has plagued OpenTTD for years
13:30:00  <peter1138> orudge, dangerous
13:30:13  <TrueBrain> "bugs"
13:30:15  <TrueBrain> :(
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:35:40  <TrueBrain> lol
13:36:44  <peter1138> Bug: peter1138 writes crap code
13:36:53  <peter1138> Wait, no, that one is real
13:50:49  <TrueBrain> is it dinner time?
13:50:55  <Rubidium> yes
13:51:07  <TrueBrain> really?! :D :D
13:51:10  <TrueBrain> I am so hungry ...
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:53  <Rubidium> well, you didn't believe my answer on whether it's dinner time, so I provided some proof why it is dinner time
13:54:06  <TrueBrain> alternative facts!
14:09:56  <peter1138> TrueBrain's dinner?
14:11:19  <TrueBrain> IEUW
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)
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)
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)
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:27  <LordAro> before JGR does :p
14:41:33  <TrueBrain> so far, I have removed threads
14:41:35  <TrueBrain> so that should be fine :P
14:41:39  <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
14:50:17  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:51:59  <TrueBrain> "those" :D
14:52:04  <TrueBrain> which one do you mean?
14:52:20  <Rubidium> all 3 of them
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:01:01  <TrueBrain> but .. meh
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
15:03:58  *** Gustavo6046_ is now known as Gustavo6046
15:06:51  <TrueBrain> lol, yeah, I am stupid, lalala
15:08:37  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
15:08:37  <TrueBrain> there ... :D
15:08:53  *** Flygon_ has joined #openttd
15:11:53  *** glx has joined #openttd
15:11:53  *** ChanServ sets mode: +v glx
15:15:43  *** Flygon__ has quit IRC
15:16:19  *** Flygon_ has quit IRC
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)
15:32:42  *** Progman has joined #openttd
15:36:40  *** frosch123 has joined #openttd
15:46:31  <frosch123> <- was linked on reddit, quite nice
15:46:48  <frosch123> though i learned that openrct2 uses js for gui modding...
15:46:50  <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)
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
15:52:57  *** lobstarooo is now known as lobster
15:53:18  <frosch123> currently it works
15:53:22  <glx> ha yeah, sometimes I lose ipv6 too, but it returns without a reboot
15:53:45  <TrueBrain> Too bad :D
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
15:59:29  <frosch123> <- does that make your eyeballs happy?
16:02:28  <frosch123> <- since when does ottd client support https?
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> "[]: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:01  <LordAro> lol
16:13:36  <TrueBrain> (and AWS redirects all traffic to HTTPS, with 1 exception .. "" :P)
16:16:41  <frosch123> so you add [] 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:17:40  <TrueBrain> I know :D
16:18:26  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:19:19  <TrueBrain> (I hope :P)
16:30:22  <frosch123> works
16:30:33  <frosch123> now we only need keep-connection-open :p
16:37:32  *** didac has joined #openttd
16:37:38  <didac> morning
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
16:41:12  <didac> yes yes
16:41:58  <didac> I've been playing with the colors too color depending on a hash of bb size so the same object has the same color and stuff like that
16:43:16  <frosch123> yeah.... i can see why you want to hide sprites :p
16:44:14  <didac>
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:12  <andythenorth>
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:40  <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:14  <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:21  <Rubidium> *can't
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:25  <andythenorth> winner
16:55:27  * andythenorth bbl
16:55:30  *** andythenorth has quit IRC
16:55:44  <Rubidium> if the load of all wagons <= 50%, it will fit under the bridge, otherwise not ;)
16:55:58  <didac> there are still some issues even with 2 units of bridge height difference
16:56:03  <glx> just remove some air from tires ;)
16:57:45  <FLHerne> I wonder how many tiles high this is
16:58:29  <didac> My ultimate intention is I managed to make it work, stacked bridges
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:16  <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:01:54  *** EER has joined #openttd
17:03:30  <_dp_> btw, I did this thing in cmclient for 1.11.2, should make it flicker less:
17:03:40  <didac>
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
17:28:36  *** Wolf01 has joined #openttd
17:34:45  <TrueBrain> frosch123: mind giving a look at with your C++ knowledge? As I mentioned yesterday, std::from_chars is an unknown to me, hopefully you have more context to evaluate it? :D
17:35:52  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9201: Add: [[nodiscard]] to std::string str_validate
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:19  <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:26  <TrueBrain> TIL :D
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:56  <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:45:27  <TrueBrain> frosch123: <- so that is identical, right? (just to confirm what you say I can put into code :P)
17:46:24  <frosch123> yes
17:46:26  <TrueBrain> <3
17:47:19  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
17:47:25  <frosch123> your habit of forward-declaring structs in-place scares me though :p
17:47:41  <TrueBrain> the addrinfo one?
17:47:47  <frosch123> yes
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:48:20  <frosch123> <- my favorite cppcon lightning talk btw. it also talks about forward declareing structs shortly :)
17:48:54  <Rubidium> frosch123: so you meant for NetworkGameList?
17:49:40  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:29  <TrueBrain> (automagic)
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)
17:56:22  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9192: Codechange: [Network] More std::string with less code
18:00:03  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:00:58  <TrueBrain> I blame dwfreed :P
18:10:10  <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9192: Codechange: [Network] More std::string with less code
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:06  <Rubidium> ah, good point
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
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
18:24:50  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9192: Codechange: [Network] More std::string with less code
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
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)
18:30:06  <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #9201: Add: [[nodiscard]] to std::string str_validate
18:31:06  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9201: Add: [[nodiscard]] to std::string str_validate
18:33:30  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9192: Codechange: [Network] More std::string with less code
18:35:54  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9200: Codechange: [Network] Use std::string for network game info
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
18:50:25  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:31  <TrueBrain> pfew :)
18:52:42  <TrueBrain> can't add a comment to a line that is not changed .. lovely :P
18:57:17  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings
18:57:20  <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
18:59:56  <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
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)
19:01:27  <frosch123> did you drop the timezone thing? or is it now off by 1.5 hours?
19:01:34  <TrueBrain> dropped it
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:02:00  <frosch123> :)
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:04:54  <TrueBrain> that makes sense
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:15  *** Speedy` has quit IRC
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:02  <glx> yeah that's an issue
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:48  <glx> "-- -k" then ;)
19:19:56  <TrueBrain> yeah, but assumes "make" again
19:20:09  <TrueBrain> and ideal we also do the same with MSVC
19:20:11  *** EER has joined #openttd
19:20:32  <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
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:21:48  <glx>
19:26:50  <TrueBrain> anyway, by the looks concurrency wasn't really working till recently :P
19:26:53  <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
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:02  <glx> I guess it's probably not possible to use from the running workflow itself
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
19:33:01  <TrueBrain> frosch123: not sure, I think that is used for pending states
19:34:36  <glx> oh is available in the workflow
19:35:04  <glx> I need to try things :)
19:35:11  <TrueBrain> go for it :P
19:36:01  <TrueBrain> <- frosch123 : there is neutral state :P
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:43:56  <peter1138> Sounds horrible :D
19:45:01  <frosch123> stop reading forums/discord :p
19:45:13  *** blathijs has quit IRC
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
19:45:47  <frosch123> remove triggers, always roll random on every evaluation :p
19:45:50  <frosch123> or just use 4
19:45:55  *** andythenorth has joined #openttd
20:14:08  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:15:00  *** lobster has quit IRC
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)
20:20:48  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:23:31  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:23:40  *** frosch123 has quit IRC
20:24:50  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:26:34  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:27:08  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
20:27:21  *** gelignite has quit IRC
20:52:24  *** Samu has quit IRC
20:53:34  *** arikover has quit IRC
21:01:29  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain updated pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
21:03:14  *** Wolf01 has quit IRC
21:04:46  <peter1138> 10mp already :/
21:04:48  <peter1138> 10pm too
21:06:23  <peter1138> Multi-part ships?
21:08:58  <andythenorth> not today
21:09:05  <andythenorth> it's 10.09mp
21:09:18  <peter1138> multipart docks?
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:01  <andythenorth> I do believe
21:10:03  <andythenorth> that you
21:10:04  <andythenorth> are wrong
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)
21:13:15  <peter1138> Was that fixed?
21:13:39  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9199: Feature: use Happy Eyeballs to make network connections (TCP-only)
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:21  <andythenorth> did I try it?
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:02  <peter1138> Also, buoys.
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:52  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings
21:25:23  *** Progman has quit IRC
21:32:02  <peter1138> They follow their cached path, and the cached path only exists if the pathfinder succeeded.
21:35:05  <andythenorth> was it bedtime?
21:35:49  <peter1138> It was but it's not any more.
21:38:22  <andythenorth> that happens
21:52:10  <peter1138> rebase rebase
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:18  *** Pedro_ has joined #openttd
22:03:42  <peter1138> Dear wife...
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
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
22:09:32  *** Tirili has quit IRC
22:11:03  <peter1138> Hmm, so how is it possible that partially finished frames are visible?
22:14:47  *** andythenorth has quit IRC
22:28:03  *** sla_ro|master has quit IRC
22:28:49  *** nielsm has quit IRC
22:46:17  *** Pedro_ has left #openttd
23:08:09  *** HerzogDeXtEr has quit IRC
23:26:14  <DorpsGek> [OpenTTD/OpenTTD] FLHerne updated pull request #8996: Fix #8987: Display 'modified version' error when failing to load JGRPP savegames
23:26:17  <DorpsGek> [OpenTTD/OpenTTD] FLHerne closed pull request #8996: Fix #8987: Display 'modified version' error when failing to load JGRPP savegames
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
23:35:31  *** lobstarooo is now known as lobster
23:56:14  *** didac has quit IRC

Powered by YARRSTE version: svn-trunk