Times are UTC Toggle Colours
01:03:04 *** Flygon has quit IRC 02:31:28 *** gelignite has quit IRC 02:46:45 *** Leopold___ has joined #openttd 02:48:25 *** herms has quit IRC 02:51:46 *** Leopold_ has quit IRC 02:56:44 *** Leopold___ has quit IRC 03:03:35 *** Leopold_ has joined #openttd 03:18:03 *** Wormnest has quit IRC 03:19:21 *** Leopold_ has quit IRC 03:20:35 *** Leopold has joined #openttd 03:22:00 <ajmiles> _glados_: Zero code cleanup whatsoever, but here's the WIP: https://github.com/ajmiles/OpenTTD/tree/d3d12gpu 03:44:21 *** Leopold has quit IRC 03:45:06 *** Leopold has joined #openttd 03:54:16 *** D-HUND has joined #openttd 03:57:35 *** debdog has quit IRC 04:00:08 *** gnu_jj has joined #openttd 04:03:20 *** gnu_jj_ has quit IRC 04:15:09 *** Leopold has quit IRC 04:16:27 <wallabra> yay i donated! 04:16:29 <wallabra> i think 04:16:31 <wallabra> i didnt think itd work 04:17:34 *** Leopold_ has joined #openttd 04:18:51 <wallabra> probably incurred taxes 04:30:04 *** Leopold_ has quit IRC 04:33:02 *** Leopold_ has joined #openttd 04:40:05 *** Leopold_ has quit IRC 04:43:14 *** Leopold_ has joined #openttd 05:12:02 *** keikoz has joined #openttd 05:19:13 *** Leopold_ has quit IRC 05:21:01 *** Leopold has joined #openttd 05:47:22 *** Leopold has quit IRC 05:48:24 *** Leopold has joined #openttd 06:58:02 *** Leopold__ has joined #openttd 06:58:37 *** Leopold has quit IRC 07:03:54 *** Leopold__ has quit IRC 07:10:28 *** Leopold has joined #openttd 07:23:58 *** Leopold has quit IRC 07:24:03 *** Leopold has joined #openttd 07:43:04 <ajmiles> peter1138: Much improved I hope! https://youtu.be/lAimWCkVJJc?si=YAxJsEYZH0pdpVkE 07:47:14 *** Leopold has quit IRC 07:49:55 *** Leopold_ has joined #openttd 08:06:15 <ajmiles> Hah, I didn't notice the railway track is invisible 08:07:21 <ajmiles> The only type I don't support properly yet is TRANSPARENT_REMAP when the remapped value is 0, because it looks like that involves a search through the palette for the closest colour 08:08:00 <ajmiles> Although I don't think that's why the railway track is invisible, as I'm making that case magenta right now 08:08:43 <ajmiles> Colour newspapers seem to be working 08:10:05 *** Leopold___ has joined #openttd 08:10:47 *** Leopold_ has quit IRC 08:12:45 <truebrain> The struggles of implementing a driver for our graphics 😄 don't you just love it? So many things and bits and exceptions 🙂 08:13:53 <ajmiles> It's gone much easier than I expected, I'll say that 08:14:55 <truebrain> Haha, not sure that makes it better 😛 08:15:40 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211224987621396540/image.png?ex=65ed6c2c&is=65daf72c&hm=cd2bf6a87efe801a68fa91b43ce26b881e67ceb82432630463cf41a43c0ae120& 08:15:40 <ajmiles> Is it normal to get these spammed out all the time? 08:18:02 <truebrain> I don't use MSVC, but scripts do use exceptions in some places in their normal flow 08:20:25 <truebrain> Ah, yes, it says ScriptSuspend. That is thrown every command an AI does, to suspend the AI till the next tick 08:21:06 <truebrain> If it is normal that these are logged like that, no clue. They are correctly captured and handled 😛 08:23:13 <ajmiles> I just turned off printing exception messages 😄 08:34:52 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12174: Fix d3c673e: Don't defer OnResize() after ReInit() https://github.com/OpenTTD/OpenTTD/pull/12174#pullrequestreview-1899628704 08:35:04 *** Leopold___ has quit IRC 08:36:01 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #12174: Fix d3c673e: Don't defer OnResize() after ReInit() https://github.com/OpenTTD/OpenTTD/pull/12174 08:36:10 *** Leopold has joined #openttd 08:37:41 <peter1138> Still cold, -1°C again. All the layers and watching for ice 😮 08:37:45 *** Wolf01 has joined #openttd 08:37:59 <peter1138> I should ride my trike instead but I can't keep up on that. 08:42:25 *** Flygon has joined #openttd 08:43:30 *** nielsm has joined #openttd 08:47:14 <truebrain> hmm, here it is a lot warmer 08:49:13 *** Leopold has quit IRC 08:50:16 *** Leopold has joined #openttd 09:04:10 *** Leopold has quit IRC 09:11:03 *** Leopold has joined #openttd 09:18:33 *** chucky76 has joined #openttd 09:18:33 <chucky76> https://cdn.discordapp.com/attachments/1008473233844097104/1211240802005553173/Screenshot_2024-02-25_101441.jpg?ex=65ed7ae6&is=65db05e6&hm=748ca179cbaa11794047722b8aa667e8736777d8cd854dfc322015e5bf6a8d5d& 09:18:33 <chucky76> Hi, we got some troubles with RC1. In fact it looks like the protocol of admin interface has been changed. I have take a look at commits but nothing found yet. Anybody knows about it? Where can I find the changing? 09:21:28 <Rubidium> it's primarily https://github.com/OpenTTD/OpenTTD/commit/36a0818bc597f741bb897cae21a99b4814ec348c 09:23:15 <Rubidium> you might also see different behaviour due to the fix of https://github.com/OpenTTD/OpenTTD/issues/10983 but that did not change the protocol version 09:23:21 *** Leopold has quit IRC 09:25:18 <chucky76> oh, thank you for the fast response. 09:25:20 <rau117> rubidium42viaGitHub: Hmmmmmm... What about adding a hotkey to increase/decrease interface size? Ctrl + [=] / Ctrl + [-] 09:25:20 <rau117> At least this won't make things worse, and it will also be consistent with the behavior of other applications. The same browsers for example... or Factorio. 09:27:05 *** Leopold_ has joined #openttd 09:48:26 *** gelignite has joined #openttd 09:56:41 *** herms has joined #openttd 10:02:49 <DorpsGek> [OpenTTD/website] michicc commented on pull request #307: Add: Blog post about timekeeping in OpenTTD 14 https://github.com/OpenTTD/website/pull/307#pullrequestreview-1899643378 10:04:29 <DorpsGek> [OpenTTD/website] michicc commented on pull request #307: Add: Blog post about timekeeping in OpenTTD 14 https://github.com/OpenTTD/website/pull/307#issuecomment-1962879943 10:09:27 <xarick> hi 10:11:31 *** herms has quit IRC 10:13:13 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep commented on pull request #10691: Change: Add Depots and DepotIDs for airports with hangars. https://github.com/OpenTTD/OpenTTD/pull/10691#issuecomment-1962882428 10:22:23 *** Leopold_ has quit IRC 10:22:54 *** Leopold has joined #openttd 10:31:58 *** Leopold has quit IRC 10:32:58 *** Leopold has joined #openttd 10:36:13 <DorpsGek> [OpenTTD/team] Bulest opened issue #523: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/523 10:38:14 <andythenorth> so what's the maximum ID for articulated parts? Can't find it in the grf wiki 10:38:25 <andythenorth> 16383? 10:38:35 *** Leopold has quit IRC 10:39:42 *** Leopold has joined #openttd 10:47:11 *** Leopold has quit IRC 10:47:56 <michi_cc[d]> From the callback 16 page: "Bit 0 to 13 define the ID of the vehicle to add". 2 ^ 14 = 16384 10:48:14 *** Leopold has joined #openttd 10:49:11 <xarick> lala 11:09:41 <andythenorth> thanks 11:13:01 <xarick> I wanna do something like FindClosestPreciseShipDepot vs the other methods 11:13:29 <xarick> to see how much it diverges from the old yapf code 11:13:39 <xarick> just for statistics 11:18:27 <xarick> oh, uh... old yapf had no closest ship depot 11:18:32 <xarick> I forgot 11:20:43 *** ahyangyi has quit IRC 11:21:22 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211271718736232498/image.png?ex=65ed97b2&is=65db22b2&hm=2a5f8322c3e6c1c35cd5dc97a3f163f14d72a6b92237a971b63cd0071849e8cc& 11:21:22 <xarick> meanwhile, I'm testing 10000 instances of FindClosestDepot to see how much divergence there is between Kuhnovic's method and Xarick's method with unrestricted distance 11:22:01 <xarick> ~89% of the time we found the same depot, the other ~10% we didn't 11:23:55 <xarick> but I need a method to find the most accurate version of this 11:24:01 <xarick> to compare against 11:34:07 *** gelignite has quit IRC 11:40:59 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12165: Codechange: Use bitmap for free unit ID generation. https://github.com/OpenTTD/OpenTTD/pull/12165#pullrequestreview-1899659102 11:41:56 *** Leopold__ has joined #openttd 11:42:21 *** Leopold has quit IRC 11:43:17 <Eddi|zuHause> and what do we learn from that statistic? sometimes there are equal pathfinding solutions, and only unrelated implementation details determine which one is chosen 11:44:42 <Eddi|zuHause> (ignoring the obvious "one algorithm is incorrect" result) 11:45:48 <peter1138> xarick: Nice, useful stat to measure 🙂 11:45:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #12169: Codechange: Use functions to access colour gradients and replace magic numbers. https://github.com/OpenTTD/OpenTTD/pull/12169#pullrequestreview-1899659905 11:46:23 <peter1138> Also shows where unit-testing can be useful. 11:55:06 <xarick> glad you like it 11:55:43 <xarick> there is no old yapf method for closest ship depot, but there was my old version of it before Water Regions were a thing 11:55:52 <xarick> can I use it? 12:11:14 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211284268530147428/image.png?ex=65eda362&is=65db2e62&hm=0cc62b32d8106588948bbd6fcf6418fd43f7c9d62ce0f6315260631ac12a9be8& 12:11:14 <xarick> FindPreciseDepot code :p 12:13:24 <xarick> waiting now for 10000 FindClosestDepot calls 12:13:31 <DorpsGek> [OpenTTD/OpenTTD] dkle87 opened issue #12175: [Crash]: https://github.com/OpenTTD/OpenTTD/issues/12175 12:15:49 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211285419740635147/image.png?ex=65eda474&is=65db2f74&hm=3578d72b696b4b98bc359a42ea9325762baf0104e04af11e2a5532bbf9ffbf79& 12:15:49 <xarick> yay, I'm 96% accurate 12:17:20 <xarick> it would be more accurate if I add back the rest 12:17:25 <xarick> that I removed 12:17:40 <xarick> so tempted to add it back ... 12:36:17 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #12165: Codechange: Use bitmap for free unit ID generation. https://github.com/OpenTTD/OpenTTD/pull/12165 12:37:01 <peter1138> Ah, forgot to change the commit message :/ 12:38:10 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #12169: Codechange: Use functions to access colour gradients and replace magic numbers. https://github.com/OpenTTD/OpenTTD/pull/12169 12:41:13 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12144: Codechange: Use FindVehiclesWithOrder when removing a road stop. https://github.com/OpenTTD/OpenTTD/pull/12144#issuecomment-1962926004 12:47:33 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12131: Fix: Scale graph gridlines and axes with GUI scale https://github.com/OpenTTD/OpenTTD/pull/12131#pullrequestreview-1899671126 12:48:05 *** Leopold__ has quit IRC 12:50:20 *** Leopold_ has joined #openttd 13:06:57 *** Leopold_ has quit IRC 13:07:27 <ajmiles> What does the threading model for OpenTTD look like? I've seen mentions around the codebase of needing to be careful about calling certain things on certain threads, so it sounds like there's more than one at least! 13:08:33 *** Leopold has joined #openttd 13:09:56 <Eddi|zuHause> most of the game logic must run in a single thread, for determinism reasons. things that run in a separate thread include: gui updates, savegame compression, cargodist, AIs 13:12:09 <michi_cc[d]> Some of the drawing, too. 13:20:58 <Eddi|zuHause> well, you could try to untangle the game logic data dependencies to try to split it into several threads, but that is a garganutan task 13:27:29 <truebrain> ajmiles: mainly for what you are doing: there is a drawing thread and a game thread. They cannot be active both at the same time. The drawing thread should never change the game state. The game thread is also doing "drawing" related tasks, like sorting of sprites, preparing the viewport, etc. So the naming is somewhat misleading. 13:28:52 <ajmiles> It looks like the work that's taking real time (issuing 1000s of graphics API calls) in the Video Driver is on the Main Thread 13:29:05 <truebrain> on the drawing thread, yes 13:29:11 <ajmiles> I have a task that could pretty easily be multithreaded (recording of those commands) 13:29:11 <truebrain> whether that is the main thread or not, strongly depends on OS and driver 13:29:33 <truebrain> most of the video driver is executed in the drawing thread 13:29:40 <truebrain> (but not all 😛 ) 13:30:38 <truebrain> you can in theory spawn threads from the drawing thread to use more cores; just make sure they are joined before the drawing thread is released 🙂 13:31:05 <truebrain> when the game thread starts, you have no longer any guarantee of any access to the game state, including palette information etc 13:31:39 <truebrain> (which means you would need to copy all the information, which most of the time negates any advantages of creating extra threads for drawing) 13:32:09 <ajmiles> I think I've probably gathered everything I need by the time Paint comes around 13:34:24 <truebrain> a few years ago I started this splitsing up into different threads, but you find all kind of things that secretly exchanges information between game and drawing 13:34:39 <truebrain> so it is a slow progress, but an ongoing one 🙂 13:35:53 <truebrain> (as example, sprite sorting should be possible in the drawing thread, but there are a few annoying parts that still expect it to be done in the game thread 😛 ) 13:36:54 <peter1138> Z-buffer could be good. 13:38:49 <truebrain> the first problem is splitting the code that does the sorting; that allows for other ways to do the sorting 🙂 13:39:04 <truebrain> JGRPP already makes this part multi-threaded; just haven't checked how 🙂 13:40:09 <truebrain> but you find out things like a global to track the current viewport that is being drawn, which is accessed in more than one place .. those lovely things. That code is not C++ yet, to say the least 😄 13:43:02 <DorpsGek> [OpenTTD/OpenTTD] rei-artist opened issue #12176: [Bug]: Ships are circling in one place. https://github.com/OpenTTD/OpenTTD/issues/12176 13:50:01 <merni> I am not sure that dock is even accessible 13:51:46 <merni> Hm, no, that's not the issue 13:52:18 <merni> occasionally more ships seem to join the dance too 13:52:45 *** Leopold___ has joined #openttd 13:52:53 <merni> kuhnovic: , is it intended that ships go in circles without declaring themselves lost? 13:52:56 *** Leopold has quit IRC 13:53:14 <truebrain> are they actually lost? 😄 13:55:02 <merni> Well, they seem to have a perfectly good path to their destination, and yet go in circles in one spot 13:55:04 <merni> So it seems to be 13:55:18 <truebrain> I would argue, that makes them not lost, just queued 🙂 13:55:41 <truebrain> doesn't make it not a bug, mind you 13:55:42 <merni> They are not queueing outside the dock though 13:56:10 <truebrain> maybe they are queued on the edge of a region or something? 13:56:41 <truebrain> that the local pathfinder says: nah, dock is not available 13:56:49 <truebrain> so they stick around on the edge? I dunno, just guessing 13:56:58 <truebrain> either way, it would explain why they are not lost 🙂 Just circling 😉 14:00:00 <andythenorth> oof, ran out of varact2 IDs 😐 14:00:02 <andythenorth> oopsie 14:00:07 <merni> Anyway it looks pretty funny 14:02:26 <merni> does that ship PF debug drawing still exist? If so how do I trigger it? 14:07:26 <xarick> wow 14:08:30 <ajmiles> Fixed a bug in the GPU blitter that means it now runs on AMD GPUs and not just NVIDIA ones. And even better, the AMD GPU I'm running it on is the most potato integrated AMD GPU money can buy. It has only one Workgroup Processor and the game is still rendering at ~30Hz at 4K before I've done anything to optimise it 14:08:30 <xarick> I'll check it 14:09:07 <truebrain> 30Hz? That is not a lot 😄 14:10:50 <ajmiles> This integrated GPU is 500 gigaflops peak. So about on par with a discrete desktop GPU from ~2008 14:11:03 <truebrain> I think the 8bpp handles 60Hz on that with ease 😛 14:11:32 *** Ox7C5 has joined #openttd 14:11:46 <Eddi|zuHause> "but this game is from 1994" :p 14:11:46 <truebrain> I can't believe there was a time we thought 30Hz was good .. I now have 165Hz screens, and pretty happy with that 😛 So funny how that goes 😄 14:12:19 <ajmiles> There's plenty to do with it, I'm not concerned. There's a barrier between every Dispatch now which means the machine is probably at least 10x underutilised 14:13:22 <Rubidium> just load one of Xarick's test saves and even with 165 Hz it will feel like a few Hz at most 14:13:36 <ajmiles> Late-game OpenTTD is not exactly a frame-drop free experience when you decide to *crazy* things like move the camera or zoom out 14:13:39 <truebrain> you mistake fps with ups 😛 14:13:55 <truebrain> ajmiles: just never zoom out! NEVAH 😛 14:14:02 <ajmiles> What about scrolling?! 14:14:06 <ajmiles> Can I do that? 14:14:08 <truebrain> nah 14:15:29 <xarick> gonna try revert some changes 14:15:37 <ajmiles> Oh wait, I had the debug-layer and GPU-based validation enabled. That would not have helped. 14:15:50 <kuhnovic> merni: Not behind a computer right now, but can you check if it's the same as #8022? Are the ships trying to find a depot to service? 14:16:02 <xarick> no, it's different 14:16:09 <xarick> they are heading to a dock 14:16:16 <kuhnovic> The debug drawing was removed, I do have it in a patch somewhere 14:16:31 <xarick> they're not flagged as "lost" 14:16:44 <kuhnovic> Sounds bad 14:17:08 <kuhnovic> I'll try to find some time to look at it today 14:17:10 <xarick> the path is valid, even though it's doing circles 14:17:37 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211316072192417852/image.png?ex=65edc100&is=65db4c00&hm=02ea5d2ac082a185fb2ffd1fb2e92e0040c27e675d9d605311f0272dc7a99abc& 14:17:37 <ajmiles> Right, actually turn off all the debug stuff and it's ~75Hz on my 75Hz display. 14:17:47 <truebrain> see, much better 😛 14:20:13 <ajmiles> And 3ms is being spent by DXGI doing a copy from my AMD integrate GPU to the discrete NVIDIA GPU to which the monitor is attached. 14:20:17 <ajmiles> So it's all fine! 14:22:59 <Eddi|zuHause> a long time ago i made it a habit to always pause before zooming out 14:26:18 <ajmiles> The main menu has railway, but my game does not. I wonder why 14:27:04 <ajmiles> I wonder if this is because these sprites have RGB 14:27:28 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211318552729096232/image.png?ex=65edc350&is=65db4e50&hm=f126cc2d5538632cba3735dd785bec4c11ab81192eaa72fd2275407fbce07a2c& 14:27:28 <ajmiles> Missing on the UI too 14:31:43 *** janciothor has joined #openttd 14:31:43 <janciothor> you produce these locomotives like cookies in a bakery, 🥞 🧇 😁 it's just a pity they don't have the same size scale as GETS. 😔 14:35:06 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211320473984434217/image.png?ex=65edc51a&is=65db501a&hm=a0e1bc2f081444aa31a5b688ada3bd4ee7d905797b5b317e3d69ad58ee8797dc& 14:35:06 <xarick> right around the edges... 14:35:39 *** D-HUND is now known as debdog 14:36:26 <xarick> when it's on the bottom side, best path is going back to the right side, when it gets there, best path is going back to the down side 14:41:03 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12177: Codefix #12162, 3105d0b: Textbuf::Assign read beyond std::string_view https://github.com/OpenTTD/OpenTTD/pull/12177 14:44:41 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #8480: Feature: Extended depots https://github.com/OpenTTD/OpenTTD/pull/8480 14:44:44 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #10691: Change: Add Depots and DepotIDs for airports with hangars. https://github.com/OpenTTD/OpenTTD/pull/10691 14:44:47 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #9577: Feature: Multi-tile depots https://github.com/OpenTTD/OpenTTD/pull/9577 14:49:04 <ajmiles> It turns out if you take a GPU-accelerated blitter and then run it on the CPU using WARP - performance is not great. :tapstemple: 14:50:43 <merni> xarick: ooh 14:50:56 <merni> that probably is it 14:51:05 <merni> the two parallel canals confuse it? 14:52:30 <truebrain> ajmiles: shocker! 14:53:26 <xarick> still investigating, I notice both paths have the same number of regions towards destination: five 14:53:44 <xarick> could this be a matter of costs? 14:54:15 <merni> I have only a very high-level idea of how the ship PF works :p 15:01:14 <merni> Hmm, cannot reproduce #12175 15:01:42 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211327167796092979/image.png?ex=65edcb56&is=65db5656&hm=c94bbd173425188169e77c845f5c2bcad3211cfe8c33f120939237649831cfe9& 15:01:42 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211327168127176724/image.png?ex=65edcb56&is=65db5656&hm=f9079c6628fe44fc55f4e9a6371c317d1e7fc34415d51bb4d5d5420aa249d7eb& 15:01:47 <xarick> path 1 15:02:39 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211327405537624074/image.png?ex=65edcb8e&is=65db568e&hm=50b662207ffdb6f7d9d260bf7fa480c4c2136fb89b1406d7145fceb6d384db8f& 15:02:39 <xarick> path 2 15:03:52 <xarick> well, looks like the problem is not here... 15:04:08 <xarick> path 2 is shorter 15:05:19 <xarick> seems to me it's the low level pathfinder that has a different opinion on what's the best path 15:05:28 <merni> Hm I was thinking "wtf happened to the option to shift+click to choose which depot to send to"... that's a JGRPP feature 15:07:10 <xarick> let me check what the low lvl pf says 15:07:56 <truebrain> merni: lol ... DOH 🙂 15:15:15 <xarick> yep 15:18:23 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211331366948704308/image.png?ex=65edcf3f&is=65db5a3f&hm=e605acdb29f02914eb7f4d1cf50b72e5a4d0635b077abb232b800d27644f1d9e& 15:18:23 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211331367393165352/image.png?ex=65edcf3f&is=65db5a3f&hm=58e620c8867d321ceb0641a429096c80cf238d3645a5b57cd86454bbe4a03c31& 15:18:23 <xarick> high lvl pf and low lvl pf are in disagreement 15:19:41 <xarick> RIP Water Regions 15:19:53 <xarick> I wonder how Kunhovic gonna deal with this 15:22:40 <xarick> is_intermediate_destination = true, yeah, this seems to be the culprit 15:23:49 <xarick> region 53, 151 is the intermediate region 15:24:00 <merni> xarick: ... 15:25:08 <xarick> the center tile of 53, 151 is grass 15:25:43 <xarick> i don't know, seems... weird to pf to a non water tile 15:25:59 <xarick> but it worked 99.99% of the time so far 15:26:07 <xarick> so I dunno 15:26:35 *** Leopold___ has quit IRC 15:27:42 *** Leopold_ has joined #openttd 15:29:30 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #8480: Feature: Extended depots https://github.com/OpenTTD/OpenTTD/pull/8480#pullrequestreview-1899701011 15:32:02 <xarick> 54, 151 is the other intermediate region when the ship is on the other region, heh... 15:33:05 <xarick> the center tile of that region is probably a road or a house 15:33:38 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan updated pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163 15:33:46 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan updated pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163 15:34:35 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan updated pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163 15:37:24 *** Leopold__ has joined #openttd 15:38:17 *** Leopold_ has quit IRC 15:39:46 <xarick> time for some paint skills 15:39:48 <DorpsGek> [OpenTTD/OpenTTD] github-advanced-security[bot] commented on pull request #9577: Feature: Multi-tile depots https://github.com/OpenTTD/OpenTTD/pull/9577#pullrequestreview-1899702750 15:43:52 *** Leopold__ has quit IRC 15:47:35 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan updated pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163 15:47:44 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#pullrequestreview-1899704097 15:47:47 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#pullrequestreview-1899704108 15:48:57 <DorpsGek> [OpenTTD/OpenTTD] Fefer-Ivan commented on pull request #12163: Add: Basic autocompletion on tab for console commands https://github.com/OpenTTD/OpenTTD/pull/12163#issuecomment-1962980615 15:49:02 *** Leopold_ has joined #openttd 15:51:32 *** Leopold_ has quit IRC 15:54:28 *** Leopold_ has joined #openttd 15:55:35 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211340729419300964/Captura_de_ecra_2024-02-25_145513.png?ex=65edd7f7&is=65db62f7&hm=3bb2ee203fd08bad02650e8413a84d031391206e7239f732c8669af341177b08& 15:55:35 <xarick> what do you think of my painting skills? 15:56:02 <xarick> follow the numbers 15:56:48 <andythenorth> hi hi, asking for a friend 15:56:54 <andythenorth> if an nml file has 934146 lines 15:57:07 <andythenorth> and nmlc hits the concurrent varact2 ID limit 15:57:23 <andythenorth> how do I help my friend find out the cause? 15:58:09 <andythenorth> we know which vehicle triggers the error, but it's not particularly a special newly added switch chain, and it worked in a previous version 15:58:36 <andythenorth> which suggests a cause arising from other recent changes 15:58:50 *** Wormnest has joined #openttd 16:03:08 <xarick> xarick: When the ship enters the region at 54, 153, follow the yellow numbers. The intermediate region given by the high level pf is number 5, it tells the the low level pf to pathfind to the center tile of region 54, 151, forcing the ship to turn back to 55, 153, but... 16:03:09 <xarick> ... when the ship enters the region at 55, 153, follow the cyan numbers. The intermediate region given by the high level pf is number 5, it tells the the low level pf to pathfind to the center tile of region 53, 151, forcing the ship to turn back to 54, 153, repeat... 16:04:31 <xarick> perhaps a solution would be.... 16:04:43 <xarick> restrict path right off the bat? 16:05:16 <xarick> considering the high level pathfinder gives the exact path, this would solve the problem 16:05:55 <kuhnovic> So it essentially keeps pinging back and forth? 16:07:41 <xarick> it's a mix of unfortunate intermediate region dictating the low lvl pf where to go 16:08:27 <xarick> it doesn't fail on the first attempt, so there's no path restricted to a corridor 16:08:30 <kuhnovic> I was afraid this could happen. Restricting the "region corridor" is indeed a way to prevent this. But it does lead to less optimal paths. That's the whole reason why I chose to restrict only as a last resort. 16:10:25 <andythenorth> I think I've just learnt about O(n) or something, the hard way 16:11:12 <merni> andythenorth: I would tell the friend the cause is having an NML file with a million lines 16:11:17 <merni> Crazy 16:11:22 <andythenorth> in 2 lines, I've managed to make a python function take 35s that previously took about 1s 16:12:11 <kuhnovic> xarick: no time to dig into it now, but i'll try to have a look tonight. Thanks for looking into this. 16:15:08 *** Leopold_ has quit IRC 16:15:21 <xarick> np 16:16:33 *** Leopold_ has joined #openttd 16:18:38 <truebrain> kuhnovic: Doesn't the ship PF cache the route for a few tiles? That mostly resolves these problems fine 🙂 16:18:51 <truebrain> Once it is over the threshold, it won't go back 16:22:08 <andythenorth> hmm this is bizarre, I have a python loop that gets much faster if I time it 😛 16:22:13 <andythenorth> do we suspect PEBKAC? 16:22:34 <truebrain> Stop writing silly code? 😛 16:23:04 <truebrain> Or don't load the "only fast if you measure me" module 😛 16:23:29 <kuhnovic> Only until it reaches a new region 16:28:54 <Eddi|zuHause> i thought that module is an industry standard? 16:29:27 <andythenorth> whatever I did has stopped 16:31:01 <andythenorth> but the varact 2 IDs still run out 😛 16:31:09 <andythenorth> now I have to read 1m lines 😛 16:31:35 <Eddi|zuHause> that can usually be solved by clever reordering 16:31:55 <andythenorth> yeah that's what I tried 16:32:05 <Eddi|zuHause> unless you have crazy interdependencies 16:32:05 <andythenorth> think I've found the cause though, a switch with 220 items 16:32:38 <Eddi|zuHause> you might want to split that, then :) 16:34:38 <andythenorth> I do 😛 16:36:07 <andythenorth> hmm this is a case for per-vehicle storage 16:36:26 <andythenorth> I have to work out a set of passenger coaches by checking all their IDs in a switch 16:36:38 <andythenorth> would be better to check a register 16:38:27 <xarick> just tested restricted corridor, it fixed the issue 16:38:35 <xarick> so unfortunate 16:39:02 <xarick> on the other hand, makes pf'ing even faster 16:40:42 <andythenorth> hmm 16:43:29 <Eddi|zuHause> andythenorth: and the existing bit thingie doesn't work for that? 16:43:54 <andythenorth> no, because it's almost unusable 16:44:01 <andythenorth> we have covered this before 🙂 16:44:05 *** klote has joined #openttd 16:44:09 <klote> hi 16:44:21 <klote> Anyone here? 16:44:30 <Eddi|zuHause> you can check "are all of the vehicles passenger cars", or "are any of the vehicles passenger cars" with 1 bit each 16:44:46 <andythenorth> can't check the preceeding vehicle with it 16:44:52 <andythenorth> it's the most lolz grf feature I think 16:45:17 *** klote[d] has joined #openttd 16:45:17 <klote[d]> oh lol 16:45:19 <andythenorth> it's so almost useful, but was probably added for one specific TTDP case, I imagine in DB Set 16:45:21 *** klote has quit IRC 16:45:28 <andythenorth> probably vital that it works like it does 16:45:45 <klote[d]> Hello i need some help understanding how to edit NewGRF. 16:46:01 <Eddi|zuHause> i don't think dbset uses it, i vaguely remember discussing it with george, but it already existed then 16:46:21 <klote[d]> Im trying to decompile a newgrf but i get error offset to large in sprite 0! 16:46:29 *** Leopold_ has quit IRC 16:46:47 <klote[d]> Im a total noob in this dont really know where to start. and ChatGPT isnt really helping me either 😛 16:46:48 <Eddi|zuHause> which newgrf, and which version of grfcodec? 16:47:21 <klote[d]> the grfcodec that is from 2016 availible from the website 16:47:48 <klote[d]> 45555453-European_Train_Set-2022.08.28 16:47:59 <Eddi|zuHause> i'd be more worried if you said a version from 2008 16:48:16 <klote[d]> trying to edit this one i want to change the train prices and year it brings the trains 16:48:27 <klote[d]> maybe add different trains from another newgrf 16:48:48 *** Leopold has joined #openttd 16:49:36 <andythenorth> GPT only makes lies about grf 16:49:40 <klote[d]> 😛 16:49:44 <andythenorth> I like GPT, but it is bad at grf 16:50:05 <klote[d]> any chance some one could explain the basics to me 16:50:05 <ajmiles> truebrain: peter1138 OK, getting awesome look numbers from the profiler for this zoomed out stress test. I loaded the same save game, zoomed out to the same place, brought up the frame rate dialog and then waggled the camera and watched the frame rate. I compared the Nightly Steam build and compared it to my local build. Is there anything about these numbers that could be misleading me or does 16:50:05 <ajmiles> this seem pretty great? 16:50:05 <ajmiles> CPU-Blitter + OpenGL 16:50:05 <ajmiles> https://youtu.be/x0wgJo56X6s?si=LoPQjdYyaBYb_Jah 16:50:05 <ajmiles> GPU-Blitter + D3D12 16:50:06 <ajmiles> https://youtu.be/UxwJrVFVbfw?si=wWpymtvsL2h94Gy1 16:50:19 <Eddi|zuHause> GPT in general only makes lies, that sometimes happen to be true. 16:50:22 <klote[d]> maybe do a voice call 16:51:01 <klote[d]> I really want that train set to be compatible with FIRS industry 16:51:08 <klote[d]> i have my own server 16:53:00 <Eddi|zuHause> there recently was a discussion about technically valid grfs that grfcodec fails to handle, can you check the recent PRs, whether that applies to your grf? 16:53:22 <klote[d]> PRs? 16:53:51 <Eddi|zuHause> on the github repo, "PRs" are suggested changes 16:54:40 <klote[d]> So the GRFCodec that is on the OpenTTD website should be able to handle it? 16:55:59 <Eddi|zuHause> like you said, the website offers a version from 2016, that is a pretty long time ago. while grfcodec doesn't change often, it does change. 16:57:01 <klote[d]> https://github.com/OpenTTD/grfcodec 16:57:05 <klote[d]> that ones newer i think 16:57:22 <klote[d]> But it doesnt contain .exe and i have no clue how to complile that 17:00:52 <klote[d]> Hmm ok so i need visual basic to compile that and use the command make... 17:03:24 <klote[d]> chatgpt is helping somewhat lol 17:07:22 <Eddi|zuHause> don't trust GPT 17:09:41 <merni> No 17:09:49 <andythenorth> hmm I think Horse has simply consumed all varact 2 now 😛 17:09:57 <andythenorth> grf complete? 17:10:04 <merni> compiled versions of GRFCodec are at https://www.openttd.org/downloads/grfcodec-releases/latest 17:10:22 <merni> klote[d]: ^ 17:10:31 <peter1138> Yes, but it's ancient 🙂 17:10:32 <andythenorth> I think I hit local minima on the tradeoff with procedures using varact 2 vs. compile time 17:10:50 <merni> Euh... I guess we don't have CI for grfcodec? 17:10:52 <klote[d]> merni: Yeah but thats 2016 one that gives me a decompile error 17:11:05 <merni> Yeah ignore me lol 17:11:26 <peter1138> We do but it doesn't to nightlies, and we just haven't done a release in years. 17:11:35 <merni> Maybe someone should :P 17:11:39 <klote[d]> Would be nice if they could update it 17:12:05 <klote[d]> im going to "try" to compile it... 17:12:19 <klote[d]> with the help of a payed gpt 4.0 advice 😛 17:12:57 <merni> I would not advise that. Hallucination is no subsitute for truth :P 17:13:00 <michi_cc[d]> Are you familiar with NFO? If not, something like https://github.com/UnicycleBloke/yagl will help you a lot more, as the NFO that comes out of grfcodec is still complete gibberish. 17:13:20 <klote[d]> michi_cc[d]: No im a total noob 17:14:32 <klote[d]> Wouldnt this mean id have to rebuild the NewGRF? 17:14:39 <klote[d]> or can i edit existing? 17:15:08 <klote[d]> To decode a GRF file into YAGL, run the following command: 17:15:10 <klote[d]> ah 17:15:11 <klote[d]> nvm 17:15:31 <klote[d]> wait i cant? 17:15:55 <michi_cc[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1211360944727265280/image.png?ex=65edeacb&is=65db75cb&hm=9bac1317e70a1512676ad9dcd6a7ee1eb95bad86cded3b432a916f8e3ecf4b25& 17:15:55 <michi_cc[d]> Don't bother with grfcodec then. A decompiled NewGRF will look like this: 17:16:14 <klote[d]> oh lol 17:16:31 *** brickblock19280 has joined #openttd 17:16:31 <brickblock19280> Might as well write raw grf 17:16:36 <klote[d]> rip 17:16:46 <klote[d]> i want to use those sprites and train sets T-T 17:17:10 <michi_cc[d]> YAGL is supposed to allow decompilation/compilation is a somewhat human readable format, but I haven't personally used it, so no idea how the current state of it really is. 17:17:16 <brickblock19280> Decompiling will give you the sprites which you could code again in nml 17:17:42 <brickblock19280> I think yagl is the best currently 17:17:57 <klote[d]> Yeah seems like it also specifically meant for FIRS 17:18:13 <michi_cc[d]> Well, you are probably in luck, as <https://github.com/CoconutKR/EuropeanTrainSet> has the proper sources. 17:18:35 <michi_cc[d]> Always better to directly use that instead of trying some decompilation. 17:19:49 <klote[d]> it chinese 17:21:34 <frosch123> no, it's korean 17:21:37 <wensimehrp> 那个是韩文…… 17:22:13 <klote[d]> Yeah google translate 17:23:51 <klote[d]> That one says i need to have python 3 and NML 17:23:58 <klote[d]> to build NewGRF 17:24:24 <klote[d]> can i just use YAGL instead? 17:25:36 <locosage> it's likely much easier to understand korean than any sort of decompiled grf xD 17:33:21 <Eddi|zuHause> they say korean is the easiest writing system 17:33:56 *** gelignite has joined #openttd 17:34:10 *** Leopold has quit IRC 17:35:18 <klote[d]> oh wow im looking at what truebrain is making 17:35:29 <klote[d]> browserbased NewGRF creation tool 17:35:52 *** Leopold_ has joined #openttd 17:37:01 <klote[d]> https://cdn.discordapp.com/attachments/1008473233844097104/1211366254380847344/image.png?ex=65edefbd&is=65db7abd&hm=9b01cb734e9f57d34a25268074586be00cad73b1c432a07500711fd1f7cd4aaa& 17:37:01 <klote[d]> loading forever 17:48:08 <klote[d]> this is going way over my head lol 17:48:25 *** Leopold_ has quit IRC 17:48:30 <klote[d]> Think im just going to stick with the availible ones 17:48:45 <klote[d]> Unless some one is willing to make something for me. 17:50:08 *** Leopold_ has joined #openttd 17:53:29 *** Leopold_ has quit IRC 17:56:57 <peter1138> LordAro, I KNEW it 17:59:01 <LordAro> peter1138: legs are pain 17:59:11 <peter1138> Well done tho 18:12:49 <andythenorth> wonder if we could analyse the varact 2 useage somehow 18:12:53 <andythenorth> not sure 18:13:21 <andythenorth> Horse is now so complicated, I can't manually analyse what might be consuming the IDs 😛 18:21:45 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211377510215057529/image.png?ex=65edfa38&is=65db8538&hm=743c0cf182fc578a09a7c3ed94baada13fa3abd9fda6e2cd4dcf844faa548f77& 18:21:45 <xarick> last results 18:21:52 <xarick> 10000 samples 18:22:40 <xarick> all that added complexity I had only yields 6 more accurate results out of 10k 😦 18:22:49 <xarick> I'm disappointed 18:29:14 <xarick> ohh wait 18:29:17 <xarick> found a mistake 18:35:32 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/7b1e3cfeb58ceed9babc33922480372c55d06fa4 18:35:33 <DorpsGek> - Update: Translations from eints (by translators) 18:37:31 <xarick> nevermind, it's correct 18:38:12 *** Leopold_ has joined #openttd 18:43:23 *** Ox7C5 has quit IRC 18:52:07 <_glx_> andythenorth: 220 different choices ? 18:53:53 <_glx_> split it, that way each subset can reuse IDs of other subsets 18:55:19 <_glx_> 10 switches of 22 choices needs less IDs than 1 switch of 220 choices 18:56:10 <_glx_> well 10+1 because you need a prefilter 18:59:07 <kuhnovic> xarick: And this is why I prefer K.I.S.S. solutions 🙂 19:00:08 <_glx_> yup simple is easier to follow too 19:00:17 <_glx_> and debug 19:02:35 <kuhnovic> "Make it easy for the next guy to fix... especially since the next guy is probably you" 19:11:50 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #12151: Fix #12086: Crash if NWidgetMatrix holds content taller than 64K pixels. https://github.com/OpenTTD/OpenTTD/pull/12151#issuecomment-1963032917 19:13:03 *** Leopold_ has quit IRC 19:13:51 <kuhnovic> xarick: I can confirm that restricting the PF search fixes #12176. I'm going to see if I can come up with a solution that's a little nicer than "just restrict it", as that will lead to noticeably worse paths in many cases. If I can't come up with anything then always restricting it will be the fix for now, and then a better solution can be found later. 19:15:50 <andythenorth> _glx_: yup I should, but it's not seeming to be the cause of the current ID expiry 19:15:54 *** Leopold_ has joined #openttd 19:16:11 <andythenorth> I reduced the number of items in it significantly, to no effect 19:17:09 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12151: Fix #12086: Crash if NWidgetMatrix holds content taller than 64K pixels. https://github.com/OpenTTD/OpenTTD/pull/12151#issuecomment-1963034299 19:19:34 <truebrain> ajmiles: Until you implemented everything, comparing is not all that useful ofc 🙂 only when there is feature parity it is worth talking about actual numbers 🙂 anyway, weren't you doing Vulkan? A D3D driver has already been done a few years ago, you can find that somewhere as a closed PR. Just as a "so you know" 🙂 19:19:56 <andythenorth> ok I've commented some switches out until Horse compiles 😛 19:19:59 <andythenorth> `nmlc info: Concurrent spritegroups: 255/256 ("generated/iron-horse.nml", line 352010)` 19:20:13 <peter1138> There you go, the problem is on line 352,010. 19:20:26 <peter1138> 😉 19:21:04 <peter1138> I guess action 2 ID 255 is valid? 😦 19:21:14 <DorpsGek> [OpenTTD/team] frosch123 commented on issue #523: [fr_FR] Translator access request https://github.com/OpenTTD/team/issues/523 19:22:27 <andythenorth> 255 is fine, this compiles 19:22:40 <andythenorth> but only if I comment out a bunch of stuff 🙂 19:22:50 <peter1138> No, I mean in terms of increasing act 2 IDs. 19:23:30 <andythenorth> not some kind of reserved value for extended byte or something? 19:23:39 <peter1138> Quite. 19:24:17 <frosch123> just move some switches before line 352010 further down, or some switches after line 352010 further up 19:24:41 <truebrain> or stop making 1 gigantic GRF, and split it up! 😛 19:25:09 <frosch123> that won't help, he will just get 4 grfs which do not compile 19:25:30 <truebrain> repeat repeat repeat 😛 19:25:34 <truebrain> 256 GRFs that won't compile! 19:26:15 <frosch123> if anyone would automate grf generation and grfid assignment, and actually consume all 4B grfids on bananas, it would be andy 19:27:51 <truebrain> klote[d]: sadly don't really have the time to work on TrueGRF, so it is in a bit of a limbo state. It should load however. It is just very limited in capability .. time as a resource, it is such a problem 🙂 19:28:19 <peter1138> 1 NewGRF file per variant. 19:29:38 <DorpsGek> [OpenTTD/OpenTTD] J0anJosep updated pull request #9577: Feature: Multi-tile depots https://github.com/OpenTTD/OpenTTD/pull/9577 19:30:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12151: Fix #12086: Crash if NWidgetMatrix holds content taller than 64K pixels. https://github.com/OpenTTD/OpenTTD/pull/12151#issuecomment-1963037708 19:36:19 *** Leopold_ has quit IRC 19:40:49 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178 19:43:43 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899738552 19:44:53 <xarick> nice, more than 64k stations in a list possible now 19:46:41 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed pull request #12151: Fix #12086: Crash if NWidgetMatrix holds content taller than 64K pixels. https://github.com/OpenTTD/OpenTTD/pull/12151 19:49:22 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211399563290607678/image.png?ex=65ee0ec2&is=65db99c2&hm=76aa5a46420d25c680599248958d147fa7ac02e92349e5cf0cfc17ce02e3b586& 19:49:22 <xarick> hmm 🙂 19:50:11 <xarick> alright, I'm dropping the complexity 19:50:33 <kuhnovic> Hehe, some things are just not worth it 19:51:06 <truebrain> kuhnovic: ghehe; well, that explains why it is bouncing around at least 🙂 Wouldn't it be easier to just extend that cache a bit? As otherwise you will always end up in these edge-cases, unless your estimation function is spot-on (which it isn't, like, ever 😛 ) 19:54:50 <kuhnovic> The problem is that the high level path can change completely if the next PF call is done from a region that's not on the current high level path. Not likely to happen, but it does happen as we now see. I'm now playing around with extending-the-cache-to-the-next-region-in-the-high-level-path. This still allows the low level PF to deviate and find a more optimal path, but it always has to lead back 19:54:50 <kuhnovic> to a region that's on the high-level-path. 19:56:09 <truebrain> that often is the only way around these issues, in my experience 🙂 Just remember +1 (or even +2), to avoid things going: OWH WAIT, THIS IS QUICKER 😛 19:57:13 <truebrain> in my younger years I wanted to write a perfect estimation function .. I found out that hard way that is very unlikely 😛 19:57:40 <ajmiles> truebrain: If you're talking about the D3D11 one, that was no different to the OpenGL one, it didn't blit anything, it just drew one quad at the end of the frame to combine dst/anim? 19:57:52 <kuhnovic> Hehe yeah you learn over time, often the hard way 😛 19:58:11 <truebrain> ajmiles: yup; just making sure you are aware 🙂 19:58:53 <ajmiles> Yeah, apart from being able to run on platforms where only D3D is available, I'm not sure how interesting that is 19:59:14 <truebrain> as by closure reason, for us, it is not interesting. Just more technical debt to maintain 20:01:40 <ajmiles> 32bpp I got working a few hours ago, and all the remap stuff is implemented (AFAIK) identically (with one small difference atm). The biggest miss that's left that I know of right now is the world map - I'm not sure how that draw 20:02:13 <ajmiles> I'm guessing that's either a ton of SetPixel or DrawLine 20:02:35 <truebrain> that would sound like OpenTTD 😛 But I don't know 🙂 20:03:12 <peter1138> Yeah, lots of SetPixel calls... and it doesn't pay any attention to interface scale. 20:03:33 <truebrain> pfff, interface scale is for those with too much money anyway 😛 20:11:56 <ajmiles> It's a nice change of pace working on a codebase that's relatively easy to understand and doesn't take 20 minutes to compile 20:13:26 <_zephyris> The small map doesn't scale with UI?? Uh oh, I feel a rabbit hole. 20:14:51 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178 20:16:28 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211406380242837575/WorldMap.mp4?ex=65ee151b&is=65dba01b&hm=e06180420941ff3e20f6a932a3e5d514b3d89c075a2b0a7d094d2632ddfc1c97& 20:16:29 <ajmiles> Another one ticked off the list - probably... 20:17:01 <ajmiles> The fact that it's all SetPixel calls is definitely something. That entire Window was black without it being implemented 20:20:37 <xarick> great progress! 20:21:12 <ajmiles> Alright. Thick lines now so everyone can see their operating profit go to the moon 20:22:42 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899743973 20:23:30 <ajmiles> Does anything other than the blitter actually need the sprite 'data' kept around after the sprite is loaded? Assuming my blitter goes off and creates GPU textures for these things, could there be a mode where the original data is deleted to save memory? Or does the gameplay logic rely on know sprite colour for some purpose? 20:25:46 <Rubidium> I'm not sure whether it still exists/is used, but some sprites were used to generate the game map 20:26:18 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899744496 20:27:27 <truebrain> peter1138: I lack context to understand your reply there 😄 20:29:17 <peter1138> Changing the return type of the scrollbar functions caused lots of issues originally. 20:29:52 <truebrain> Rubidium: there is currently no compiler that considers an `int` 64bit as far as I know, and given the issued we had with the 16 -> 32, I doubt that ever happens 😛 so your reply confuses me a lot, and sounds more academic than practical 🙂 20:30:11 <peter1138> It still does, but that function I mentioned, along with preferring the use of iterators, got rid of a bit of that. 20:30:27 <truebrain> Ah! That is the context I was missing 😄 20:31:00 <truebrain> Honestly, I would expect these functions to be size_t 😛 20:31:30 *** gelignite has quit IRC 20:31:50 <peter1138> Some things are easier with signed values. 20:32:07 <truebrain> Anyway, as far as I know, `int` vs `int32_t` is purely implicit vs explicit with 32+bit compilers, and that was what my comment was about 20:33:36 <peter1138> (Part of the reason I did #12151 was that it was less intrusive, being so close to a release.) 20:33:53 <peter1138> ((Given the age of #8006)) 20:34:16 <peter1138> But yes, it is a hack. 20:34:23 <truebrain> 8006 was more that the given developer went through all kinds of motions with the approach.. it has seen many forms 😛 20:34:54 <peter1138> Unsigned causes most of the issues, which is why size_t isn't suitable. 20:35:12 <peter1138> And int64_t is fairly excessive. 20:35:32 <truebrain> ssize_t then 😛 20:35:35 <peter1138> `using StorageType = int32_t;` 20:35:47 <peter1138> Then just one place to change it. 20:36:00 <truebrain> anyway, I don't really care about the size; I was purely asking: do we like `int` there, or should we go to `int32_t`, to be more clear about the datasize to everyone 20:36:02 <peter1138> Yeah, ssize_t is not standard, iirc. 20:36:14 <truebrain> but the reply I got I don't actually understand .. 20:36:21 <truebrain> which is a me-problem 🙂 20:36:55 <peter1138> The reply seems to be about changing the whole code-base to replace (u)int with specific (u)intXX_t version. 20:37:05 <truebrain> yeah, and I explicitly was not talking about that 😛 20:40:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899746619 20:41:30 <truebrain> also curious about your take on that peter1138 , as we have had more of these discussions over the last few months 🙂 20:43:32 <truebrain> owh, lol `int` is even 16bit on LP32 .. lolz 20:43:43 <truebrain> I forgot about this whole int changing size debacle we had in the past 😛 20:46:02 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10544: Fix #5713: Use pathfinder to find closest ship depot https://github.com/OpenTTD/OpenTTD/pull/10544 20:46:12 <xarick> simplified! 20:46:25 <xarick> oh, already failing 20:46:49 <xarick> Error: *** b/src/pathfinder/yapf/yapf_ship.cpp:394: Trailing whitespace: ' ' 20:47:54 <andythenorth> frosch123: Horse is already split into 3 grfs 😛 20:48:01 <andythenorth> ...which now won't compile 😛 20:48:09 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10544: Fix #5713: Use pathfinder to find closest ship depot https://github.com/OpenTTD/OpenTTD/pull/10544 20:50:02 <xarick> gotta edit my beautiful written post 😦 20:51:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899748303 20:55:13 <peter1138> EngineID? No. 20:55:45 <peter1138> Funny that you made that random change... that's something I fixed years ago. 20:59:04 <xarick> post edited, it's much simpler 20:59:17 <xarick> (and dumber) 20:59:29 <truebrain> what would really have been helpful, if `int` wasn't defined as "at least NN bytes" 😛 20:59:33 <truebrain> such a wildcard 21:01:09 <truebrain> ghehe peter1138 , that wasn't my code 🙂 21:01:20 *** Leopold_ has joined #openttd 21:01:30 <andythenorth> /me commenting things out and counting action 2s 21:01:32 <peter1138> Phew 😄 21:01:35 <xarick> +362 lines -81, is that more palatable? 21:01:36 <andythenorth> goes it throw out? 21:01:39 <truebrain> but it is Rbs 😛 21:01:45 <truebrain> so your comment still stands 🙂 Just in the wrong place 😉 21:02:04 <Rubidium> peter1138: what's wrong about EngineID? It's autoreplace_gui.cpp that explicitly casts to that before passing it to DrawEngineList 21:02:05 <peter1138> Is it in the PR too? 21:02:06 <peter1138> Hmm 21:02:19 <kuhnovic> xarick: It's not the size, it's what you do with it 😉 21:02:20 <truebrain> I just replaced `int` with `int32_t`; the rest is all Rb 🙂 21:02:34 <peter1138> Autoreplace_gui is wrong then. 21:02:51 <peter1138> I guess I saw it before and didn't fix it then. 21:03:23 <peter1138> I can fix that. 21:03:34 <xarick> there is no more teleport pathfind at the last region, and there are no more two attempts, just one 21:03:53 <xarick> and there is no more distance manhattan as last resort 21:04:18 <truebrain> You don't even have a patch for that?! 😮 21:04:18 <truebrain> :p 21:04:26 <peter1138> I probably did. 21:04:31 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899750001 21:04:39 <peter1138> Honestly, I remember seeing it before. 21:04:40 <xarick> that last one will hurt NPF 21:04:44 <xarick> but wtv... 21:04:49 <kuhnovic> Who cares 😛 21:05:21 <kuhnovic> As long as it doesn't completely destroy NPF performance of course 21:05:50 <kuhnovic> Oh man, running a 4K scenario is no fun in debug mode. Especially with debug drawing... 21:05:50 <xarick> it won't find nearest depot as often as it used to 21:06:36 <xarick> not that it actually had any code to find it to begin with, it was just feeded the destination 21:06:58 <xarick> now it has to work for it 21:07:03 *** Leopold_ has quit IRC 21:07:09 <xarick> and no fallback 21:08:08 *** Leopold_ has joined #openttd 21:12:10 <kuhnovic> I was kinda wondering why you're bother to change NPF at all. I tend to just focus on YAPF and leave NPF for what it is. 21:12:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899751138 21:12:45 <truebrain> Rubidium: not sure what you mean with `GetRowFromWidget` and comparing to `INT32_MAX` .. you PR changes an `uint16_t` to an `int` .. so it if would compare to an `INT32_MAX`, it would already be broken? What am I missing what you are seeing? 21:12:49 <kuhnovic> Btw, can you add your findings to https://github.com/OpenTTD/OpenTTD/issues/12176 xarick ? I think it's good to have this for future reference 21:13:07 <xarick> ok 21:13:34 <truebrain> owh, I see what you refer to, but that is already very weird code, lolz ... 21:13:39 <truebrain> ``` uint pos = w->GetRowFromWidget(clickpos, widget, padding, line_height); 21:13:39 <truebrain> if (pos != INT_MAX) pos += this->GetPosition();``` 21:13:43 <truebrain> that is just ...... wuth? 21:14:36 <Rubidium> yes it is, but that function defines INT_MAX to be returned and now you compare against INT32_MAX 21:14:50 <truebrain> so would you be fine with int32_t if I change that function to not return int, but int32_t? 21:14:54 <Rubidium> that it used to implicitly cast int to uint is another "issue" 21:15:22 <truebrain> ah, no, that is a completely rabbithole, lolz 21:15:29 <truebrain> ugh, past-us has been so sloppy in so many places 😄 21:16:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178 21:16:21 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #12175: [Crash]: Game error on Depot Actions https://github.com/OpenTTD/OpenTTD/issues/12175 21:16:24 <Rubidium> solved peter1138's EngineID 'issue', I think 21:16:49 <peter1138> Well. 21:16:57 <peter1138> Github is on a go slow for me. 21:17:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #12179: Codechange: replace "byte" with "uint8_t" in settings https://github.com/OpenTTD/OpenTTD/pull/12179 21:18:09 <truebrain> and thatone has annoyed me a lot over the last few months 😛 21:18:50 <peter1138> Github does not want to show me that last push. 21:19:06 <truebrain> annoying 21:21:21 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on issue #12176: [Bug]: Ships are circling in one place. https://github.com/OpenTTD/OpenTTD/issues/12176 21:24:11 <truebrain> the sloppiness of how we pass along ints to uints and back when it comes to scrolling 😄 This will take a while to untangle 🙂 21:24:32 <truebrain> `PlaylistAdd` takes an `size_t`, but it can be `INT_MAX` 😛 21:25:11 <truebrain> also explains the many forms 8006 took 🙂 21:25:52 <peter1138> Is std::span(first, last) valid, or does it always need std::span(first, count)... 21:26:14 <truebrain> cppreference says only the second form exists 21:26:20 <peter1138> Yes. 21:26:31 <peter1138> So I'm confused as to why the first form compiles and appears to run. 21:26:41 <truebrain> silent cast from pointer to size_t? 😒 21:27:04 <truebrain> owh, no, I was reading wrong 21:27:12 <truebrain> (first, last) is in the docs 21:27:33 <Rubidium> huh? Where on cppreference does it state only the second form exists? 21:27:49 <truebrain> bit too late there Rb 😛 21:27:51 <_glx_> our custom span was only (first, count) but std::span has both 21:29:06 <peter1138> I find the documentation for std::span is a bit otbuse. 21:29:10 <peter1138> And obtuse. 21:29:27 <truebrain> What threw me off, is that it is `It first, End last` 😛 21:29:35 <truebrain> but the description lower is a bit better 21:29:37 *** Leopold_ has quit IRC 21:29:50 <truebrain> `Constructs a span that is a view over the range [first, last); the resulting span has data() == std::to_address(first) and size() == last-first. ` 21:30:05 <peter1138> It is weird, if I look into the headers it's all templates and if constexpr... 21:30:52 <truebrain> hmm, it is `[first, last)`, mind the `)`, which isn't a `]` .. somehow my brain has issues with calling that `last`, as it is the one after last 😛 21:31:23 <truebrain> "You are the last in the line", meaning you aren't part of the line 21:31:25 <truebrain> C++ logic 🙂 21:31:52 <ajmiles> https://cdn.discordapp.com/attachments/1008473233844097104/1211425351704510534/Lines.mp4?ex=65ee26c7&is=65dbb1c7&hm=d5f8f8e750d2c4157d031ea4123116e13dfa2e7a713dce757321e5d51b1f9761& 21:31:52 <ajmiles> They look ok to me? 21:33:38 <peter1138> Ah, I think it was fixed in my scrollbar iterator branch, which was... waiting for std::span. 21:33:44 <peter1138> However, that is a big patch. 21:33:50 <ajmiles> Ah I need to find somewhere with dashed lines... 21:34:00 <peter1138> And also std::span does not work with anything other than vectors or arrays, which is a bit pants. 21:34:21 <truebrain> like what doesn't it work with that you want it to work with? 21:35:35 <peter1138> std::list 21:35:40 <peter1138> And our pools. 21:36:10 <truebrain> odd, I thought std::span didn't care about the type. Annoying 😦 21:36:23 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #12180: Codefix: DrawEngineList does not accept EngineID. https://github.com/OpenTTD/OpenTTD/pull/12180 21:37:29 <truebrain> funny how much nicer that looks 😄 21:37:31 <peter1138> Ouch. I just stabbed myself in the cheek with my thumb. 21:37:40 <truebrain> silly goose 21:38:40 <peter1138> Probably the first loop (the one that uses std::span()) could use a algorithm of some sort, but my brain isn't working for that yet :p 21:38:54 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #10544: Fix #5713: Use pathfinder to find closest ship depot https://github.com/OpenTTD/OpenTTD/pull/10544 21:39:06 <xarick> fixed some comments 21:39:43 <xarick> the npf comment is misleading too 😦 21:39:49 <truebrain> sometimes you find these functions in our code, that makes you go: huh... wth? What does it even mean? https://github.com/OpenTTD/OpenTTD/blob/master/src/town_gui.cpp#L92 is one of these. 21:40:05 <peter1138> Annoying thing about that code: it's possible to omit the `*` before `this->vscroll[side]` and... it still compiles. 21:41:25 <_jgr_> peter1138: The previous custom span wouldn't work with those either 21:41:28 <truebrain> peter1138: so why not make it `const Scrollbar sb`? 🙂 21:41:47 <_jgr_> Neither of them use contiguous spans 21:41:52 <peter1138> _jgr_: I'm aware, which is why I hadn't already used our custom span 🙂 21:42:12 <peter1138> truebrain: And pass a copy of it? Hmm. 21:42:27 <truebrain> did not check how big that struct is 😛 21:43:24 <peter1138> It has 5 member variables. It's not huge but also not nothing. 21:43:34 <truebrain> yeah. that is a bit big 🙂 21:44:30 <xarick> dear ppl fixing Scrollbar limits: I plan to have 1 million stations, make sure the list can list 1 million stations, kekeke 21:45:21 <peter1138> We should use int20_t then, so the limit is less than 1 million. 21:45:29 <truebrain> lolz 21:46:02 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic opened pull request #12181: Fix #12176: Ships are circling in one place https://github.com/OpenTTD/OpenTTD/pull/12181 21:46:33 <peter1138> Have fun rearranging the map array to support more than 65535 stations though 🙂 21:46:50 <truebrain> I read the other day someone is reviving newmap 21:46:50 <truebrain> so ... 21:47:02 <peter1138> Beautiful. 21:47:16 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899756759 21:48:22 <kuhnovic> xarick: if you feel like it, a bit of AI torture testing #12181 wouldn't hurt 😇 21:48:29 <xarick> peter1138: https://github.com/SamuXarick/OpenTTD/pull/10 21:49:07 <peter1138> 1044k instead of, say, 1M. 21:49:27 <kuhnovic> "Motivation: Buoy" seems like a weak argument nowadays 21:49:34 <peter1138> Yeah 😄 21:50:02 <peter1138> But also, 1M stations... that sounds like a recipe for another load of pool iteration performance enhancements :p 21:50:47 <kuhnovic> I thought you liked a challenge 😛 ? 21:52:38 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #12178: Codechange: use int instead of uint16_t for scroll bar position/size/capacity https://github.com/OpenTTD/OpenTTD/pull/12178#pullrequestreview-1899757632 21:53:27 <peter1138> I still need to somehow create a savegame with more orders than vehicles... Hmm. 21:53:42 <xarick> I have one 21:53:49 <truebrain> haha, that is a nice solution peter1138 (in 12178); and yes, if we want to backport this, it should be kept as small as possible 😄 21:54:56 <DorpsGek> [OpenTTD/OpenTTD] Kuhnovic commented on issue #12176: [Bug]: Ships are circling in one place. https://github.com/OpenTTD/OpenTTD/issues/12176 21:55:34 <peter1138> Later, rather than checking for INT_MAX or INT32_MAX, we can check for `Scrollbar::out_of_range` or something a bit more standard and it makes it clear what is going on. 21:55:50 <truebrain> more C++-ification! 21:56:32 <peter1138> Well, I like the iterator approach as well. 21:56:43 <truebrain> iterator approach? 21:56:59 <xarick> peter1138: https://1drv.ms/u/s!Ah9vX-Q9n7Ijm0yv9OV-9DRMw2Kg?e=DyVzNx 21:57:11 <peter1138> Like in #12180 which I need to look at because it has a red X 😦 21:57:18 <peter1138> MacOS. 21:57:46 <peter1138> Oh really. 21:57:59 <truebrain> I am a bit surprised, but I guess I shouldn't, why no compiler warns about our random int -> uint conversions 😛 21:58:06 <peter1138> > no viable constructor or deduction guide for deduction of template arguments of 'span' 21:58:10 <peter1138> Thanks macOS. 21:59:45 <truebrain> lol 21:59:48 <truebrain> always that one target 😦 22:00:22 <Rubidium> I'll await #12180 before continueing on #12178 22:00:49 <DorpsGek> [OpenTTD/OpenTTD] PeterN updated pull request #12180: Codefix: DrawEngineList does not accept EngineID. https://github.com/OpenTTD/OpenTTD/pull/12180 22:00:51 <peter1138> std::span removed. 22:01:26 <truebrain> back to the old way of working! BECAUSE THAT WORKS 😛 22:01:31 <peter1138> `std::span(first, extent)` might have worked but I can't be bothered to check. 22:02:44 <peter1138> It's still iterators as least 😄 22:02:49 <truebrain> lol 22:03:47 <peter1138> Maybe I should make a function of the first/last bit as I have a feeling that's useful elsewhere. 22:08:25 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on pull request #12131: Fix: Scale graph gridlines and axes with GUI scale https://github.com/OpenTTD/OpenTTD/pull/12131#pullrequestreview-1899760248 22:14:26 <klote[d]> truebrain: Ah thats a bummer... things like this would make Developing new content or adjusting existing content so much more accessable to people 22:14:38 <truebrain> it is why I started the project 🙂 22:15:20 <truebrain> it is only a lot, and I mean: a lot, of work 🙂 22:15:31 <klote[d]> Yeah i understand lol 22:16:11 *** nielsm has quit IRC 22:19:02 *** keikoz has quit IRC 22:19:04 <klote[d]> Has any one tried making a API connection with things like APIgtp 22:27:23 <andythenorth> hmm 22:27:34 <andythenorth> failed to rearrange my action 2s so far 😛 22:27:50 <peter1138> Hmm, how's this? <https://github.com/PeterN/OpenTTD/commit/74fbcb3024928fe28f4df797b23319473e72a5f4> 22:28:11 <peter1138> More code but reusable. 22:29:06 <DorpsGek> [OpenTTD/OpenTTD] zephyris commented on pull request #12164: Add: Highlight in white all pieces of company owned infrastructure in the viewport https://github.com/OpenTTD/OpenTTD/pull/12164#issuecomment-1963083382 22:30:11 <truebrain> peter1138: looks fine to me. Isn't there some C++ syntax for the `GetIterators`, I only wonder? 22:30:39 <andythenorth> ach 62 global switches handling sets of colours 22:30:44 <andythenorth> wonder how much they're the cause of the issue 22:31:33 <andythenorth> not a quick one to test 😦 22:31:43 <peter1138> Possibly ranges, but that is too new. 22:31:55 <peter1138> But yeah, my knowledge here is lacking. 22:32:12 <truebrain> so is mine 😄 22:32:14 <truebrain> frosch! 😛 22:32:37 <peter1138> There's probably some extra modern C++ stuff that will ensure that container is actually a container... 22:32:58 *** Wolf01 has quit IRC 22:33:04 <truebrain> and also making it std::span compatible etc? 😛 22:34:00 <andythenorth> ach the 62 colour sets all resolve via one global switch, so those are fine 22:36:03 <peter1138> Well you can pass first, last to std::span. 22:36:12 <peter1138> Except on macOS. 22:36:15 <truebrain> MacOS told you "no" earlier 😛 22:36:15 <truebrain> 😄 22:36:35 <peter1138> `std::span(first, std::distance(first, last))` probably works 22:36:48 <peter1138> But I dunno. 22:36:49 <peter1138> Maybe not. 22:36:55 <truebrain> but that is weird ... C++20 says (first, last) should also work 😛 22:36:59 <truebrain> given some constraints on last 22:37:28 <peter1138> In this case it's fine, I didn't actually need a span. 22:37:34 <truebrain> true 22:37:39 <truebrain> still weird, that we are actually C++20 😛 22:37:49 <truebrain> from C++11 to C++20 in how many years? 😄 22:42:49 <andythenorth> pfff....another expected candiate for high varact 2 use...makes no difference 😛 22:42:56 <andythenorth> hard to know what nmlc is doing behind my back 🙂 22:43:27 <andythenorth> turning off bits of the grf...or re-ordering it...doesn't yield much 22:43:39 <andythenorth> nmlc must be quite good at optimising varact 2 use? 22:49:02 *** Leopold_ has joined #openttd 22:49:56 <andythenorth> oof rearranging articulated parts callback squeaks in 22:50:06 <xarick> back, ok let's torture 12181 22:50:10 <andythenorth> so the thing that was failing to compile now works, with 252 / 256 IDs 22:50:12 <xarick> 🙂 22:50:47 <andythenorth> I had a big graphics chain switch in between the callbacks block and the varact 2 handling the articulated parts 22:56:18 <andythenorth> 222 / 256 if I turn off some stuff 22:56:19 <andythenorth> hmm 22:59:47 *** Leopold_ has quit IRC 22:59:49 <andythenorth> ok found a switch I can shard 😄 22:59:52 *** Leopold_ has joined #openttd 22:59:57 <andythenorth> always nice to spend a few hours unpicking this stuff 23:13:33 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211450943757881374/image.png?ex=65ee3e9c&is=65dbc99c&hm=4ed2848802e9ce1b9cdb2a23877bfd7be6ca03c11e65a6fb50a70b858789ef94& 23:13:33 <xarick> my excelent debugging skills! 23:14:01 <xarick> so it happens more often than 0.01% apparently 23:16:54 <xarick> I need a bigger sample, gonna try 1 million 23:21:39 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211452982999257098/image.png?ex=65ee4082&is=65dbcb82&hm=89c6d2d4737663c282e0bc0c8edb754631105427513adb47d306651bf3ba31ac& 23:24:03 <xarick> 4,1 % of the time 23:25:59 <xarick> but which of these would result in a ship doing circles? 23:26:37 <xarick> how would I conveniently test this case without visually inspecting 23:28:20 <xarick> i have so many ships, even 1 million is too little 23:44:46 *** tokai has joined #openttd 23:44:46 *** ChanServ sets mode: +v tokai 23:50:23 <xarick> random big number... 23:50:25 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1211460225257963630/image.png?ex=65ee4741&is=65dbd241&hm=3515f448c9dd2e21c510188dfb5ea11f9ec7b6af1162a20b28eb193dcd37acf7& 23:50:31 <xarick> 2.69% 23:50:43 <xarick> okay, im off to bed, goodnight 23:51:25 *** tokai|noir has quit IRC