Back to Home / #openttd / 2021 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2021-02-27

---Logopened Sat Feb 27 00:00:57 2021
00:14-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has joined #openttd
00:14-!-Flygon__ is "Flygon" on #openttd
00:20-!-Flygon_ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Ping timeout: 480 seconds]
00:52-!-snail_UES_ [] has quit [Quit: snail_UES_]
01:02-!-Flygon_ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has joined #openttd
01:02-!-Flygon_ is "Flygon" on #openttd
01:08-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Ping timeout: 480 seconds]
01:12-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has joined #openttd
01:12-!-Flygon__ is "Flygon" on #openttd
01:14-!-Westie [~oftc@2001:41d0:2:c10:2::54] has quit [Server closed connection]
01:15-!-Westie [~oftc@] has joined #openttd
01:15-!-Westie is "oftc" on #openttd
01:19-!-Flygon_ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Ping timeout: 480 seconds]
01:26-!-Flygon_ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has joined #openttd
01:26-!-Flygon_ is "Flygon" on #openttd
01:33-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Ping timeout: 480 seconds]
01:34-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has joined #openttd
01:34-!-Flygon__ is "Flygon" on #openttd
01:41-!-Flygon_ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Ping timeout: 480 seconds]
01:46-!-rptr [] has quit [Ping timeout: 480 seconds]
01:54-!-berndj [] has quit [Server closed connection]
01:56-!-berndj [] has joined #openttd
01:56-!-berndj is "Bernd Jendrissek" on #osm-za #openttd #oftc
01:57-!-milek7_ [] has quit [Server closed connection]
01:57-!-milek7 [] has joined #openttd
01:57-!-milek7 is "m7" on #openttd
02:00-!-jottyfan [] has joined #openttd
02:00-!-jottyfan is "jottyfan" on #openttd
02:07-!-Timberwolf [] has quit [Server closed connection]
02:07-!-Timberwolf [] has joined #openttd
02:07-!-Timberwolf is "Matt Kimber" on #openttd
02:08-!-masse[m] [~masserauh@2001:470:1af1:101::7841] has joined #openttd
02:08-!-masse[m] is "info.rauhala:masse" on #openttd #/r/openttd
02:10-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has joined #openttd
02:10-!-rptr is "morbidgirl" on #openttd #C #debian #debian-next #llvm
02:10-!-didac [] has joined #openttd
02:10-!-didac is "OFTC WebIRC Client" on #openttd
02:16-!-masse[m] [~masserauh@2001:470:1af1:101::7841] has left #openttd [User left]
02:22-!-didac [] has quit [Remote host closed the connection]
02:37-!-welterde [] has quit [Server closed connection]
02:37-!-welterde [] has joined #openttd
02:37-!-welterde is "Tassilo Schweyer" on #ix #freeside @#i4 #freedombox @#pnx #tor-dev #monotone @#wwottdgd #openttd
02:39-!-SmatZ [] has quit [Server closed connection]
02:39-!-SmatZ [] has joined #openttd
02:39-!-SmatZ is "Zdenek Sojka" on #openttd.notice #openttd.noai #openttd
02:40-!-andythenorth [] has joined #openttd
02:40-!-andythenorth is "andythenorth" on #openttd
02:50-!-sla_ro|master [] has joined #openttd
02:50-!-sla_ro|master is "slamaster" on @#sla #openttd
03:00-!-nielsm [] has joined #openttd
03:00-!-nielsm is "Niels Martin Hansen" on #openttd
03:02-!-k-man [] has quit [Ping timeout: 480 seconds]
03:10-!-andythenorth [] has quit [Quit: andythenorth]
03:21-!-Progman [] has joined #openttd
03:21-!-Progman is "Peter Henschel" on #openttd
03:24-!-grossing [] has quit [Server closed connection]
03:24-!-grossing [] has joined #openttd
03:24-!-grossing is "Florian Gross" on #openttd #centos #oftc #kaschemme #osm-de-ot
03:28-!-tonyfinn[m] [~tonyfinnm@2001:470:1af1:101::53d9] has quit [Server closed connection]
03:28-!-tonyfinn[m] [~tonyfinnm@2001:470:1af1:101::53d9] has joined #openttd
03:28-!-tonyfinn[m] is "org.matrix:tonyfinn" on #openttd #/r/openttd
03:40-!-Wolf01 [] has joined #openttd
03:40-!-Wolf01 is "Wolf01" on #openttd
03:41-!-andythenorth [] has joined #openttd
03:41-!-andythenorth is "andythenorth" on #openttd
03:51-!-k-man [] has joined #openttd
03:51-!-k-man is "Jason Lewis" on #debian-au #debian-next #debian #oftc #openttd #virt
03:57-!-LordAro [] has quit [Server closed connection]
03:57-!-LordAro [] has joined #openttd
03:57-!-LordAro is "Charles P" on #openttd
04:05-!-skrzyp [] has quit [Server closed connection]
04:05-!-skrzyp [] has joined #openttd
04:05-!-skrzyp is "skrzyp" on #openttd
04:16-!-osvaldo[m] [~osvaldohi@2001:470:1af1:101::44e2] has quit [Server closed connection]
04:16-!-osvaldo[m] [~osvaldohi@2001:470:1af1:101::44e2] has joined #openttd
04:16-!-osvaldo[m] is "org.hispagatos:osvaldo" on #openttd #debian-nginx
04:18<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8751: Disconnecting clients affect other clients in the queue
04:21-!-JamesRoss[m] [~twpolmatr@2001:470:1af1:101::7165] has quit [Server closed connection]
04:21-!-JamesRoss[m] [~twpolmatr@2001:470:1af1:101::7165] has joined #openttd
04:21-!-JamesRoss[m] is "org.matrix:twpol" on #openttd
04:32<_dp_>yeah, it sends pings for queued clients when first finishes dowloading but not while it's still going
04:32<TrueBrain>you are not the only one who can find bugs :P
04:33<_dp_>I saw that bug yesterday, just didn't get to reporting it yet :p
04:33<TrueBrain>sure sure
04:34<_dp_>btw, a interesting detail: most of the map waiting these days is due to server compressing the map, not the network speed
04:35<TrueBrain>the world changed, that is for sure :)
04:35<TrueBrain>it is fully optimized for 2004 Internet
04:35<Eddi|zuHause>we used to have a setting to tweak compression speed
04:36<_dp_>there is a setting but it changes between slow and too slow :p
04:36<Eddi|zuHause>you can set it to uncompressed :p
04:37<_dp_>uncompressed feels like such a waste with all the megabytes of 0s openttd is writing
04:38<_dp_>there should be some faster compression libraries
04:38<_dp_>that at least do some rle xD
04:39<TrueBrain>who was going to implement zstd again?
04:42-!-yur3shmukcik[m] [~yur3shmuk@2001:470:1af1:101::44f3] has quit [Server closed connection]
04:42-!-yur3shmukcik[m] [~yur3shmuk@2001:470:1af1:101::44f3] has joined #openttd
04:42-!-yur3shmukcik[m] is "de.tchncs:yur3shmukcik" on #openttd #debian-xfce
04:42<TrueBrain>funny, the problem is in fact a bit bigger, your ticket
04:42<TrueBrain>the server keeps on saving/sending while the client disconnected
04:43<TrueBrain>not until that is done, the next client can go :P
04:43<_dp_>wow zstd looks awesome
04:43<TrueBrain>so servers running big maps can be DoS'd this way
04:44<_dp_>yeah, queueing has a lot of room for improvement xD
04:44<TrueBrain>yeah, zstd is awesome. Someone a while ago came in and was going to implement it, at least, that was suggested
04:44<_dp_>why can't it send map to several clients at once?
04:44<TrueBrain>speed of L4 compression with the size of any decent compression
04:44<_dp_>it can even be the same map
04:44<TrueBrain>the stagger-issue
04:45<TrueBrain>say, you join a new client at the end when the last finished
04:45<TrueBrain>so you can keep using the same map over and over
04:45<TrueBrain>at the end, the queue to catch up would be HUGE
04:45-!-Eddi|zuHause [] has quit [Server closed connection]
04:45<_dp_>well, yeah, there should be some threshold
04:45<TrueBrain>so a threshold of 1 is a lot easier to implement :D
04:45-!-Eddi|zuHause [] has joined #openttd
04:45-!-Eddi|zuHause is "Johannes E. Krause" on #openttd
04:46<_dp_>but then one slow but persistent client nearly blocks the entire server :p
04:46<TrueBrain>wouldn't make a difference for servers that pause during join anyway
04:46<TrueBrain>(which is the default)
04:47<_dp_>it's nearly unplayable for any significant number of clients
04:48<TrueBrain>okay, solved the primary issue of your ticket
04:48<TrueBrain>the desync is more annoyed, as I am pretty sure it is this one packet that can skip queue
04:48<TrueBrain>so first, solving that "server doesn't respond" issue .. hmm
04:52-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has quit [Quit: Leaving]
04:52<TrueBrain>I just send a packet to all clients that are waiting every second
04:52<TrueBrain>should be more than enough to avoid that problem, without wasting bandwidth
04:52<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread)
04:52<_dp_>there are some other issues with clients being out of the queue, I think I talked about it before
04:53<TrueBrain>if I get a penny every time you mention something like "there is somewhere here possible there somewhere an issue with the network", I wouldn't have to find a job ;)
04:53<TrueBrain>sorry :D
04:53<TrueBrain>you have to be a bit more specific ;)
04:54<TrueBrain>you complain a lot about network, but mostly not in words I can digest :) This ticket is very useful, as that is actionable :)
04:55<TrueBrain>so if you have anything more, spill! :D
04:56<_dp_>well, I have this in my notes:
04:58<_dp_>mistimed company reset is a citymania issue but the rest should be openttd
04:59<TrueBrain>it is very difficult to understand what is happening there :P
04:59-!-Progman [] has quit [Remote host closed the connection]
04:59<TrueBrain>but let me fix the desync issue first
04:59<_dp_>well, yeah, that's why it's not a ticket yet
05:00<_dp_>hard to repro that kind of stuff
05:00<TrueBrain>chain-of-events is often enough to understand what is going on :)
05:00<TrueBrain>that is the most work, honestly
05:01<TrueBrain>okay, the desync is just a stupid bug
05:01<_dp_>well, that's all I have on those issues :P
05:02<_dp_>server log and some speculations basically...
05:03<_dp_>you can see that kind of stuff on redding server all day long, doesn't really much unfortunately :(
05:06<TrueBrain>right, lets see if there are other commands that can create a desync in the same way as company-ctrl could
05:06<TrueBrain>4 commands that get the client-id
05:06-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has joined #openttd
05:06-!-rptr is "morbidgirl" on #llvm #debian-next #debian #C #openttd
05:07<TrueBrain>no, none of them will cause a similar issue
05:08<TrueBrain>GoalScript has one instance
05:11<TrueBrain>same issue, just no chance on desync
05:11<TrueBrain>still, lets fix that
05:11-!-Heiki[m] [~heikimatr@2001:470:1af1:101::5162] has quit [Server closed connection]
05:11-!-Heiki[m] [~heikimatr@2001:470:1af1:101::5162] has joined #openttd
05:11-!-Heiki[m] is "org.matrix:heiki" on #openttd
05:11<TrueBrain>GS Goal
05:11<TrueBrain>don't think you are the only one who can't type today :P
05:12<TrueBrain>CmdGoalQuestion to be really exact
05:12<TrueBrain>right, now that is solved, lets see about your dpaste ..
05:13<_dp_>I can try to confirm some of it with a python client...
05:14<TrueBrain>that paste might make sense to you, but to me it reads as: client was joining a company that got reset, and he got kicked for that
05:14<TrueBrain>which doesn't really seem so much as a bug
05:14<TrueBrain>more just poor timing
05:16<_dp_>poor timing isn't exactly a good reason for kicking clients :p
05:17<TrueBrain>there is also not really a lot that can be done in such situations, and on normal servers this should be ultra rare
05:17<TrueBrain>like super dupah rare
05:20<TrueBrain>so there are 2 ways a client can be forced to become a spectator (which happens out-of-band, from the maps point of view):
05:20<TrueBrain>1) when while joining, the new company you requested could not be made
05:20<TrueBrain>2) when the company you were joining is sold off
05:20-!-jgx [~jgx@] has quit [Remote host closed the connection]
05:21-!-jgx [~jgx@] has joined #openttd
05:21-!-jgx is "realname" on #openttd
05:21<TrueBrain>the first shouldn't be any problem, as you shouldn't have any command queued after that
05:24<TrueBrain>the second also shouldn't be an issue, as there too you shouldn't have had any commands queued up
05:27<TrueBrain>well, no, the second could potentially be an issue, when you send a DoCommand to the server at the EXACT moment he moves you to spectator
05:28<TrueBrain>there is 1 game-tick delay between those two
05:28<TrueBrain>so if your server removes companies when a new client joins, like a garbage collection situation
05:28<TrueBrain>you make it a lot more likely to trigger this issue
05:29<TrueBrain>client joins, sends a command, takes a tick for the server to pick up on that
05:29<TrueBrain>server, on client join, does garbage collection, removes company, receive docommand
05:29<TrueBrain>something like that
05:32-!-HerzogDeXtEr [] has joined #openttd
05:32-!-HerzogDeXtEr is "purple" on #openttd
05:36<_dp_>I'll test it some more...
05:36<_dp_>was pause on join always a non-gui setting?
05:36<_dp_>I could've sworn I changed it from gui yesterday...
05:37<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain opened pull request #8755: Fix: several bugs related to joining a network server
05:37<TrueBrain>I really wouldn't know :)
05:37<TrueBrain>I wasn't here when they made this new setting GUI
05:38<TrueBrain>well that squashes 4 bugs, of which I am pretty sure 2 date back to the invention of the new network protocol
05:38<_dp_>I actually tested pause on join interacts with connecting clients yesterday
05:38<_dp_>wtf was I clicking then... xD
05:39<TrueBrain>if you don't mind testing my PR _dp_ , that would be appreciated
05:39-!-andythenorth [] has quit [Quit: andythenorth]
05:39<_dp_>TrueBrain, yeah, I'll do
05:42<_dp_>NetworkServerNewCompany checks for _network_server so that if is kinda redundant
05:43<TrueBrain>it is, but it makes the function a whole lot more readable that _ci is only used when _network_server is set
05:43<_dp_>yeah, I guess...
05:44<_dp_>though could mb use a comment before someone optimizes it out :p
05:50<TrueBrain>he is very lazy and doesn't want to type aye
05:50<TrueBrain>sn h wll tlk lk ths
05:51<_dp_>TrueBrain, I didn't do any tests yet but I don't quite like your solution tbh
05:51<_dp_>by checking _network_server you just flipped the issue around, not solved it afaict
05:51<_dp_>server and client should success or fail synchronously
05:51<_dp_>but they can't if client info is desynced
05:51<TrueBrain>server validates all DoCommands first
05:52<TrueBrain>remember this only happens for queue packets during map download
05:52<_dp_>isn't company_ctrl always valid?
05:53<_dp_>well, cca_new case I mean
05:53<TrueBrain>the whole if-statement can most likely be removed, as it became bull
05:53<TrueBrain>but I didn't want to go that far yet, as "it might be there for some reason or another"
05:53<TrueBrain>anyway, see my commit messages
05:53<TrueBrain>I think I explain the reasoning there pretty well
05:55<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread)
05:57<_dp_>TrueBrain, server checks whether that client exist after it already queued the that command for all clients afaict
05:57<_dp_>non-existing client creating a company is a much rare cases I guess but should still be posible
05:57<TrueBrain>no; server first validates all commands before it sends them out to the rest
05:58<TrueBrain>the server doesn't blindly broadcasts every DoCommand
05:58<TrueBrain>that would be rather bad :D
05:58<dwfreed>DoCommand blowupeverything()
05:59<_dp_>that validation will stop here
05:59<TrueBrain>and yes, very very strictly speaking, you have 1 tick to leave the server when you created a new company
05:59<TrueBrain>as the only clients that can issue a command, are ones the server know about
06:00<TrueBrain>so that check during testing is never going to fail, like, ever
06:00<TrueBrain>then there is 1 tick delay before everyone executes it
06:00<TrueBrain>except for clients that are joining
06:00<TrueBrain>as I mentioned, the if() could just as well be removed
06:01<_dp_>if it's removed it will create companies twice :p
06:02<_dp_>one on validation, one on execution
06:02<TrueBrain>you .. just pointed out the line that prevents that from happening?
06:02<TrueBrain>the if() around ci doesn't do that
06:03<TrueBrain> <- this is the commit introducing the bug
06:04<TrueBrain>it changed from a "is this ID valid" to a "it has to exist"
06:04<TrueBrain>which is wrong
06:04<_dp_>ah, you meant removing if (ci == nullptr) ?
06:04<TrueBrain>so it is a 13 year old bug
06:04<_dp_>something will probably crash
06:04<_dp_>oh, wait, that may actually crash your pr
06:05<TrueBrain>and we are back to the "somethings" :P
06:05<_dp_>it takes more than 3 seconds to test stuff involving 3 openttd instances :p
06:07<_dp_>but now I know what to test first ;)
06:12<Eddi|zuHause>we should prevent this guy from ever meeting samu. the world might implode
06:13<_dp_>haha, yeah, I just ignored it in hope this stupidity never reaches the github :p
06:14<TrueBrain>that you read all that
06:14<_dp_>that's just literally turning half of the game into
06:15<Eddi|zuHause>exactly. it puts even more emphasis on station walking
06:15<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread)
06:16<Eddi|zuHause>TrueBrain: i didn't strictly read "all" of it, but i tried hard to find the parts that would explain any motivation. didn't find it.
06:18-!-cawal[m] [~cawalbant@2001:470:1af1:101::44e3] has quit [Server closed connection]
06:19-!-cawal[m] [~cawalbant@2001:470:1af1:101::44e3] has joined #openttd
06:19-!-cawal[m] is "city.banter:cawal" on #openttd #debian-xfce
06:20<Eddi|zuHause>what's really the problem with long-distance routes is that there's no simulation of what the receiving industry is willing to pay
06:20-!-nartir[m] [~nartirlin@2001:470:1af1:101::450a] has quit [Server closed connection]
06:20-!-nartir[m] [~nartirlin@2001:470:1af1:101::450a] has joined #openttd
06:20-!-nartir[m] is "life.linuxgaming:nartir" on #openttd
06:21<TrueBrain>because OpenTTD has no concept of economy, not really anyway
06:24<_dp_>I guess I'd say that optimal route being too long on default settings is not ideal
06:24<_dp_>would probably be better to have cargo payment rates slightly different
06:24<_dp_>and you can do with newgrfs ofc... but no one does
06:25<Eddi|zuHause>there's loads of things wrong with payment rates. but if you're just tweaking random calculations without a bigger plan, you're just shifting the problems around instead of solving them
06:26<_dp_>yeah, that's for sure
06:26<_dp_>default stuff mb not ideal but it kinda works
06:26<@peter1138>Michael Blunck?
06:27<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #8753: Change: Improve console warnings on invalid network commands
06:30<@DorpsGek>[OpenTTD/OpenTTD] ldpl commented on pull request #8753: Change: Improve console warnings on invalid network commands
06:31-!-Samu [] has joined #openttd
06:31-!-Samu is "realname" on #openttd
06:32<Eddi|zuHause>peter1138: my exact same thought every single time.
06:32<TrueBrain>I have to admit, me too :D
06:32<TrueBrain>michi_cc: hmm, ClearSystemSprites() is a bit different than any other call, and I am not sure how to solve it properly .. basically, normally when we exit UpdateWindows, we can freely draw
06:32<TrueBrain>nothing is going to influence that anymore
06:33<TrueBrain>GameLoop cannot make a single change, that would make what we want to draw invalid
06:33<TrueBrain>EXCEPT for ClearSystemSprites :D
06:33<TrueBrain>and I am not sure how to solve that properly
06:33<+michi_cc>Hmm, maybe set a flag somehwere and then check that before starting drawing?
06:33<TrueBrain>and skip the frame?
06:34<TrueBrain>(only the next UpdateWindows will correct the cursor_cache)
06:34<+michi_cc>Why skip it, or is loading a sprite from disk not possible then?
06:34<TrueBrain>DrawMouseCursor is called from UpdateWindows, which is filling the cache
06:35<+michi_cc>But DrawMouseCursor is completely a no-op if the video driver draws the cursor.
06:36<TrueBrain>DrawMouseCursor creates the OpenGL sprite, if it is not there yet
06:36<TrueBrain>which seems to be the problem, if I get this right: DrawMouseCursor is called, everything is swell, and everything prepares for drawing. GameLoop runs, clears the cache, and OpenGL is told to render a sprite that is removed
06:37<+michi_cc>Oh, you meant OpenGLBackend::DrawMouseCursor? Because that is create the OpenGL sprite and only called on Paint.
06:37-!-nielsm [] has quit [Ping timeout: 480 seconds]
06:37<TrueBrain>called on Paint? Hmm, now that is interesting ..
06:37<TrueBrain>DrawMouseCursor is normally called from UpdateWindows
06:38<TrueBrain>ah, OpenGL calls it again
06:38<+michi_cc>First line in ::DrawMouseCursor is "if (VideoDriver::GetInstance()->UseSystemCursor()) return;";
06:38<TrueBrain>yeah, okay
06:38<TrueBrain>so why is the mouse corrupted in that case, as then this should be fine
06:38<TrueBrain>threads ... you got to hate them :D
06:38-!-jottyfan [] has quit [Quit: jottyfan]
06:39<TrueBrain>you are right michi_cc , tnx :)
06:39<TrueBrain>functions with the same name called at different times confused me there :D But I knew this ...
06:39<+michi_cc>::DrawMouseCursor and OpenGLBackend::DrawMouseCursor are not the same C++ name :D
06:40<TrueBrain>can you delete a texture from another thread, with OpenGL?
06:40<TrueBrain>can that be the cause of a problem?
06:40<+michi_cc>No, all OpenGL functions depend on a valid context, and that is always thread-specific.
06:41<TrueBrain>so I should set a flag and delay clearing the cursor cache .. lets try
06:41<+michi_cc>So, no, you may not call ClearSystemSprites from a different thread.
06:41-!-Progman [] has joined #openttd
06:41-!-Progman is "Peter Henschel" on #openttd
06:43<TrueBrain>nope, still the same problem
06:51-!-pothyurf[m] [~pothyurfc@2001:470:1af1:101::44eb] has quit [Server closed connection]
06:51-!-pothyurf[m] [~pothyurfc@2001:470:1af1:101::44eb] has joined #openttd
06:51-!-pothyurf[m] is "space.cybre:pothyurf" on #openttd #debian-xfce
06:51-!-bkilm[m] [~bkilmatri@2001:470:1af1:101::6529] has quit [Server closed connection]
06:51-!-bkilm[m] [~bkilmatri@2001:470:1af1:101::6529] has joined #openttd
06:51-!-bkilm[m] is "org.matrix:bkil" on #openttd #C #friendica
06:52<TrueBrain>some debugging later, and it is all done from the same thread for sure
06:52<TrueBrain>so that is not the issue .. hmm
06:53<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8756: Fix #8750: [OpenGL] Line drawing did not set proper RGB/mask colours.
06:54<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8756: Fix #8750: [OpenGL] Line drawing did not set proper RGB/mask colours.
06:57<TrueBrain>owh, so maybe the problem is not so much OpenGL with threads, but our own GetRawSprite
06:57<TrueBrain>that it is flushing the sprites in GameLoop, while DrawMouseCursor() is making it into a OpenGL sprite
06:58<TrueBrain>GetRawSprite reads from the game-state, ofc
06:58<TrueBrain>well, the problem is, it is a difficult mutex to create
06:58<TrueBrain>we want things to draw while GameLoop continues
06:58<TrueBrain>that is the whole point
06:59<TrueBrain>so I think I am better off making a "PrepareCursorCache" or something
06:59<TrueBrain>and do that while the state is still locked
06:59<TrueBrain>the thing that might be tricky there, is that an LRU is used
07:00<TrueBrain>so strictly seen, it could be possible, that it constantly needs to use GetRawSprite?
07:00<TrueBrain>(if _cursor.sprite_count is bigger than LRU size?)
07:00-!-roadt__ [~roadt@] has joined #openttd
07:00-!-roadt__ is "roadt" on #openttd
07:01<+michi_cc>Yes, that way it could happen. It will not be default, no idea if NewGRFs can somehow define an animated cursor with a zillion frames.
07:01<TrueBrain>so OpenGL violates the: do not touch game state during Draw .. so I can blame you, job's done :D :D <3
07:02<+michi_cc>I was never threading OpenGL drawing :P
07:02<TrueBrain>so I got to clean up, pffft :D
07:02<TrueBrain>no, it is totally fine
07:02<TrueBrain>just a bit short on ideas how to solve it
07:03<TrueBrain>you can have at most 16 sprite sequences
07:03<+michi_cc>I don't really know if that LRU is really necessary. General advice on Google is to not create textures "often", but I'm not sure if our cursor switching frequency counts as often.
07:04<+michi_cc>So it might be totally fine to just create textures for exactly the set cursor when it is set.
07:04<TrueBrain>you got to love words like "often"
07:04<TrueBrain>how do you quantify it?
07:04<TrueBrain>well .. just .. you know
07:04<TrueBrain>for a 3D game, I can imagine people do 1000 new textures every frame
07:04<TrueBrain>that is bad
07:05<TrueBrain>but indeed .. that new sprite once every blue-moon for us
07:05<TrueBrain> if (_cursor.sprite_count + seq.count > lengthof(_cursor.sprite_seq)) break;
07:05<TrueBrain>so sprite_count is limited to the length of sprite_seq
07:05<+michi_cc>The unfortunate truth for 3D game stuff is usually: measure for each vendor, each GPU and the ten most common driver versions.
07:05<TrueBrain>which is 16
07:05<TrueBrain>so the 40 LRU cache is sufficient to keep all sprites for at least a single frame
07:06<+michi_cc>Or just get popular enough with your game, then the driver vendors will put in special optimizations for you into their drivers :D
07:06-!-roadt_ [~roadt@] has quit [Ping timeout: 480 seconds]
07:09<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8756: Fix #8750: [OpenGL] Line drawing did not set proper RGB/mask colours.
07:09<@DorpsGek>[OpenTTD/OpenTTD] michicc closed issue #8750: Graph point connector lines are transparent
07:11<TrueBrain>there, problem solved \o/
07:11<TrueBrain>tnx michi_cc :D
07:11<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8741: Move GameLoop into a thread (and no longer run Paint in a thread)
07:22<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8755: Fix: several bugs related to joining a network server
07:22<TrueBrain>_dp_: looked it over again, and indeed, that if() statement can just be removed
07:23<TrueBrain>also resolves the very very unlikely chance someone disconnects in a single frame after creating a company :P
07:24-!-frosch123 [] has joined #openttd
07:24-!-frosch123 is "frosch" on #openttd
07:25<TrueBrain>_dp_: mainly what I forgot, that the server sets the ClientID on broadcast to everyone
07:25<TrueBrain>so this value is only set at DC_EXEC
07:25<TrueBrain>and valid at the time of setting it
07:25-!-Exec [] has quit [Server closed connection]
07:25-!-Exec [] has joined #openttd
07:25-!-Exec is "Exec" on #openttd
07:25<TrueBrain>so what-ever the latency was, it is irrelevant, and the company should be created
07:26<TrueBrain>updated commit message etc to match that
07:34-!-Strakaty [] has quit [Server closed connection]
07:34-!-Strakaty [] has joined #openttd
07:34-!-Strakaty is "..." on #openttd
07:34<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8755: Fix: several bugs related to joining a network server
07:35<_dp_>you're updating it faster than I can test :p
07:39-!-sla_ro|master [] has quit []
07:44<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8704: Change: Move toolbar button for cargo payment graph under industries
07:44<TrueBrain>_dp_: because I am not lazy :P :P :D
07:45<TrueBrain>that last ticket feels like it is a change just for the shake of changing .. curious if there is more to it :)
07:45<TrueBrain>shake? Lol
07:45<@DorpsGek>[OpenTTD/OpenTTD] kiwitreekor updated pull request #7575: Feature: Industry production graph
07:45<TrueBrain>yes, lets go with shake
07:46<@DorpsGek>[OpenTTD/OpenTTD] kiwitreekor commented on pull request #7575: Feature: Industry production graph
07:49<LordAro>TrueBrain: thoughts on RC1 today/tomorrow?
07:49<TrueBrain>I would prefer that
07:50<_dp_>TrueBrain, you want me to spam github with every little weird thing I found? :p
07:50<TrueBrain>_dp_: I do not want anyone to spam any system
07:50<TrueBrain>but if they are things worth mentioning, collect them in a single place, yes
07:50<_dp_>funnily enough when I wanted to screenshot some weird thing I actually found kind of a bug))
07:50<_dp_>client_7 never had a join message
07:50<TrueBrain>just make sure I can either reproduce it, or get what the fuck you are showing :P
07:52<TrueBrain>LordAro: do we also want to branch already, in that case? I ask, as I never really like branching, but I get why we do it :P
07:52<TrueBrain>backporting is just annoying, basically
07:52<LordAro>TrueBrain: it'd save effort to wait until we actually do the release :p
07:52<LordAro>otherwise i'd have to backport the network fixes or whatever :p
07:53<TrueBrain>so we can try that this release, just branch a few days before the release
07:53<TrueBrain>instead of at RC, I guess
07:53<LordAro>also review the remaining "feature" PRs, as they won't get backported otherwise
07:53<_dp_>well, I'm pretty much stress testing it with python atm so reproing stuff logically is a bit tricky :p
07:53<LordAro>_dp_: what do your python scripts look like?
07:54<TrueBrain>LordAro: we could collect the PRs we want in 1.11, and just not merge any others for the next 2 weeks or so, branch after?
07:54<_dp_>LordAro, ehm... this?
07:54<_dp_>and whole bunch of code behind it
07:55<+michi_cc>If we'd want to stay consistent, calling it beta2 would match not branching right now.
07:55<TrueBrain>michi_cc: fair point
07:55<TrueBrain>ugh, GameSpeed window .. I guess that should be done for 1.11
07:55<LordAro>_dp_: ah, properly faking the client
07:55<+michi_cc>I mean, there's no law to require is to do RC1-5 before release :)
07:55<TrueBrain>as otherwise FFWD really is pointless
07:56<LordAro>TrueBrain: ideally, yes :)
07:56<TrueBrain>okay, so lets do a beta2 :)
07:56<TrueBrain>so .. who is doing the changelog? :D
07:56<LordAro>i wasn't expecting anyone else to do it :p
07:56<TrueBrain>happy you offer :D
07:57<_dp_>beta2 after merging desync fixes pls
07:57<_dp_>so I can actually try to see if that help
07:58<_dp_>though it only fails with many clients usually so may not be happening on beta2 :(
07:58<TrueBrain> is what I found for 1.11
07:59<LordAro>_dp_: move all your servers to beta2, simple :p
07:59<@DorpsGek>[OpenTTD/OpenTTD] frosch123 opened pull request #8757: Fix: Issues with cursors consisting of multiple sprites
07:59<frosch123>^^ just leaving that here, but have to go now :)
07:59<_dp_>LordAro, yeah, and have empty servers :p
08:00-!-andythenorth [] has joined #openttd
08:00-!-andythenorth is "andythenorth" on #openttd
08:00<TrueBrain>andythenorth: my dearest macOS tester! How great to see you today! :D
08:01<TrueBrain>if you have any chance in the next few days to test some macOS related stuff, I would love to know if works, and that you don't see anything odd when loading game, fast-forward, generate a 2kx2k map, and change font-size in-game. You should see zero difference
08:03<TrueBrain>LordAro: guess we should also fix OpenGFX missing 2 sprites soon :D
08:03-!-Progman [] has quit [Remote host closed the connection]
08:03<LordAro>ideally before release, yes :p
08:04<LordAro>TrueBrain: but first, can i break a bananas server?
08:04<TrueBrain>LordAro: staging, yes, always
08:05<TrueBrain>what are you planning?
08:05<LordAro>certbot :p
08:05<LordAro>difficult to mess up one without the other
08:05<LordAro>as they're the same server
08:06<@DorpsGek>[OpenTTD/OpenTTD] ldpl commented on issue #8751: Disconnecting clients affect other clients in the queue
08:07<LordAro>TrueBrain: should also do things like opensfx & nml releases
08:08-!-andythenorth [] has quit [Ping timeout: 480 seconds]
08:08<TrueBrain>I poked the translators
08:08<_dp_>8093 vs 8751 nicely illustrates the difference between weird thing and fixable bug :p
08:08<TrueBrain>LordAro: ah .. euh .. yeah, just go for it .. do it on one of the two first if you can
08:09<LordAro>oh for sure, i wouldn't break both at once :p
08:09<LordAro>(though it should handle that anyway, right?)
08:09<TrueBrain>it does
08:09<TrueBrain>just costs more :P
08:10<frosch123>nml still has a PR pending :p
08:11<frosch123>i was going to look into the missing ogfx sprites this weekend though
08:11<_dp_>well, I guess 8093 helped with vehicle pr, it just didn't fix all of the "regular desync" issues
08:12<TrueBrain>I like that we can now just poke the translators :D
08:12<TrueBrain>26 languages without translator
08:13<TrueBrain>out of 63
08:13<TrueBrain>that is not bad
08:13<LordAro>i had it in mind to put a "reminder" in the news post
08:14<TrueBrain>yeah, might be good for the beta post to mention the empty teams
08:15<TrueBrain>just to see if that drags in a few more people :)
08:15<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8757: Fix: Issues with cursors consisting of multiple sprites
08:23<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8099: UI elements (incl. news message) do not resize properly, causing graphical glitches
08:26<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8099: UI elements (incl. news message) do not resize properly, causing graphical glitches
08:28<_dp_>progress of testing #8755 so far: bugs in OpenTTD - 0, bugs in Python - 1 :p
08:31-!-andythenorth [] has joined #openttd
08:31-!-andythenorth is "andythenorth" on #openttd
08:35<TrueBrain>tempted to gamify "fix bugs out of the issuelist"
08:35<TrueBrain>most are just "out there"
08:35<TrueBrain>should just RNG which to pick up
08:35<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8099: UI elements (incl. news message) do not resize properly, causing graphical glitches
08:35<TrueBrain>or live-stream it, ofc
08:36<Eddi|zuHause>TrueBrain: you're going to send andy on a rampage
08:36<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8099: UI elements (incl. news message) do not resize properly, causing graphical glitches
08:38<LordAro>TrueBrain: first step of any minor change, completely refactor it :)
08:38<TrueBrain>oh-oh :P
08:38<TrueBrain>hmm .. fixing many of these bugs is only fun when you are comms with people joking about it, honestly
08:39<TrueBrain>tracking down the bug itself just is not fun at all, so finding a way to make it more fun would be good
08:39<+michi_cc>Okay, let's see if I can properly butcher frosch's PR :)
08:40<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8757: Fix: Issues with cursors consisting of multiple sprites
08:40<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8099: UI elements (incl. news message) do not resize properly, causing graphical glitches
08:41<@DorpsGek>[OpenTTD/OpenTTD] michicc approved pull request #8757: Fix: Issues with cursors consisting of multiple sprites
08:41<TrueBrain>I like how you used one of my tricks :D
08:41<TrueBrain>nice michi_cc :D
08:42<TrueBrain>the news message error seems to be the same as most of the others: reflowing doesn't change height/width of the UIs already active
08:43<TrueBrain>I guess that is done only once, which would make sense
08:49-!-iSoSyS [] has joined #openttd
08:49-!-iSoSyS is "realname" on #/r/openttd #openttd
08:49-!-iSoSyS [] has quit []
08:51<@DorpsGek>[OpenTTD/OpenTTD] 2TallTyler commented on pull request #8704: Change: Move toolbar button for cargo payment graph under industries
08:52<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8757: Fix: Issues with cursors consisting of multiple sprites
09:15<_dp_>you can still easily dos the server just by spamming join and map begin packets...
09:16<_dp_>quiz time, find all the bugs on this screenshot :P
09:25<_dp_>oh, got a better screenshot:
09:29-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:9066::1] has quit [Remote host closed the connection]
09:30-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:9066::1] has joined #openttd
09:30-!-Gustavo6046 is "Gustavo Rehermann <>" on #openttd #llvm
09:31<LordAro>TrueBrain: wait, what
09:31<LordAro>i already did this refactor
09:31<LordAro>i have zero memory of this
09:31<TrueBrain>You are not that old .....
09:31<TrueBrain>You sleeping well? :D
09:32<@DorpsGek>[OpenTTD/aws-infra] LordAro opened pull request #8: Refactor & certbot renewal via webroot
09:32<LordAro>i mean, what
09:32<LordAro>look at #7
09:32<LordAro>i replicated it almost exactly
09:33<TrueBrain>You never merged it, lol
09:33<TrueBrain>Well, merge it now and rebase :)
09:33<LordAro>rebasing it going to be a pain :p
09:34<@DorpsGek>[OpenTTD/aws-infra] LordAro merged pull request #7: Lots of refactoring
09:34<@DorpsGek>[OpenTTD/aws-infra] LordAro pushed 1 commits to master
09:34<@DorpsGek> - Codechange: Reorganise playbook into an actually defined role that we call before certbot/nginx (by LordAro)
09:35<TrueBrain>silly LordAro
09:35<LordAro>TrueBrain: even down to the names of the role
09:35<TrueBrain>at least you are consistent :D
09:36<TrueBrain>so you have that going for you :)
09:47<@DorpsGek>[OpenTTD/aws-infra] LordAro updated pull request #8: Refactor & certbot renewal via webroot
09:48<_dp_>join-map begin-disconnect dos:
09:48<_dp_>savegame reuse is a must for dos protection
09:48<_dp_>also why does it show 30 ms on graphics rendering?
09:49<_dp_>it's way below 1ms without connecting clients
09:49<@DorpsGek>[OpenTTD/aws-infra] LordAro updated pull request #8: Refactor & certbot renewal via webroot
09:49<_dp_>well, just 1 ms, not way below
09:55<frosch123>aw, i kind of expected michi_cc to completely rewrite my fix
09:56<frosch123>not enough opengl magic :)
09:56<+michi_cc>Sorry to disappoint :D
10:00<@DorpsGek>[OpenTTD/aws-infra] LordAro updated pull request #8: Refactor & certbot renewal via webroot
10:00<LordAro>TrueBrain: ready for review :)
10:04<_dp_>TrueBrain, "If we are transfer a map to this client" #8755
10:05-!-nielsm [] has joined #openttd
10:05-!-nielsm is "Niels Martin Hansen" on #openttd
10:13-!-Wormnest [~Wormnest@] has joined #openttd
10:13-!-Wormnest is "Wormnest" on #openttd
10:14<TrueBrain>_dp_: you understand that you talk in riddles, right?
10:14<TrueBrain>LordAro: already deployed, I assume? :P
10:15<LordAro>TrueBrain: to bananas-1, yes
10:15<LordAro>not touched bananas-2 yet
10:16<_dp_>TrueBrain, only riddle should be that screenshot :p
10:16-!-supermop_Home [] has quit [Ping timeout: 480 seconds]
10:16<_dp_>TrueBrain, if you meant last msg it doesn't seem like a correct english
10:17<_dp_>TrueBrain, sholudn't it be "transferring" ?
10:17-!-Flygon__ [~Flygon@2001:44b8:411e:4e00:1d69:3b0b:1222:8030] has quit [Read error: Connection reset by peer]
10:18<TrueBrain>_dp_: context is everything, but you are giving me little to go on here. If you see something wrong in a PR, mention it there, not here please
10:18<TrueBrain>this is just a guessing game at this point
10:19<TrueBrain>(sometimes people forget I cannot know what they are doing / seeing / busy with, so the context switch for me becomes HUGE :P)
10:19<_dp_>I was going to do if you missed it here :p
10:20<@DorpsGek>[OpenTTD/aws-infra] TrueBrain approved pull request #8: Refactor & certbot renewal via webroot
10:20<TrueBrain>LordAro: I see no reason not to deploy this to -2 too
10:21<TrueBrain>and you didn't even trigger an error on the server, nice :D
10:21<LordAro>yeah, was quite pleased with that
10:21<TrueBrain>you should be :)
10:28-!-_2TallTyler [~oftc-webi@] has joined #openttd
10:28-!-_2TallTyler is "OFTC WebIRC Client" on #openttd
10:32<_2TallTyler>TrueBrain: I'd like to have #8688 ready before 1.11. The only thing keeping it in draft is my question (in the PR) about the title feeling cramped. If someone can answer that, it'll be ready for review.
10:33<@DorpsGek>[OpenTTD/master-server] TrueBrain opened pull request #25: Add: ability to blacklist certain servernames and blacklist ""
10:33<TrueBrain>ugh, I really have to PR this now
10:33<TrueBrain>I really did not want to .. but the next month is almost there
10:34<TrueBrain>I cannot side-stream a patch every month :)
10:34<TrueBrain>comments on wording etc are welcome
10:35-!-supermop_Home [] has joined #openttd
10:35-!-supermop_Home is "Guest" on #openttd
10:36<TrueBrain>_2TallTyler: marked the PR for 1.11
10:37<_2TallTyler>Perhaps I'm searching the wrong thing in the server menu, but I don't see any servers by that name?
10:37<TrueBrain>look at the commit dates in that PR _2TallTyler :)
10:37<TrueBrain>there might be a relation between those 2 events
10:38<@DorpsGek>[OpenTTD/OpenTTD] ldpl commented on pull request #8755: Fix: several bugs related to joining a network server
10:39<@DorpsGek>[OpenTTD/OpenTTD] supermop commented on issue #8647: Road and Tramway Catenary Drawn Incorrectly / Unsorted
10:40<_2TallTyler>I'm a bit lost. If the commits aren't merged, why has the problem been fixed?
10:41<TrueBrain>I really really did not want to PR this
10:41<TrueBrain>but I also see no other way
10:41<TrueBrain>as I am not going to hide it for another month :)
10:41<TrueBrain>and in case you are still not picking up on it: this PR is already running in production
10:41<_2TallTyler>Oh, I understand now
10:41-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has quit [Ping timeout: 480 seconds]
10:42<_2TallTyler>Perhaps a screenshot of the problem, if you previously captured one, would help explain for those looking at the PR now?
10:43<_2TallTyler>For example, I don't understand what you mean by "fake server that can't be played on"
10:43<TrueBrain>what I tried to balance is the fine line between making clear we don't appreciate this effort of theirs, and talking bad about them. I think a screenshot would be more in the latter than in the first :)
10:43<TrueBrain>it is a server that is in the serverlist that you cannot play on
10:43<TrueBrain>better wording is welcome
10:44<_2TallTyler>What happens if you try to join a fake server? It just doesn't connect?
10:44<TrueBrain>they are always full
10:44<TrueBrain>the servers were not meant to be played on
10:44<TrueBrain>as in: client 1/1
10:44<TrueBrain>all day every day
10:45<_2TallTyler>Oh, I see. Perhaps that brief explanation would be helpful in the PR :)
10:45<_dp_>not that you can't try too join a full server but no one bothered I guess
10:45<TrueBrain>I tried; I couldn't
10:46<@DorpsGek>[OpenTTD/master-server] frosch123 approved pull request #25: Add: ability to blacklist certain servernames and blacklist ""
10:46<_dp_>interesting, they were actually joinable when it just started
10:46<_dp_>ran like crap but joinable
10:46<TrueBrain>also with 0/1 clients
10:46<TrueBrain>from where I saw them first
10:46<TrueBrain>like .. a multiplayer server with max 1 client, that is just odd
10:47<TrueBrain>anyway, really don't want to speak bad about them, they most likely have a great service etc etc
10:47<TrueBrain>their way of advertisement is just in poor taste
10:47<@DorpsGek>[OpenTTD/master-server] TrueBrain merged pull request #25: Add: ability to blacklist certain servernames and blacklist ""
10:48<TrueBrain>sorry _2TallTyler , I don't want to go in further detail in that PR why it all exactly means .. it just doesn't feel right .. feels like kicking them or something
10:48<TrueBrain>I understand why you ask, but not all details always have to be told to the world in these cases :)
10:49<TrueBrain>the reason I also didn't go for banning IPs etc, is because I am sure they deliver a great service to people
10:49<_2TallTyler>No worries, I trust your judgement more than mine on this matter :)
10:50<TrueBrain>I just hope they write us an email saying they are sorry and that they did not consider if it would be in poor taste or not, and will stop doing it
10:50<TrueBrain>so I can revert this code :)
10:51<TrueBrain>first time in, what, 14 years, we had to deal with something like this .. meh
10:52<_dp_>TrueBrain, is it normal that graphics rendering time increases on the server when clients join?
10:52<_dp_>I get there is a lock on game state but shouldn't count as rendering time, no?
10:53<TrueBrain>first guess: the chat takes more time to render
10:53<_dp_>no, it's like 1 ms to 30 ms
10:53<TrueBrain>so? :)
10:53<_dp_>chat doesn't lag that much ;P
10:54<TrueBrain>how do you know?
10:54<_dp_>it doesn't lag normally?..
10:55<TrueBrain>see, that is a better argument. As I said, first guess :)
10:55<_dp_>my guess is just that waiting for a lock counts as rendering time
10:56<TrueBrain>run the game with no threads and you know
10:58<_dp_>and how do I do that?
10:59<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8755: Fix: several bugs related to joining a network server
10:59<TrueBrain>either compile with NO_THREADS
10:59<TrueBrain>or run with -v<yourvideodriver>:no_threads to only run without drawing threads
11:00<_dp_>damn, I was close xD
11:00<_dp_>doesn't help that it accepts -v sdl:anycrap silently :p
11:01<TrueBrain>oops, "lag" doesn't reset if the server sends a command
11:01<TrueBrain>happy I decided to add a debug statement to be sure
11:02<_dp_>haha, I was just checking that as well
11:06<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain updated pull request #8755: Fix: several bugs related to joining a network server
11:06<@DorpsGek>[OpenTTD/OpenTTD] frosch123 commented on pull request #8688: Feature: Hide block signal GUI by default
11:07<@peter1138>Feature: Remove block signals.
11:08<_2TallTyler>Pretty much, but without breaking old savegames or starting a community uproar :) Also signal priorities still need presignals.
11:09<@peter1138>"Path signals are the only signals needed by the majority of players"
11:09<@peter1138>I don't know who you are but you are welcome for a pint or two.
11:10<LordAro> how's this?
11:10<@DorpsGek>[OpenTTD/OpenTTD] frosch123 commented on pull request #8688: Feature: Hide block signal GUI by default
11:11<@peter1138>I just an error window pop up and the text of the button to close it is... "I see"
11:11<TrueBrain>_dp_: for me, the chat window adds 3ms to graphics rendering. Othewise, client or no client, no difference on a server for me
11:12<frosch123>LordAro: cleary there are too few PR references on the first line
11:12<TrueBrain>LordAro: "Feature: configurable refresh-rate" -> "Feature: configurable display refresh-rate"
11:12<LordAro>frosch123: i thought about adding all the ones that fixed things in previous PRs, but decided against it
11:13<frosch123>is the second line a OCD test? how many get upset by the lowercase?
11:13<TrueBrain>Fix: [AI] Allow estimating CloneVehicle if short on money <- strictly seen not only "AI"; also for humans. I am fine with this message btw
11:13<TrueBrain>the one lower case makes it funny frosch123 :)
11:13<LordAro>TrueBrain: btw, something weird with the framerate window for me - video output displaying quite a high ms
11:14<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on pull request #8704: Change: Move toolbar button for cargo payment graph under industries
11:14<LordAro>FF will go up to 400x, so it's clearly not actually taking that long
11:14<TrueBrain>LordAro: run -ddriver=4 and show output plz :)
11:15<TrueBrain>wauw, that is a long list for a beta2 .. damn .. looks good other than the 2 mentions
11:15<TrueBrain>and the capital, ofc
11:16<@peter1138>Ooof, UKRS running sounds... such a delight.
11:16<TrueBrain>wow, an OpenGL that takes 10ms ? That sounds ... weird
11:16<LordAro>TrueBrain: like i say, it's clearly not taking that long, seems more like the measurement is in the wrong place?
11:16<TrueBrain>something michi_cc might be interesting in
11:17<TrueBrain>how do you know it is not taking that long?
11:17<TrueBrain>do you have a screenshot from FF?
11:18<TrueBrain>video output gets faster if you fast-forward? Lol
11:18<LordAro>ooh, the viewport isn't resizing either
11:18<LordAro>that's odd
11:19<_dp_>TrueBrain, holy crap, that actually is chat window... I can make it go from 3 ms to 15 just by spamming in chat %)
11:19<_dp_>never expected it to be THAT slow
11:19<TrueBrain>_dp_: and you didn't believe me ... tssk
11:19<TrueBrain>never assume, always measure :)
11:19*_dp_ should also probably test release build
11:20<LordAro>viewport is red herring, looks like it got confused about fullscreen
11:21<LordAro>video output also drops when moving around the screen
11:21<LordAro>without FF
11:21<TrueBrain>can you try this branch?
11:21<TrueBrain>if that is easier :D
11:23<LordAro>no change to video output measurement
11:23<TrueBrain>LordAro: I guess you have full animation off?
11:23<TrueBrain>if you turn that on
11:23<LordAro>i did, yes
11:23<LordAro>no change if it's turned on, though graphics frame rate sometimes drops to ~55
11:24<LordAro>FF seems to boost to ~450-550x in this branch though
11:24<TrueBrain>yeah, so it is really taking so much time
11:24<TrueBrain>that branch multithreads exactly that part
11:24<LordAro>this is native Linux/SDL2
11:24<LordAro>nvidia 980ti + mesa
11:24<TrueBrain>for me, in a VM I have to admit, it is lightning fast
11:24<TrueBrain>but I have a 1080
11:25<TrueBrain>so there might be something there
11:25<TrueBrain>if you click the video output
11:25<TrueBrain>the graph
11:25<TrueBrain>is it constantly high?
11:25<TrueBrain>or are there very few datapoints
11:26<LordAro>constantly high (still in your branch)
11:26<LordAro>it seems to switch between ~12ms & ~10ms though
11:26<TrueBrain>but many datapoints?
11:26<TrueBrain>or just like a few per second?
11:26<TrueBrain>yeah, the framerate window doesn't measure when it is not called a tick
11:27<TrueBrain>so if you call it once every 10 ticks with expensive stuff
11:27<TrueBrain>it shows higher than it really is :D
11:27<TrueBrain>hence the question ;)
11:27<LordAro>is there a good pre-GL commit i can try?
11:27<TrueBrain>run with -v sdl
11:27<TrueBrain>no need to go back in commits :)
11:28<@peter1138>Why does the framerate graph keep speeding up?
11:28<@peter1138>(& slowing down)
11:29<LordAro>^ it does seem to keep doing that
11:29<TrueBrain>yeah, the framerate window wants to estimate how many seconds it shows
11:30<TrueBrain>but with the 60fps
11:30<LordAro>video output is about 2ms with sdl
11:30<TrueBrain>it often ends on this border of scale
11:30<TrueBrain>so it keeps jumping around
11:30<TrueBrain>LordAro: did FF get faster too?
11:30<LordAro>about the same, 450x ish
11:30<LordAro>(still your branch)
11:30<TrueBrain>and in master?
11:30<LordAro>let me try rebooting, i did install a load of updates earlier
11:30<TrueBrain>it should remain 450
11:30<TrueBrain>but it sounds like your OpenGL is acting up, really
11:31<@peter1138>Falling back to software rendering?
11:31<LordAro>maybe closer to 350-400x in master
11:31<LordAro>which is about what i got with GL
11:31<TrueBrain>so it really is spending 10ms, I think LordAro :)
11:32<LordAro>like i say, i'll try a reboot
11:32<TrueBrain>let's hope that solves it :D
11:33<LordAro>and i'm back
11:33<TrueBrain>that is quick
11:33<TrueBrain>_dp_: somehow I am not really surprised drawing chat takes time
11:33<@peter1138>Got my graphics showing on Discord, that is hard to see with all the jumping about.
11:33<TrueBrain>if you just look at the code .. boy
11:33<LordAro>i'd say NVMe, but that's my windows install :p
11:33<LordAro>linux is on a plain old boring SSD
11:33<_dp_>TrueBrain, idk, it's horrendously slow
11:33<_dp_>1ms to 10ms on release
11:34<TrueBrain>peter1138: yeah, I know the problem you refer to; will see if I can understand the framerate window code enough to fix it :)
11:34<_dp_>and that isn't even the max amount of text it can get...
11:34<LordAro>no change :/
11:34<LordAro>it's not particularly an issue, just a bit odd
11:35<TrueBrain>LordAro: this is the moment I have to hand you over to michi_cc , I am sure he has knobs he knows to turn to see what part of OpenGL is being slow :)
11:35<TrueBrain>but with OpenGL, we can expect more of these :D
11:35<@peter1138>Is it vsync?
11:35<TrueBrain>vsync is off by default; you can enable it via -vsdl-opengl:vsync, I believe
11:36<@peter1138>Oh, so it's not vsync if it's off by default
11:36<LordAro>peter1138: well, who knows with opengl
11:36<LordAro>being all magic as it is
11:36<TrueBrain>LordAro: possible it is one of those persistent buffer thingies
11:36<TrueBrain>I know on AMD this was a thing
11:37<@peter1138>vsync can be forced on, I suppose.
11:37<LordAro>i suppose i could try installing the nouveau driver
11:37<LordAro>but i quite like my system actually working
11:37<@DorpsGek>[OpenTTD/OpenTTD] 2TallTyler updated pull request #8688: Feature: Hide block signal GUI by default
11:37<TrueBrain>LordAro: src/video/opengl.cpp line 573
11:37<TrueBrain>make sure that variable always get false
11:37<TrueBrain>who knows, maybe it is the same problem as AMD
11:37<TrueBrain>I have no clue, to be clear, about any of this
11:38<TrueBrain>just .. making .. slightly-educated guesses here
11:38<TrueBrain>so put this->persistent_mapping_supported = false; outside of the if-block or something
11:38<@peter1138>"Video output" goes high for me with vsync turned on.
11:38<TrueBrain>peter1138: that is fully to be expected, yes
11:39<LordAro>TrueBrain: nope
11:39<TrueBrain>LordAro: I am out of ideas :)
11:39<TrueBrain>tried different blitters?
11:39<TrueBrain>(I lied)
11:43<+michi_cc>LordAro: NVidia has performance debugging tools (Nsight), but I'd suspect they only work for their own Linux 3D driver, not mesa.
11:43<+michi_cc>Debugging 3D performance by trial and error is a pain in the butt.
11:43<LordAro>8bpp-simple is ~9ms, 32bpp-simple is ~7ms, 32bpp-sse4-anim is ~7ms
11:44<TrueBrain>8bpp-optimized? and 40bpp-anim?
11:44<LordAro>faster, but i suppose that's expected
11:44<TrueBrain>doubt it matters, really
11:45<LordAro>7ms & 12ms respectively
11:45<+michi_cc>Okay, according to Google, llvmpipe is the Mesa software renderer. If that really is the case, we should blacklist that. Using the OpenGL code path with a software emulated backend is never a good idea.
11:46<TrueBrain>haha, lol, no
11:46<LordAro>oh hang on, nvidia driver is already installed
11:46<TrueBrain>so he is simulating OpenGL :D
11:47<LordAro>well that's not especially helpful
11:47<LordAro> Kernel driver in use: nvidia
11:48-!-glx [] has joined #openttd
11:48-!-glx is "Loïc GUILLOUX" on #openttd
11:48-!-mode/#openttd [+v glx] by ChanServ
11:49<LordAro>michi_cc: let me know if you want anything testing
11:50<TrueBrain>your case makes it worth the while to merge the gameloop-thread for 1.11 :P
11:51<TrueBrain>not sure we should, honestly :)
11:51<TrueBrain>possibly better to wait merging that till after branch :D
11:51-!-Progman [] has joined #openttd
11:51-!-Progman is "Peter Henschel" on #openttd
11:52<@peter1138>Will the gameloop-thread fix vsync making everything run slow? (rather than just the UI)
11:52<TrueBrain>sorry, I don't understand that sentence
11:52<+michi_cc>TrueBrain: Am I missing something or is the SDL GL video driver not setting any SDL_GL_SetAttribute?
11:53<TrueBrain>michi_cc: what attributes should it set?
11:53<TrueBrain>and no, you are not missing something :D
11:54<TrueBrain>the defaults looked sane enough to my untrained eye :D
11:54<@peter1138>Currently if you enable vsync, the pause waiting for vsync causes everything to stop, so ffwd becomes pretty limited.
11:54<TrueBrain>ah, yes, peter1138 , my gameloop-thread "fixes" that :)
11:54<@peter1138>Cool :)
11:54<TrueBrain>try it, if you like
11:54<TrueBrain>would love the input
11:54<@peter1138>I don't have a build environment, sorry.
11:55<TrueBrain>and I don't have a build ready :(
11:55<TrueBrain>no worries :)
11:55<+michi_cc>Possibly SDL_GL_ACCELERATED_VISUAL for LordAro (not sure that works for this specific case, though). Maybe also SDL_GL_DEPTH_SIZE, and red, green, blue sizes.
11:55<TrueBrain>the default rgb makes 8bpp
11:55<+michi_cc>I might actually also add those to Win32, just to prevent totally stupid drivers from fucking up.
11:55<TrueBrain>what depth-size would you assign?
11:55<+glx>TrueBrain: a build should be easy to trigger ;)
11:55<TrueBrain>owh, of course, lol
11:56<@peter1138>This game is missing a Glide driver.
11:56<+michi_cc>And at least for SDL, the docs say the default is 16, which would waste a bit performance as we don't use depth at all.
11:56<TrueBrain>michi_cc: indeed
11:56<@peter1138>So... sprite sorting? ;-)
11:56<TrueBrain>rgb all 3 to 8?
11:56<+michi_cc>Basically everything from SelectPixelFormat(HDC dc, bool fullscreen)
11:57<TrueBrain>michi_cc: which is impossible to read for me :D
11:57-!-snail_UES_ [] has joined #openttd
11:57-!-snail_UES_ is "Jacopo Coletto" on #openttd
11:58<@DorpsGek>[OpenTTD/aws-infra] LordAro dismissed a review for pull request #8: Refactor & certbot renewal via webroot
11:58<@DorpsGek>[OpenTTD/aws-infra] LordAro updated pull request #8: Refactor & certbot renewal via webroot
11:58<LordAro>TrueBrain: ansible run on both servers
11:58<@DorpsGek>[OpenTTD/aws-infra] TrueBrain approved pull request #8: Refactor & certbot renewal via webroot
11:59<+michi_cc>Going by the list on we want 8 bit RGB, don't care about back-buffer alpha and don't need depth/stencil/accum.
12:00<+michi_cc>We probably only want accelerated, maybe a core context profile, and potentially a SDL_GL_CONTEXT_DEBUG_FLAG in SDL_GL_CONTEXT_FLAGS for "_debug_driver_level >= 8".
12:00<TrueBrain>wait, we have levels up to 8? :D
12:01<+michi_cc>we have 9 actually :)
12:01<LordAro>you should try -d9 :p
12:01<TrueBrain>but you are the master here michi_cc , what do you want .. "maybe"s don't really help me :D
12:02<TrueBrain>for starters, LordAro , can you test this:
12:02<+michi_cc>For the OpenGL backend specifically, driver=8 is enable GL debug output, and driver=9 tells GL to spam any message it can.
12:02<TrueBrain>I did not test this yet :P
12:02<TrueBrain>okay, added the debug too
12:02<TrueBrain>core context profile yes/no?
12:03<+michi_cc>TrueBrain: I want all of it, unless SDL on Linux makes crap out of one of the settings :D I don't really know to what all the settings actually map to on GLX/EGL.
12:03<TrueBrain>okiedokie boss-man
12:04<+michi_cc>Win32 is trying to get a Core profile 3.2 context first and falls back to any context it can get second. I don't think that fallback is possible with SDL.
12:04<TrueBrain>LordAro: <- in case you are lazy :)
12:04<TrueBrain>owh, I made a boo-boo
12:05<TrueBrain>michi_cc: well, I can set 3.2 as minimum, try to make context, if fails, try any
12:05<TrueBrain>LordAro: try link above again plz :D
12:05<TrueBrain>I should set the stuff before making the context, lol
12:05<+michi_cc>You probably need to move the SDL_GL_CONTEXT_FLAGS as well.
12:06<TrueBrain>whistles innocent
12:06<LordAro>no obvious change
12:06<LordAro>glxinfo also says llvmpipe
12:06<LordAro>so maybe there is just something screwed up with my graphics driver
12:06<TrueBrain>huh? It allows a software renderer?
12:07<TrueBrain>we explicit ask for hardware ..
12:07-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has joined #openttd
12:07-!-rptr is "morbidgirl" on #openttd #C #debian #debian-next #llvm
12:07<TrueBrain>you did use the version where I put the SetAttribute before CreateContext, to double-check?
12:07<+michi_cc>LordAro: Is it still loading sdl-opengl? If yes, the SDL_GL_ACCELERATED_VISUAL seems to be not very useful.
12:07<TrueBrain>lovely odd
12:08<TrueBrain>"set to 1 to require hardware acceleration, set to 0 to force software rendering; defaults to allow either"
12:09<TrueBrain>LordAro: based on, maybe fiddle a bit with these attributes?
12:09<TrueBrain>see if it helps?
12:10<TrueBrain>it should either fall back to non-opengl, or pick another profile, I would guess
12:10<LordAro>[ 4.174] (EE) NVIDIA: Failed to load module "glxserver_nvidia" (module does not exist, 0)
12:11<TrueBrain>michi_cc: I can check after the context if the context is hardware accelerated, I guess
12:11-!-sla_ro|master [] has joined #openttd
12:11-!-sla_ro|master is "slamaster" on @#sla #openttd
12:11<+michi_cc>That, or also
12:11<TrueBrain>LordAro: just as a FYI, we have 2 problems here: 1) your system, 2) us accepting the context :D
12:12<TrueBrain>that is a better solution :D
12:12<+michi_cc>Until they invent mmwnpipe :)
12:13<TrueBrain>looking in the code, SDL_GL_ACCELERATED_VISUAL is of little use indeed
12:14<TrueBrain>it needs an extension before it does anything to start with
12:14<@peter1138>Software accelerated counts?
12:16<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
12:16<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain opened pull request #8759: Fix: [SDL2] set GL attributes to get the best GL context possible
12:16<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
12:17<TrueBrain>tested it in my VM, does what I expect
12:17<@peter1138>No way to force if you felt like it?
12:17<TrueBrain>doesn't mean a lot :P
12:17<@DorpsGek>[OpenTTD/OpenTTD] michicc approved pull request #8759: Fix: [SDL2] set GL attributes to get the best GL context possible
12:19-!-jottyfan [] has joined #openttd
12:19-!-jottyfan is "jottyfan" on #openttd
12:20<@DorpsGek>[OpenTTD/OpenTTD] michicc dismissed a review for pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
12:20<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
12:20<+michi_cc>Okay, added a pure compile time flag to allow software backend for development.
12:22<@DorpsGek>[OpenTTD/OpenTTD] ldpl commented on pull request #8755: Fix: several bugs related to joining a network server
12:24<_dp_>"new company" connection button is definitely my most hated openttd feature :/
12:25<_dp_>can we just remove it? :p
12:27<_dp_>weirdest part is that connecting with "new company" is not the same as connecting as spectator and immediately starting a new company
12:27<_dp_>has same effect for user but different implementation
12:28<+glx>maybe it can be fixed to connect as spectator then create company when client actually finished joining
12:28<LordAro>OpenGL renderer string: GeForce GTX 980 Ti/PCIe/SSE2
12:29<Eddi|zuHause>_dp_: so you should reimplement it, to use the same code paths?
12:29<LordAro>TrueBrain: video output now 0.15ms :)
12:29<_dp_>well, implementation is only half of the problem
12:29<_dp_>other part is that players use it instead of "spectate button"
12:30<+glx>that's a player issue ;)
12:30<Eddi|zuHause>not sure why that is a problem
12:30<LordAro>TrueBrain: on a related note, i now need to resize my EFI partition
12:31<_dp_>spamming server with useless companies
12:31<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on pull request #8755: Fix: several bugs related to joining a network server
12:32<_dp_>^^ can I just ignore that question? :/
12:36<_dp_>also having new company button pretty much only helps players who don't know a thing about the game and can't do anything productive
12:36<_dp_>so they just end up messing with other players anyway :(
12:42-!-_2TallTyler [~oftc-webi@] has quit [Quit: Page closed]
12:44-!-erle- [~stephan@2a04:ee41:3:3297:644e:7a14:d258:226] has joined #openttd
12:44-!-erle- is "Stephan" on #openttd #debian #debian-raspberrypi
12:48<@DorpsGek>[OpenTTD/aws-infra] LordAro merged pull request #8: Refactor & certbot renewal via webroot
12:48<@DorpsGek>[OpenTTD/aws-infra] LordAro pushed 6 commits to master
12:48<@DorpsGek> - Change: Use debian user directly (by LordAro)
12:48<@DorpsGek> - Fix: Split up apt commands so that they actually all work (by LordAro)
12:48<@DorpsGek> - Fix: Missing handler from previous role moves and move files into proper place (by LordAro)
12:48<@DorpsGek> - Change: Use tags for existing roles (by LordAro)
12:48<@DorpsGek> - Codechange: Move firewall-related commands into its own role (by LordAro)
12:48<@DorpsGek> - Change: Do certbot renewal via webroot (by LordAro)
12:49<TrueBrain>A bit overtuned :D
12:51<TrueBrain>and glad OpenGL works for you LordAro :D
12:51<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8759: Fix: [SDL2] set GL attributes to get the best GL context possible
12:51<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
12:51<TrueBrain>and helped us avoid this situation for others :D
12:52<TrueBrain>lets see what _dp_ broke this time
12:53<TrueBrain>I cannot reproduce your short description
12:53<TrueBrain>I started a server, 2 clients, go to multiplayer, hit join game, hit newgame on both at the same time
12:53<TrueBrain>joins fine
12:54<_dp_>hm... try 4kx4k map
12:54<TrueBrain>the transfer was still busy
12:56-!-Wuzzy [] has joined #openttd
12:56-!-Wuzzy is "Wuzzy" on #openttd
12:56<@peter1138>17:24 < _dp_> "new company" connection button is definitely my most hated openttd feature :/
12:56<TrueBrain>his hatred changed by the day, nothing to worry about
12:57<TrueBrain>depends on where he is looking at
12:57<@peter1138>IIRC in the early days company switching wasn't possible, so that's how it was done. It does seem an odd way to do things now.
12:57<TrueBrain>but the summary is: everything is broken :)
12:57<_dp_>TrueBrain, but some stuff more broken then other! :p
12:57<TrueBrain>can you reproduce your own issue?
12:58<_dp_>TrueBrain, try with 4k map few times it doesn't seem to be 100% reliable but I get about 50%
12:58<TrueBrain>how does map-size come into play here?
12:58<@peter1138>Takes longer to compress/download?
12:59<TrueBrain>it takes me 20s to download the map; I tihnk that should be enough :P
13:01<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8758: Fix: [OpenGL] Don't use OpenGL on MESA software renderers.
13:01<TrueBrain>_dp_: I think you need to give more context, like your settings etc
13:02<_dp_>yeah, I'll try to think what affects it
13:02<TrueBrain>begin with pause-on-join etc
13:03<_dp_>yeah, I checked that one already
13:03<TrueBrain>I added delays in the join process at the most annoying places, but nothing breaks
13:04*_dp_ removed openttd.cfg
13:04<_dp_>wtf is this game? xD
13:04<TrueBrain>-x -c bla.cfg, works really well these days :)
13:04<TrueBrain>-x prevents changes from being written
13:04<TrueBrain>-c changes all important folders to your local cwd
13:04<TrueBrain>while, reading bla.cfg
13:05<_dp_>normally I overwrite openttd.cfg each time anyway so whatever
13:07<_dp_>but it's really weird what started without config:
13:07<_dp_>it's tiny
13:07<_dp_>and zbase, wut?
13:07<TrueBrain>you are in too many discord servers
13:07<_dp_>and all but one are openttd :p
13:08<_dp_>that one is mashinki xDD
13:09<_dp_>oh, not even zbase, freaking abase :/
13:10<TrueBrain>funny how the server is SAVING GAME for the full time a client is joining
13:14<_dp_>interesting, so on default settings I get this:
13:14<TrueBrain>_dp_: if you can still reproduce it, knowing what packet fails is handy after all ;)
13:14<_dp_>it's a freaking localhost!!! :p
13:14<TrueBrain>stop sending such hug emaps
13:15<TrueBrain>did not know there is another upper limit; I guess that makes sense
13:16<TrueBrain>so after they got the map, it took them more than 500 ticks to acknowledge that fact
13:16<TrueBrain>that is .. impressive
13:16<TrueBrain>@calc 500 / 33.3
13:16<@DorpsGek>TrueBrain: 15.015015015015017
13:16<TrueBrain>15 seconds to load the map?
13:17<_dp_>no, it gets kicked just as it finishes downloading the map
13:17<TrueBrain>owh, downloading is inclusive
13:17<TrueBrain>how nice
13:18<TrueBrain>either way, very little to do with my PR
13:18<_dp_>yeah, but still a bug kinda
13:19<TrueBrain>and there will be 100 more
13:19<_dp_>is that 500 tick limit even adjustable?
13:19<TrueBrain>max_join_time, ofc it is
13:19<TrueBrain>but that brings us to the question: that new company error you reported, is that also happening in master?
13:20<_dp_>TrueBrain, on master it was desync
13:20<TrueBrain>hmm, I guess
13:21<TrueBrain>but so it is likely the problem was already there, my PR only makes it visible in a new way
13:21<_dp_>or, no, I mean desync if one left
13:21<TrueBrain>so can you reproduce this on master in the same way?
13:21<TrueBrain>(not the timeout, the protocol error)
13:21<_dp_>well, I can't even on your pr now))
13:21<_dp_>let me figure out what's going on
13:28<supermop_Home>is there an opengfx nightly?
13:29<TrueBrain>there should, but it might be that the schedule is cancelled by GitHub :D
13:29<TrueBrain>I enabled it again :)
13:29<supermop_Home>ah ok
13:29<TrueBrain>runs at 21:00 UTC
13:30<supermop_Home>i am trying to test my log flumes, and as long as i am in mountainous arctic land anyway, might as well look at my hotel sprites
13:39<supermop_Home>because my flume 'rear catenary' is drawn over the log due to #8647, I can't see the log to get it aligned...
13:40<supermop_Home>my workaround is to include a chunk of flume on the log itself for now just to line it up:
13:55<@DorpsGek>[OpenTTD/OpenTTD] ldpl approved pull request #8755: Fix: several bugs related to joining a network server
14:00*peter1138 grumbles about image alignment on the main menu
14:01<@DorpsGek>[OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
14:01<@DorpsGek> - Update: Translations from eints (by translators)
14:01<@peter1138>IIRC that was baked-in offsets in the sprites which aligns them, but of course only at 1x size.
14:02<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8733: Feature: Build train locomotive filter
14:02-!-didac [] has joined #openttd
14:02-!-didac is "OFTC WebIRC Client" on #openttd
14:08<_dp_>that bug was crazily lucky, it's just a new company join but I hit some weird timings with that map size
14:08<_dp_>I change tree generator to original and it already doesn't repro
14:09<TrueBrain>good :)
14:10<andythenorth>new trees!
14:15<_dp_>feels like it hits max_join_time but at a weird state as it's exactly 15 seconds since join
14:15<supermop_Home>andy i had a bad idea for steeltown the other day
14:16<TrueBrain>_dp_: well, I have said it a few times already, but we should just make a new protocol version
14:17<TrueBrain>and fix a ton of issues and old tardiness
14:17<_dp_>yeeeshhh, burn it! xD
14:17<TrueBrain>that is one of the things we can put on the pile
14:17<TrueBrain>not burn
14:17<TrueBrain>but the protocol is old, and designed for another Internet
14:19<_dp_>funny talk for a game that somewhat predates internet xD
14:19<TrueBrain>we already replaced the network completely once
14:19<TrueBrain>as the original network was .. euh ..
14:19<TrueBrain>not meant for Internet :P
14:19<andythenorth>supermop_Home ? o_O
14:19<TrueBrain>desync-heaven, basically :)
14:26<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8753: Change: Improve console warnings on invalid network commands
14:28<supermop_Home>andythenorth i was testing cable cars in 1895,
14:29<supermop_Home>and thought my steam trucks pulling trailers full of 1970s looking pickups looked a little odd
14:30<supermop_Home>so thinking, before 1900-ish maybe i should draw little steam engines / tractors / boilers as vehicles cargo
14:31<supermop_Home>so i thought, what if like the assembly plant doesn't exist before like 1905, and there is a locomotive works, or boiler shop or something before that
14:36<@peter1138>Too expensive. I have a diesel Citroen instead.
14:37<supermop_Home>hmm none pf the sound effects seem appropriate for a log
14:38<supermop_Home>is there much chance that 8647 will get any attention before april?
14:44<@DorpsGek>[OpenTTD/OpenTTD] ldpl opened issue #8760: Game asserts/crashes when closed during newgrf scan
14:45<Wolf01>"do not close the game or shutdown your computer while a progress bar is displayed"
14:56<@peter1138>Stupid variety distribution... how do you get a hilly map...
14:57<andythenorth>you can't TrueBrain banned them!
14:59<Eddi|zuHause>peter1138: turn it completely off, and you get a uniformly hilly map
15:00<@peter1138>Yes, it's one extreme to the other.
15:00<supermop_Home>hmm andythenorth also i am getting mostly sawmills on top of hill and forests at the bottom in arctic basic... which makes log flumes a little useless
15:00<Wolf01>I noticed that too ^
15:01<andythenorth>not sure what to say :)
15:01<andythenorth>uphill log flume?
15:11-!-gelignite [] has joined #openttd
15:11-!-gelignite is "realname" on #llvm #openttd
15:18<supermop_Home>for gui sprites, do i provide large and small versions?
15:20<@peter1138>For engine preview?
15:21-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has quit [Remote host closed the connection]
15:21-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has joined #openttd
15:21-!-rptr is "morbidgirl" on #openttd #C #debian #debian-next #llvm
15:27-!-jottyfan [] has quit [Quit: jottyfan]
15:32<supermop_Home>for construction toolbar
15:37<supermop_Home>once i get these in think log flume grf is pretty much set, except for the part where it is broken by the caternary
15:49<@peter1138>I suppose you could but it won't fit in.
16:04<andythenorth>I have done no OpenTTD
16:04<andythenorth>just played Blitz
16:15-!-gelignite [] has quit [Quit: Stay safe!]
16:20<frosch123>supermop_Home: interface zoom level will use the zoomed gui sprites, if you provide them
16:20<frosch123>so you can provide 2x and 4x gui sprites
16:22<@peter1138>Yup. There was a fad at one point of providing 2x sprites but identifying them as 1x, to make a "big gui" ... but eurgh.
16:35<FLHerne>new Gronk paint
16:36<supermop_Home>FLHerne looks too america
16:36<@DorpsGek>[OpenTTD/OpenTTD] ldpl opened issue #8761: Client gets kicked for invalid packet when joining large map with a new company
16:45<frosch123>did someone leak the author of rocket gronk?
16:51-!-erle- [~stephan@2a04:ee41:3:3297:644e:7a14:d258:226] has quit [Quit: Leaving]
16:55-!-Netsplit <-> quits: WormnestAndroid, snail_UES_, nielsm, Wormnest
16:55-!-Netsplit over, joins: WormnestAndroid
16:56-!-Netsplit over, joins: nielsm
16:56-!-Netsplit over, joins: snail_UES_
16:56-!-Netsplit over, joins: Wormnest
16:56-!-Samu [] has quit [Quit: Leaving]
16:57-!-didac [] has quit [Remote host closed the connection]
17:01<supermop_Home>all lined up:
17:06<supermop_Home>do i change sprites based on drive side via a cb or a parameter?
17:10<frosch123>no idea what you mean
17:10<frosch123>you can check the drive-side in a switch() expression
17:24-!-rptr [~rptr@2a00:801:3f2:4b56:e93e:1663:ff0c:6c42] has quit [Quit: Leaving]
17:24<FLHerne>andythenorth: This old BR advert is 100% Horse/FIRS
17:25*andythenorth watches
17:26<andythenorth>it really is
17:27<andythenorth>no pacer in Horse
17:30<FLHerne>It would need a special sound effect for going round corners
17:30-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:45<supermop_Home>andythenorth much 43 porn
17:45<supermop_Home>espescially the last shot of all the cabs in the terminal
17:47*andythenorth bed
17:47<andythenorth>bye :)
17:47-!-Wuzzy2 [] has joined #openttd
17:47-!-Wuzzy2 is "Wuzzy" on #openttd
17:48-!-andythenorth [] has quit [Quit: andythenorth]
17:49-!-Wuzzy [] has quit [Ping timeout: 480 seconds]
17:59-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:25<@DorpsGek>[OpenTTD/OpenTTD] mattkimber opened issue #8762: Alignment issues dragging articulated vehicles in depot
18:48<@DorpsGek>[OpenTTD/OpenTTD] stormcone commented on issue #8762: Alignment issues dragging articulated vehicles in depot
18:53-!-nielsm [] has quit [Ping timeout: 480 seconds]
18:59-!-Progman [] has quit [Remote host closed the connection]
19:06-!-sla_ro|master [] has quit []
19:24<@DorpsGek>[OpenTTD/OpenTTD] mattkimber commented on issue #8762: Alignment issues dragging articulated vehicles in depot
19:24<@DorpsGek>[OpenTTD/OpenTTD] mattkimber closed issue #8762: Alignment issues dragging articulated vehicles in depot
19:34-!-Flygon [~Flygon@2001:44b8:411e:4e00:8dc6:16f8:33bd:7185] has joined #openttd
19:34-!-Flygon is "Flygon" on #openttd
20:21<@peter1138>^ Parts of the "vehicle cursor" disappear when at the edges of the window with OpenGL, I suppose some < 0 check isn't accounting for the offset.
20:51-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
21:19-!-glx [] has quit []
21:30-!-qwebirc84939 [] has joined #openttd
21:30-!-qwebirc84939 is "OFTC WebIRC Client" on #openttd
21:30-!-qwebirc84939 [] has quit [Remote host closed the connection]
21:54-!-Wuzzy2 [] has quit [Quit: Wuzzy2]
22:02-!-Wormnest [~Wormnest@] has quit [Quit: Leaving]
22:17-!-debdog [~debdog@2a00:79c0:653:7f00:7a24:afff:fe8a:d04d] has joined #openttd
22:17-!-debdog is "Wowbagger" on #openttd
22:21-!-D-HUND [~debdog@2a00:79c0:67a:c200:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:30-!-muffindrake2 [] has joined #openttd
22:30-!-muffindrake2 is "muffindrake" on #debian-next #openttd
22:32-!-muffindrake1 [] has quit [Ping timeout: 480 seconds]
22:43-!-Gustavo6046 [~Gustavo60@2804:14d:4cd8:9066::1] has quit [Ping timeout: 480 seconds]
---Logclosed Sun Feb 28 00:00:58 2021