IRC logs for #openttd on OFTC at 2021-08-17
⏴ go to previous day
01:05:00 *** Tirili has quit IRC (Quit: Leaving)
01:58:14 *** Wormnest has quit IRC (Quit: Leaving)
02:40:04 *** WormnestAndroid has quit IRC (Read error: No route to host)
02:40:15 *** WormnestAndroid has joined #openttd
02:54:26 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:32:14 *** WormnestAndroid has quit IRC (Remote host closed the connection)
04:32:27 *** WormnestAndroid has joined #openttd
06:45:21 *** sla_ro|master has joined #openttd
07:45:30 *** andythenorth has joined #openttd
07:52:35 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
07:52:36 *** WormnestAndroid has joined #openttd
08:00:40 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
08:01:16 *** WormnestAndroid has joined #openttd
08:32:58 *** Kitrana1 has quit IRC (Read error: Connection reset by peer)
08:34:10 *** Kitrana has joined #openttd
08:46:42 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #9237: I never get the new trains after 1980- but i get all plains, boats and cars https://git.io/JseBp
08:46:45 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #9237: I never get the new trains after 1980- but i get all plains, boats and cars https://git.io/JseBp
08:47:21 *** andythenorth has left #openttd
08:51:01 *** virtualrandomnumber has joined #openttd
09:14:16 <_dp_> settings code is such a macro hell
09:14:34 <_dp_> tried to add SDT_LIST and now have screen full of errors none of which make any sense :(
09:23:57 <_dp_> ‘std::in_place_type_t<ListSettingDesc>’ is not derived from ‘std::in_place_index_t<_Idx>’
09:24:03 <_dp_> wtf does that even mean?
09:26:47 <LordAro> probably that you missed a comma or {} somewhere
09:29:08 <_dp_> there isn't much to miss...
09:29:10 <_dp_> #define SDT_LIST(base, var, type, flags, def, from, to, cat, extra, startup) NSD(List, SLE_GENERAL(SL_ARR, base, var, type, lengthof(((base*)8)->var), from, to, extra), flags, startup, def)
09:35:00 <_dp_> and that whole thing is just 2 errors...
09:43:20 <LordAro> what is the type of citymania.mapgen.industry_probabilities ?
09:43:21 *** Speedyn has quit IRC (Read error: No route to host)
09:43:50 <_dp_> uint32 industry_probabilities[33];
09:44:20 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #40: Fix: STUN via IPv6 failed in all cases https://git.io/J0Ljt
09:48:54 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #41: Fix: handle clients closing their connection during connect graceful https://git.io/J0teg
09:49:37 <LordAro> _dp_: SDT_LIST isn't used anywhere, and looks like it's missing some parameters on the end of it
09:49:46 <LordAro> (e.g. SDT_SSTR has 0, pre_check, post_callback)
09:49:57 <LordAro> dunno what they are though
09:50:38 <_dp_> they seem to be just passed through to *settingsdesc constructor so should be ok
09:50:53 <_dp_> SDTG_LIST and SDTC_LIST somehow work like this
09:52:35 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #42: Fix: handle servers leaving during verification graceful https://git.io/J0tvK
09:53:58 <TrueBrain> hmmm ... there seems to be an odd condition where a server announced itself on two GC instances .. that should never happen
09:54:08 <TrueBrain> seems that it takes a TCP timeout for it to clean up, which makes sense
09:54:39 <TrueBrain> guess the one receiving the last information should always win .. as that is the one with an active connection
10:00:55 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
10:03:03 <DorpsGek> [OpenTTD/OpenTTD] nchappe updated pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J8PqI
10:05:17 <_dp_> I think I found the freaking error, needed def="""" in .ini instead of NULL
10:06:35 *** EER has quit IRC (Remote host closed the connection)
10:07:45 <_dp_> why .ini can even cause c++ compiling errors is beyound me :/
10:08:11 <LordAro> ...because it's used to generate c++?
10:08:19 <LordAro> garbage in, garbage out, as it were
10:09:41 <DorpsGek> [OpenTTD/OpenTTD] nchappe commented on pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0tkX
10:11:04 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0tIT
10:12:22 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0tIE
10:12:36 <TrueBrain> I can make two servers fight for the same invite-code now :D
10:12:40 <TrueBrain> they keep kicking the other out :P
10:13:03 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0tI1
10:21:32 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #43: Fix: multiple servers announcing themselves with the same invite-code https://git.io/J0tql
10:22:43 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #40: Fix: STUN via IPv6 failed in all cases https://git.io/J0Ljt
10:22:56 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #41: Fix: handle clients closing their connection during connect graceful https://git.io/J0teg
10:23:09 <LordAro> TrueBrain: no way to report an error to the new server?
10:23:29 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain updated pull request #42: Fix: handle servers leaving during verification graceful https://git.io/J0tvK
10:23:54 <TrueBrain> LordAro: it is a bit tricky, as it could also be a stale TCP connection
10:24:48 <TrueBrain> it is a use-case we simply overlooked when talking about persistent invite-codes :D
10:24:48 <Timberwolf> I'm thinking I should change GoRender's pipeline so it does the downscaling entirely in 2D. I'm wondering if a seam carving type algorithm (or at least a well-implemented sinc filter) would do a better job than all my weird hand-hacked multisampling stuff.
10:25:27 <TrueBrain> LordAro: guess we could send a packet to the old server with the reason we disconnected it, that might work
10:26:05 <LordAro> a new connection being able to disconnect an existing connection doesn't quite sit right with me
10:26:17 <LordAro> though i assume things are differentiated more than just invite code?
10:26:18 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #42: Fix: handle servers leaving during verification graceful https://git.io/J0tvK
10:26:31 <TrueBrain> LordAro: the new connection ofc should always win over the old
10:26:43 <TrueBrain> the old could be a stale TCP, or many other reasons, I guess :)
10:27:06 <TrueBrain> the newer connection in general, in networking, should be the winner in such cases
10:27:24 <LordAro> i'm thinking about possible malicious actions - could a third party manage to fake an invite code and disconnect someone else's server?
10:27:25 <TrueBrain> otherwise you get those annoying: "you have to wait till we timeout your old server first" situations :D
10:27:47 <TrueBrain> LordAro: no; in case you didn't follow the design, with only the invite-code you cannot claim an invite-code
10:27:51 <TrueBrain> you also need a secret that comes with it
10:27:59 <TrueBrain> on registration, you are told both invite-code + secret
10:28:02 <TrueBrain> so only you know that :)
10:28:07 <TrueBrain> (the reason we have secrets.cfg now :P)
10:28:12 <LordAro> so if the server operator has leaked their secret, that's on them
10:29:55 <TrueBrain> okay, I can indeed add an error message to the server, telling a newer server with the same invite code was registered
10:30:10 <TrueBrain> does require an OpenTTD modification however
10:35:22 *** Webster has joined #openttd
10:40:43 <TrueBrain> LordAro: you think it would be wise to switch the older server to "local" game? Or should they keep battling each other?
10:43:23 <LordAro> i think that makes sense, yeah
10:57:00 <peter1138> Alright, why is this bug (logic error) only triggered sometimes? :(
10:57:08 <peter1138> A "how is it ever working" situation.
10:57:41 <TrueBrain> You expect it to trigger always? :D
10:58:52 <peter1138> Yes, I'm not expecting UB in C# :-)
11:03:43 <peter1138> I store a record to say something has happened, but actually it only partially happened. So then the action to do it again fails because the record says it happened.
11:04:22 <peter1138> Except sometimes the action to do it again does work, so... I'm confused :D
11:04:48 <TrueBrain> another day at the office :P
11:05:32 <peter1138> And it's the same person doing the action again (the partial part is automatic, the redo is manual), so it's not user rights or the user doing something different. Hmm.
11:06:04 <peter1138> Also why do I want a cargo trailer for my bike? Tesco is only 2 minutes walk away...
11:09:35 <TrueBrain> "[2021-08-17 13:09:04] Another server with the same invite-code registered itself. Switching to "local" game-type."
11:10:03 <peter1138> Is that abuse-able?
11:10:08 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain updated pull request #43: Fix: multiple servers announcing themselves with the same invite-code https://git.io/J0tql
11:10:19 <LordAro> peter1138: see above :p
11:10:30 <LordAro> peter1138: tl;dr only if the server operator has leaked their secret
11:11:13 <TrueBrain> I am happy you all ask, and happy you all agree it is a reasonable solution :D
11:11:26 <DorpsGek> [OpenTTD/py-protocol] TrueBrain opened pull request #14: Feature: support Game Coordinator protocol 6 https://git.io/J0t8i
11:12:15 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain updated pull request #43: Fix: multiple servers announcing themselves with the same invite-code https://git.io/J0tql
11:13:35 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #44: Fix: also be graceful about servers closing connections early https://git.io/J0t44
11:13:53 <DorpsGek> [OpenTTD/py-protocol] TrueBrain updated pull request #14: Feature: support Game Coordinator protocol 6 https://git.io/J0t8i
11:17:20 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9487: Fix: report reuse of invite-code and switch to local game-type https://git.io/J0tBa
11:17:58 <TrueBrain> right, very simple PR :) I wouldn't mind a quick review :) (only of the OpenTTD one; don't worry about the rest :) )
11:18:21 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #44: Fix: also be graceful about servers closing connections early https://git.io/J0t44
11:19:03 <LordAro> nothing else that needs changing with the coordinator spec?
11:19:09 <LordAro> given you're bumping the version...
11:19:35 <TrueBrain> not that I am aware
11:19:46 <TrueBrain> it seems otherwise STUN/TURN is stable
11:19:55 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9487: Fix: report reuse of invite-code and switch to local game-type https://git.io/J0tRJ
11:20:17 <TrueBrain> I do worry a bit about the STUN vs TURN connections .. it is about 2 to 1 atm
11:21:14 <TrueBrain> yesterday we did 500MB of TURN traffic, so that really is okay
11:23:30 <TrueBrain> and 726,780 seconds of TURN usage
11:23:39 <TrueBrain> @calc 532535732 / 726780
11:23:39 <DorpsGek> TrueBrain: 732.7330581468946
11:24:38 <TrueBrain> really did not expect so many connections to prevent this way of STUNing ..
11:24:53 <TrueBrain> but okay .. another way of looking at it: 66% of the traffic doesn't need to be relayed :)
11:25:15 <DorpsGek> [OpenTTD/py-protocol] TrueBrain merged pull request #14: Feature: support Game Coordinator protocol 6 https://git.io/J0t8i
11:25:30 <LordAro> might well change after it actually gets released
11:26:12 <TrueBrain> well, we can always move the TURN servers to OVH servers .. so I am still not worried :D
11:27:58 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain updated pull request #43: Fix: multiple servers announcing themselves with the same invite-code https://git.io/J0tql
11:30:25 <TrueBrain> our ECS cluster has been a bit more busy with 12.0-beta1 release :D Shocker :P
11:35:18 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #43: Fix: multiple servers announcing themselves with the same invite-code https://git.io/J0tql
11:35:33 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9487: Fix: report reuse of invite-code and switch to local game-type https://git.io/J0tBa
11:36:02 <TrueBrain> k, time to test this on staging ..
11:36:29 <TrueBrain> too bad a deployment still kills all current TURN sessions, but yeah .. not much I can do about that :)
11:40:53 <peter1138> implement keepalived-style restarts?
11:41:53 <TrueBrain> yeah .. I think AWS has support for that
11:41:57 <TrueBrain> just haven't looked into how to do it :P
11:42:34 <TrueBrain> owh, shit, my commit murders OpenTTD .. oops
11:43:01 <DorpsGek> [OpenTTD/OpenTTD] nchappe updated pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J8PqI
11:43:51 <TrueBrain> yeah, the reviewer just didn't try hard enough
11:46:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #9488: Fix 6acf204d: crash when showing coordinator-error-messages https://git.io/J0t2Q
11:47:29 <peter1138> Damn, found an unused outdoor solar night light. Been in its box for 2 years so of course the battery is dead :(
11:51:11 <_dp_> right as I finished merging beta1 xD
11:56:55 <LordAro> nothing else we can fix quickly at the same time?
11:57:07 <LordAro> that currency setting thing doesn't look particularly complicated?
11:58:55 <TrueBrain> I think we should release beta2 today / tomorrow latest
11:59:04 <TrueBrain> so that fully depends if someone is planning to do that today / tomorrow
12:00:19 <TrueBrain> that bug is btw pretty old
12:00:52 <TrueBrain> at least 10 years, from what I can see quickly :)
12:01:40 <TrueBrain> funny how long some things take for people to notice :D
12:01:45 <TrueBrain> guess nobody really looks at the configuration file like that
12:02:37 <TrueBrain> right, I am off for a while. Will check tonight if someone wants to pick up that bug, or if we just release beta2 like this.
12:02:49 <TrueBrain> feel free to merge #9488 when approving :P
12:03:19 <DorpsGek> [OpenTTD/OpenTTD] nchappe commented on pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0toI
12:04:45 <TrueBrain> and in good news, IPv6 STUN works :D
12:09:36 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9488: Fix 6acf204d: crash when showing coordinator-error-messages https://git.io/J0tK5
12:20:43 <peter1138> Bah, USB socket on my Edge 130 is dodgy, gotta be the right angle or it won't chage :(
12:21:42 <glx> hmm should I force eints so I can translate the new string ?
12:25:38 <peter1138> LordAro, I used to want pedal power meters, now I think I'd just be disappointed with my performance...
12:40:57 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J0tSz
12:42:48 <michi_cc> LordAro: Any last words about #9457?
12:46:10 <Timberwolf> That will be good, it was driving me mad a couple of games ago when passengers wouldn't use my airports, because there was a short shuttle train out from the city centre at each end.
12:46:22 <michi_cc> Makes #9489 completely outdated, though :P
12:58:04 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9457: Feature: [Linkgraph] Prioritize faster routes for passengers and express cargo https://git.io/J8PqI
13:02:01 <peter1138> Do we still get helpfully told that cargodist is bad?
13:32:24 *** sla_ro|master has quit IRC ()
13:34:31 <TrueBrain> michi_cc: we fix that when ever we decide to really release :D And I appreciate the update in website, cheers for that :)
13:38:44 <glx> STUN (IPv6) 0% <-- at least this one should change ;)
13:38:57 <TrueBrain> hover over, it is 6!
13:41:55 <_dp_> what does stun/turn mean on servers chart?
13:42:08 <_dp_> and I guess server charts in general...
13:47:22 <DorpsGek> - Update: Translations from eints (by translators)
13:47:54 <glx> (I needed to get the new string to translate it ;) )
13:50:27 <peter1138> I suppose Direct (IPv4) will become more dominent when the dedicated servers are updated.
13:51:22 <glx> direct IPv4 means open ports, so probably
13:52:06 <LordAro> assuming dedicated servers remain the dominent form of hosting
13:52:11 <LordAro> there's no reason they will
13:52:41 <glx> but we also may get more servers behind closed ports as it's now easier for users
13:52:42 <LordAro> _dp_: those are the new connection methods
13:52:47 <LordAro> the whole reason for the networking rewrites
13:53:47 <peter1138> Where do I find my server now? Hmm.
13:54:15 <peter1138> Do I need to tweak my config at all?
13:54:52 <_dp_> LordAro, I get what it means for connections, but what it means as servers
13:54:55 <glx> no config change required (unless to specify to connection type public, private or local)
13:55:30 <peter1138> Is public the default?
13:56:51 <LordAro> _dp_: given this chart is just whatever the GC sees, it's possibly just poorly named?
13:57:25 <TrueBrain> peter1138: "local" is the default, as was the old "not advertised" :) But it migrates settings, so "advertised" servers become "public" :)
13:57:31 <_dp_> LordAro, well, there are connection charts below, so...
13:57:42 <glx> I think new values are compatible with old ones
13:58:05 <peter1138> server_game_type = local
13:58:11 <peter1138> Well... that didn't get migrated.
13:58:22 <TrueBrain> LordAro: at startup, a server is probed what it is capable of, to avoid connections trying shit that isn't going to work anyway. So IPv4 / IPv6, Direct-IP access yes/no, STUN capable or not, and, if all fails, TURN capable only :)
13:58:32 <TrueBrain> peter1138: guess we fucked up :D
13:59:36 <peter1138> Oh. Game crashed. Hmm.
14:00:08 <TrueBrain> crash report crash report crash repooorrrtttt :D
14:00:11 <peter1138> <infinite loop> in the stack trace :D
14:00:34 <glx> should be the random hard to trace one
14:01:53 <_dp_> TrueBrain, do those numbers mean there were over 500 servers started yesterday?
14:02:22 <peter1138> Multiplayer list likes to scroll the bottom, hmm.
14:06:54 <_dp_> TrueBrain, also am I getting it right that both STUN and TURN servers are basically behing NAT, but STUN can be punched and TURN can't
14:07:09 <_dp_> and it also depends on client whether it can punch to the stun-capable server or not
14:07:14 <peter1138> STUN and TURN aren't servers.
14:07:16 <Samu> how do i test this stun turn things?
14:07:19 <peter1138> They are connection methods.
14:07:51 <_dp_> peter1138, that was my first quesstion ;)
14:08:19 <peter1138> So yes, STUN is "Session Traversal Utilities for NAT"
14:08:23 <Samu> are they in openttd 12.0beta?
14:08:39 <glx> and in nightlies for some time too
14:09:27 <glx> and you don't directly test stun or turn, you just connect to a server and the best working method is used
14:09:41 <peter1138> Which means it was able to exploit weaknesses in IP stacks to make a connection. TURN is "Traversal Using Relays around NAT", so a proxy server in the way.
14:10:37 <peter1138> Damn, don't have rights to look at current stats.
14:10:57 <glx> IIRC TURN is the only for an IPv4 only client to join an IPv6 only server, and vice versa
14:11:13 <glx> missing a "way' somewhere
14:14:20 <peter1138> Samu found my server, but of course it should all be open wide anyway.
14:14:55 <_dp_> peter1138, if you're trying to answer me you missed the whole quesion, I seem to understand stun/turn connections, I'm trying to understand what "stun"/"turn" "servers" on that chart mean
14:15:16 <Samu> i joined with no problem
14:15:56 <glx> I think it's method used by clients to join servers _dp_
14:16:29 <peter1138> glx, well, there's "servers" and "connections" and stats for both.
14:17:12 <_dp_> yeah, and TB already answered it means stun/turn-capable servers, I'm just trying to clarify I understand everything correctly
14:17:48 <glx> oh yeah GC tries the different methods IIRC
14:18:27 <peter1138> I think STUN doesn't necessarily imply NAT, it can also break through straight firewalls. Maybe.
14:19:09 <glx> yes STUN can cross windows firewall if ports are open on router, but not in firewall
14:19:14 <peter1138> Samu, have you found a way to run an AI as a client? :)
14:19:18 <_dp_> peter1138, yeah, that was a bit of a poor wording
14:19:54 <Samu> that would be interesting
14:19:54 <_dp_> what I'm trying to confirm is that direct server will always have direct connections, stun server can have both stun and turn and turn server will only have turn.
14:20:27 <glx> direct server will have direct connections if client is not restricted by stupid ISP
14:20:49 <glx> worst case client will use TURN
14:21:19 <_dp_> glx, you mean isp allows connections to turn.openttd.org but not to the server directly?
14:21:32 <glx> happens with broken peerings
14:21:47 <peter1138> Could be a geographical block.
14:22:00 <_dp_> but, yeah, I guess there are some rare exceptions...
14:22:14 <LordAro> _dp_: and yet we're seeing 33% using TURN
14:22:51 <Samu> what did i use? turn or stun? how can i tell
14:22:55 <_dp_> would be interesting to see breakdown of connection types by server capability
14:23:14 <glx> you can tell, unless you received a message box about relay
14:23:30 <LordAro> isn't it in the client list window?
14:24:04 <glx> ha yeah "behind NAT" I guess
14:26:18 <peter1138> Okay, what happens if I disable my firewall rules after the server is started...
14:26:36 <peter1138> Periodically retested?
14:32:56 <peter1138> So for the IPv4 connections I see 3 "Connected to" messages before the Connected from line.
14:38:19 <TrueBrain> peter1138: no, connections are not retested :)
14:38:45 <TrueBrain> LordAro: no, only the servers shows what type of connection he is (most likely) on. There is no GUI to inform how the connection from the client to server was created :)
14:40:25 <TrueBrain> (I guess that also would only clutter the interface .. guess most people don't care how they are connected, just that they are :P)
15:39:11 *** virtualrandomnumber has joined #openttd
15:39:42 *** virtualrandomnumber has quit IRC ()
16:01:11 *** jottyfan has joined #openttd
16:07:15 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
16:07:37 *** WormnestAndroid has joined #openttd
16:14:23 *** gelignite has joined #openttd
16:34:12 *** Kitrana1 has joined #openttd
16:38:42 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
17:05:29 *** Progman has joined #openttd
17:08:17 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
17:08:34 *** Wormnest has joined #openttd
17:09:06 *** WormnestAndroid has joined #openttd
17:13:00 *** jottyfan has quit IRC (Quit: jottyfan)
17:33:50 *** andythenorth has joined #openttd
17:42:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9488: Fix 6acf204d: crash when showing coordinator-error-messages https://git.io/J0t2Q
17:42:52 *** HerzogDeXtEr has joined #openttd
17:54:13 *** sla_ro|master has joined #openttd
18:06:05 <DorpsGek> [OpenTTD/OpenTTD] ldpl opened issue #9491: [Bug]: "Use relay?" propmt can timeout with a weird error https://git.io/J0mIJ
18:07:19 <_dp_> Also would be nice to see server connection capabilites somewhere
18:07:39 <_dp_> I shouldn't be getting TURN prompts, I'd like to know if that's server fault or mine.
18:07:52 <_dp_> I mean TURN connection in general
18:14:35 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
18:16:26 <_dp_> Also is there any particular reason why new company/spectate option was removed from the bald guy button dropdown?
18:16:34 <_dp_> They were pretty convenient there
18:17:12 *** WormnestAndroid has joined #openttd
18:29:20 *** Flygon has quit IRC (Read error: Connection reset by peer)
18:42:43 *** Wolf01 is now known as Guest4640
18:46:26 *** Guest4640 has quit IRC (Ping timeout: 480 seconds)
18:53:52 *** WormnestAndroid has quit IRC (Remote host closed the connection)
18:54:14 <DorpsGek> - Update: Translations from eints (by translators)
18:54:59 *** Cursarion has quit IRC (Server closed connection)
18:55:01 *** Cursarion has joined #openttd
18:55:54 *** WormnestAndroid has joined #openttd
19:03:59 <peter1138> _dp_, something odd with your connection?
19:08:03 <_dp_> peter1138, wdym? connection seems fine
19:08:18 <peter1138> _dp_, see link in PM
19:18:08 *** SpComb has quit IRC (Server closed connection)
19:26:12 *** Gustavo6046 has quit IRC (Remote host closed the connection)
19:26:13 *** Gustavo6046_ has joined #openttd
19:26:43 *** Gustavo6046_ is now known as Gustavo6046
19:31:54 <_dp_> hm, apparently connecting peter1138's server via "search internet" asks me to use TURN but adding it by ip directly doesn't
19:32:03 <_dp_> pretty sure it shouldn't work that way...
19:35:03 <_dp_> are public servers even accessible directly atm? I only see invite codes everywhere, how is it supposed to get ip?
19:35:15 *** Heiki has quit IRC (Server closed connection)
19:44:56 <peter1138> I only see the invite code too.
19:45:58 <peter1138> Can increase debug_level net to get more info.
19:49:07 *** jottyfan has joined #openttd
19:55:56 *** gelignite has quit IRC (Quit: Stay safe!)
20:03:02 <glx> when I join via multiplayer window it uses direct IPv6
20:08:01 *** Tirili has quit IRC (Remote host closed the connection)
20:24:22 <glx> _dp_: can you try +68MvRhD ? (it's an invitation only server to test)
20:25:33 <_dp_> yep, connected without turn
20:26:32 *** andythenorth has quit IRC (Quit: andythenorth)
20:27:25 <_dp_> oh, but it asks for turn the second time
20:27:31 <_dp_> I just restarted the gaem
20:27:56 <glx> yes I see turn in the log
20:28:11 <_dp_> I've no idea when or why it asks
20:28:23 <glx> but it's an ipv4/ipv6 server fully open
20:28:51 <glx> I don't remember if GC registers both ip
20:29:22 <glx> I only see it connect brievly to the ipv6 one on start
20:30:33 <_dp_> well, I have no ipv6 whatsoever
20:30:47 <glx> let me try an ipv4 only server
20:31:39 <_dp_> anyway, it seems to be asking for turn randomly
20:32:11 <_dp_> so some kind of no ipv6 or timeout issue?
20:33:05 <_dp_> actually, not randomly, as soon as I added -d net=5 it stopped :/
20:34:49 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:35:04 <glx> hmm ipv4 only is behind nat
20:35:20 <glx> let's check the router settings
20:36:35 <glx> ok now the ports are open
20:37:02 <glx> (leftover from latest testing with TB :) )
20:39:30 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:40:06 <glx> yes I'm retrying both v4 and v6 but fully open on ipv4 this time
20:40:35 *** WormnestAndroid has joined #openttd
20:41:03 <glx> and I can see GC connection on both
20:42:13 <glx> and direct v4 works for you :)
20:42:51 <glx> so there seem to be an issue with turn
20:43:45 <glx> or an issue with stun on half closed dual stack
20:53:11 <glx> <@peter1138> So for the IPv4 connections I see 3 "Connected to" messages before the Connected from line. <-- with higher net debug level you should see "resolving stun/turn" before the "connected to" (I had that in my testing with -dnet6)
20:54:05 <glx> could mean your ipv4 was not directly accessible during registration to GC
21:01:53 *** Tirili has quit IRC (Remote host closed the connection)
21:19:06 <_dp_> would be nice to have some kind option to make sure to only start server if it's directly accessible
21:19:43 <glx> the idea with stun/turn is that you don't have to be directly accessible
21:20:42 <glx> so no need to redirect ports on the router
21:21:51 <glx> but somehow, in your case, the turn fallback was chosen while stun should have been ok
21:22:36 <_dp_> yeah, but for a proper dedicated server it just means something went wrong with networking
21:23:12 <Timberwolf> Well, I lost an entire evening implementing Lanczos3 only to discover that my custom-built scaler is quite a bit better for the specific problem of outputting palette-constrained objects at tiny resolutions.
21:24:02 <Timberwolf> Having the output scaler aware of what was going in in the 3D domain makes it better at doing things like rendering small details.
21:28:29 *** Samu has quit IRC (Ping timeout: 480 seconds)
21:51:15 *** ChanServ sets mode: +v tokai
21:58:04 *** TinoDidriksen has quit IRC (Server closed connection)
21:58:04 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:58:15 *** TinoDidriksen has joined #openttd
21:58:52 *** TinoDidriksen is now known as Guest4660
22:21:29 *** sla_ro|master has quit IRC ()
22:31:08 *** tokai|noir has joined #openttd
22:31:08 *** ChanServ sets mode: +v tokai|noir
22:36:02 <DorpsGek> [OpenTTD/OpenTTD] nchappe opened pull request #9493: Fix 977604ef: [Linkgraph] Add a special case for unknown travel times on link update https://git.io/J0mps
22:38:01 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:42:01 *** Progman has quit IRC (Remote host closed the connection)
22:45:26 *** virtualrandomnumber has joined #openttd
22:45:40 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
22:45:58 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:08:34 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:12:28 *** orudge has quit IRC (Server closed connection)
23:27:50 *** Alkel_U3 has quit IRC (Quit: maintenance)
23:34:58 *** grossing has quit IRC (Server closed connection)
23:34:59 *** grossing has joined #openttd
23:36:54 *** Alkel_U3 has joined #openttd
23:48:03 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #9493: Fix 977604ef: [Linkgraph] Add a special case for unknown travel times on link update https://git.io/J0YtU
23:48:16 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #9493: Fix 977604ef: [Linkgraph] Add a special case for unknown travel times on link update https://git.io/J0mps
23:49:51 *** ChanServ sets mode: +v tokai
23:56:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵