IRC logs for #openttd on OFTC at 2024-12-03
β΄ go to previous day
00:09:30 <peter1138> If it's the ubuntu thing then that's a pretty dumb annotation.
01:09:09 *** speeder has quit IRC (Ping timeout: 480 seconds)
01:12:25 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
01:15:09 *** SigHunter has joined #openttd
01:24:40 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
01:26:24 *** SigHunter has joined #openttd
01:51:59 *** speeder has joined #openttd
02:33:05 *** ChanServ sets mode: +v tokai
02:39:49 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:49:53 *** emperorjake has joined #openttd
02:49:53 <emperorjake> I've found a bug, the recent fix for remapping cargo types in older vehicle sets doesn't seem to affect ships. Here I've loaded FIRS 5 and WSF Ferry Set in latest vanilla nightly
02:55:40 <wensimehrp> π¨ passengers were dissolved in acid?
03:12:34 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:38:20 *** k-man has quit IRC (Ping timeout: 480 seconds)
03:59:10 *** debdog has quit IRC (Ping timeout: 480 seconds)
06:07:22 *** Rubidium has quit IRC (Remote host closed the connection)
06:15:39 *** ialokin has joined #openttd
06:16:47 *** michi_cc has joined #openttd
06:16:47 *** ChanServ sets mode: +v michi_cc
06:32:24 *** Rubidium has joined #openttd
07:04:36 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:06:17 *** k-man has quit IRC (Ping timeout: 480 seconds)
07:06:17 *** k-man_ is now known as k-man
08:59:26 *** ialokin has quit IRC (Ping timeout: 480 seconds)
09:10:00 *** ialokin has joined #openttd
09:23:10 <peter1138> What should the default cargo type of a train engine be...
09:24:08 <peter1138> Currently it's passengers, but that means if passengers is not available and the engine isn't refittable, the engine will not appear.
09:25:54 <andythenorth> passengers not being available is a bug π
09:26:07 <andythenorth> at some level, norms have to apply π
09:27:32 <mnhebi> Either that or wood. Pretty much every industry set has logs or such
09:27:57 <andythenorth> peter1138: why not GEAR?
09:28:03 <andythenorth> and cargo class bit 15 π
09:28:56 <mnhebi> Andy no! :desperateshot:
09:39:15 *** brickblock19280 has joined #openttd
09:39:15 <brickblock19280> mnhebi: I know of sets without wood or mail
10:11:14 <peter1138> I think I need something like a context-aware CT_DEFAULT.
10:11:41 <peter1138> If you have a wagon and you don't set any cargo type, what cargo type do you expect?
10:12:06 <peter1138> If you have an engine with no capacity then it doesn't matter, it just needs to be something valid.
10:12:35 <peter1138> emperorjake: In this case, the ship set does not set a cargo type at all fo many of the ships.
10:14:02 <xarick> oops, division by zero π¦
10:15:14 <xarick> 0% desert coverage triggers a division by 0
10:17:54 <kuhnovic> My company has 4 different systems for time off / sick leave / travel payment / work hours. And they are all unsynchronized...
10:20:45 <andythenorth> peter1138: "none" π
10:23:29 <xarick> aha!!! _glx_ I finally catched it! The FormatString error
10:27:52 <xarick> [2024-12-03 10:25:01] dbg: [misc:0] FormatString: Attempt to read string parameter as integer
10:32:34 <xarick> let me see if i can reliably reproduce
10:33:32 <xarick> string 34889, what is it?
10:35:38 <peter1138> My code found a bug elsewhere.
10:37:16 <peter1138> I'll fix it lunch time π
10:38:51 *** benjaminv has joined #openttd
10:47:41 <LordAro> kuhnovic: that sounds hilarious
10:54:21 <kuhnovic> It's pathetic. So easy to make a mistake. Big company bullshit is what it is.
11:04:31 <peter1138> Or we magic our annoation-check to ignore this sort of pipeline thing. But that seems odd.
11:26:11 <xarick> what a terrible coincidence
11:26:30 <xarick> how do i not autoformat that into a commit link?
11:31:54 <peter1138> Is that Release without asserts?
11:46:11 <peter1138> > We will forget to change back to ubuntu-latest after the transition is complete.
11:46:34 <peter1138> But now it fails because 24.04 is not selected, and we get a warning.
11:47:52 <peter1138> xarick: Round down to ms or s, Β΅s is not useful here.
11:48:44 <LordAro> well the number's smaller
11:48:55 <LordAro> also lol, managed to reference one of your own commits
11:49:04 <peter1138> I used Β΅s with #13117 only because the new version is sub-ms.
12:12:26 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
12:28:12 <xarick> * @note We shouldn't use range-for as we add to the vector inside the loop. */ good?
12:29:49 <xarick> or doxygen is bad here?
12:45:14 <LordAro> doxygen style is unnecessary inside a function, yes
12:46:53 *** XYZ_ has quit IRC (Ping timeout: 480 seconds)
12:59:31 <peter1138> Yes, doxygen is for documenting classes, functions and members. Not code.
13:03:30 *** XYZ_ has quit IRC (Read error: Connection reset by peer)
13:06:36 *** XYZ has quit IRC (Read error: Connection reset by peer)
13:06:38 *** XYZ__ has quit IRC (Read error: Connection reset by peer)
13:08:28 *** XYZ has quit IRC (Read error: Connection reset by peer)
13:11:34 *** XYZ has quit IRC (Read error: Connection reset by peer)
13:13:12 *** XYZ_ has quit IRC (Read error: Connection reset by peer)
13:14:20 <peter1138> Jacket potato with cheese and chilli.
13:14:26 <andythenorth> the fridge contains many choices today
13:19:26 <xarick> ```/* Re-adding the current rainforest tile to the queue to ensure all
13:19:26 <xarick> * newly converted TROPICZONE_NORMAL tiles are checked in subsequent
13:19:26 <xarick> * iterations for neighboring TROPICZONE_DESERT tiles, allowing for
13:19:26 <xarick> * a thorough and complete buffer zone creation process. */
13:19:26 <xarick> rainforest_queue.emplace_back(rainforest_tile, neighbour_tile);```
13:19:27 <xarick> that's a bit too wordly
13:20:07 <peter1138> Write it yourself based on your understanding of the algorithm not some AI crap.
13:20:27 <peter1138> And if it's not AI crap, well...
13:20:30 <xarick> rainforest_tile is the center of the "circle"
13:20:46 <xarick> and the neighbouring tiles are the tiles inside the circle
13:20:53 <xarick> there can be no desert tiles inside!
13:23:24 <xarick> results in generating the normal tile buffer zone between desert and rainforest
13:24:28 *** nielsm has quit IRC (Ping timeout: 480 seconds)
13:28:12 <xarick> you draw with a pencil of radius 6 around the rainforest?
13:43:18 <xarick> rainforest_queue can get quite big
13:46:40 <xarick> let me get a breakpoint there
13:47:18 <xarick> rainforest_queue = { size=8662028 }
13:48:04 <xarick> normal_tiles = { size=1008561 }
13:48:43 <xarick> i think rainforest_queue could be a deque?
13:48:50 <xarick> would help with memory maybe?
13:53:29 <talltyler> FYI, yozora3: JP+ Tracks is beautiful and while admiring it, I managed to cause a crash. I opened [#13147](https://github.com/OpenTTD/OpenTTD/issues/13147) so developers smarter than me can determine if you made a mistake somewhere. In any case, OpenTTD should not crash, so we will have something to fix on our end. π
13:55:16 *** yozora3 has joined #openttd
13:55:16 <yozora3> Oh it has to be empty {STRING}
13:55:28 *** XYZ has quit IRC (Read error: Connection reset by peer)
13:56:24 *** Flygon has quit IRC (Read error: Connection reset by peer)
13:58:55 <LordAro> hmm, not a lot of point approving things while the CI is broken
14:00:03 *** XYZ has quit IRC (Read error: Connection reset by peer)
14:01:49 <johnfranklin> I made and ate some βpesto chow meinβ
14:08:19 <xarick> ewww... deque eats more memory, at least in debug mode
14:08:46 <peter1138> As long as you are not removing items, then yes.
14:17:21 <xarick> i dont know how to profile memory usage
14:20:02 <yozora3> talltyler: Thank you for pointing this out, pushed an update with every {STRING} block defined
14:27:53 <truebrain> LordAro: I do not understand your part that you talk about using APIs and I don't know what more to see annotations?
14:28:03 <truebrain> They are very visible on several places in the CI results
14:28:52 <LordAro> sorry, should've put that in the PR
14:29:12 <truebrain> Go to a PR, go to Checks tab, click Annotations
14:29:35 <truebrain> Otherwise, click on the group of CI results and scroll below the graph of dependencies
14:30:20 <peter1138> This one is visible on Summary.
14:30:33 <truebrain> I am not against your PR btw, just surprised "nobody" could find it π
14:30:38 <LordAro> well, none of us could find it last night :D
14:30:57 <LordAro> and i definitely tend to click the CI job with the red cross on it
14:31:06 <LordAro> (and expect to find more info)
14:31:20 <truebrain> Annotations are one level higher
14:31:30 <truebrain> So you have to click back one level to see them π
14:32:13 <truebrain> Owh, they even made it more visible I see
14:32:25 <truebrain> On the CI results, click the Annotation button on top
14:33:07 <peter1138> I think I saw 1 error and 1 warning. And thought -- well, that's the warning, what's the error?
14:33:16 <truebrain> Again, your PR still sounds like a good idea, just surprised by the reasoning π
14:33:33 <truebrain> We make the error, because there is a warning :d
14:34:15 <truebrain> Just annoying GitHub uses a warning for these things
14:34:19 <truebrain> Should be an info, tbfh
14:35:06 <truebrain> Anyway, your PR does two things. You know how we feel about that π
14:35:17 <LordAro> that's why it's two commits!
14:35:22 <LordAro> one depends on the other
14:35:30 <truebrain> And those commit messages
14:35:48 <LordAro> Seemed silly to make two PRs for that
14:36:00 <LordAro> I'm at work, no conventions for commit messages here...
14:36:15 <truebrain> That is the best excuse of the day π
14:36:18 <peter1138> > 4 annotation(s) found
14:36:43 *** D-HUND is now known as debdog
14:37:00 <truebrain> peter1138: Yeah, there is one annotations for that job. Check Annotation checks how many there are for all jobs
14:37:52 <LordAro> also lol, it's failing for the same reason
14:39:00 <LordAro> i've got no idea what prettier is complaining about
14:39:05 <LordAro> (again, because it's telling me nothing)
14:39:06 <truebrain> Anyway, please check if glx can help you out in getting this fixed. All I currently have is a mobile to text words with π
14:40:03 <truebrain> Where is it complaining?
14:40:12 <truebrain> Only Check Annotation is failing?
14:40:33 <truebrain> Ah, well, it is very explicit what you have to do
14:40:39 <truebrain> Not sure what your issue is with that,
14:41:23 <LordAro> i do not even have npm installed on my WSL instance, i'm just grumbling about having to actually run it
14:41:26 <truebrain> Pretty sure that showing a diff is as useful, as just telling you to run the formatter tool π
14:41:46 <truebrain> Owh, you actually have to test your work, you are complaining about π
14:41:55 <truebrain> We need AI for this π
14:41:56 <LordAro> I did say it was completely untested
14:43:11 <truebrain> You make the best PRs, showing our young contributors how to (not) do it π
14:44:02 <truebrain> Anyway, I am of no actual help other than to bitch and moan you need glasses π but yeah, this is just an annoying warning GitHub produces
14:45:15 <LordAro> i needed a break from the complete shit i have to deal with normally
14:45:42 <truebrain> So you picked up TypeScript .. π
14:45:47 <peter1138> Why did you look at this then? π
14:46:02 <peter1138> (Thank you for looking!)
14:46:34 <truebrain> Either way, without all the joking, I do appreciate you looking into it, and improving the results of Check Annotation is a good idea π
14:57:05 <xarick> const auto &[rainforest_tile, tile] doesn't work
15:06:01 <peter1138> xarick: My bad. Same reason you can't use range-for, adding to the vector will invalidate the references.
15:06:55 <truebrain> LordAro: we "recently" also had similar stuff with macos-latest btw
15:07:07 <truebrain> Maybe we can find back how it was written back then
15:08:07 <LordAro> yeah, except our solution to that was to not use macos-latest :p
15:09:15 <truebrain> I was talking about checking if that warning matches your regex π
15:14:27 <peter1138> Do we have a chicken & egg here?
15:15:51 <LordAro> which does seem a bit silly
15:16:22 <truebrain> Nothing glx can't fix π
15:16:55 <truebrain> And for me it is time to talk to a big group of people about some work related thing .. I am playing dress-up and everything! Fun fun π
15:17:40 <peter1138> So the pipeline won't allow the pipeline to be updated because the pipeline fails.
15:17:58 <peter1138> Force ubuntu-24.04? :p
15:18:45 <peter1138> Delete everything and run it on andy's MBP.
15:26:53 <LordAro> just delete everything
15:27:10 <xarick> how far is 8 million from uint32 max?
15:29:47 <xarick> i'm bad at math and english
15:29:54 <xarick> so, it's not an algorithm
15:30:22 <xarick> it's a ... math something about area of the circle
15:31:13 <xarick> what is the discipline?
15:34:28 <LordAro> equation seems correct
15:47:55 <xarick> i changed my mind about using DistanceMax / DistanceSquare, I am now combining them
15:47:59 *** XYZ_ has quit IRC (Read error: Connection reset by peer)
15:48:07 <xarick> less calculations required as result
15:48:58 *** XYZ has quit IRC (Read error: Connection reset by peer)
15:50:12 <peter1138> Is the combination there to get a rounded square shape or something?
15:52:17 <xarick> yes, there are 4 points at the extremities of the circle that makes it too dissimilar from the original method
15:52:29 <xarick> otherwise DistanceSquare would be sufficient
15:52:41 <xarick> so i cap it to a distancemax of 6, nor 7
15:56:21 <xarick> it's a 7*7 circle apparently, but making it fitt in a 13 wide square (6+6+1)
15:56:54 <peter1138> Well, what does the table map out to?
15:57:28 <xarick> a circle that looks a bit more like a dot than the current one
15:58:09 <xarick> let me find the screenshots
16:02:49 <peter1138> Hmm, placing desert tiles in the scenario editor behaves oddly.
16:04:09 <xarick> now I don't know which is which lol
16:07:09 <xarick> maybe you can perfect the formula so it matches
16:07:32 <peter1138> xarick: You can just add debug output to show the size of the rainforest_queue and normal_tiles vectors at the end.
16:08:16 *** kuka_lie has joined #openttd
16:08:26 <peter1138> Number of elements * the size of each element is the memory usage.
16:09:43 <xarick> how big is a TileIndex
16:10:38 <peter1138> rainforest_queue is 2 of them, so 8 bytes each.
16:10:58 <peter1138> There's also vector's .capacity() if you want to know how much was actually allocated, even if not used.
16:11:31 <xarick> 8662028 * (4 + 4) + 1008561 * 4
16:12:08 <peter1138> Okay, you've added half the map.
16:12:24 <peter1138> Assuming you're doing 4096x4096, because you always do.
16:15:20 <xarick> since the tile.first is the center of the circle, tile.second is the tile testing if it's inside the circle
16:18:13 <peter1138> map won't reduce the size.
16:20:59 <xarick> std::vector<std::pair<TileIndex, std::vector<TileIndex>> ?
16:24:05 <peter1138> Show the size after the first loop
16:24:15 <peter1138> Which bit is adding the most tiles.
16:26:12 *** Wormnest has joined #openttd
16:28:05 <xarick> the first emplacement: rainforest_queue.emplace_back(tile, tile);
16:30:13 <xarick> the second emplacement: rainforest_queue.emplace_back(rainforest_tile, neighbour_tile);
16:30:59 <xarick> the third: normal_tiles = { size=1008561 }
16:31:25 <xarick> funny, 8662028 - 7653467 = 1008561
16:32:36 <peter1138> Okay so most of the first round is unique values.
16:33:15 <peter1138> Therefore using a `std::map` or `std::vector<std::pair<TileIndex, std::vector<TileIndex>>>` would just make it worse.
16:57:09 <xarick> may be slower, but i wanna test something different
17:03:21 <_glx_> ok, I have time now, so about annotations the failure is only because emscripten has an annotation
17:03:37 <_glx_> annotation check doesn't see its own annotations
17:04:48 <LordAro> seems like a silly thing to run then
17:05:04 <LordAro> if you could actually make it run with the code in the PR, then maybe
17:05:45 <LordAro> wait, i'm talking about my OTTD/actions PR, are you talking about OTTD in general?
17:05:45 <peter1138> Placing rocks on desert tiles is weird.
17:06:10 <_glx_> I'm talking about the current failures due to github info
17:06:55 <peter1138> Desert "flooding" π
17:07:15 <_glx_> and there's also the "fun" fact that cmake deprecation messages could be unseen as they don't trigger errors
17:08:00 <_glx_> but seem to be more important to me than ubuntu-latest changing (in our case)
17:17:15 <_glx_> maybe we could fine tune the filtering based on annotion_level and some other field
17:17:42 <LordAro> _glx_: there's no other data as far as i can tell
17:17:46 <andythenorth> peter1138: what about "Dessert" flooding?
17:18:15 <LordAro> path == .github, perhaps?
17:26:35 <_glx_> yeah warning and .github should work
17:28:42 <_glx_> that's a failure from before github message
17:31:51 <_glx_> lol of course annotation check doesn't use itself
17:33:02 <peter1138> That was the chicken & egg bit.
17:34:37 <_glx_> hmm I think it can use the files from the PR
17:35:05 <LordAro> i thought GH was forced to use workflow from master regardless?
17:37:20 <_glx_> we force master for release trigger (PR builds) but IIRC it uses current workflow (from PR) during CI
17:40:11 <_glx_> but maybe even when `uses: ./...` it still uses master
17:40:49 <_glx_> makes sense, as it would be a pain with the indirections
17:43:25 <peter1138> It either needs to be forced, or changed to not use ubuntu-latest, I guess.
17:44:17 <_glx_> we can force merge in this case I think
17:45:14 <xarick> strange, I don't recall seeing this many spikes
17:46:26 <xarick> desert looks too spiky in some edges
17:50:46 <xarick> pff π¦ I need the "perfect" circle I guess? or maybe the order the tiles are checked matters...
17:51:14 <LordAro> _glx_: can i leave you to do the merge & tag & everything?
17:51:18 <xarick> the differences used to be very minimal
18:03:04 <_glx_> hmm reruning failed builds still fails
18:07:40 <_glx_> ah no it's skipped on main
18:24:11 <_glx_> it's weird, it looks like it got the updated version, but the output is the same (it's supposed to print the annotations)
18:25:04 <peter1138> Shouldn't it be @v5.2.2?
18:25:11 <peter1138> Or does it just not go into that much detail.
18:27:21 <_glx_> could be rerun not doing full stuff
18:31:07 <xarick> im turning pr into draft, i'm insatisfied with the resulting desert zones π¦
18:32:03 <xarick> also it eats memory π¦
18:32:46 <peter1138> It's only temporarily during map gen though, right?
18:33:12 <xarick> last time I saw it, it was good
18:33:17 <xarick> now it looks too spiky
18:33:49 <xarick> by last time, I mean 4 years ago
18:41:27 <peter1138> Yup, no change with that.
19:01:49 <xarick> maybe I need to know how to generate the exact circle used in the original method
19:33:37 *** gelignite has joined #openttd
19:43:54 <peter1138> If so, then a combination of DistanceManhattan and DistanceMax
19:51:30 <peter1138> First we take Manhattan, then we take Berlin.
19:56:55 <johnfranklin> Considering Jet Lag I am 21 years old, if not considering Jet Lag I am still 20.
20:02:48 <kuhnovic> SchrΓΆdingers birthday
20:06:58 <johnfranklin> If to be serious⦠time of birth is 04:46 UTC+8, which is 40 minutes later
20:10:15 <peter1138> Well, Happy Birthday!
20:12:00 <johnfranklin> Thanks, the least-likely-to-happen surprise happened π
20:15:02 <kuhnovic> (sorry, I had to π )
20:15:42 <xarick> i came across something that resulted in 149 items
20:16:30 <xarick> is this the perfect circle?
20:17:15 <xarick> it would also make for a better circular tile search
20:17:38 <andythenorth> what was I doing today?
20:17:42 *** kuka_lie has quit IRC (Quit: leaving)
20:17:46 <johnfranklin> I mean I thought it would be impossible for persons such as Peter to give me birthday wish
20:17:57 *** kuka_lie has joined #openttd
20:18:22 <xarick> this guy's v2i is basically a TileIndexDiffC in OpenTTD
20:19:56 <_glx_> ok, let's try to "debug" annotation check using forks
20:21:49 <kuhnovic> xarick: It would also be fairly expensive due to the sorting
20:22:43 <xarick> it only needs to be generated once
20:23:01 <xarick> and make the vector it static constexpr somewhere
20:23:50 <xarick> feels like I'm walking backwards though
20:23:56 <kuhnovic> I wonder if sorting is constexpr, but it should be fine if done only once.
20:24:18 <xarick> i wanna first test the circle of this "result"
20:24:32 *** kuka_lie has quit IRC (Quit: leaving)
20:25:40 <johnfranklin> Is O(n^2) expensive in openttd?
20:33:36 <kuhnovic> And more importantly, how often you run it
20:39:43 <xarick> this is not what i expected
20:40:31 <xarick> don't exist in the original circle
20:41:07 <xarick> i need to look at the original though, cus i forgot what it's like lol
20:44:04 <_glx_> it's as close to a circle as possible I think
20:44:18 <kuhnovic> You're are probably flooring the decimal number instead of rounding
20:44:56 <kuhnovic> Double-to-integer-conversion truncates the decimal part which is the same as floor
20:46:08 <_glx_> good start, the problem is consistent
20:47:07 <xarick> _make_desert_or_rainforest_data
20:51:33 <_glx_> arg stupid remotes pushing to the wrong repo
20:51:36 <xarick> 60 is center, i didn't print it by mistake
20:57:50 <xarick> v2i from stackoverflow
20:58:13 <kuhnovic> You are probably doing something like `if (dist_squared < radius * radius)` . Try changing that to `if (2*dist_squared < radius * radius + 1)` . That's essentially rounding using integer math.
21:01:49 <kuhnovic> Or just use doubles and drop the integer math. It doesn't matter since it's for map generation, no risk of desyncs
21:03:20 <peter1138> Use integer math and fine-tune your squared radius.
21:03:31 <kuhnovic> Then it would just be `if (std::sqrt(x, y) <= radius + 0.5)` . Assuming your center is at 0,0 and x y and radius are all doubles.
21:03:50 <peter1138> Integer math will still be faster.
21:04:03 <kuhnovic> He says it's a one time calculation
21:04:07 <peter1138> Probably dwarfed by all the other checks mind you.
21:04:27 <peter1138> Isn' the radius check for every tile?
21:04:40 <peter1138> Or has the algorithm been changed.
21:05:03 <LordAro> _glx_: getting anywhere?
21:05:22 <peter1138> Seems strange. The existing code uses a static table already, so I don't see a purpose to calculating one.
21:05:25 <xarick> this is a vector with tileindexdiffc's generated by code
21:08:09 <_glx_> no, I make obvious changes and the output is still the same, but I think I known what happens, dist/index.js still uses the unmodified version
21:08:24 <_glx_> it's the first time we touch the actual source
21:08:30 <LordAro> i did wonder what that dist was doing
21:08:49 <LordAro> would make sense though
21:09:05 <_glx_> dist is the compiled result
21:17:18 <peter1138> Oops, accidentally did type-erasure, and it crashes :S
21:17:26 <peter1138> Compiler did not say no.
21:18:28 <peter1138> Left is `DistanceManhattan < 10 && DistanceMax < 7`
21:20:39 <xarick> oh nvm, left is made with code
21:20:46 <xarick> it's the right we need to mimic
21:22:02 <xarick> but that distancemanhattan 10 hmm.... hmmm good idea, let me try
21:23:32 <peter1138> Well, your corners are outside that, so no dice.
21:34:54 <andythenorth> peter1138: badges for tiles? π
21:37:02 <_glx_> of course this one fails
21:37:57 <LordAro> what are those numbers in your output? they look like ids rather than anything that should be there
21:39:29 <LordAro> i mean the numbers in your image
21:40:04 <_glx_> ah yes script_run.id π
21:40:13 <_glx_> I wanted to print something
21:40:33 <LordAro> i assume it's not in your generated output? :p
21:43:07 <_glx_> just checked, it's the correct one π
21:43:11 *** speeder has quit IRC (Ping timeout: 480 seconds)
21:43:59 <_glx_> but running a final test on my openttd fork
21:45:18 <_jgr_> xarick: Is it actually necessary to change the code but preserve the existing shape?
21:45:50 <xarick> it's just faster, especially in debug mode for some reason
21:46:58 <_glx_> and I just noticed I squashed previous PR and totally failed to follow commit style
21:49:29 <_jgr_> xarick: My point is now that it probably isn't necessary to replicate a bot very good circle, if you can efficiently do an actual circle
21:55:19 <_glx_> finally, rerunning failed jobs pass
21:58:30 <_glx_> ok "fixed" all failed annotation checks
21:59:15 <peter1138> Time for some spam then...
22:08:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:13:44 <xarick> ``` auto circle_offset_of_radius = [](int r) {
22:13:44 <xarick> std::vector<TileIndexDiffC> circle;
22:13:44 <xarick> for (int16_t x = -r; x <= r; ++x) {
22:13:44 <xarick> int32_t my = r * r - x * x;
22:13:44 <xarick> for (int16_t y = 0; y * y < my; ++y) {
22:13:45 <xarick> circle.push_back(TileIndexDiffC(x, y));
22:13:45 <xarick> if (y > 0) circle.push_back(TileIndexDiffC(x, -y));
22:13:49 <xarick> std::ranges::sort(circle, [](const TileIndexDiffC &a, const TileIndexDiffC &b) { return a.x * a.x + a.y * a.y < b.x * b.x + b.y * b.y; });
22:16:25 <xarick> ``` for (const auto offset : circle_offset_of_radius(6)) {
22:16:25 <xarick> TileIndex neighbour_tile = AddTileIndexDiffCWrap(center, offset);```
22:17:55 <xarick> but i can't do it equal to the original
22:18:02 <xarick> I'm missing something.
22:25:58 <xarick> oh, it doesn't work as I intended
22:26:24 *** speeder has joined #openttd
22:27:17 <xarick> seems to be constantly recreating the offsets :p
22:28:57 <xarick> `static const auto make_desert_or_rainforest_data = circle_offset_of_radius(7);` perhaps
22:35:06 <peter1138> Why do you need to create the offsets when the table is already there full of them?
22:37:12 <xarick> I don't know, I got distracted
22:38:02 <peter1138> This would be better, I guess.
22:38:15 <xarick> sometimes I forget why I do things
22:51:40 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
23:01:33 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day β΅