IRC logs for #openttd on OFTC at 2021-11-03
⏴ go to previous day
02:35:28 *** Wormnest has quit IRC (Quit: Leaving)
04:13:13 *** snail_UES_ has quit IRC (Quit: snail_UES_)
05:39:35 *** _aD has quit IRC (Ping timeout: 480 seconds)
07:13:37 *** andythenorth has joined #openttd
07:18:37 *** andythenorth has quit IRC ()
07:19:52 *** sla_ro|master has joined #openttd
08:07:43 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:38:04 *** andythenorth has joined #openttd
08:53:46 *** sla_ro|master has quit IRC ()
08:56:17 *** gnu_jj has quit IRC (Remote host closed the connection)
09:29:46 *** andythenorth has quit IRC (Quit: andythenorth)
11:10:27 *** sla_ro|master has joined #openttd
11:13:06 <Samu> it's positive, I'm infected with covid
11:17:40 <Samu> what have I done to deserve this
11:28:26 *** juzza1 has quit IRC (Ping timeout: 480 seconds)
11:41:46 <Tryard> Hi, I would like to know if it is possible to develop an extension to permit to share rails and stops between players
11:43:02 <dP> only possible by patching the game and it's already done in jgrpp
11:44:41 *** virtualrandomnumber has joined #openttd
11:45:38 *** virtualrandomnumber has quit IRC ()
11:47:50 <Tryard> That's cool, ant this version is compatible with public servers?
11:48:50 <dP> no, it's only compatible with jgrpp servers
11:49:23 <Tryard> Do you know where I can find a compatible public server?
11:49:58 <dP> but it doesn't have infrastructure sharing because you can't do that compatibly
11:50:26 <Tryard> It is possible to build a compatible server?
11:51:00 <dP> if you want jgrpp servers just start the game as usual, it will show ones you can connect to
11:51:28 <dP> depends on what you want, some features you can do compatibly some not
11:52:11 <Tryard> Another questions, Do you know if it possible to buy shares of a company?
11:52:42 <Tryard> I never understood very well this feature
11:54:49 <dP> there is a setting to enable buying "shares" but it's pretty pointless imo
11:54:58 <dP> just some artifact from the original game
11:56:28 <Tryard> If you buy shares you don't receive any money?
11:56:43 <Tryard> Are there no advantages?
11:57:22 *** WormnestAndroid has joined #openttd
11:57:23 <dP> you can buy them cheap and sell them when company grows
11:57:50 <dP> I've seen someone even playing by watching ai companies and "trading" their shares
11:58:01 <Tryard> So it is possible to make money in this manner
11:58:51 <dP> in multiplayer you can even exploit it and get infinite money xD
12:00:08 <Tryard> But is not enabled as default, right?
12:01:06 <Tryard> Where it is possible to enable it?
12:01:24 <dP> like everything else, in settings
12:01:37 <dP> called "Competitors->Allow buying shares from other companies"
12:03:28 <Tryard> Ok, and anyone can buy your company shares also without your approval?
12:04:03 <dP> not that it changes anything for you
12:05:10 <Tryard> Yes, it is only to know how it work
12:06:23 <Tryard> Thank you so much, I love this game and I think that with jgrpp patch my love will encrease
14:24:02 *** ChanServ sets mode: +v tokai
14:30:56 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
15:26:50 *** Wormnest has joined #openttd
16:46:35 *** _aD has quit IRC (Ping timeout: 480 seconds)
16:54:08 *** tokai|noir has joined #openttd
16:54:09 *** ChanServ sets mode: +v tokai|noir
17:00:43 *** frosch123 has joined #openttd
17:01:01 *** tokai has quit IRC (Ping timeout: 480 seconds)
17:05:14 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:21:10 <Tryard> How I can list a dedicated server?
17:22:43 <LordAro> Tryard: i don't understand what you mean
17:23:24 <Tryard> I would like to build a dedicated server that everyone can find in the list of public servers
17:23:37 <LordAro> in which case, see the above link
17:23:46 <LordAro> frosch123: we should replace @ports with that :p
17:31:23 <Tryard> This command doesn't work: set server_game_type public
17:31:53 <Tryard> this is the command to make a public dedicated server
17:32:37 <LordAro> Tryard: we can't do much with "doesn't work", what is the error?
17:33:04 <frosch123> Tryard: the page is about openttd 12.0+
17:33:10 <frosch123> just in case you are using some ancient version
17:33:24 <Tryard> 'server_game_type' is an unknown setting.
17:34:58 <Tryard> But also in the repo of jgrpp in the multiplayer doc the command is the same
17:35:16 <LordAro> need to ask JGR if you have problems then, we can't help with that
17:35:58 <LordAro> yeah, it's possible it's been updated, but not released yet
17:36:09 <frosch123> 0.44 seems to have the 12.0 multiplayer
17:36:53 <Tryard> Guide is different, I will try it
17:40:07 <TrueBrain> So JGRPP is now so mature, it has release candidates :D that is a very good sign :)
17:40:16 *** gelignite has joined #openttd
17:40:46 <Tryard> What do you think about JGRPP?
17:45:19 <LordAro> what would you like us to think of it?
17:47:33 <DorpsGek> [OpenTTD/OpenTTD] ldpl opened pull request #9666: Fix: Every 16th client gets stuck wating for server restart https://git.io/JPQSk
17:48:40 <glx> cool I can check if they updated the images
17:49:11 <LordAro> dP: i'd recommend expanding the comment a bit
17:51:19 <dP> pressed ctrl+ender accidentally
17:52:56 <LordAro> i meant the comment in the file ;)
17:53:04 <glx> ubuntu uses 20211101.1 but windows still on 20211018.0
17:53:34 <LordAro> windows docker images are pain
17:53:42 <LordAro> can't use nanoserver because msys dependency
17:53:46 <LordAro> so all the images are >4G
17:54:52 <glx> windows image should be updated soon, 20201102.4 was released yesterday
17:56:02 <glx> so I guess tomorrow nightly will build
17:56:51 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #9666: Fix: Every 16th client gets stuck wating for server restart https://git.io/JPQSk
17:57:47 <LordAro> well, except for the whitespace ;)
17:58:04 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #9666: Fix: Every 16th client never reconnects after server restart https://git.io/JPQSk
17:58:17 <frosch123> tomorrow? it started failing on a wednesday, so i assumed it would be fixed on a wednesday
17:58:56 <glx> ubuntu and macos use images released 2 days ago
17:59:12 <glx> and windows images were released today
17:59:47 <frosch123> but only windows nightly failed?
18:00:07 <glx> yes only windows is concerned by chocolatey
18:03:00 <dP> though that whole reconnect "throttling" seems kinda questionable
18:03:07 <dP> what difference will that fraction of a second make
18:04:25 <LordAro> i would imagine TrueBrain had his reasons
18:04:37 <LordAro> should've written those reasons down, but i'm sure they were good reasons
18:11:36 <TrueBrain> Let's go back in time 17 years and address that issue :p
18:13:22 <TrueBrain> Also, can't believe we wrote this network protocol 17 years ago .. lol
18:15:04 <LordAro> ah, i assumed it was new
18:15:04 <frosch123> that's also where the "+1" was lost
18:16:02 <TrueBrain> it was 17 years ago the mechanism got introduced ;)
18:16:16 <TrueBrain> The throttling was put to question, not based on what :p
18:16:56 <TrueBrain> But yeah, happy you point out I am not even to blame for this bug :p
18:20:38 *** ChanServ sets mode: +v tokai
18:22:38 <dP> that commit though suggests there is actually some problem if they're not throttled
18:22:45 <dP> but still doesn't explain what it is :(
18:25:00 <nielsm> probably related to the server accepting multiple connections at a time, perhaps a problem with slower connections, where it can affect already-connected players?
18:25:31 <TrueBrain> Most likely: tcp accept() backlog is not that big, dropping clients if they all come in on the same time
18:25:42 <TrueBrain> Just guessing here, did not read the code
18:27:31 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
18:30:49 <TrueBrain> Yeah, backlog is 1, so that throttle actually solves a problem
18:31:09 <TrueBrain> Without it, only a few clients would be able to reconnect
18:31:17 <TrueBrain> The other connections would bounce
18:31:42 <frosch123> where do you see the backlog?
18:31:52 <dP> there still is a chance they'll reconnect at the same time
18:31:54 <frosch123> is it some default? or does ottd enforce it?
18:32:02 <dP> why not just increase the backlog?
18:32:42 <TrueBrain> You ask why it is there, I give you the most probable reason ;)
18:32:42 <milek7> though depending on OS such low value is probably ignored anyway
18:33:08 <TrueBrain> Do put this in a 2004 time frame when debating these things :)
18:39:09 <milek7> is there any interest with d3d11 backend?
18:41:21 <dP> TrueBrain, pretty sure SOMAXCONN existed in 2004 :p
18:41:51 <TrueBrain> That is thinking way too easy about the problem
18:42:28 <TrueBrain> Cross OS support was not really existing back in the day ;)
18:42:57 <LordAro> * TrueBrain shakes his walking stick at the children
18:44:04 <TrueBrain> I remember I wrote a blog about crosscompiling for MacOS .. was pretty popular for several years ..
18:44:14 <TrueBrain> You normally just couldn't do that
18:44:39 <TrueBrain> Were the code was in C :p
18:44:53 <dP> even considering cross os and stuff 1 is way too specific of a value
18:46:27 <dP> also it's all nice and cozy but but we're in 2021 and backlog is still 1 :p
18:46:34 <frosch123> TrueBrain: now you tell ms people how to fix the windows farm :)
18:46:48 <TrueBrain> They said they push a new image today
18:47:00 <TrueBrain> Just the definition of "day" is vague
18:47:00 <frosch123> i know, i got the same notifications
18:47:27 <TrueBrain> But yeah, it was funny we were actually right :)
18:47:27 <frosch123> if they do it every week, i assume it is automated, and at the same time as last week
18:47:30 *** planetmaker has joined #openttd
18:47:38 *** planetmaker is now known as Guest4837
18:49:33 *** Guest4837 is now known as planetmaker
18:50:13 <TrueBrain> making all of the windows images better, one bug at the time :P
18:50:24 <glx> yesterday's nightly was not using newest ubuntu and macos images while the were already released
18:51:12 <TrueBrain> just give it some time, it will work out :)
18:51:36 <glx> so for me tomorrow nightly should be ok, but today will still fail
18:53:39 <TrueBrain> not like we want to release 12.1 today :)
18:54:18 <TrueBrain> one could however already prepare changelog, website news, etc :P
18:54:55 <TrueBrain> frosch123: also a bit insane, there are people actually interested in using TrueWiki :P
18:55:26 <TrueBrain> I should decouple OpenTTD's wiki from it soon .. now forks also try to deploy it to AWS :P
18:55:28 <frosch123> what is the current share price?
18:57:35 <frosch123> does github ceo matter? cto is usually more important
18:57:46 <TrueBrain> Nat was very focal about things when it mattered
18:58:19 <frosch123> was he at gh before ms takeover?
19:01:36 <frosch123> i did not hear anything about devspaces btw
19:02:25 <TrueBrain> euh, he became CEO at the takeover, misread you, sorry :P
19:03:12 <TrueBrain> like I said, mostly when they are this late in betas, signups go really quick
19:03:13 <TrueBrain> but I guess they have something else planned
19:03:22 <TrueBrain> I hope they announce soon what they will do with codespaces for individuals
20:11:14 <frosch123> that would be the worst option :/
20:14:34 <TrueBrain> sometimes it is like we only read a part of the conversation :P
20:19:12 <LordAro> TrueBrain: you realise that log is still freely available?
20:19:22 <TrueBrain> LordAro: yeah, not much I can do about that
20:19:44 <TrueBrain> I told him last time too not to publish that, but ... here we are
20:19:55 <TrueBrain> as we figured last time, reading is hard :)
20:20:09 <frosch123> log is only for members, isn't it?
20:20:19 <frosch123> not sure which permission is needed
20:20:35 <TrueBrain> go to the page in private mode, and you see it is for anyone
20:20:42 <LordAro> aha, i can delete the initial revision
20:20:51 <TrueBrain> really?! Interesting :D
20:21:15 <LordAro> can even do it from the mobile site
20:21:16 <TrueBrain> now it is admin-only :P
20:30:42 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9666: Fix: Every 16th client never reconnects after server restart https://git.io/JP7Y7
20:33:42 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9666: Fix: Every 16th client never reconnects after server restart https://git.io/JPQSk
20:36:25 <TrueBrain> GitHub Codespaces really is nice to work with :)
20:36:31 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #77: Fix: old NewGRF entries were not removed from NewGRF lookup table https://git.io/JP7Oi
20:38:20 <glx> part of the observed "leak" ?
20:39:50 <TrueBrain> most of the leak was fixed by using the right DB to monitor expire events
20:40:04 <TrueBrain> by his numbers, this would only leak .. 4500 * 100 bytes
20:40:06 <DorpsGek> [OpenTTD/game-coordinator] glx22 approved pull request #77: Fix: old NewGRF entries were not removed from NewGRF lookup table https://git.io/JP73k
20:40:15 <TrueBrain> so not even a MB of memory :)
20:40:38 <glx> so only a bandwidth issue :)
20:41:26 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #77: Fix: old NewGRF entries were not removed from NewGRF lookup table https://git.io/JP7Oi
20:41:45 <TrueBrain> now there is another crash that happens from time to time .. lets see what that is about ..
20:41:55 <TrueBrain> it actually kills the whole instance
20:44:27 <TrueBrain> that is on another instance
20:44:33 <TrueBrain> we run 2 TURN instances, 2 STUN instances, and 2 GC instances
20:47:49 <frosch123> i only received sentry mails about the GC instances battling over deregistering a server
20:49:02 <TrueBrain> yeah, 1G crashes the instance
20:49:04 <frosch123> oh wait, there was a different one on monday
20:49:15 <frosch123> i know how to trigger 1G :)
20:49:36 <frosch123> start two servers with the same invite code
20:50:05 <frosch123> use the race condition to set them both to "public" at the same time, so GC battle over the code, and both think they go tit
20:50:18 <frosch123> then exit both servers at the same time, e.g. via killall -9
20:50:28 <frosch123> so, then both GC race again to deleting the server
20:50:50 <TrueBrain> please file a bug about both being public, as that requires a bit more time
20:50:55 <TrueBrain> but the sentry report is a bit weird
20:51:00 <TrueBrain> as remove_server() protect against such cases
20:51:06 <TrueBrain> it starts with: if id not in list: return
20:51:16 <TrueBrain> but when it gets to actually removing the id from the list, it is no longer there :P
20:51:50 <TrueBrain> I really have to rewrite the whole GC, as I learnt a lot what is needed etc with this version :)
20:52:10 <frosch123> the gc wants to delete a server, and during that await it receives a delete from the other instance
20:52:48 <frosch123> because both instances think it's their server
20:53:04 <TrueBrain> what is mostly broken, that both the stream "delete" and the local "delete" ends up in remove_server .. the first should first validate if he is in fact owner of the server
20:53:40 <TrueBrain> all other things from the stream do that .. except for this function
20:53:59 <TrueBrain> owh well .. if you can please make an issue from your way to crash it, I might spend my weekend rewriting the GC :P
20:55:28 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain opened pull request #78: Fix: don't crash the instance of a command from the stream crashes https://git.io/JP7GB
20:55:37 <TrueBrain> let's at least do this, so the instance doesn't actually crash :)
20:56:28 <frosch123> also log the exception message?
20:56:36 <TrueBrain> log.exception does exactly that :)
20:56:55 <frosch123> ah, silly global state
20:57:09 <glx> #9667 is probably not a bug, but the effect of inflation calculation
20:57:30 <TrueBrain> "global" state .. in an exception handler you can access the exception
20:57:34 <TrueBrain> not sure you can consider that global :P
20:59:00 <DorpsGek> [OpenTTD/game-coordinator] TrueBrain merged pull request #78: Fix: instance crash when command from stream causes an exception https://git.io/JP7GB
21:01:19 <TrueBrain> right, that should fix the most important pieces :) Rest can all wait :)
21:04:01 *** tokai|noir has joined #openttd
21:04:01 *** ChanServ sets mode: +v tokai|noir
21:04:29 <DorpsGek> [OpenTTD/OpenTTD] James103 opened issue #9668: [Bug]: No nightly builds are published after October 25. https://git.io/JP7ZH
21:05:23 *** HerzogDeXtEr has joined #openttd
21:05:30 <DorpsGek> [OpenTTD/game-coordinator] frosch123 opened issue #79: Race conditons between GC instances allow registering/deregistering multiple servers with the same invite code https://git.io/JP7Zj
21:06:01 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #9668: [Bug]: No nightly builds are published after October 25. https://git.io/JP7ZH
21:06:21 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9668: [Bug]: No nightly builds are published after October 25. https://git.io/JP7ZH
21:06:53 <TrueBrain> I wonder what the odds are that you end up on 2 instances ..
21:07:25 <glx> surprising james didn't report it earlier
21:07:36 <TrueBrain> now complaining he doesn't complain sooner?
21:07:43 <frosch123> TrueBrain: the "actions" tab is only accessible to members, not for james, is it?
21:08:07 <TrueBrain> frosch123: again, try it with a private window :D :D
21:08:08 <frosch123> TrueBrain: i observed 100%
21:08:19 <TrueBrain> frosch123: that are strange odds .. as it should be a round-robin :P
21:08:24 <frosch123> i think registering one server actually blocks the instance so long that the other one is choosen
21:08:49 <TrueBrain> that shouldn't be happening
21:08:50 <TrueBrain> registration is async
21:08:52 <TrueBrain> but it is something else to look into
21:08:58 <frosch123> round-robin works for me, how many server are started per second? :p
21:09:14 <TrueBrain> hmm, it is your local DNS doing the RR
21:09:17 <frosch123> if i start them at the same time, i will have consecutive requests
21:09:18 <TrueBrain> so there you might have a point
21:09:37 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9649: Fix missing commas in crash message for savegame crash due to missing NewGRF https://git.io/JP7no
21:10:23 <TrueBrain> I like GC redeployments
21:10:25 <TrueBrain> it disconnects EVERYONE
21:10:26 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9649: Fix missing commas in crash message for savegame crash due to missing NewGRF https://git.io/JiGsz
21:10:28 <TrueBrain> but it recovers in seconds :)
21:10:30 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9648: [Bug]: Missing commas in crash message for savegame crash due to missing NewGRF https://git.io/Ji3OX
21:10:56 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:12:16 <TrueBrain> ugh, I am getting old .. I was validating the deployment, I was like: I must not forget to do A ... and ..
21:12:17 <TrueBrain> yeah .. can't remember
21:33:57 <LordAro> probably not important
21:37:50 *** Tirili has quit IRC (Quit: Leaving)
21:52:23 *** gelignite has quit IRC (Quit: Stay safe!)
21:57:08 <dP> hm, a lot of minimap rendering performance seems to be lost in boilerplate
21:57:24 <dP> did a quick test with pointers and got about 5x improvement in some cases
21:57:32 <dP> but I've no idea how to do that properly
22:04:23 <frosch123> does it still call SetPixel in the blitter for every pixel?
22:05:32 <frosch123> you could render the minimap into a "bitmap" and then blit that with one blitter call
22:06:44 <dP> that would kinda make it double rendering
22:06:52 <frosch123> so mimimap has a "int width, height; uint8* color;" or something member, which has an inline-able PutPixel to write into the *color
22:07:25 <frosch123> yes, it does more, but it does it in blocks of consecutive memory
22:07:36 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:07:59 <frosch123> which is the core to SIMD, vectorisation, cache-locality and whatever is hype :)
22:09:38 <dP> how would that make it any more consecutive? final blit sure but you still need to make initial bitmap
22:10:07 <dP> also consecutive on screen is diagonal on the tile map so you're screwed either way
22:10:18 <frosch123> the setpixel is inline-able, instead of a virtual function call
22:10:55 <frosch123> the "bitmap"->"screen" transition would be a single virtual call to the blitter
22:10:59 <frosch123> and it can operate in block
22:11:08 <frosch123> since both "bitmap" and "screen" are consecutive
22:11:55 <frosch123> but i guess you meant "is the bottleneck scanning the map" vs "is the bottleneck calling all the setpixel"
22:12:01 <frosch123> i only addressed the latter
22:13:19 <dP> well, if you completely dismiss making blitter setpixel inlineable then I guess bitmap is the next best option
22:14:51 <dP> and for what I've seen map scanning is less important that setpixel but still significant
22:14:54 <frosch123> yes, i dismiss making blitter setpixel inlineable. that would end up in yapf-style static polymorphy
22:15:46 <dP> well, it works fine for rust xD
22:16:17 <frosch123> i already forgot how the opengl blitter works, but it would likely also be happier by blitting a whole bitmap, than single pixels
22:18:53 <dP> idk, doesn't look that different to me, inlining aside
22:21:06 <frosch123> bonus: if you can blit "bitmaps" from arbitrary memory, you can also preview heightmaps and .png from bananas
22:21:24 <frosch123> (noone wants to load those images into the global spritecache)
22:22:24 <dP> also extra zoom levels for minimap would be much easier to do with bitmap
22:24:13 <dP> well, at least as long as you don't mind some blockiness xD
22:26:45 <dP> hm, actually it doesn't even have to be bitmap, some kind of inlineable iterator should do just fine
22:27:18 <dP> pass it to blitter as template parameter
22:27:46 <frosch123> you can't do virtual template functions
22:33:06 *** sla_ro|master has quit IRC ()
22:41:12 *** Samu has quit IRC (Quit: Leaving)
22:49:09 <dP> well, you just need to unfold one function into a few so there probably is some wretheched way to do that with templatess
22:49:59 <JGR> Adding a rectangle blit function to the Blitter virtual interface is easier, I've got that in my branch
22:50:50 <frosch123> everything is already done :)
22:51:16 <JGR> Not really, I've haven't tried to optimise the minimap. I don't really use it much TBH.
22:51:52 <dP> you have minimap in the main viewport :p
22:51:56 <frosch123> isn't there this viewport-zoomout-into-minimap-like?
22:52:05 <frosch123> doesn't it have the same problem?
22:52:34 <dP> it lags as hell so I guess so xD
22:52:50 <dP> main reason I didn't do it in cmclient
22:52:58 <dP> and why I'm looking at its performance atm
22:53:06 <JGR> The viewport map mode is a different implementation than the minimap. I've optimised it quite a bit compared to the original patch on the forums.
22:56:12 <JGR> Things like caching land pixels and vehicle separately, using a smaller dirty block size, not marking the viewport dirty unnecessarily, indexing bridges/tunnels ahead of time, etc
22:59:27 <dP> and even that lags quite a lot compared to vanilla rendering
22:59:57 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:00:55 <dP> about the same as minimap actually
23:01:03 <frosch123> does it lag more than vanilla zoomed out?
23:01:23 <frosch123> it does not need spritesorting, so i assumed it would be faster than that at least
23:01:48 <dP> sprite sorting should be negligible nowadays
23:02:18 <JGR> The minimap updates relatively infrequently. Viewport map mode updates in real time similarly to normal rendering, some lag is inevitable if the map is very busy.
23:02:26 <frosch123> well, also newgrf sprite resolve for all objects/industries/houses/tracks
23:02:38 <JGR> I've found it render much faster than zoomed out normal rendering anyway.
23:05:14 <dP> for me vanilla zoomed out renders 40 fps, jgrpp 0.43.1 on same level 50 fps but zomed out more drops less than 40, up to 15
23:06:51 <dP> that's moving the map, zooming lag spikes are even worse
23:07:49 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
23:21:31 <JGR> Been a while since I looked at this code... The land cache (to avoid needing to re-scan the map when it's just vehicles moving about) isn't used when the viewport is moving.
23:22:35 <JGR> So you'll probably get significantly different results for stationary and moving viewports.
23:25:20 <dP> well, ofc stationary is faster
23:25:29 <dP> but it's mostly the zooming lag that kills it for me
23:30:22 <JGR> Heh, found my first post-release regression
23:31:59 <JGR> Loaded wentbourne for a test and the ship pathfinder triggered an assert
continue to next day ⏵