IRC logs for #openttd on OFTC at 2025-12-21
ā“ go to previous day
00:02:13 <_auxilian> _glx_: I guess I just don't know what I'm doing then. My apologies
00:02:46 <_glx_> no worry, learning git is not easy
00:13:12 <xarick> so I added const_iterator to my BPlusTree... 1969 lines became 2121
00:14:35 <_glx_> and I can reproduce the crash
00:38:25 <mmtunligit> glad to know thats a thing that exists and needs to be changed if im messing around with commands
00:51:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:52:05 *** WormnestAndroid has joined #openttd
01:01:53 *** tokai|noir has joined #openttd
01:01:53 *** ChanServ sets mode: +v tokai|noir
01:08:24 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:08:45 *** tokai has quit IRC (Ping timeout: 480 seconds)
01:13:58 *** WormnestAndroid has joined #openttd
03:50:08 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
03:50:45 *** WormnestAndroid has joined #openttd
04:44:05 <DorpsGek> - Update: Translations from eints (by translators)
05:14:30 *** WormnestAndroid has quit IRC (Remote host closed the connection)
05:14:33 *** WormnestAndroid has joined #openttd
07:02:57 *** Flygon has quit IRC (Remote host closed the connection)
09:20:24 <xarick> a good rectangle offender AI is OtviAI if not mistaken
09:31:30 <merni> why do you want to offend rectangles?
09:33:23 <xarick> oops, it offends more than just a rectangle :|
09:35:05 <xarick> i think it miscalculates the vertices
09:35:26 <xarick> and ends up valuating a grand portion of the map
09:36:55 <xarick> it wraps to the other side of the map
10:14:53 <rito12_51026> Haha I've just successfully crashed master
10:14:55 *** gelignite has joined #openttd
10:21:57 <kuhnovic> I just hope you can't crash RC3 in the same way š
10:27:33 <xarick> RemoveTop is different
10:31:36 <xarick> remove_item being used as a counter
10:34:25 <xarick> is there a way to avoid using lower_bound on item resume
10:34:39 <xarick> std::distance or something?
10:41:48 <Rubidium> sure, you can avoid using lower_bound... but is that what you want?
10:42:06 <Rubidium> what do you think you can gain from avoiding lower_bound?
10:45:44 <Rubidium> rito12_51026: crashing OpenTTD is easy if you know how :D
10:52:48 <xarick> can std::optional store auto?
10:54:21 <xarick> std::optional<auto> not allowed
10:55:44 <xarick> `std::optional<std::variant<ScriptListMap::iterator, SQInteger>> resume_item;`
10:56:42 <xarick> okay, going to keep lower_bound
10:56:52 <xarick> not quite what I wanted from a performance perspective
11:26:39 <xarick> RemoveTop feels a bit hackish
11:27:17 <xarick> throws a list current iterator position out
11:28:05 <xarick> it should in my opinion leave the sorter iteration intact
11:28:35 <xarick> but it's moving it to begin
11:34:21 <_zephyris> So I'm trying to add the missing bridge decks to OGFX1 for the 2 haters
11:34:55 <_zephyris> ... but `make all` doesn't give an output which is recognised by openttd?
11:35:22 <_zephyris> First problem I'm getting is the python code to detect versioning, why's this (seemingly invalid) code used? `from datetime import date; print( (date(,,)-date(2000,1,1)).days)`
11:35:54 <_zephyris> But not sure why having a missing version/incorrect version would stop OGFX1 appearing in my baseset list at all?
12:15:17 <_glx_> xarick: Old version could do that too if sorter was in wrong direction
12:15:51 <_glx_> With the double Sort calls
12:17:38 <_glx_> xarick: Seeing this "huge" peak I guess you are using high ops per ticks value
12:18:42 <_glx_> But overall the game is still smooth
12:20:04 <xarick> const_iterator is driving me crazy
12:22:08 <xarick> if I do (for auto ...) it works
12:26:35 <xarick> oh, const iters can't be increased?
12:28:28 <xarick> or i do a sub_range which i dunno how
12:31:57 <_glx_> Your container is missing the operator
13:07:06 <Rubidium> also `const iterator` != `const_iterator`
13:23:27 <xarick> there's otviai dealing with rectangles
13:24:39 <xarick> this used to be one giant stall
13:45:12 <peter1138> What's on the agenda today...
13:46:20 <peter1138> That was last week.
14:04:22 <Rubidium> merge some (of your) approved reviews?
15:23:00 <_glx_> and of course windows is not happy
15:37:37 <peter1138> _zephyris, another week?
15:37:46 <talltyler> #14952 is a good fix that would be nice to have in the release.
15:39:17 <peter1138> It'a fix, just mark it backport-requested.
15:39:58 <talltyler> Yes, if we wait a week for RC4 the original author might finish it.
15:40:13 <talltyler> Or if we don't want to wait, I can finish it...but I like to avoid that for new contributors š
15:40:42 <_zephyris> Would indeed be nice
15:40:57 <_zephyris> Good fix, surprised I haven't noticed it before.
15:40:58 <Rubidium> so... what have we learnt of the 15 release? I reckon that betas are pointless
15:41:06 <peter1138> As long as RC3 isn't critically broken with anything new since RC2, it doesn't make sense to do another so soon :)
15:41:37 <peter1138> Possibly. Or we should have done week-by-week updates.
15:42:07 <talltyler> We learned that _zephyris should play OpenTTD more often š
15:42:10 <peter1138> Part of it is everyone is a bit scared to do it, until we've started doing it, then it becomes second nature.
15:43:09 <peter1138> _glx_, Windows got further this time. At least I know our resident benchmarked wasn't interested :)
15:49:43 <talltyler> That's the second German translation issue in 6 months, where we can't tell the reporter to join the translation team because it's full.
15:49:43 <talltyler> Why do we have limit on team size? Is it technical or social? Do we need to prune inactive translators?
15:50:25 <talltyler> I'm not a fan of pinging the most recent translator to ask them to make a change š
15:50:54 <talltyler> Release New Year's Eve, so it's still technically 2025 š
15:53:08 <_glx_> talltyler: team being full doesn't prevent requesting access
15:54:29 <peter1138> I think inheriting from std::allocator is probably not in the spirit of things.
15:54:59 <peter1138> And what I've added is mentioned in cppreference as the correct thing to do.
16:03:55 <talltyler> Okay, so thinking about password-less network games, the two main complaints I see are:
16:03:55 <talltyler> * I can't start a company and invite my friends when they're not online at the same time as me
16:03:55 <talltyler> * I can't start a company and allow anybody to join (public company)
16:03:55 <talltyler> I can only assume the second option is for private servers, where you trust everyone you've invited.
16:03:55 <talltyler> Has anyone else thought about these? Or should I just start a discussion to ~~gather thoughts~~ get forgotten about?
16:04:00 <peter1138> Should be okay to have a "purge" of translators who haven't contributed for a while, if we have that info?
16:04:44 <talltyler> The only way I know is to read eints commit descriptions, which seems a bit laborious
16:04:48 <_glx_> can be retrieved with parsing of eints commits
16:07:07 <mmtunligit> talltyler: i mean at least for the second point there, it seems like it probably wouldnt be too difficult to just add an option in company management that sets it as a public company
16:07:36 <rito12_51026> talltyler: No, the second option is widely used on PL server when an player is going offline and is not going to rejoin anymore in this session, so they set a password like `1234` and post it on the chat or in the company name.
16:08:14 <talltyler> Ah, so "feel free to take over my company"
16:08:25 <rito12_51026> What changed in takeovers between beta3 and RC3 ?
16:11:53 <mmtunligit> could also do something like generate a code for the company that can be used X number of times, and if you join the game with that code in a new field below the username itll auto join you to that company
16:12:19 <mmtunligit> and add you to list of approved members so you dont have to put it in every time
16:13:50 <talltyler> We have server invite codes, it would make sense to have the same for companies
16:14:20 <talltyler> But generated by OpenTTD, not a password so players can't put in their bank password š
16:16:35 <talltyler> I like limiting how many times it can be used, too
16:16:51 <mmtunligit> talltyler: you should be able to set it to unlimited as well
16:17:32 <mmtunligit> my inital concept was "discord server invites" but i dont know if everyone on IRC is familiar with how those work so i wrote it out instead
16:25:45 *** Wormnest has joined #openttd
16:27:11 <rito12_51026> kuhnovic: I have to disappoint you, I can crash RC3 this way but not beta3.
16:27:41 <LordAro> istr frosch having something to pull out translator activity, i think there was a purge a couple of years ago?
16:27:57 <LordAro> possibly of those that have never contributed?
16:29:24 <peter1138> Hmm, are there any other script containers that should be memory-tracked?
16:30:06 <_glx_> hmm but it seems to still report way lower than the real allocation
16:31:14 <peter1138> I don't know what that means.
16:31:17 <_glx_> first seems to be the map, and second looks like the set
16:32:48 <peter1138> Which is the value that the allocator is reporting?
16:34:37 <peter1138> Also, what is this "Array" type... seems bit of a pointless way to wrap a vector?
16:35:04 <peter1138> 100 bytes per item is kinda weird.
16:35:31 <peter1138> It's not a multiple of 8, which you'd expect if pointers are involved.
16:38:34 <peter1138> (otoh, Array can be tracked too)
16:39:39 <Rubidium> there might be a difference between the internal nodes and leafs in size, which added together gives you that number. Though exactly 100 bytes/item is kinda extremely lucky I'd say
17:07:32 <_glx_> using breakpoints I can see allocator called for map and set, but just the AddRectangle step shows a +50MB inside VS, while ingame tracking reports only half of that
17:08:07 <talltyler> Why can I not find where sea tiles destroy nearby desert...?
17:11:52 <Rubidium> for rivers look for TROPICZONE in water_cmd.cpp
17:12:24 <talltyler> I found rivers, it's just sea tiles that elude me
17:12:56 <talltyler> I worded it poorly, they don't destroy them when flooding. It's just during map generation that desert doesn't generate near sea.
17:13:37 <Rubidium> CreateDesertOrRainForest
17:14:30 <peter1138> _glx_, not sure how to get such data with clang.
17:14:39 <peter1138> Nemory profiling I suppose.
17:14:40 <talltyler> Ah, I made a silly mistake, `>` instead of `>=` when checking height š
17:16:48 <_glx_> haha I was doing it in debug build
17:16:52 <peter1138> _glx_, can you send me your script so I can have a play :)
17:17:14 <_glx_> in release the reported usage is the same as real increase I see in VS, so 25MB
17:17:44 <_glx_> MS std lib must do silly things in debug
17:19:43 <peter1138> It might be using a default allocator for its own internal debug tracking.
17:26:50 <_glx_> so yeah report seems pretty accurate
17:28:07 <_glx_> and as always testing with debug build is not the best idea for perf/memory usage
17:32:25 <peter1138> Hmm, is it actually working... :o
17:33:55 <peter1138> I guess when the script dies the ScriptList is freed.
17:34:04 <_glx_> the script pauses before AddRectangle and after it
17:34:46 <_glx_> so you can easily see the memory usage change in performance window
17:36:59 <_glx_> hmm but Break() handling requires ai_developer_tools
17:37:22 <peter1138> Yes, I did not have that enabled :)
17:38:09 <peter1138> Hmm, also on Steam I only have RC2... :o
17:38:45 <peter1138> Okay, I had to quit the other non-Steam game that was running through Steam.
17:38:48 <_glx_> adding a `while(true) Sleep(1);` at the end of `Start()` should work too
17:39:07 <peter1138> I even told it to switch from beta to 14.1 and back, and it still grabbed RC2 :o
17:40:33 <_glx_> I have RC3 in steam š
17:40:51 <peter1138> Yes, I do now, after making sure nothing else was running.
17:41:10 <_glx_> 1.16MB before, 1.16MB after in RC2 (expected)
17:43:03 <_glx_> 1.16MB, 24.9MB for the PR
17:43:16 <peter1138> With default memory limit, if I Xarick it on a 4kx4k map it gets killed. Nice.
17:43:29 <peter1138> Hangs a bit, needs your suspendable patch.
17:44:57 <peter1138> Cool. No magic numbers :)
17:46:25 <_glx_> hehe I was wondering why does it stalls, then I remembered the branch was from before suspendable
17:49:10 *** gelignite has joined #openttd
17:49:37 <xarick> I suspect RemoveTop is slower
17:50:12 <_glx_> it's suspendable now, so even if it's slower it should be fine
17:50:48 <xarick> testing the safe btree, but had to rebase-adapt to the new code
17:51:00 <xarick> had to initialize sorter and initialize values
17:51:20 <_glx_> all your tests will be slower since most of them will be suspended
17:52:18 <_glx_> so ops_limit/5 items per tick
17:53:04 <xarick> wondering what JGR will do
17:54:07 <xarick> oh, he already did some merges
17:54:31 <_glx_> but in the end, the final time should only increase a little
17:55:22 <_glx_> because speading a lot in a single tick vs using more shorter ticks should be kinda equivalent
17:58:25 <xarick> is it codestyle or performance, JGR?
17:59:01 <xarick> const auto item = iter->first;
18:01:13 <_glx_> yes it's not using range-for
18:02:15 <xarick> i want to make my branch of safe btree as close as possible to jgr's
18:02:43 <xarick> that's the branch that should be a verbatim copy of his
18:03:20 <xarick> even if sometimes it goes against my style... i need a base reference point
18:11:16 <xarick> ah, ValueChange, I don't use it
18:13:28 <peter1138> _glx_, should I rebase the PR?
18:19:35 <_glx_> I rebased locally, just to be able to see the memory usage rising in framerate window
18:20:06 <_glx_> and a steady 10/11 ms per tick
18:21:23 <_glx_> there's still a stall when the script dies (cleanup of the list)
18:24:06 <xarick> oh he got rid of ValueChange too
18:31:10 *** nucrow has quit IRC (Quit: User went offline on Discord a while ago)
18:33:25 <peter1138> _glx_, hmm, probably not much can be done about that.
18:33:51 <peter1138> Assuming it's the std::map and std::set clearing up internally.
18:34:01 <_glx_> yeah I think it's the set/map clear()
18:34:36 <_glx_> not really surprising with more than 300MB allocated for the list š
18:35:35 <xarick> it was worser with buckets
18:47:34 *** Flygon has quit IRC (Remote host closed the connection)
18:51:47 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
18:52:15 *** MinchinWeb[m] has joined #openttd
20:10:16 <xarick> if the script is told to save during valuate, what happens
20:11:04 <xarick> imagine it also saves the list it's currently valuating
20:32:55 <_glx_> it's the same as saving while you are filling the list manually in the script.
20:39:45 <peter1138> Should we support text lines longer than 32767 pixels?
20:58:48 <Rubidium> peter1138: probably not... it's not like changing the type is going to fix the underlying issue. It'll make it only harder to trigger, but they'll just try harder to trigger it :(
21:21:50 <xarick> JGR valuate trick is slower
21:23:49 <xarick> how do i store any type of stuff in std::optional
21:26:35 <xarick> `std::optional<void *> resume_item; ///< Item to use on valuation start.`
21:26:55 <xarick> then whoever uses resume_item decodes it to the real form
21:30:21 <_glx_> oh no wonder clearing map or set is slow, it has to clear nodes one by one
21:32:51 <_jgr_> Each node lives in its own malloc allocation, this is unavoidable really
21:33:27 <_glx_> yeah, the only way is to not use map or set
21:38:27 <Rubidium> well... technically your allocator could do its own memory management with larger/increasing allocation blocks and then you only need to release those. But that's just adding a lot of complexity. In theory you could make Clear also make do simple Remove so it becomes suspendable, but that won't really help with the garbage collection runs
21:49:13 <xarick> mr. copilot is telling me to use std::any instead of std::optional
21:50:19 <_glx_> suspendable Clear() is very easy to do, but indeed it won't solve the stalls when the script is not self clearing the list
21:50:52 <xarick> ~ScriptList calls the suspendable Clear ?
21:51:24 <_glx_> it's done outside the VM
21:54:24 <xarick> std::any is c++17 it seems
21:54:53 <_jgr_> I would strongly suggest that you don't bother with std::any
22:00:01 <xarick> `begin = list->items.lower_bound(std::any_cast<SQInteger>(this->resume_item));`
22:02:53 <_jgr_> This is vastly worse than just using std::optional
22:03:31 <andythenorth> don't trust the robots
22:04:04 <andythenorth> mine gave me 100 lines today of AST manipulation, for something that was a 15 line regexp
22:04:24 <andythenorth> readlines() vs computing the whole tree in a dir of python files
22:06:02 <xarick> it even has a has_value and a reset
22:06:23 <xarick> gonna see what's so bad about it
22:13:12 <xarick> well it compiled, but failed regression, so it's bad
22:25:53 <xarick> only json.hpp uses std::any
22:26:21 <xarick> is it really that bad?
22:28:33 <_jgr_> It is the wrong tool for the job you are trying to do
22:29:12 <_glx_> looks like a "less" safe version of std::variant for all types
22:32:23 <_glx_> hmm "safe" might be the wrong word, but validating the value type seems to be way harder than with variants
22:33:15 <xarick> i wanna store either a ScriptListMap::iterator, or a SQInteger, or a OrthogonalTileIterator
22:39:17 <xarick> gonna check performance
22:40:39 <peter1138> talltyler, good luck.
22:46:10 <talltyler> GitHub needs fewer buttons
22:47:19 <mmtunligit> what is "command line"
22:47:29 <mmtunligit> very difficult concept
22:57:19 <_glx_> haha and a merge on top
23:01:17 <xarick> didn't do RemoveItemTests yet
23:02:12 <xarick> probably the gain is due to avoiding lower_bound entirely
23:03:47 <xarick> I still kept JGR's begin trick
23:07:51 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:09:15 <_glx_> iter != begin is a simpler check š
23:10:46 <_jgr_> Saving a single lower_bound per resume doesn't seem like very much to me
23:26:07 <_glx_> it's just getting worse
23:26:53 <talltyler> I am trying to decide whether I try to explain interactive rebase or just open my own PR with a co-authored-by
23:27:27 <_glx_> interactive rebase when clearly everything editing is done via github ?
23:27:39 <talltyler> I want to support new contributors but damn, reading comprehension. I explicitly explained what not to do
23:27:52 <talltyler> Exactly, Iād have to explain the command line
23:28:19 <_glx_> and how to setup git too most likely
23:28:44 <_glx_> don't think they even have a compiler installed
23:29:35 <talltyler> Well, their original code only partly solved the issue, so I suspect it was not tested
continue to next day āµ
