IRC logs for #openttd on OFTC at 2025-10-31
⏴ go to previous day
00:57:05 <_glx_> `auto` is for variables
00:59:08 <_glx_> (because you don't want to fully type templated iterators for variables)
02:12:02 <zanooda2000> How about making "non-traditional button behaviour" use regular "traditional" top menu button on 2nd click instead of closing deopdown list ?
02:12:02 <zanooda2000> Like on 1st click on "companies list" you get just the dropdown list, but on 2nd click on the same button while dropdown still open, you will get _your_ company window, as it was before on 1st click without holding
02:12:02 <zanooda2000> Such thing will save speed of "old" buttons, but also will let you use dropdown without holding button.
03:56:23 *** gnu_jj_ has joined #openttd
03:59:59 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:39:24 *** Zathras_1 has joined #openttd
04:39:34 *** Zathras has joined #openttd
04:42:54 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:42:59 *** Zathras_4 has quit IRC (Ping timeout: 480 seconds)
05:04:14 *** bryjen has quit IRC (Quit: Leaving)
07:02:04 *** toktik has quit IRC (Remote host closed the connection)
07:26:17 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:43:47 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
09:43:48 *** WormnestAndroid has joined #openttd
10:05:23 <xarick> some "this->" are missing in script_list.cpp, is it worth a PR to add them?
10:26:51 <xarick> btw i have no idea what kind of magic is happening in `bool ScriptList::LoadObject(HSQUIRRELVM vm)`
10:47:00 <xarick> Codechange or Codefix? I forgot
10:55:11 <peter1138> Urgh, I gotta find and fit my mudguards ready for tomorrow.
10:55:58 <peter1138> Our rule is once the clocks change, mudguards are mandatory. Saves arguing over whether the weather is good enough. But I need to find them :)
11:00:18 <xarick> is that multi docking tile related?
11:01:40 <Borg> xarick: its not a bug.. its a feature
11:02:03 <peter1138> No, they appear to think the ship should randomly go to a depot if it has only one goto station order.
11:02:04 <Borg> and I think changing it is good idea
11:02:51 <Borg> if ship have one order.. player did sth wrong.. send ship to depot for inspection
11:03:13 <Borg> anyway :) I gave patch.. do what you want with it :)
11:03:39 <Borg> also keep in mind.. that oil rigs can go out of service.. and then you end up w/ ships with invalid order
11:03:53 <Borg> so they will start to circle and horn around depots..
11:04:05 <Borg> so sending them to depot is not bad idea imo
11:05:18 <talltyler> Wouldn’t it make more sense for it to wait at the only valid station? The nearest depot might be far away and boats are slow.
11:05:56 <alfagamma7> how about adding a limit to the no of vehicles a single depot can carry?
11:06:10 <alfagamma7> .....might be a bad idea I think
11:06:27 <_jgr_> There are already news messages about vehicles with incomplete orders
11:08:06 <Borg> talltyler: well, if depot cannot be found.. ship will get lost.. still imo better behaviour than horning around
11:08:28 <Borg> _jgr_: yes and what you do? you send them to depot to sell. or repurpose for other oil rig
11:09:22 <Borg> _jgr_: and in multiplayer games.. you might not be around for the event
11:09:28 <Borg> so. again, sending for depot is better..
11:09:30 <_jgr_> Yes, that's for the player to do. Having vehicles go on jollies of their own accord is not helpful.
11:09:52 <Borg> okey :) I did what I could.. patch posted..
11:09:57 <alfagamma7> Interesting wording
11:16:36 <xarick> I also cleaned up some coding style on the safe btree set/map
11:16:43 <xarick> but that's JGR related
11:16:59 <xarick> i don't feel like commiting to JGR, it has many other changes :/
11:28:43 <xarick> i'm still considering getting rid of RetargetIterator template
11:29:28 <xarick> do as the ChangeValue do
11:37:16 <xarick> yeah, that's a bit more mouthful
12:03:55 <xarick> `iter = iter.generation() > 0 ? container.lower_bound(iter.key() : container.end();`
12:04:42 <peter1138> Have you moved on to trying to "optimise" JGRPP?
12:05:15 <xarick> I am hoping to get this into a PR, but it's a 3rd party thing 🙁
12:05:28 <xarick> i dunno how to handle that
12:06:42 <_jgr_> I think you are wasting your time PRing this
12:07:27 <xarick> it makes scripts really faster when handling list operations
12:08:19 <xarick> a faster fast forward with AIs
12:27:39 <xarick> is std::next(iter) the same as ++iter?
12:27:40 <andythenorth> I wonder if we should split the development channels
12:28:13 <andythenorth> this one is quite overwhelmed by
12:28:13 <andythenorth> * and a lot of pray and spray development that will never go anywhere, and saps the fun from the project
12:29:07 <talltyler> I use Discord’s Ignore feature liberally to avoid the fun leaking out 🙂
12:29:21 <talltyler> (You are not on my ignore list, Andy 😄 )
12:30:00 <andythenorth> I usually think it's a bad sign when communities only work because of ignore lists
12:30:33 <andythenorth> oof so tempted to pretend peter is on my ignore list 😛
12:31:57 <locosage> ignoring is kinda dumb, you just see half of the conversation
12:31:59 <talltyler> Speaking of fun in the project, I wish you posted more sprites in here 🙂
12:33:53 <talltyler> I don’t want everyone to post sprites, just Andy 😛
12:34:45 <talltyler> This shouldn’t be GRF development but Horse/FIRS development has driven so much OpenTTD development that I give it a pass
12:36:05 <peter1138> There is only #openttd.
12:37:47 <andythenorth> I was asked to not post sprites in here
12:38:05 <andythenorth> there are other places I can do that
12:38:40 <talltyler> Fair enough, I've just hidden Discord channel #openttd because it's a silly place 🙂
12:39:04 <talltyler> Maybe you need a thread in Discord channel #development-forum that I can follow
12:39:18 <talltyler> I am aware this is a personal issue for me and not a problem for anybody else 😛
12:39:30 <peter1138> Nah, post things in here so we can see them.
12:39:34 <andythenorth> no I just alternate Discord channel #openttd and Discord channel #add-on-development, depending which one I've been warned about most recently
12:39:56 <andythenorth> there is quite a thing about "grf stuff is off topic"
12:40:09 <andythenorth> but everyone having their own thread does not advance much
12:42:15 <andythenorth> it's very noticeable now that this has so much filtering
12:42:30 <andythenorth> and this has none 🙂
12:42:35 <alfagamma7> Should really play a game of OpenTTD
12:43:16 <andythenorth> peter1138, I did not see any docks
12:43:19 <peter1138> andythenorth, one reason I didn't is because it's a quite a bit of extra work to add :p
12:43:20 <mmtunligit> peter1138: yes YES
12:43:32 <andythenorth> "lazy developers" meme time
12:43:33 <talltyler> I wonder how much work it would take to generalize the available vehicle list and just reuse it in the purchase and replace menus
12:43:43 <peter1138> andythenorth, but also, if it did have them, should it share config with the build window?
12:44:07 <peter1138> talltyler, the list is generic, just the widgets aren't.
12:44:10 <andythenorth> I know that I can badge recommended replacements though 😛
12:44:32 <peter1138> I did look at ways of having 'embedded' sections of widgets but kept getting side-tracked.
12:44:50 <andythenorth> docs have a replacement tree for specific engines
12:45:01 <andythenorth> and it could be done also by filtering role etc
12:45:15 <peter1138> Recommended replacements seems like something that is separate from badges.
12:45:23 <peter1138> Given badges are static etc etc.
12:45:26 <andythenorth> yeah, having thought it through I agree
12:45:31 <_jgr_> locosage: The main performance issue with tree tile loop was with snow-related (arctic), and I've made changes to mitigate that
12:45:36 <andythenorth> isn't there some never-used action 0 prop for AIs to choose engines?
12:45:55 <peter1138> Yeah but it's never used.
12:46:42 <andythenorth> never really explored those
12:47:04 <peter1138> Or do you just have a static list per vehicle (yay, variants fuck us over again)
12:47:12 <andythenorth> I like what civil AI does
12:47:20 <peter1138> (A callback can be shared, at least)
12:47:22 <locosage> _jgr_: In theory it's not really related to trees, it's just general speed up due to better caching. Though I didn't investigate it much to see where exactly did performance gains come from.
12:47:24 <andythenorth> goes it replace Variants with the next attempt?
12:47:32 <andythenorth> I like Variants, but seems it's only me
12:47:57 <talltyler> I like Variants a lot as a user, but haven't done any GRF stuff since it was released
12:48:02 <locosage> it can probably also improved further, performance just wasn't my goal in that pr
12:49:21 <_jgr_> Tiles need to visited as part of the tile loop anyway, and the cache misses associated with that are fairly unavoidable
12:49:47 <_jgr_> Doing tree related stuff at that time doesn't really cost anything significant extra
12:49:56 <talltyler> I think a callback for replacement makes more sense than a property. Better structure for variants, and the recommended replacement might change when a new vehicle is invented.
12:50:08 <locosage> sure, but it less misses if they're iterated in repeatable pattern rather than completely random
12:50:25 <talltyler> Although for variants, maybe you want to replace it with the same livery
12:50:38 <talltyler> (or passenger config, or whatever else people do with variants)
12:51:38 <andythenorth> I think 'recommended replacement' (single result) gets a bit close to 'just autopilot the whole game'
12:51:40 <_jgr_> locosage: Yes, iterating in memory order is better in that sense, but it's visually obvious as well
12:51:44 <andythenorth> choosing the trains is a fun part
12:51:58 <talltyler> True, perhaps it's a feature we don't need
12:51:59 <andythenorth> 'recommended replacements' (plural) is just helpful filtering though
12:52:04 <locosage> _jgr_: well, the code I linkes isn't visuall obvious at all
12:52:16 <talltyler> Yeah, sounds like solving the wrong problem
12:53:13 <locosage> in fact, afaict it's completely indistinguishable from random and pattern size can be reduced
12:56:05 *** Wormnest has joined #openttd
12:56:39 <_jgr_> At first glance I'm not sure how this is a really a better memory access pattern
12:56:51 <_jgr_> I might take another look later, I need to pop off now
12:57:10 <locosage> well, I'm not sure either since I haven't investigated it much as I was solving a different issue xD
12:57:40 <locosage> but it's probably worth looking into
13:45:59 <_glx_> xarick: nothing magic, it's just the opposite of SaveObject with safety checks
13:49:12 <xarick> Remove tag is valid for that?
13:52:13 <xarick> I checking regression list tests to see if it tests how it orders items with the same values with SORT_BY_VALUE sorter
13:55:57 <_glx_> easy, values are sorted, and all items with same value are also sorted
13:58:34 <LordAro> `return (result ? strdup("true") : strdup("false"));` screaming noises.
13:59:43 <_glx_> hope it properly release memory at some point
14:00:06 <peter1138> LordAro, according to Rust, memory leaks are memory safe :)
14:01:15 <LordAro> i would very dearly like to rewrite this whole library in rust
14:01:37 <LordAro> it's a horrendous libxml-but-with-extra-bits-bolted-on string parsing mess
14:02:41 <zanooda2000> andythenorth: Just make such locomotives more powerful so actual players will do so. Slow locos are boring.
14:04:48 <andythenorth> I am confused about what those words mean
14:05:46 <zanooda2000> Just askin to make at least some highspeed locomotives actually powerful enough to be able to be used with freight trains.
14:05:57 <andythenorth> I don't know what that means
14:06:23 <andythenorth> is there a missing piece of information? Do you play with wagon speed limits off?
14:06:30 <_glx_> slow but powerful is typical for freight
14:06:58 <zanooda2000> andythenorth: Yes, mostly
14:07:18 <andythenorth> I guess there are lots of grfs to choose from
14:10:03 <zanooda2000> Yes, but Iron Horse is quite simple and nice-looking, something like Vanilla Experience++. Unfortunately, there are no truly fast and powerful trains (at the same time).
14:10:03 <zanooda2000> There's always NUTS for power/speed/capacity, but it lacks the charm of "*slightly *realistic" trains.
14:17:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:17:50 *** WormnestAndroid has joined #openttd
14:18:07 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:18:08 *** WormnestAndroid has joined #openttd
14:18:11 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:18:11 *** WormnestAndroid has joined #openttd
14:21:28 <andythenorth> did someone post a screenshot of docks?
14:21:39 <andythenorth> don't obiwan typo 'docks'
14:25:05 <peter1138> There was, indeed, an unsolicited picture of docks.
14:35:24 <andythenorth> are there more dock pictures?
14:35:29 <andythenorth> I remember a livestream
15:24:53 <xarick> the sort by value actually sorts by value first, item second, in ascending or descending order
15:26:00 <xarick> probably obvious for you, but I was always wondering about ties
15:28:12 <peter1138> Hmm, where did I put my cable ties?
15:28:13 <xarick> now i wonder if the insertion order matters :p
15:31:24 <andythenorth> there's some in my utility room cupboard
15:31:57 *** kuka_lie has joined #openttd
15:32:54 <peter1138> Yes, can I have them back?
15:37:04 <_jgr_> locosage: From the look of it you're effectively using a constant stride from the pseudo-random starting point in the pattern, so the hardware prefetcher may be able to do something with that directly
15:39:13 <_glx_> xarick: items are always sorted ascending when added, both by item and by value
15:40:28 <_glx_> list sort actually just changes how the data is iterated
15:41:58 *** gelignite has joined #openttd
15:52:37 <peter1138> It's a pain to do it efficiently :)
16:01:34 <peter1138> Especially when "someone" decides to add the every tile on the map to a list.
16:06:16 <xarick> haven't tested that on the safe btree yet
16:07:07 *** Flygon has quit IRC (Remote host closed the connection)
16:08:18 <xarick> there's many performance metrics to test
16:12:01 <andythenorth> I added the whole map to memory in GS once
16:12:21 <andythenorth> then I deleted it
16:13:27 <xarick> i suppose we can't use unordered_map/set anywhere here 😛
16:16:18 <xarick> nop, failed regression
16:17:18 <xarick> even the buckets have order
16:26:19 <xarick> hmm the bucket list itself could be a FlatSet?
16:29:57 <xarick> FlatSet has no member ::iterator
16:32:09 <andythenorth> goes it increase number of cargos?
16:34:43 <andythenorth> I've got a new FIRS economy, that is quite maximalist
16:38:04 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
16:38:08 <andythenorth> but I am considering adding more building materials (concrete products, bricks and tiles, maybe slate), maybe adding more foodstuffs (sugar, cocoa beans, edible oil), maybe splitting goods up a bit
16:47:19 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:47:41 <locosage> _jgr_: my guess is that it can cache memory access a bit since it's at least somewhat sequential
16:48:00 <locosage> should be even better if pattern iteration was split in x/y loops too
16:48:10 <locosage> either way, less random more performance I guess
16:48:29 *** WormnestAndroid has joined #openttd
16:53:54 <locosage> hm, though without the need for deterministic drawing can just hit LFSR MapSize()/256 times, sort indexes and run them all in order
16:54:01 <locosage> no need for having a pattern
16:56:28 <locosage> though sorting is nlog(n) it likely still beats the tile loop
16:56:51 <locosage> sorting 65k ints is like nothing
16:57:12 <locosage> well, a bit more for jgrpp I guess xD
17:00:36 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
17:00:37 *** WormnestAndroid has joined #openttd
17:01:18 <mmtunligit> if i have a callback function for a command that only checks if the command succeded or not do i need to do the tuple thing? i can figure out whats going wrong from the error messages when i try to build
17:06:12 <peter1138> If you only need to know success, then there is Succeeded() and Failed() methods of the CommandCost return.
17:06:48 <peter1138> Can't remember how that fits in with callbacks though.
17:18:56 *** Smedles has quit IRC (Read error: Connection reset by peer)
17:19:26 *** Smedles has joined #openttd
17:24:34 <xarick> why can't FlastSet use iterator? why const_iterator
17:27:31 <locosage> ouch, sorting is actually pretty slow...
17:27:45 <andythenorth> peter1138 so your patch is 96 cargos? 👀
17:30:38 <locosage> somehow that pattern loop runs the same time as sorted without even counting the sorting cost
17:30:39 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
17:31:33 <mmtunligit> ok yeah im pretty sure callbacks require a tuple
17:31:37 *** WormnestAndroid has joined #openttd
17:31:44 <mmtunligit> at teh very least i needed one anyway
17:37:38 <locosage> ok, no, with global array sorted is much faster
17:37:45 <locosage> only if sorting isn't counted though
17:55:04 <xarick> I tried flat_set but im having problems
17:56:10 <xarick> probably const_iterator related, i dunno
18:08:26 *** Wormnest has joined #openttd
18:22:14 <xarick> iterators incompatible
18:27:13 <xarick> requires too much brains
18:53:22 <Borg> when I look at most of OpenTTD code.. my eyes hurt.. I see whole christmass tress of if {} else {} deep nested.. I wonder why this style is preffered
18:53:34 <Borg> instead of trying to early elimiate bad paths via continue;
18:53:52 <Borg> sometimes its unavoidable of course.. but most of time you really can do it
19:10:54 <Rubidium> Borg: I wouldn't say it's prefered to deeply nest, though there's a limit to the amount of picking apart you can do to each PR. Similarly, there's a disincentive to improve the code due to the PR proces causing such improvements not to be made
19:11:54 <Rubidium> and it probably highly depends on the code paths you're looking at
19:12:01 <andythenorth> goes it permit self-approve again? 👀
19:13:45 <peter1138> I think we do try to avoid it when adding code, and sometimes someone had a code duffing spree.
19:16:33 <Rubidium> basically it's a resource constraint. I could make many PRs, but someone needs to review them... and then it's often "better" for the end user when something functional gets reviewed instead of changing the coding style
19:17:30 <locosage> wow, tile loop in master is somehow significantly faster than in beta3
19:17:48 <locosage> tile loop getting too fast was not the problem I anticipated 😅
19:18:09 <locosage> hard to compare different implementations when it runs in 0.6ms
19:18:31 <peter1138> Just run it in a tight tictoc loop, that always gives entirely 100% accurate results...
19:18:36 <andythenorth> some projects do skip review in certain circumstances
19:18:43 <andythenorth> "if the tests pass..."?
19:19:02 <andythenorth> our tests are not very comprehensive? 😛
19:19:14 <_jgr_> locosage: Use valgrind, gperf, operf, or something else along those lines?
19:19:18 <locosage> tictoc would be a bit synthetic, I wanted to run it in a real game
19:19:21 <peter1138> Rubidium, refactor PRs do tend to get through quicker than heavy feature PRs, so it's not entirely fruitless.
19:19:51 <peter1138> I mean, the /s was very much not hidden.
19:20:01 <andythenorth> feature velocity is pretty good right now, but the project is a bit thin on active people again
19:20:13 <peter1138> My problem is refactoring things and then putting in too mucH :)
19:20:23 <peter1138> Then I throw it away because it's invasive.
19:21:14 <locosage> _jgr_: I'm not sure profiler results are comparable between different executables
19:21:49 <locosage> anyway, the main thing I need to compare with is master and it's quite clear since it's like 2x faster
19:22:08 <_jgr_> locosage: You can run the same savegame through the two builds and then compare the outputs
19:23:24 <locosage> I guess I can just time run -v null, should be good enough for development
19:27:32 <Borg> dunno about your policy here, but doing refactor for sole refactor is kinda waste of time..
19:27:49 <Borg> im touching some code now.. and I decide to refactor it first... test
19:27:53 <Borg> and then I will add feature
19:28:16 <Borg> of course.. now it doesnt compile... ;)
19:28:25 <Borg> I probably fucked up some nesting
19:32:06 <mmtunligit> i havent really seen any christmas trees in the stuff im looking at
19:34:17 <Borg> okey workz.... elimanted all else
19:35:57 <Borg> mmtunligit: im working at jgrpp branch :) atm.. tracerestrict.cpp have some
19:37:55 <_jgr_> This sounds like the kind of quest that will eat a lot of time to no tangible benefit?
19:41:12 <Borg> _jgr_: benfit is.. I will have my stuff working :)
19:41:17 <talltyler> Can I refactor some code and call it a War On Christmas? 😛
19:42:48 <Borg> anyway.. back to coding..
19:42:55 <locosage> plz stop refactoring, I can't keep up fixing cmclient 😜
19:43:12 <Borg> locosage: no worries.. its private branch :)
19:57:54 *** Wolf01 is now known as Guest30298
19:58:07 *** Guest30298 has quit IRC (Quit: Once again the world is quick to bury me.)
20:23:25 <mmtunligit> im *really* good at remebering to rename my functions and variables when copy and pasting them from elsewhere, i just want everyone to know this
20:24:03 <mmtunligit> i definently did not spend half an hour banging my head against a wall as to why this f*!@$ng thing wouldnt build
20:36:30 <xarick> i replaced safe btree map to std::map
20:44:30 <xarick> the gains were not from safe btree
20:45:21 <_glx_> binary tree and map don't have the same purpose
20:45:50 <xarick> at least the Valuate part is still as fast
20:54:17 <Borg> mmtunligit: well, OpenTTD C++ style is far from my own.. also, I dont do C++ actually.. so I strugle..
20:54:25 <Borg> but its ok :) once stuff is done.. I will relax and play game
21:07:26 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
21:12:01 <andythenorth> hmm ports in small lakes still 🙂
21:12:31 <andythenorth> do we have water regions now? and do they have a tile count or anything?
21:14:43 <andythenorth> * the port has specific tiles that have to be coast
21:14:43 <andythenorth> * coast tiles are water tiles iirc
21:14:43 <andythenorth> * ideally there'd be a check on the coast tile (in the grf, using new vars), where the predicate would be: `number of connected water tiles > n || tile is connected to map edge`
21:27:14 <xarick> SlowValuate creates a new list, iterates the old list, adds items of the old list to the new list with values valuated, clears old list, adds new list to old list
21:30:04 <xarick> SlowValuate_PR14311xxxx handles one list only, sorts by item, iterates the list and adds items with values valuated, restores the original sorter
21:31:56 <xarick> actually, doesn't sort anything lol
21:32:12 <xarick> that's a mistake from me
21:32:38 <xarick> perhaps it doesn't have to
21:33:37 <xarick> yeah, i don't pre-sort it on SlowValuate
21:41:31 <xarick> Pre-Sort made no difference, hmm
21:46:27 <_glx_> sorting is kinda free for lists (they are already sorted anyway)
21:48:04 <_glx_> but it's important to use the right sorter type when iterating in your slow valuate
21:48:15 <_glx_> (the right one is by item)
21:48:36 <_glx_> ascending or descending doesn't matter
21:49:22 <_glx_> by value won't work because it affects the iterating
21:54:03 <xarick> why is std::map std::set faster
21:54:11 <xarick> than the 3rd party stuff
21:54:47 <xarick> not always though, something seems slow, and i wonder if it's list.Clear or list.AddList
21:56:13 <xarick> AddItem is faster, confirmed
22:04:52 *** Borg has quit IRC (Quit: leaving)
22:05:07 <rito12_51026> In order to show different text in each list I will have to use unique wids for each of them, right?
22:06:18 *** aperezdc has quit IRC (Remote host closed the connection)
22:30:12 <xarick> jgr doesn't have a CopyList nor CloneList
22:30:27 <xarick> i think i implemented it badly
22:33:54 <xarick> glx, are iterator positions cloned?
22:38:48 *** aperezdc has joined #openttd
22:42:25 <mmtunligit> hmm, side effect of being able to move the station sign is that the base tile of the station could be on a tile that also belongs to a different station, is this an issue? im already ensuring that it cant be placed on the base tile of a different station for visibility reasons
22:42:58 *** aperezdc__ has joined #openttd
22:46:38 <xarick> isn't that involving kdtree stuff?
22:46:49 *** aperezdc has quit IRC (Ping timeout: 480 seconds)
22:47:57 <mmtunligit> not signs or waypoints as far as i can tell
22:50:16 *** aperezdc__ has quit IRC (Remote host closed the connection)
22:51:57 <mmtunligit> that was actually really helpful, thank you
22:52:36 <mmtunligit> id noticed that there was something to do with a "kdtree" back when i was first looking at what id need to do for this but wrote it off as probably not nessecary and scary and confusing
22:53:13 <_jgr_> The existing code to move station signs should manage kdtree updates already
22:54:23 <mmtunligit> yeah it does, the bit i need to figure stuff out to do with it for is checking where to put a waypoint sign
22:56:32 <andythenorth> actual naptime now
23:06:14 <xarick> _jgr_: I need help. For the CloneObject/CopyList, does this look correct?
23:06:45 <xarick> worried about this->values_inited
23:08:37 <xarick> perhaps this->values and this->values_inited need not to be cloned, they would be initiated on first use?
23:11:49 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:13:56 *** WormnestAndroid has joined #openttd
23:20:46 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:32:49 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:33:48 <xarick> ah ya, this->Begin() inits the sorter which inits the values
23:33:59 <xarick> looks like no need to copy that
23:35:40 *** WormnestAndroid has joined #openttd
23:36:00 <xarick> just tested, only this->Sort(...) and this->items need to be copied over
23:37:56 *** aperezdc has joined #openttd
23:38:18 *** kuka_lie has quit IRC (Quit: Lost terminal)
23:38:43 <xarick> regression clones a list which doesn't make use of this->values unfortunately
23:40:32 <_glx_> in vanilla the clone has the same content, and iterator is reset (need to use Begin() first when iterating the clone)
23:44:06 <_glx_> (and `new ScriptList()` also uninitialised anyway)
23:47:56 <xarick> I'm undoing the 3rd party stuff, this might be actually PR'able soon
23:48:18 <_glx_> hmm actually `CopyList()` might have issues if you copy a list into another one if the destination is initialised and use the same sorting as the copied one
23:53:18 <_glx_> not tested, but I think something like ```list.Begin();
23:53:18 <_glx_> <some iterations using list.Next() without reaching end>
23:53:18 <_glx_> <continue iterations using list.Next()>``` is probably breaking things
23:53:23 *** aperezdc has quit IRC (Remote host closed the connection)
23:55:13 <_glx_> if `list` and `other` have the same sorting
continue to next day ⏵
